Industry & Manufacturing

Usually, and where we cannot we say so rather than quoting for an integration that will not exist. Older controllers often expose more than people assume, through a serial port, a local file the machine writes, or an OPC server nobody has looked at. Where a line genuinely cannot talk to anything, the honest answer is a tablet in front of the operator, which costs a fraction of the alternative and gets you the reading.

No. Most of what a plant needs sits alongside the ERP rather than inside it, and finance should keep working in the system it knows. We build against your ERP, writing to it where it is the record of truth and reading from it everywhere else. Replacing an ERP is a programme in its own right and it should never be a side effect of wanting better shop floor reporting.

The data collection side does not: reading from a machine is passive and can be set up while the line runs. Where a change does need downtime, it goes into a window the plant agrees to, which in practice means a night or a Sunday, and it is rehearsed before it is done.

By keeping it apart from the office network, which is the single most valuable control in a factory. Old controllers cannot be patched and should never be reachable from a laptop that opens email. We segment the two, isolate what cannot be updated, and hold saved configurations for the equipment most likely to fail so a replacement is an afternoon rather than a week.

One line and one screen, which is usually the right answer rather than a compromise. Pick the line that matters most, get its output and downtime onto a display the shift can see, and let it prove the approach before it is repeated across the plant. That costs a fraction of a site wide programme and it produces the thing that actually decides whether this goes further: a few weeks of honest numbers from equipment your people recognise. Plants that start everywhere at once usually spend the first quarter on integration and have nothing on a screen to show for it, which is how these projects lose their sponsor.

Then it fails, and that is worth saying plainly because it is the most common way shop floor software dies. The defence is designing against the actual conditions rather than the specification: badge or card sign in rather than a password typed with gloves on, four or five reason codes rather than forty, targets big enough for a gloved hand, and readable under the lighting the plant genuinely has. The test is not whether it works in a demonstration. It is whether the data is still honest three weeks in, when the line is behind and nobody is watching. We check that with the supervisor, not with the sponsor.

Almost certainly not, and an MES you already run is usually the cheapest source of truth in the building rather than a competitor. The common situation is that it holds far more than anyone reads, because nothing was ever built on top of it and the reporting it ships with was designed for a different plant. We build against it, take what it already records, and add only the parts it genuinely does not do. Replacing an MES is a programme with its own budget and its own risk, and it should never happen as a side effect of wanting a downtime ranking.

Yes, and the work is joining records that already exist rather than creating new ones. Batch and serial history usually sits in three places: production knows what ran when, quality holds the inspection results, and dispatch knows where it went. Each is fine on its own and the join is what nobody built, which is why a recall question turns into three people and a filing cabinet. We connect those so the answer to which customers received material from this batch is a query. It is worth doing before you need it, because the week you need it is the worst week to start.