This article is for plant managers, production managers, continuous improvement and operational excellence leads who are launching or relaunching a lean program, and who will have to say, a few months later, what it delivered. It covers a trap that rarely makes the lists, because it happens before the first kaizen event: starting without a reliable baseline for OEE, downtime and micro-stops. Without that starting point, the gain gets argued about instead of observed, and the program loses momentum.
- A lean program without a measured starting point cannot prove its gain.
- A baseline locks in an OEE figure, its calculation rules and its context.
- Measure before the first project, across all shifts, micro-stops included.
- Same instrument and same rules to the end, or the comparison fails.
The trap that happens before the first improvement project
Johnny Keire, managing director of Theos Consulting, a French lean management consultancy, published Obstacles et pièges dans l’implémentation Lean : comment les éviter (in French). He reviews cultural obstacles, method errors (focusing on tools such as 5S, VSM or Kanban without aligning strategy and objectives), management commitment, communication and team training, and finally KPI follow-up. On that last point he is blunt: “Mesurer les résultats est crucial pour ajuster les actions. Ne pas suivre de KPI permet aux problèmes de persister.” (in other words: measuring results is crucial to adjust actions, and not tracking KPIs lets problems persist).
His article provides the method for running the program. This one looks at what must exist before it starts: a measured starting point. A KPI tracked every week says nothing about the effect of lean if it has no pre-project reference, calculated with the same rules on the same scope. That reference, the baseline, is what proves the gain. And its absence is often why a well-launched program runs out of steam.
Why lean programs run out of steam after a few months
The pattern is familiar on the shop floor. In the first weeks, results are visible: tidy workstations, posted standards, start-of-shift meetings in place. Then the gains become harder to see, and management asks the awkward question: what did the program deliver, in production hours and good parts? If nobody can answer without a debate, the program loses its resources, then its champions.
Four causes come up again and again:
- No reference at all. Improvement projects started at the same time as tracking. The first figure measured already includes part of the program’s effect.
- A reference that is not comparable. Planned production time, reference rate or scope changed between the start and today. The two OEE figures do not describe the same thing.
- A change of measuring instrument midway. Manual end-of-shift logs mostly miss short stops. When you switch to automatic measurement in the middle of the program, micro-stops appear and OEE seems to drop while the shop floor is actually improving.
- A mix effect mistaken for a lean effect. A period of long runs on easy products lifts OEE without any project being responsible. The reverse discourages teams who did good work.
What an OEE baseline must lock in
A baseline is not a single number. It is an OEE figure together with the rules used to calculate it and the context in which it was measured. Use the following table as a checklist.
| Element | What you lock in | Why | Common trap |
|---|---|---|---|
| Scope | The machines or line concerned, starting with the bottleneck | The gain is judged on the equipment that limits flow | Measuring the whole shop floor and diluting the project’s effect |
| Calculation rules | Planned production time, reference rate, micro-stop threshold, definition of a good part | OEE can only be compared under identical rules | Using the usual rate instead of the nameplate rate, which flatters the starting point |
| Duration and coverage | All shifts, a representative product mix cycle | Smooth out differences between shifts and products | Measuring a quiet week and presenting it as normal |
| Breakdown | Availability, performance, quality | Know which loss the program must attack | Tracking an overall OEE that hides opposite trends |
| Downtime Pareto | Duration and frequency by cause, micro-stops included | Choose projects based on real losses | Keeping only long stops, the easiest to log |
| Context | Product mix, volumes, headcount, special events | Separate the program’s effect from the effect of context | Forgetting to note a low-load week or a product launch |
A step-by-step method to set the baseline before launch
Test the method on a pilot line before extending it to the rest of the shop floor.
- Choose the pilot scope. Ideally the bottleneck equipment on the line targeted by the first project. A narrow, well-measured scope is worth more than a whole shop floor measured badly.
- Write down the calculation rules and get them approved. Planned production time, reference rate (the nameplate rate, not the one you usually hold), micro-stop threshold, list of downtime reasons. One page is enough, approved by production and continuous improvement. These rules will not change during the program.
- Measure automatically, without changing anything. During the reference period you observe: no projects, no new instructions. The duration must cover all shifts and a representative product mix, for example a few weeks for a three-shift line running a short product cycle. Treat this as an order of magnitude to adjust to your plant.
- Break down and prioritize. Split the loss into availability, performance and quality, then build the downtime Pareto, micro-stops included. Projects are chosen on these losses, not on the lean tool the team knows best.
- Set the target in OEE points before launch. For example, a defined number of points to gain on the bottleneck within six months, with constant calculation rules. Management approves the target before the first project, not after the first results.
- Keep the same measurement during and after the program. Same instrument, same rules, same scope. If a rule has to change, recalculate the baseline with the new rule rather than comparing two incompatible figures.
Keeping momentum: let the curve speak during the program
The baseline proves the final gain, but it also keeps the pace. A short, regular review, for example every week in the performance meeting, compares the period’s OEE with the reference, component by component. Each project is linked to a loss in the initial Pareto: everyone knows what it should move, and checks that it does.
Plateaus can be read too. For example, a line whose availability improves while performance slips often points to micro-stops or a degraded rate that the current project does not address. Without the breakdown, that plateau looks like lean failing. With it, it points to the next project.
Finally, rolling out to other lines is decided on gains held over time, not on a peak. The same protocol then applies: baseline first, projects second. If the program relies on outside support, the data to gather before day one of the engagement is covered in our article Before hiring a lean consultant: 3 measurements to have in hand.
Where TEEPTRAK fits: one stable measurement from start to finish
TEEPTRAK measures OEE, downtime and micro-stops in real time. A module wired into the electrical cabinet and a sensor at the edge of the line take about one hour to install per machine, with no connection to the PLC, and OEE is available within 48 hours. The baseline can therefore be set before launch without an IT project, and the same measurement continues during and after the program, under the same rules. Every stop is timestamped with its duration and reason, micro-stops included. TEEPTRAK does not provide the lean method or the coaching: it provides the measurement used to judge the results. It is used in more than 700 plants in over 30 countries, with an average gain of 10 to 15 OEE points.
Further reading
- Obstacles et pièges dans l’implémentation Lean : comment les éviter (Johnny Keire, Theos Consulting, in French)
- Before hiring a lean consultant: 3 measurements to have in hand
- Performance tracking: 5 measurement pitfalls that distort decisions
FAQ
How long should the baseline measurement last? Long enough to cover all shifts and a product mix that represents normal activity. A measurement that is too short captures one unusual week, not how the line usually runs. It is better to delay the first project by a few weeks than to start without a comparable reference.
Can I use existing manual logs as a baseline? They give a first idea, but they usually underestimate short stops and micro-stops. If you later switch to automatic measurement, the comparison no longer holds. The rule: baseline and follow-up use the same instrument.
The program already started without a baseline. What now? Set a reference measurement now on a line where no project has started yet, or lock in the current state as a new starting point. You will not prove past gains, but you will measure the next ones without debate.
0 Comments