Did the improvement hold?
Most improvement work stops when the fix is agreed. The useful question comes weeks later.
Most improvement work I've seen, on production lines at Unilever, in launches at BAT and in operations teams since, is organised around the fix. Someone maps the process, someone finds the loss, a countermeasure is agreed, a task is closed. The dashboard turns green for a week.
The question that rarely gets the same attention comes later: did it hold?
Five tools, no thread
A typical improvement loop lives in five places. The process map sits in one tool, the data in a spreadsheet, the analysis in a slide deck, the actions in a task tracker, and the result, if anyone checks it, in a dashboard that knows nothing about the rest.
Each tool is fine on its own. The trouble is the gaps between them. The evidence doesn't travel with the finding, the finding doesn't travel with the decision, and by the time someone asks whether the fix worked, nobody can reconstruct why it was chosen.
Write down what you expect
A KPI tells you that a number moved. It can't tell you why, or whether your change is what moved it. A finding can: this station, this loss, this evidence, this cause. If you also write down what you expect the fix to do, you can check it later.
Checking is the work
That's what I'm building Vrolen around. It keeps the whole cycle in one place, from observation and evidence to the decision and the fix, and then checks whether the fix produced the expected result. If it did, the fix becomes the new standard. If it didn't, you find out while it's still cheap to change course.
Simulation helps in one narrow case: when a proposed change is worth testing on a model before anyone touches the real line.