Back to Insights

Article

Map the process before you automate it

Automating a workaround just makes it permanent. A short argument for documentation first.

John PereiraJohn Pereira · PresidentApril 2026
Map the process before you automate it

A customer asks us to automate order entry. We ask how an order gets entered today, and get three different answers from three people. One keys it from the email. One prints it, marks it up, and hands it to the first. One has a spreadsheet that nobody else knows about that fixes the part numbers first. All three are right. None of them is the process.

If we automate what the first person described, the spreadsheet step disappears and the part numbers start arriving wrong. We would have built a faster way to make the mistake.

Three people's versions of order entry above the real process underneath, with the just-to-be-sure steps highlighted Three honest descriptions of the same job, and the process that actually runs. The highlighted steps are the ones automation would have locked in.

Workarounds look like process

Every workaround started as a fix for something the system or the process did not handle. Over time the fix becomes the way it is done, and the original reason is forgotten. Automation is very good at locking that in. Once the workaround is in code, it has a cost to change and an owner who will defend it.

Mapping first is how you find them. Not a flowchart from the manager's memory, but a walk through the actual work with the people who do it, writing down every handoff, every lookup, every place someone checks something "just to be sure." The just-to-be-sure steps are the interesting ones. Each is a signal that something upstream is not trusted.

What a map gives you

  • The real sequence, including the parts nobody put in the procedure.
  • The decision points, where a human applies judgment the system could not. Some of those should stay human. Some are rules nobody wrote down.
  • The data that actually drives the step, which is often not the field the ERP thinks it is.
  • The owner of each step, which is how you find out that a process has three.

With that in hand, automation gets smaller and better. Half the steps turn out to be compensating for a bad default, a missing field, or a report that lies. Fix those and the remaining work is simple enough to automate well.

It is faster, not slower

The objection is always time. Mapping feels like delay. In practice a few days of walking the floor saves weeks of building the wrong thing, and the map becomes the documentation and training material you were going to need anyway. We do not start an automation project without one, and we hand the map over whether or not the automation happens.

More articles