Operational Excellence Starts on the Floor and Survives in the System
Most writing on operational excellence agrees on the definition: continuously improve processes, remove waste, increase value for the customer. Nobody argues with that. Where it gets stuck is elsewhere: the improvement is made, and six months later the process is back to what it was. The reason is usually not the method — it is that the improvement has no counterpart in the system.
The Turkish Lean Institute’s guide to operational excellence sets the subject up correctly: leadership ownership, process mapping, empowering people to solve problems, tracking the right indicators, and turning all of it into culture. I agree, and I have no objection to add. What I want to add comes from the ERP and manufacturing floor: whether that transformation lasts is largely decided by the screen people open every day.
A small note: in capitals, OPEX (Operational Excellence) is a management approach; in mixed case, OpEx (operational expenditure) is a cost line. They get confused because both can come up in the same meeting. A well-run OPEX effort is expected to reduce OpEx — but they are not the same thing.
Why do the boards go up, and then come down?
There is a familiar cycle. Good work is done: the value stream is mapped, waste becomes visible, kaizen starts, a board goes up on the wall. Six months later the board is out of date, the A3s are in a folder, and the process has quietly gone back to what it was. Nobody acted in bad faith, and nobody argued against lean thinking.
The Shingo Institute’s model has a good explanation for this: purpose and systems drive behaviour. Systems are usually designed to produce a particular business result, without regard for the behaviour the system drives in people. And then behaviour is expected to change on its own.
In a manufacturing company, the ERP is one of the systems that drives behaviour most. Which screen the operator enters a record on, where the planner takes the list from, which code quality uses to book scrap, what the supervisor looks at during shift handover — all of that is behaviour, and all of it is shaped by the system. If an improvement never touches those screens, the only thing holding it up is people’s goodwill. The shift changes, and so does the goodwill.
Five places where it comes apart
1. Measurement lives in Excel. OEE, first-time-right, downtime — collected from forms filled in by hand, with someone sitting down at the weekend to build the table. A measurement that depends on one person, arrives late, and starts every meeting with “is this figure right?” cannot carry an improvement programme.
2. Standard work has no counterpart on the screen. A new standard is set and the instruction is posted, but the system still allows the old way — often makes it easier. People then start working outside the system. That is how shadow processes are born: one record in the system, a different flow in reality.
3. The improvement never becomes a rule. If “from now on we will check this” does not turn into a field, a requirement or an alert, then the decision lives in one person’s memory. When that person goes on leave, the improvement goes with them.
4. The data that measures the improvement is already wrong. Half the downtime is booked as “other”, scrap reasons all land on one code, and the lead time in the system has not been updated for years. Analysis on that data measures coding habits, not root causes. The job before kaizen is to fix the measurement.
5. Visibility arrives late. The problem happens on Thursday, the board is updated on Monday, the meeting is held on Wednesday. Lean’s “see the deviation immediately” and weekly reporting cannot sit in the same sentence.
Simplify first, or digitise first?
Bill Gates’ well-known rule settles half of this debate: automation applied to an efficient operation magnifies the efficiency, and automation applied to an inefficient operation magnifies the inefficiency. True. Digitise a bad process and you are left with a fast, expensive bad process.
But a wrong conclusion is drawn from the same sentence: “Let us become lean first and touch the system later.” In practice that “later” never arrives, because continuous improvement has no finish line by definition; hold the system back and you hold it back forever. The opposite trap exists too: “Let us install the ERP first and get lean afterwards.” Then today’s mess is cast into the system, and removing it becomes far more expensive.
The middle route that works ties the sequence to a small loop rather than a big programme:
- Improve on the floor. Remove a step, an approval, a movement. No software yet.
- Put the measurement of the new state into the system. Measure the record the system creates by itself, not a form filled in by hand.
- Bury the standard in the screen. Let the new rule become a field, a requirement, an alert or an approval flow.
- Move on to the next subject. One cell, one material group, one process. Not the whole plant.
When the third step is skipped, the fourth never happens: the first improvement did not survive, so the team does not believe in the second one.
What to measure
The classic lean indicators are sound: first-time-right, lead time, unit cost, complaints and recommendation scores, the number of suggestions actually implemented, OEE. I would add three more from the floor:
- Data quality itself. The percentage of downtime closed as “other”, the deviation between the lead time in the system and the actual one, the number of open orders never closed. These are the numbers that should fall before the improvement starts.
- Time to close a suggestion. The number of suggestions shows participation; the time to close them shows trust. A suggestion left unanswered blocks the next one.
- The Excel test. Is the planner or the supervisor re-entering data that already exists in the system? If so, the system is not carrying that work. (Opening Excel to try a scenario is one thing; retyping the data is another.)
One caution: always track a cost indicator together with a service indicator. An effort that chases inventory turns on its own can look “successful” while quietly breaking delivery.
Is it possible in a smaller company?
It is, and it often produces results faster: the decision path is short and there are fewer layers in between. But the obstacle is not resources, it is time. Nobody can step away from daily work; a three-month programme goes into the calendar and by the second week the day job takes over.
That is why, in a smaller company, starting operational excellence with a single subject and two hours a week is more realistic than setting up a full transformation programme. Once one cell, one product or one report shows a result, the rest follows on its own.
Waste in the office: double entry and waiting approvals
Waste in production is visible: the pallet waiting, the excess stock, the part coming back. Waste in the office is not. The same data keyed into two systems, a form waiting for a signature, an Excel file travelling as an e-mail attachment, a message asking whether something was approved yet.
The tool for improving this is usually not new software: it is setting up the existing system properly, making two systems talk to each other, and removing the unnecessary approval step altogether. The order matters — speeding up a step you have not removed makes that step permanent.
In closing
Software on its own neither simplifies nor breaks anything; it speeds up the process it is given. Whoever designs the process decides which direction that is. Operational excellence is therefore not a software project — and yet no improvement lasts when its measurement, its standard and its rule have no counterpart in the system.
For the definition, the list of methodologies and the indicator set, see the Operational Excellence (OPEX) field note.
Did the last improvement you made this month turn into a field, a rule or a report in the system? If not, it will most likely last until the next shift change.
Sources
- Yalın Enstitü (Turkish Lean Institute), Operasyonel Mükemmellik (OPEX) Nedir? Nasıl Elde Edilir? — definition, methodologies, the OPEX / OpEx distinction and the indicator list.
- Shingo Institute, The Shingo Model — the “Purpose and Systems Drive Behavior” insight.
- Lean Enterprise Institute, What is Lean? — the lean transformation framework built on purpose, process and people.
- Bill Gates, Business @ the Speed of Thought, 1999 — the rule on automation in efficient and inefficient operations.