Cutting quality documentation from 6 hours a shift to 90 minutes

The situation#

Three plants, each with a MES, a process historian and a shared ERP. Plenty of data and almost no ability to ask a question that spanned two systems.

The blocker was mundane. The same press was Press 4 in the MES, PRS-004 in the maintenance spreadsheet and L2_PressB in the historian, and the mapping between them lived in the head of one engineer at each site.

Every cross-system question therefore became a manual spreadsheet exercise. Quality engineers wrote non-conformance documentation from scratch because pulling the supporting production context took longer than retyping it. Shift reports were compiled the following morning, partly from memory.

The group had been quoted for a predictive maintenance platform twice. Neither vendor had asked to see the maintenance data.

What we did#

Weeks 1–3 — reconciled asset identity. Tedious, unglamorous and the whole foundation. We built one asset register with a canonical identifier per machine, mapped every source system's local name onto it, and sat with the site engineers to resolve the cases the data could not settle. Roughly 4,200 assets across the three plants.

Weeks 4–6 — the modelled layer. Production, quality, maintenance and downtime ingested into one tested layer keyed on that register, with freshness alerting. Read-only from the OT side, isolated from control networks.

Weeks 7–9 — quality documentation. Non-conformance and inspection reports drafted from the structured record, with the production context already attached, for a quality engineer to review and sign. The reports that could not be drafted reliably were left manual rather than half-automated.

Weeks 10–11 — shift reporting and handover. Reports generated at shift end with variances flagged against plan, plus the runbook and the site-level ownership handover.

Read-only, and isolated#

We read from the OT systems and never write to them. The integration sits behind a one-way boundary from the control networks, and a fault in our layer cannot affect machine operation.

Anything that could influence machine behaviour was explicitly out of scope. That is safety-instrumented engineering, which is a different discipline with different obligations, and it was worth stating in writing at the start rather than fielding the question repeatedly.

What we would do differently#

We automated shift reporting before fixing downtime reason codes. Operators had been recording downtime reasons as free text for years, with the same cause written a dozen ways, and we generated the first month of reports against that.

The reports were precise, timely and subtly wrong — they under-counted the largest category because it was spelled four different ways. We caught it in week nine, agreed a controlled list with the site supervisors, and backfilled.

The sequencing error was ours. A controlled vocabulary should have gone in with the asset register in week three, because both are the same class of problem: the data is useless until everyone means the same thing by it. We now treat reason codes as part of the identity workstream rather than a reporting detail.

Where it went next#

The group moved to a support retainer covering the platform and the pipelines. Supplier quotation extraction went live at one plant six weeks later, reusing the extraction and review scaffolding from the quality work.

Predictive maintenance is now genuinely assessable for two asset classes where the structured history is deep enough. For the rest, the honest answer remains that there is not enough labelled failure data yet — which is a better position than starting there would have produced.