Skip to content
Software Architecture Guide

Process Automation Magnifies Efficiency

Explanation

Section titled “Explanation”

Automation does not judge a process. It repeats the process faster. If the process is sound, efficiency grows. If the process has waste, the same waste runs at higher speed.

Digitizing a flawed process does not fix it. It exposes and amplifies the flaws. A process should not be moved into a tool as it is.

The cow-path pitfall

Automating a broken process gets you to the wrong place faster. This is the “paving the cow paths” metaphor. Earlier technology waves, such as the personal computer and enterprise resource planning (ERP) systems, often did this. Teams put old paper forms on screens and digitized their filing cabinets without rethinking the work. The technology made the existing mess run faster.

Remove waste first

Business process reengineering made the same point. Its argument was that managers should remove work that adds no value instead of digitizing it. One well-known title put it as “Don’t Automate, Obliterate.”

Practical steps before automating:

  • Eliminate superfluous steps.
  • Clarify roles.
  • Build a model of the current (“as-is”) process. A detailed picture can reveal where to improve.
  • Sketch an ideal process model. See the articles AS-IS and TO-BE View and Process Analysis.

A streamlined process is also easier to digitalize.

Link to requirements

Requirements derived from current-state processes can lead to a solution that paves cow paths. The better focus is the target-state process. Process quality therefore shapes the requirements, and the requirements shape the solution.

Evidence from robotic process automation (RPA)

EY found that many early RPA projects fail. A common cause is that teams automate processes they do not fully understand.

Example

Section titled “Example”

A team is asked to build an app for approving purchase orders. The current process has five approval steps, and two of them only forward the request. Before coding, the team draws the as-is process and removes the two forwarding steps. It also names one owner per step. Then it builds the app for the shorter process. Without that review, the app would have carried the extra steps into software.

Trade-offs

Section titled “Trade-offs”

Analyzing and redesigning a process before automating takes time and delays the start of software work. In return, the team avoids building waste into a system. Redesign also needs people who understand the process, and an unclear process is a known cause of failed automation projects.

Improve the process first, then automate it.

Diagram source 
flowchart LR
  A[Existing process] --> B{Efficient?}
  B -- No --> C[Analyze and redesign]
  C --> D[Improved process]
  B -- Yes --> D
  D --> E[Automate]
  E --> F[Efficiency magnified]

Checks

Section titled “Checks”
  • The documented requirements come from the target-state process, not only from the current-state process.
  • Superfluous steps were removed and roles clarified before automation was planned.
  • An as-is process model exists and was reviewed for improvement opportunities.
  • The team can show that it fully understands each process it plans to automate.
Section titled “Related”

Sources

Section titled “Sources”