Every automation project I've seen fail had one thing in common: nobody mapped the process before touching software. The team jumped straight to "let's build a system for this," and six months later they had a fast, expensive way to do something that shouldn't have been done at all. Process mapping before automation is the cheapest insurance you can buy in a project, and it costs an afternoon, not a budget line.
The instinct to automate is usually right. The mistake is in the sequencing. If you automate a process that's full of workarounds, exceptions, and steps nobody remembers the reason for, you don't get a better process. You get the same mess, just faster and harder to change, because now it's encoded in software instead of a person's habits.
I've watched a retail chain in Tangerang spend real money building an approval workflow app that faithfully reproduced a four-signature purchase order process. Nobody had asked why it needed four signatures. Turns out it was a fraud-prevention rule from a single incident eight years earlier, and three of the four approvers just rubber-stamped everything without reading. The software made the rubber-stamping instant. That's not efficiency, that's expensive theater.
"That's not efficiency, that's expensive theater."
Ervandra Halim, technology consultant for operations-heavy businesses
Why does mapping come first?
Mapping comes first because a process map forces you to see the workflow as steps, handoffs, and waits, rather than as "how we've always done it." Once it's on paper, or a wall of sticky notes, patterns jump out that are invisible when the process only lives in people's heads:
- Steps that exist because of one bad incident years ago, never revisited
- Approvals that add a wait but no actual decision
- Data entered twice into two systems because nobody connected them
- Handoffs where one person waits on another for information that could be provided upfront
None of this requires a consultant or a fancy tool. It requires writing the actual steps down and asking, out loud, in a room with the people who do the work, "why does this step exist?"
The afternoon method
This is the version I actually use with clients, and it fits in a half-day session with the team that runs the process, not just their managers.
- List every step in order. Sticky notes, a whiteboard, or a shared doc. One step per note. Don't skip steps because they feel "obvious."
- Mark who does each step and who they wait on. Draw an arrow from step to step showing handoffs. This is where you see queues and dead time.
- Circle any step that exists only because of a past mistake or a since-departed manager's preference. Ask the room directly: does anyone know why this step exists? Silence is a signal.
- Time-stamp the waits, not just the work. Most process pain isn't the work itself, it's the waiting between steps. A form that takes five minutes to fill out but sits for three days waiting for a signature is a three-day process, not a five-minute one.
- Delete before you digitize. For every circled step, decide: kill it, merge it, or keep it with a documented reason. Only after this pass do you decide what to automate.
In my experience, this exercise removes 25-35% of steps before any code is written. That's not a rounding error. That's a third of your future software budget you just saved, because you're no longer paying to speed up work that shouldn't exist.
What does this look like in a real workflow?
Purchase requests at a mid-size distributor make a good real-world example of what a mapped process actually reveals. The unmapped version looks simple in someone's head: "employee requests, manager approves, purchasing buys." Mapped honestly, with every handoff and wait made visible, it often looks like this instead:
| Step | Who | Wait | Reason it exists |
|---|---|---|---|
| Fill paper form | Requester | none | Legacy from pre-email era |
| Walk form to manager | Requester | hours-days | No digital routing |
| Manager approves | Manager | days (in meetings) | Genuine judgment call |
| Re-key into purchasing system | Admin | days (backlog) | Systems never connected |
| Second approval over 5M IDR | Finance | days | Real control, rarely triggered |
| Purchase placed | Purchasing | - | The actual work |
Once mapped, it's obvious the re-keying step is the real automation target, and the "walk form to manager" step just needs a phone or web form, not an app. This is the same discipline covered in Automating Repetitive Back Office Tasks: Where to Start: find the step that's pure friction before you build anything.
How do you know when you're ready to automate?
The map's cleanliness is the signal: once it's clean, the automation conversation changes completely. Instead of "build us a system like our current process," it becomes "here are the three steps that actually need software, and here's the data that has to flow between them." That's a scoped, buildable, and honestly a much cheaper project. Vendors quote faster and more accurately against a clean process than a messy one, because there's less ambiguity to price in as risk.
This also protects you from a specific trap: legacy processes that were themselves built around old, limited software. If you're mapping a workflow that already runs through a system your team has outgrown, the mapping exercise will surface that too, and it's worth reading The Hidden Cost of Legacy Systems in Your Business alongside it.
The takeaway
Don't buy or build automation software until you've mapped the process on paper and killed the steps that don't earn their place. An afternoon with sticky notes and the people who actually do the work will save you months of expensive rework and a system that just does the wrong thing faster. If you want a second pair of eyes on a process before you commit budget to automating it, that's exactly the kind of conversation worth having early, not after the invoice.
