In brief
- Automating a confused process produces faster confusion.
- Map the process as it really runs, including spreadsheets, phone calls and workarounds.
- Remove and simplify steps before automating any of them.
- Choose the simplest technology that supports the redesigned process, and measure against the old baseline.
Many technology projects begin with a solution. An organisation hears about a new platform, an AI tool or an automation product and starts looking for places to apply it. Months later, the tool is installed, the old problems are still there, and staff have built a new set of workarounds around the new system.
Over years of building software for distributors, clinics, restaurants, schools and larger organisations, I have come to rely on a low-technology first step that prevents much of this. Before automating anything, draw the process on paper, with the people who do the work.
Why the process comes first
Every organisation has two processes for any piece of work. There is the official one, described in a manual or in the head of a manager. And there is the real one, which includes the extra phone call to confirm an order, the spreadsheet someone keeps on the side, and the step everyone skips because it never made sense.
Software built around the official process will fail where the real process differs. Automation applied to the real process without examining it will faithfully speed up its flaws. In both cases the technology is blamed for a problem that was never technical.
Step one: map the real process
Gather the people who actually do the work, not only their managers. Use a wall, a whiteboard or large sheets of paper. Walk through one real example from start to finish, and draw each step as it happens.
For each step, note:
- Who does it.
- What information they need, and where they get it.
- What they produce, and who receives it.
- How long it usually takes, and how long it waits before the next step.
- What goes wrong, and how people handle it.
Then walk through an unusual example: a returned order, a patient who changes an appointment twice, a fee paid in instalments. The exceptions reveal the real process far better than the routine case.
The most useful question
"What do you do when the system does not let you do what you need?" The answers show where the true process lives.
Step two: find the friction
Once the map exists, look for the places where time, money or goodwill are lost. Common patterns include:
- Re-entry: the same information typed into two or three places.
- Waiting: work sitting idle while it waits for an approval or a missing detail.
- Rework: errors discovered late and corrected by going back several steps.
- Hand-off confusion: nobody sure who owns the next step.
- Hidden tools: personal spreadsheets or notebooks that the organisation depends on without knowing it.
Mark each one on the map. It helps to estimate, even roughly, how often it happens and what it costs. That estimate becomes the baseline for judging any change.
Step three: redesign before automating
This is the step most often skipped, and the most valuable. Ask of every step:
- Can it be removed entirely?
- Can it be combined with another step?
- Can it be moved earlier, so errors are caught at the source?
- Can it be simplified, with fewer choices or a clearer rule?
Only after that should you ask whether a step can be automated. A surprising amount of improvement usually comes from the first four questions, at almost no cost.
Redesign with the team, not for it. People adopt changes they helped shape. They also know which "obvious" simplifications will break something.
Step four: choose the simplest technology that works
With a redesigned process in hand, the technology question becomes much clearer. Match each need to the least complex tool that meets it.
| Need | Often enough | Consider more only if |
|---|---|---|
| Stop re-entering data | A shared system or a simple integration | Volumes are high or systems cannot connect |
| Enforce a clear rule | A workflow with validation | Rules change frequently or have many exceptions |
| Read and classify documents | Templates and structured forms | Documents vary widely in format |
| Draft responses or summaries | Standard templates | Content varies and review is practical |
| Multi-step coordination | A checklist and clear ownership | Steps are frequent, tedious and well understood |
AI becomes the right choice where tasks involve reading, interpreting or drafting at a volume and variety that rules cannot handle, and where a person can review the output. For multi-step work, I have described how to set sensible limits in Where AI Agents Help, and Where They Should Stop.
Step five: measure against the old baseline
After the change, return to the estimates from step two. Is re-entry gone? Is waiting shorter? Are errors caught earlier? Compare with the baseline, not with the promises made during the project.
Keep the paper map. Update it when the process changes. It becomes one of the most useful documents an organisation owns, and a far better starting point for the next improvement than a vendor brochure.
What this looks like in small organisations
Small businesses and clinics sometimes assume process mapping is a large company exercise. The opposite is true. In a small organisation, a two-hour session with three or four people can map the core processes completely, and the improvements show up within weeks.
The method needs no special software, no consultant's framework and no budget. It needs honesty about how work really happens, and the patience to understand a problem before buying a solution.
Questions
Frequently asked questions
What is process mapping?
Process mapping is the practice of drawing the steps of a piece of work from start to finish, including who does each step, what information moves between steps, how long each takes and where problems occur. It is used to understand and improve processes before changing systems.
Why do digital transformation projects fail?
Common reasons include automating a process that was never understood or redesigned, choosing technology before defining the problem, excluding the people who do the work from decisions, and measuring success by installation rather than by improvement against a baseline.
