Waste Diagnostic · System 03 · deciding what happens to each finding
Cut It or Fix It
You have a list of named patterns with numbers against them, and every one of them is annoying. Deciding what happens to each is a different judgment from the one that found them. Some of this work should stop entirely. Some of it has to keep happening and can be made much cheaper. Getting those two the wrong way round costs more than leaving the list alone.
The idea in one line: decide by what the step is for, then by what it would take to serve that purpose the cheapest reliable way. Automation is the fourth question on the list, and asking it first is how a business ends up paying every month to run a step nobody needed.
Each pile has a different goal
System 01 sorted the work by who each step is for. That sorting was never the point on its own. The point is that each pile has a different definition of success.
Almost every expensive mistake in this work is a goal applied to the wrong pile. Speeding up a step that should not exist buys you the same waste at a higher rate. Deleting a control because it was slow removes a requirement that will come back, usually at the worst possible moment and with somebody’s name attached to it.
Eliminate before you improve
There is an order to this, and it runs opposite to the order in which the options occur to people.
Automation sits fourth for reasons that have nothing to do with whether the tooling works. An automated step costs almost nothing per run, which means it stops being questioned: the cost disappears into a subscription and the step becomes permanent. Automating also freezes the current design in place, including the parts of it that were accidents, and it usually takes more work to build than the step would have taken to delete. A step you automate is a step you have decided to keep forever.
The honest exception is common enough to plan for. Sometimes a step cannot be eliminated yet, because the requirement is real, or a system you do not control forces it, or the person who would have to agree is not ready to. Automate it, and write down the one thing that would have to change for it to go away. That note is what stops a temporary accommodation becoming the permanent shape of the business.
How to challenge a required step safely
The middle pile is where most of the money is, and it is the pile people leave alone, because arguing with it sounds like arguing with compliance.
Split it in two, the way System 01 does. The objective is one thing and the execution is another, and only one of them was handed down by somebody with authority. “We must be able to prove this was approved” is an objective. “It is approved by three people in sequence over nine days” is a design decision somebody made once, probably under different conditions, and very likely nobody has looked at since.
Five levers change the execution and leave the objective exactly where it was.
Put a threshold on it
- Run the full control above a number and a sample below it. Most control regimes were designed for the largest case and then applied to every case.
Move it earlier
- Validate where the information is first entered, so the error never travels. A check at the end catches the same problem after everyone downstream has already handled it.
Collapse the approvals
- One accountable approver beats three consenting ones. Where several people sign, each of them is relying on the others having looked, which is how a serious control becomes a formality.
Take the evidence from the work
- Let the record be a by-product of doing the step rather than a separate act of documenting it. Most audit trails are re-typed versions of something the system already knows.
Change who does it
- A written delegated limit moves the decision to where the work is. The control is not weaker for being exercised by somebody closer to it, as long as the limit is explicit.
The one rule about all five
- Whoever carries the risk approves the new design in writing before it runs. A control redesigned by the people it inconvenienced, and never shown to the person accountable for it, is a finding of its own.
What a decision has to contain
A change nobody can check is a preference. Each finding leaves this stage with these lines against it.
Expect the work to move rather than disappear. Cutting a step releases whatever demand it was absorbing, and that demand goes somewhere, usually into the next queue along. This is why the measurement belongs on the whole flow from request to finished rather than on the step you changed. A step that got faster while the overall time stayed flat is a result worth knowing about, and it is invisible if you only measured the step.
Open ChatGPT, Claude, or whatever you use, and paste in your findings with their costs. Then send these four messages one after another in the same chat. The third one matters most: an assistant will agree with everything you want to cut unless you ask it to argue.
- “Here are my findings with their piles and their costs. For each one, propose the highest rung it could sit on: eliminate, reduce, simplify, automate, accept. Justify anything you put on automate by saying why the three above it fail.”
- “For everything I’ve marked as required, tell me which of the five levers could apply, and what would have to be true for it to be safe.”
- “Argue the other side. For each elimination, make the strongest case that the step exists for a reason I haven’t found yet, and tell me who I should ask.”
- “Write the reversal line for each decision: the specific result that should make me undo it.”
Which one to do first
Not the biggest. The first change is doing a job other than saving money, which is establishing that things here can change.
A good first cut
- Sits in the process pile, so nobody has to weigh a risk.
- Is owned by people who were in the room when you found it.
- Can be reversed inside a week if it goes badly.
- Produces a difference somebody notices without being told.
A bad first cut
- Needs a system change, a budget, or a vendor.
- Touches a control, so it needs a sign-off you don’t have yet.
- Depends on a team that has not heard of any of this.
- Pays back in a quarter, by which point nobody remembers it happened.
After that, go to the findings that traced back to the same upstream ambiguity in System 02. One clarified request or one named owner can take four entries off the list at once, and those are the cheapest wins available to you.
Leave the required-work redesigns until the habit exists. They are worth the most and they need somebody accountable to put their name on a new control, which takes longer to arrange than the work itself takes to do.
A worked example
The invoice approval from System 01, decided row by row.
One control kept and redesigned, one defect fixed at its source, three steps that stopped happening, and two weeks of elapsed time that mostly went away with the queue. None of it needed anything new to pay for.
Plenty of processes do end up needing software, and some need a hire or a different operating rhythm instead. The difference after this exercise is that you know precisely what the thing has to do, which steps it replaces, and what those steps were costing. That is a far better brief than “we need a system,” and it is the only version of the question where the answer can be judged afterwards.
Systems 01 to 03 are one method taken in three passes: sort the steps, name and size the patterns, decide what happens to each. The complete system assembles them into something you can run start to finish on a real process, with the evidence to collect first and a master prompt to paste into whatever assistant you already use.