The same problem gets solved at full cost every year because the fix and the finding end up in different places. The fix goes into the line, the schedule, the procedure. The finding, which is the expensive part, the three weeks and four people it took to work out why, goes into a slide, a folder, and somebody’s memory. Continuous improvement in manufacturing does not usually fail at the fixing. Most plants are good at fixing. It fails at the keeping, so the next crew on the next shift in the next building pays full price for an answer the operation already bought. I spend most of my time watching operations try to change how they work, which really means watching where the change stalls. Last spring I sat with a continuous improvement lead who had a binder of A3s going back four years. The one she was working on that week had almost the same title as one from two years earlier, written by an engineer who had since left. Same machine, same symptom, a different set of people rediscovering it. She was not sloppy. She was one of the best I have worked with. She had simply never been given a reason to look in a binder organized by project number for a problem that comes back attached to a machine. Why continuous improvement in manufacturing rediscovers its own answers None of what goes wrong here is about effort. The finding is filed by project. Improvement work gets stored under the initiative that produced it, with a date and a sponsor and a charter. Problems do not come back that way. They come back attached to an asset, a part number, a supplier lot, a recipe, a time of year. It gets filed one way and looked for another way, so nobody finds it. The finding has no trigger. A report does nothing on its own. It waits for someone to remember it exists and go get it. The person most likely to remember is the person who wrote it, which is exactly the person the operation is about to lose to a promotion, a night rotation, or a retirement. The dead ends are never written down. A large share of the cost of an investigation is the things that turned out not to be the cause. Almost nobody records those, so the next team spends the same two weeks eliminating the same candidates, and the record shows a clean two-week project rather than a repeat. What re-solving the same problem costs Put your own numbers into this. The sizes will be different in your plant. The pattern will not be. Say, for example, that your continuous improvement process closes forty projects a year. Say a third of them are re-solves of something the operation had already answered somewhere. That is roughly thirteen investigations, at whatever an investigation costs you in engineering hours, downtime, scrap and meeting time. Now say you keep half of what you learn instead of almost none of it. The re-solves do not disappear, but they get cheap. A second solve with the reasoning in hand is hours, not weeks, because you start where the last team finished instead of at the alarm. That is the whole argument for capture, and it is arithmetic rather than philosophy. An operation that keeps its findings is buying each answer once. An operation that keeps nothing pays for the same answer again every time it comes back. Both plants look equally busy. Only one of them is getting smarter. The gap grows without showing up in any report, which is why it rarely makes a business case. Nobody writes a variance report for the investigation you did not have to run. How to make a fix last after the person who made it leaves A captured learning is the fix plus the conditions that triggered it, the options ruled out, and a place to store it where the next person will find it without knowing it exists. This is the part you can do this week, with a spreadsheet and no budget. Five habits, in the order they matter. File it against the thing that recurs. The asset, the reason code, the part number, the supplier, the recipe, the step in the process. The project number is how you found it. It is not how it will come back. Write the trigger in two sentences. Under what conditions does this finding matter? “Seal rejects in bursts on the second pallet of a new supplier lot” is a trigger. “Filler performance improvement” is a title. Record what you ruled out. Four lines. The candidates that looked right and were not, and how you knew. This is the cheapest thing on the list and the most valuable to whoever comes next. Put it where people already work. A note attached to the reason code an operator picks at 2am beats a document library nobody has permission to search. If recovering the finding depends on somebody remembering to go looking, it depends on one person’s memory again. Check whether the problem came back. Ninety days out, ask whether the problem came back, and write the answer on the same record. Until somebody checks, you do not know whether the fix held. Then run the test. Take your last four closed improvement projects, hand them to somebody who joined this year, and give them ten minutes to tell you what was actually learned, without asking a colleague. Whatever they cannot recover is not filed. It is stored in the people who were in the room, and it leaves when they do. This is not a documentation chore, and it is not a wiki. Nobody needs a policy binder. What an operation needs is for the expensive part of last year’s work to be sitting where the next person will trip over it when the conditions line up. Where this stalls in real operations Capture is always the first step dropped when the line is down, and the line is always down. That is honest and it will not change, so the capture step has to be small enough to survive a bad day. Two sentences and a tag, written by the person who did the work, in the system they already have open. Anything that needs a meeting to complete will not get completed. An operation that keeps nothing is not holding steady. It is losing what it already learned, year after year, while paying full price for answers it already found. The knowledge is being produced either way. Every shift makes more of it. The only question is whether any of it gets written down before the people who have it move on. This week: Pull your last four closed improvement projects, hand them to someone who joined this year, and see how much of the reasoning they can recover in ten minutes without asking a colleague.