Here is an uncomfortable observation. Now that quality is being sold as an operating system, most plants will buy the screenshot instead. The ZEISS Factory of the Future coverage – quality as the new operating system of manufacturing – gets the diagnosis right, roughly two decades late, which is about the usual latency between software marketing and shop floors. My concern is the cure. I have stood in a plant where the entire escalation protocol was laminated A4 taped to a pillar, and it outran a competitor's €400,000 platform, because the paper knew who to call and the platform knew who to email. An operating system is not the interface. It is what happens when something goes wrong.

What an operating system actually does

A software engineer will tell you an operating system has almost nothing to do with the screen. It schedules – deciding which process gets processor time next. It handles interrupts: a signal arrives and a pre-written handler fires in microseconds, not minutes. It enforces privilege levels, so userland cannot write to kernel memory. And it kills runaway processes before they drag the whole machine down. Every one of those functions has a precise quality analogue:

  • Scheduling is triage. Which deviation gets your best engineer today, and which waits until Thursday.
  • Interrupt handlers are reaction plans. Written before the fault occurs, never during it.
  • Privilege levels are approval gates. Who may sign a deviation, who may accept a concession, who may stop the line.
  • Process termination is escalation. The kill path when a cell, a batch or a supplier goes rogue.

A dashboard is userland. It renders state. It does not arbitrate it. A platform that displays OEE beautifully but cannot answer "who decides in the next ten minutes" is a very expensive wallpaper engine.

The kernel shipped from the org chart, not the licence

When I built the QA/QC department for a greenfield plant of more than 900 people, we installed the kernel by hand, on paper, before a single software licence was bought. The escalation lattice came first: for every failure class, a threshold, a name, a response time and a back-up name – written, laminated, tested with live drills. QRQC sessions opened within hours of detection, timer running, owner named. The Q-Wall met daily at a fixed cadence and attendance was not optional. Reaction plans for the top twenty failure modes existed in advance, so the handler was written before the interrupt arrived. The approval gates were settled while the paint on the hall was still drying.

Only once that machinery ran did we buy software, and its job was to digitise a working system, not to invent one. The kernel, not the licences, delivered a 70% reduction in defect costs and 98% customer satisfaction. The software later made the system faster and prettier. It did not make it true.

Earlier, at Witte Automotive, I had run the same mechanisms – QRQC, A3, Q-Wall – against entrenched habits at an established plant, cutting failure costs the hard way, one reaction plan at a time. The greenfield proved what the brownfield suggested: the order of operations is the whole game. Mechanism first, tooling second. Reverse them and the tooling fossilises whatever dysfunction it finds.

Where the vendor stops and you start

Credit where due: vendors sell admirable things. Metrology, SPC engines, data models, traceability across the digital thread – ZEISS's instruments are superb. But no vendor can sell you three answers: whether a shift leader at 02:00 may stop the line when Cpk drifts below 1.33, what happens to a supplier who misses a third PPAP milestone, and who owns the kill decision on a suspect batch parked between two operations. Those answers ship from the org chart – job descriptions, delegation matrices, the reaction plans nobody demos from a stage.

Dashboards render the plant. The kernel – who decides, who reacts, who may stop the line – has never shipped in a box.

I build software myself, so this is not technophobia. My orchestration platform runs 63 AI models in parallel with consensus synthesis, and it has taught me one governing lesson: software orchestrates judgement, it never replaces it. Consensus among models is useful precisely because divergence forces arbitration by a human who owns the outcome. The same holds on a shop floor.

The industry press keeps documenting the same gap in different clothes. An EY survey found autonomous AI implementation outpacing oversight – a governance gap, in their wording. Analysts now urge firms to move AI governance to the point of action. On a production line the point of action has always been obvious: a reaction plan with a name, a threshold and a clock on it. If your quality platform arrives without those, you have bought autonomy without arbitration. That is not an operating system. It is an unmonitored process running with root privileges.

Key takeaways

  • Design the escalation lattice before the architecture: for every failure class, a threshold, an owner, a response time and a back-up – on paper, drilled.
  • Write reaction plans for your top failure modes before you need them. An operating system only handles the interrupts it has handlers for.
  • Run the cadence manually – QRQC within hours, Q-Wall daily – for at least a quarter before licensing anything. Software should digitise a working process, never invent one.
  • Put decision rights in job descriptions: who approves deviations, who accepts concessions, who can stop the line. If that lives only in the vendor's workflow configuration, it is not governance.

Before anyone signs, ask the audit question: if the vendor vanished tomorrow, would the system still run? If the answer is no – if escalation, reaction and the right to stop the line live inside someone else's stack – you have bought a dashboard and called it an operating system. The kernel is not for sale. It never was. Buy tools. Build operating systems.