Do you need to map your processes before you automate them with AI?

Yes. Automating a process nobody has described speeds up the documented version while the real work carries on around it, and that is one of the commonest reasons AI projects stall. But the map you need is not the one in the process manual. It is the route the work actually takes: the phone call before the order is entered, the spreadsheet that reconciles two systems, the one person who has to approve. Map that, put a cost on each problem you find, and only then decide what to automate, what to redesign and what to leave alone.

Why does automating first go wrong?

Michael Hammer made the argument in 1990, in a Harvard Business Review article whose title is the whole case: Reengineering Work: Don't Automate, Obliterate (Hammer, 1990). Automating an existing process makes the old steps faster. It does not ask whether the steps should exist.

AI raises the stakes. An agent built from the documented process handles the documented cases. When the real process differs, and it usually does, the exceptions fall back to people, who soon start routing around the agent. MIT NANDA's 2025 study based on 150 interviews, a survey of 350 employees and 300 public deployments, found that about 5 per cent of generative AI pilots achieved rapid revenue acceleration while most stalled with little measurable effect on profit and loss. The cause, the report said, was not model quality but a "learning gap": tools that do not learn from or adapt to the way the organisation works (Fortune, 2025).

What should a process map show?

A process document describes the process somebody designed. The work follows the process that survived contact with customers, systems and staff turnover. The gap between the two is where the cost sits:

• Workarounds. A step the system cannot do, done by hand or in a spreadsheet.
• Handoffs. Work waiting for one person, often the only one who knows how.
• Rework. Things done twice because the first version was not trusted.
• Invisible steps. Phone calls, chats and side emails that never touch a system of record, so process mining, which reads system event logs, cannot see them (van der Aalst, 2016).

If you ask three people how a process works, you get three honest and different answers, because each sees one segment. Those contradictions are not noise to average away. They mark exactly where the documented process and the real one part.

How detailed does a process map need to be?

Detailed enough to answer three questions, and no more:

1. What actually happens, step by step, including the steps outside any system?
2. Where does the work wait, and on whom?
3. What does each problem cost today, in your people's hours?

A map that answers those is enough to decide. A map drawn to full notation standards that answers none of them looks thorough but will not help you decide.

Can I map processes myself, or do I need a consultant?

For one small process, yes. The standard BPM textbook sorts discovery methods into evidence-based methods (documents, observation, event logs), interviews with the people in the process, and workshops (Dumas, La Rosa, Mendling and Reijers, 2018). For a single process, the simplest version works: sit with the people who do it, follow a few real cases from start to finish, and write down what happens rather than what should happen. The method breaks down with scale. One person can hold a handful of good conversations a day, and the people chosen for interviews are rarely the ones who do the workaround. Across a company of a few hundred people, a handful of interviews will map the process management believes in. You need to hear from far more of the people doing the work, which is where outside help, or a tool that scales the conversations, earns its place.

What should you automate once the map exists?

• Automate the high-volume steps that follow rules most of the time.
• Redesign the steps that exist only because of an old limitation; do not automate them.
• Support, do not replace, the judgement calls: let AI prepare the case and a person decide. Leave alone the rare cases that cost little.
• Rank what remains by what it costs today, and build the top item first.

Our view

In our experience the map is the part that decides whether an AI project lands, and it is the part most budgets skip. We built Transcript for it: a private conversation with every person in the company, with follow-ups, that turns what people know into one picture of how the work really runs, with each problem counted in hours. Our engineers then build from that picture with the company's team. Whether you use us or not, do not fund an automation before someone has described the work it is meant to replace.

Questions people ask next

Why should I map a process before automating it?

Because automation copies the process it is given. If that process is the documented one, the automation will be exact and wrong, and people will work around it.

What is the difference between as-is and to-be process mapping?

As-is describes how the work runs today; to-be describes how it should run after the change. The to-be is where you decide what to automate, redesign or drop. A common failure is to skip the as-is, or to draw it from the manual instead of from the people doing the work, so the to-be fixes a process that does not exist.

What tools should I use for process mapping?

For drawing, a whiteboard or any BPMN tool will do. Process and task mining tools show the steps inside your systems. For the steps outside them, you still need to talk to the people who do the work, at enough scale to hear the workarounds.

How long does it take to map a business process?

One process with a few people: days. A whole company of a few hundred people by interviews and workshops: usually months. In our experience, private AI conversations held with everyone in parallel bring that down to weeks.

What business processes should you not automate?

Steps that exist only because of an old limitation (redesign or remove them), rare cases that cost little, and final decisions that depend on context, where AI should prepare the work and a person should decide.

References

• Wil M. P. van der Aalst, Process Mining: Data Science in Action, second edition, Springer (2016), https://link.springer.com/book/10.1007/978-3-662-49851-4
• Dumas, M., La Rosa, M., Mendling, J. and Reijers, H. A., Process Discovery, in Fundamentals of Business Process Management, second edition, Springer (2018), https://link.springer.com/chapter/10.1007/978-3-662-56509-4_5
• Michael Hammer, Reengineering Work: Don't Automate, Obliterate, Harvard Business Review, July to August 1990, https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate
• Sheryl Estrada, MIT report: 95% of generative AI pilots at companies are failing, Fortune, 18 August 2025, reporting on MIT NANDA, The GenAI Divide: State of AI in Business 2025 (2025), https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/