Breaking a Process Into Steps a Machine Can Do

Write the process down first

Not the process as documented — the process as performed, from the person who performs it. Those differ more often than management expects.

Every step, including the checks nobody mentions and the exceptions everyone knows about.

Mark each step

1. Rule — a condition anyone could write down
2. Model — requires reading, understanding or judgement about language
3. Human — requires accountability, relationship or a decision with consequences

Most processes come out roughly 60% rule, 25% model, 15% human. The rules are cheaper, faster and more reliable, so automate them first.

Keep the model steps small

One model step should do one thing: classify, or extract, or draft. A single step asked to read, decide and write will fail in ways you cannot diagnose.

Small steps are individually testable, individually measurable and individually replaceable.

Design the exception path with the main path

• Where does an uncertain item go, and who sees it?
• How does a person send it back if it was wrongly routed?
• What happens if the destination system is unavailable?
• How does someone find an item that has stalled?

The exception path is where most of the operational pain lives and where most designs are thin.

Instrument every step

Count what enters and leaves each step, and how long it takes. That data is what tells you where the process is actually constrained once it is live.

It is a few hours of work and it is the difference between tuning from evidence and tuning from opinion.

Frequently asked questions