Liquid ResearchNo. 02Automation

Automation Before Standardization Is Just Faster Chaos

Sequencing matters more than tooling when work becomes automated.

By Alenn RebolledoFebruary 24, 202612 min readHuman + Machine

Automation is often introduced as a fix for inconsistency. It is closer to a multiplier of it. Whatever the process currently does — including the parts nobody agrees on — happens more often, faster, and with less visibility once it is automated.

Four states of work

Figure 1

Figure 1 — states of a business process

StateDescriptionReady to automate?
ManualPerformed from memory, varies by personNo
StandardizedWritten, owned, repeatableYes, in part
AutomatedExecuted by software with defined inputsMaintain
VisibleMeasured, exceptions surfacedTarget state

The useful move is rarely manual to automated. It is manual to standardized, then a narrow slice of the standardized work to automated, then visible.

A readiness test

  1. Can one person describe the process in writing in under a page?
  2. Does the process have a named owner?
  3. Are the inputs consistent enough to define rules?
  4. Is the failure mode acceptable when it runs unattended?
  5. Would we still want this outcome if it happened fifty times a day?

Variation compounds when it runs unattended

A manual process with a five percent error rate produces a handful of problems a week, and a person usually catches them. The same process automated at fifty runs a day produces the same rate against a much larger base, with nobody watching the intermediate steps.

Figure 2

Defects per month at a 5% error rate, by run volume

20 runs/month (manual)

1 defects

200 runs/month

10 defects

1,000 runs/month (automated)

50 defects

1,000 runs/month at a 1% rate

10 defects

The error rate does not change. Only exposure does. Standardization lowers the rate; automation raises the base.

Source: Liquid analysis — arithmetic on a stated error rate, not measured client data

The last two bars are the whole argument for sequencing. Reducing the error rate before scaling volume produces a fifth of the defects at the same throughput — and the work that reduces the rate is standardization, not tooling.

The cost of unwinding it later

Figure 3

What changes when a process is automated before it is defined

DimensionBefore automationAfter automation
Who can explain itThe person doing itWhoever configured it, if still employed
Cost of a changeA conversationA rebuild and a regression risk
Visibility of failureImmediate and localDelayed and aggregate
AccountabilityNamed personDiffused into the tool
Vendor dependencyNoneStructural

What should stay human

  • Judgment about exceptions and edge cases
  • Pricing and negotiation
  • Relationship and escalation moments
  • Anything where being wrong is expensive and hard to detect

Automate the repetition. Keep the judgment.

Done in the right order, automation removes administrative drag without removing accountability. Done in the wrong order, it produces a system nobody can explain and nobody owns.

References

  1. 01Walter A. Shewhart / W. Edwards Deming. Statistical process control — common and special cause variation (overview). https://en.wikipedia.org/wiki/Statistical_process_control
  2. 02Toyota Production System. Standardized work as a precondition for improvement (overview). https://en.wikipedia.org/wiki/Toyota_Production_System

Author

AR

Alenn Rebolledo

Founder

Alenn founded Liquid after working across startups, technology, analytics, operations, and marketing strategy. His research focuses on where growth is actually constrained and how operating systems change business outcomes.

Strategy · Systems · Growth · Decision Intelligence

Related services

Have a similar problem?

Bring the specifics. We will tell you where the constraint sits.

Related Research

StrategyNo. 01

The Constraint Is Usually Somewhere Else

Most growth programs begin where attention is loudest rather than where throughput is limited. A short method for locating the binding constraint before spending against it.

The Constraint Series

Alenn Rebolledo · February 10, 2026 · 13 min read
SystemsNo. 04

More Software Is Rarely the Answer

Tool sprawl is usually a symptom of undefined ownership. A framework for deciding whether a problem needs a purchase, a connection, or a decision.

The Operating System Series

Alenn Rebolledo · March 24, 2026 · 6 min read