Making process knowledge institutional: how does the system learn what the operator knows?

Every plant has a layer of knowledge that appears in no document yet production genuinely depends on: which setting holds with which stock, which customer accepts which tolerance without complaint, which die sends the first ten impressions to scrap. As long as that knowledge sits in one person's memory, the plant runs on that person's calendar.

What happens when knowledge sits with a person

The symptoms are familiar. Setup times stretch when the experienced operator is on leave; a new hire has to learn the same job a second time; a customer-specific exception is missed because the person who knew it was not on shift. None of this is a software defect — but none of it is reportable either, because none of it is recorded.

The result usually shows up as cost, but its source is lost knowledge: doing the same job twice, finding the setting by trial and error, learning about an out-of-tolerance product from a customer complaint. Where those losses are booked is covered in detail in the article on invisible cost .

A plant's real system maturity is measured by how much it slows down when its most experienced person takes two weeks off.

Three layers: recipe, setup, exception

Treating process knowledge as one undivided mass inflates the project before it starts. Treating it as three layers clarifies the sequence; each layer is written down differently and lives in a different place.

The first layer already exists in most systems: the bill of materials and the routing definition. The second layer is usually missing — setup values are written in the notebook next to the machine, not into the system. The third layer is almost never written down, because an exception is by definition irregular.

Why the exception layer is the most valuable

A new employee learns the recipe in a day and approximates the setup within a week. The exception, however, is learned only by making a mistake — and the customer pays for that mistake. Starting the institutionalisation work with exceptions therefore removes the most risk for the least effort.

How to get it written down

The common approach is to sit down with experienced staff and write everything into a document. That approach nearly always stalls halfway, because knowledge is not recalled until it is asked for. The method that works is to collect it inside the flow of work.

1. 1Use the work order as the hook. Whoever sets the machine enters the parameters used when starting the job. The first entries will be incomplete; by the third month that product has a parameter history.
2. 2Treat deviation as an opportunity. When plan and actual diverge, capture the reason from a picklist. Over time that list becomes the plant's real catalogue of exceptions.
3. 3Turn quality outcomes into rules. When a customer complaint is closed, the rule that prevents its recurrence is defined on the same screen. The rule is attached to the product or the customer — never to a person.
4. 4Make approval mandatory, keep commentary optional. Approval should be mandatory at critical steps while the comment field stays optional. Mandatory free text produces a field that looks filled but is empty.

Recording that does not burden the operator

A recording system determines data quality through two things: how long entry takes and what the person entering gets back. If entry is slow, records are made late and in bulk; if there is nothing in return, records are made carelessly. When both are true you have data that cannot be trusted — the most expensive situation of all.

Our practical criterion is simple: one scan per movement. Material consumption by barcode, downtime reason in a single tap, quality result from predefined options. Mobile barcode and MES we build the screens to that criterion. On the return side it is enough for the operator to see the state of their own line: ahead of target or behind it.

How you measure it

“Institutionalisation” is an abstract word with measurable counterparts. The four indicators below show knowledge moving from people into the system. None of them requires new data collection; all come out of records you already keep.

• First-time-right setup rate. How many attempts it takes to reach target values at job start. It rises as parameter history accumulates.
• Handover effect. The deviation in setup time and scrap rate on shifts without the experienced operator. Institutionalisation narrows that gap.
• Share of “other”. The proportion of downtime and scrap records that fall into free text because no reason fits. A falling share shows the reason tree covers reality.
• Repeat complaint share. Customer complaints arriving a second time for the same cause. It declines as exception rules are written down.

You can see which screen we track these on at the executive dashboard .

Frequently asked questions

What if experienced operators do not want to put their knowledge into the system?

Resistance usually comes from added workload rather than fear of losing standing. When knowledge is requested as a separate documentation task, the resistance is justified. When it is collected inside the flow of work — by entering the value used while setting up — the added load is close to zero and resistance fades on its own.

How long does this work take?

If the recipe layer is already in place, the setup and exception layers usually need two to three months of production history to become meaningful. What determines the timeline is not the project plan but how often the item is produced: knowledge about a rarely produced item accumulates slowly.

We have written procedures — isn't that enough?

A procedure says what to do; process knowledge says which value holds under which condition. Neither replaces the other. Procedures belong to the quality system, process knowledge to the production record — and the latter stays current only when it is kept against the work order.