Business Process Mapping Before You Buy Anything: The Map That Decides the Software.
Most software is bought to fix a process nobody has drawn. The symptom is real: orders re-keyed, quotes that do not match invoices, a month-end that takes three weeks. The purchase is a guess about which process produces the symptom, made from a demo, and the implementation is where the company finds out whether the guess was right. Usually it was half right, which is the expensive kind of right.
Business process mapping before the purchase is how you stop guessing. It is not documentation for its own sake, and it is not the forty-page procedure manual that nobody reads. It is a short set of maps of the processes that carry money, drawn to the depth where the decisions live, and it takes days rather than months. This post is about what to map, how deep, and the four decisions the map makes for you before a vendor is in the room.
What to map: the processes that carry money.
Not every process. A mid-market operator has hundreds of routines and most of them do not matter to a software decision. The ones that do are the handful that carry money or stock from one state to another: lead to customer, quote to order, order to fulfilment, fulfilment to invoice, invoice to cash, purchase to payable, hire to payroll. Six to ten maps cover almost any business, and the ones that are currently painful are usually two or three of them.
Start with the painful ones. The map of the process that produced the symptom is the map that decides the purchase.
How deep: to the decision, not to the click.
The most common failure in process mapping is depth. Teams either draw boxes so high that the map says "sales sends order to operations" and decides nothing, or they document every click in the current system and produce a manual for software they are about to replace.
The right depth is the decision. Each step on the map answers: who does this, in which system, from what information, and what do they decide? "Sales checks stock before quoting" is a step with a decision in it: where does the stock number come from, is it trusted, what happens if it is wrong? "Sales clicks Quote, then New" is not.
Two things belong on every map that people leave off. The exceptions, because the happy path is rarely the problem; the process breaks on the rush order, the partial shipment, the customer with two billing addresses. We have argued before that the exceptions are the documentation. The handoffs, every point where the process leaves one person or system and enters another, because that is where the work waits, gets re-keyed, or gets lost.
The four decisions the map makes.
Decision one: is this a software problem at all? Roughly a third of the painful processes we map turn out to be a missing decision or a missing owner rather than a missing tool. Nobody decided whether a quote can be sent before credit is checked, so it is sometimes checked and sometimes not, and the system takes the blame. No purchase fixes that. A sentence does. The map finds it in an afternoon, before the sentence has cost a licence.
Decision two: configure, integrate, or buy? With the map drawn, each broken step falls into one of three bins. The step is inside a system you already own and the system can be configured to do it: the fix is configuration such as a blueprint, measured in days. The step is a handoff between two systems you own and the information is not crossing: the fix is an integration, measured in weeks. The step needs a capability no system you own has: only then is it a purchase. Companies that skip the map put everything in bin three, which is why they own more software than they use.
Decision three: what the requirements actually are. A map with decisions on it converts directly into requirements a vendor can be held to, and, more usefully, into the short list of things the software must do rather than the long list of things it could. The forty-tab requirements matrix comes from mapping nothing and asking everyone; the one-page list comes from mapping the money and asking the map. Our piece on whether you need an ERP or an integration is, in the end, this decision applied to the biggest purchase most operators make.
Decision four: what to leave alone. Every map has steps that work. They are not on the requirements list, they are not in the demo, and the new software must not be allowed to break them. Writing them down is how an implementation avoids replacing a working process with a worse one because the vendor's default was different.
Why this matters more now.
Everything above was true before AI. What changed is that a process nobody drew is now also a process no model can run. An automation, an agent, a forecast: each one needs the steps, the decisions and the exceptions written down somewhere it can read, and a company that skipped the map for its software purchase will skip it again for its AI project and get the same result twice. The map is the foundation for both, and it is the cheaper of the two places to lay it.
What a good map looks like.
One page per process, six to ten processes, the painful ones first.
Steps at the depth of the decision: who, which system, from what information, deciding what.
Every handoff marked, every exception named, and the current owner of each step written down even when the honest answer is nobody.
Beside each broken step, its bin: decide, configure, integrate, buy, or leave alone.
A date and a version, because it will be wrong in six months and that is fine.
It should take a week of half-days with the people who do the work, not a quarter with a consultant who does not. If it takes longer, the depth is wrong.
How we run it.
Process mapping is the first half of our discovery, and discovery is paid for only if you proceed to a build. It produces the maps, the bins and the one-page requirements, and where the answer is configure or integrate, a guaranteed estimate for the work; if we estimate low, we absorb the difference. Where the answer is buy, it produces the short list a vendor has to meet, and we say so plainly even when the honest answer is that you do not need us for the next step.
The map decides the software. Drawing it first is the cheapest decision in the whole purchase, and it is the one most companies pay a vendor to skip.
Know whether your data and processes are ready for AI before you pay for it.
The AI Readiness Review is a 90-minute working session plus a written scorecard across data hygiene, documented process, permissions and ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments