Guide · Foundational
Before You Automate a Process, Prove You Understand It
A repeatable process is not necessarily a understood process. Faster execution can make an untested assumption more expensive.
Remove, simplify and establish meaning before choosing technology.
Five accounts of the same work
Management may believe an order is ready once sales approves it. The procedure may say engineering must confirm the specification. The CRM may record the sales approval as “complete”. A planner may know that the actual trigger is a revised spreadsheet arriving by email. All four accounts can be locally reasonable while describing different boundaries.
The fifth account is what can be verified: the particular order, its timestamps, the specification used, the acceptance event and the people who handled it. That evidence does not automatically make every system record correct. It gives you a way to test the competing claims rather than choosing the most polished diagram.
Follow a case, not an ideal path
Choose a recent example and reconstruct its journey. Ask the people involved to show the records they used, the decisions they made and the messages they sent. Include a normal case, a difficult case and one that was abandoned or returned. This is a starting sample, not evidence that every case behaves the same way.
Pay particular attention to waiting, copying, informal approval and recovery. These are often absent from a procedure because they happen between its named steps. An employee who checks an inbox several times a day may be compensating for a missing notification. Automating the inbox check preserves that workaround; establishing a reliable event may remove the need for it.
Make assumptions inspectable
Write down the claims your design depends on. “Every approved order has a valid customer ID” is a testable statement. “The data is good enough” is not. For each claim, identify the source, a check, the known exceptions and the consequence of being wrong. Keep the unsupported parts visible.
Distinguish observation from interpretation. A two-day gap between timestamps may indicate waiting, batch processing or simply an event that was recorded late. The log alone may not tell you which. Interview evidence can help, but recollection also has limits. Where accounts disagree, investigate the disagreement instead of averaging it away.
The intervention sequence
REMOVE work that serves no necessary purpose. SIMPLIFY what remains. STANDARDISE where variation adds no value, while preserving legitimate differences. INTEGRATE where reliable exchange can remove a manual bridge. AUTOMATE where a known rule and correct result can be specified. APPLY AI where interpretation or unstructured information genuinely matters.
This is a reasoning sequence, not a rigid delivery plan. A safety requirement may make removal inappropriate. Integration may require an identity decision first. AI may help organise interview notes early, without being trusted to decide the operating model. The point is to justify the intervention rather than beginning with a favourite tool.
Prove the changed process too
A successful test run does not establish that the intervention works under operational conditions. Define the expected outcome, failure cases, owner and evidence before release. Check whether the new process removes work or merely shifts it to another team. Review exceptions and preserve a route for people to challenge the design.
For the order example, the useful outcome might be that planning receives a complete, accepted specification without manual chasing. Counting automated emails would not prove that. Examine whether the receiving team can act, whether rejected items remain visible and whether the work still succeeds when the original expert is absent. Technology earns its place through that operational evidence.
Questions worth asking
- Which step exists only because an earlier step is unreliable?
- What evidence would disprove our current account of this process?
- What should happen when the standard path cannot be followed?
Foundational explanation and illustrative examples. This article does not report findings from client engagements or establish a pattern in your organisation.