Question 07 · Operations

Are our processes stable and repeatable enough to automate?

Why it matters

People absorb variation. They re-tape a carton, read a damaged label, or walk around a blocked aisle. Automation performs a defined process and stops, or errs, when conditions fall outside it.

The question is whether the process, as it is performed today, is consistent enough to be defined.

What can go wrong

  • The documented process and the performed process differ, and the automation is designed for the documented one.
  • Exceptions that staff handle informally become stoppages that need a person each time.
  • Inbound product arrives with inconsistent labels, pallet quality, or packaging.
  • Upstream and downstream steps cannot keep pace, so the automated step starves or blocks.
  • When the system is down, there is no practiced manual procedure to keep orders moving.

What evidence to examine

Evidence What it can establish
Process maps drawn from observation How the work is performed, as opposed to how it is written
Exception logs and rates by type How often the process leaves its standard path, and why
Throughput data by hour and shift Variability the automation must handle
Inbound quality records: labels, pallets, packaging Whether incoming material is consistent enough to handle automatically
Counts of manual interventions and touches Hidden work that the process depends on
Downtime and fallback procedures Whether operations can continue during an outage
Standard operating procedures compared with observed practice The gap between the designed process and the real one

Warning signs

  • Exception rates are not measured.
  • Performance depends on a few experienced people who “know how it works.”
  • The same process is performed differently on each shift.
  • Supplier adherence to labeling and packaging requirements is not tracked.

What to do next

  1. Observe the process on more than one shift and map what happens.
  2. Measure exceptions for a defined period and group them by cause.
  3. Stabilize the highest-volume exceptions, and write the fallback procedure, before automating.

Automating an unstable process can make its problems harder and more expensive to manage.