Map the Process Before You Buy the Software: Delete Before You Digitise
Before you buy or build software for a process, map the process as it actually runs, not as the policy manual describes it. Gather the people who do the work, walk one real recent case from start to finish, and draw every step, handoff, wait, decision and workaround. Then simplify it: delete steps, combine them, move decisions closer to the work. Only then decide what software needs to do.
Half a day with a whiteboard usually shows that part of the problem is not software at all. The rest becomes a much smaller, clearer brief, which is cheaper to quote and harder to get wrong.
The short answer
- Map one process with a clear start and end, such as “customer order to payment received”.
- Map it with the people who do the work, using a real case, not the official version.
- Mark four things: handoffs, waits, re-typing and workarounds. That is where the cost hides.
- Simplify before you automate. Every step you remove is one nobody pays to build or maintain.
- The simplified map becomes the brief: what the system must do, for whom, and what it replaces.
Why the map comes first
Software copies whatever you give it. Automate a process with five approvals and three re-typed spreadsheets, and you get five approvals and three re-typed screens, faster and harder to change.
Michael Hammer made the argument in the Harvard Business Review in 1990, under a title that still summarises it: “Reengineering Work: Don’t Automate, Obliterate”. His target was large companies spending heavily on technology that sped up processes nobody had questioned. The same thing happens at a smaller scale in every business that buys a system to fix a process it has never looked at.
Abdulqader Wahiba, founder and CEO of ZAWAT, reduces the principle to four words: delete before you digitise.
“Every step you automate is a step you will maintain for years. If it can be deleted, delete it first. The cheapest feature is the one you never had to build.” — Abdulqader Wahiba
The method, step by step
1. Pick one process with a clear start and end
“Sales” is too big. “From a customer’s order to the payment being received” is the right size. Name the trigger that starts it and the result that ends it. If you are not sure where to begin, choose the process that generates the most complaints, or the one that depends on a single person.
2. Put the right people in the room
Invite the people who actually do each step: the salesperson, the storekeeper, the driver, the accountant. Managers know the official process. Staff know the real one, including the workaround someone invented three years ago that everything now depends on. Two to three hours is enough for one process.
3. Walk a real case, not the policy
Take an actual order from last week and follow it. Who received it? Where was it written down? Who typed it again? What happened when an item was out of stock? Real cases surface the exceptions, and exceptions are where systems succeed or fail.
4. Draw it in lanes
Give each role its own horizontal lane. Put each step in a box in the lane of whoever does it. Arrows between lanes are handoffs. Sticky notes on a wall work as well as any software, and they are easier to move while people argue.
5. Mark the four places where cost hides
- Handoffs. Every arrow between lanes is a chance for something to wait or get lost.
- Waits. Where does work sit idle? Waiting for an approval, a signature, a reply on WhatsApp?
- Re-typing. Any time the same information is entered twice, by hand, into a different place.
- Workarounds. The private spreadsheet, the phone call that “always” happens, the step only one person knows.
6. Put rough numbers on it
How often does this process run each week? How long does each case take from start to end, and how much of that is waiting? How many cases go wrong each month? Rough counts are enough. They tell you where the time goes and give you a baseline to measure the new process against.
7. Simplify before you design anything
Go through the map with five questions:
- Can we delete this step? Ask who uses its output. If nobody does, stop doing it.
- Can we combine steps? Two people checking the same thing in sequence is often one check.
- Can the decision move closer to the work? An approval that waits for the general manager might belong with the branch manager below a set amount.
- Can we standardise it? Five ways of writing a customer’s name become one.
- Can the information be captured once? If it is typed at the start, nobody should type it again.
8. Draw the new map, and only then talk about software
The simplified map shows what the system must do: which steps it supports, who uses it, what information it captures once and passes on, and which spreadsheets and chat groups it replaces. That is the core of a brief. Writing requirements with user stories turns it into something a developer can quote.
An example: order to cash at a distributor
Take a typical order-to-cash process at a Muscat distributor with three branches. This is an illustration of the pattern, not a client case.
A customer sends an order by WhatsApp. The salesperson types it into a spreadsheet, then phones the warehouse to check stock. The storekeeper prints a picking list. The driver delivers and brings back a signed paper note. The accountant types the invoice into the accounting system, and someone chases payment by phone.
The map shows the same order typed three times, two phone calls to check things a system could show, and a paper note that waits days to reach the accountant. Before any software, the business can agree one order format and send signed delivery notes the same day. After that, the system it needs is clear and much smaller: orders captured once, stock visible to sales, invoices raised from the delivery record. That may be an integration between existing tools, not a new system; how system integration actually works explains the difference.
Five mistakes that spoil a process map
- Mapping the official process. If the map matches the policy manual, nobody told you the truth.
- Only managers in the room. You will get the process as it was designed, not as it runs.
- Mapping everything at once. One process per session. A map of the whole company is a poster, not a tool.
- Jumping to solutions. “We need an app” in the first hour ends the honest part of the conversation.
- Polishing the notation. Formal diagram standards exist, and analysts use them, but a clear sketch everyone understands beats a correct diagram nobody reads.
What the map tells you to do next
A finished map usually points to one of three outcomes. The fix is a change in how people work, with no software at all. A standard product fits the simplified process, and which business system you need helps you choose it. Or the process is distinctive enough to justify custom software, in which case the map has already done much of the first week of a discovery phase.
Frequently asked questions
How long does it take to map a process? For one process of moderate size, two to three hours with the right people, plus time to tidy the map and gather rough numbers. Mapping is fast; agreeing the simplified version can take longer.
Do I need special software or a consultant? No. A wall, sticky notes and the people who do the work are enough for a first map. Outside help is useful when departments disagree or when nobody can challenge a step without politics getting in the way.
What is a swimlane diagram? A process map with one horizontal lane per role or department. Each step sits in the lane of whoever performs it, so handoffs between people become visible as arrows crossing lanes.
What if staff are defensive about their workarounds? Treat workarounds as evidence that the official process failed them, not as rule-breaking. The person who built the private spreadsheet usually understands the real requirement better than anyone.
Should the process change before or after the new system? Before, wherever you can. Changing the process first is cheaper, and it means the system is built for the way you intend to work rather than the way you used to.
Want a second pair of eyes on your process before you buy anything? ZAWAT maps the work first and builds only what the simplified process needs, from business systems to integrations. Book a call.