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.
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.
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.
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.
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.
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.
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.
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:
Process Documentation Software: When the Tool Is Not the Missing Piece. (article)
You Can't Automate a Process Nobody Has Written Down (article)
Nobody Wrote The Process Down (video)
A flowchart is a diagram notation. A process map is a flowchart with a purpose: it shows who does each step, in which system, from what information, and what they decide, including handoffs and exceptions. The notation can be swimlanes, boxes and arrows, or a table. What makes it a useful process map is that each step records a decision and an owner, not that it uses a particular shape.
For a software decision, days rather than months. Six to ten processes that carry money or stock cover most mid-market companies, and the two or three painful ones are the ones to map first. Each takes a half-day workshop with the people who run it and a few hours to write up. Mapping every process in the company to the click level is the version that takes months and decides nothing.
The people who actually do the steps, not only their managers, because the exceptions live with the operators. Include one person from each system the process touches, so handoffs are described from both sides. Keep the group small, five or six people, and have one facilitator who asks what happens when things go wrong. Vendors should not be in the room; the map decides what to ask them later.
Use it to make four decisions: whether the problem is software at all, whether the fix is configuration, integration or purchase, what the system of record is for each piece of information, and what the requirements are for any purchase. Then keep the map as the baseline for the implementation, so the vendor builds to the process you drew and not to a demo script.
Not always. A company with an operations lead who can facilitate without defending the current process can do it internally. An outside facilitator helps when the processes cross departments that disagree, when the team is too close to the exceptions to see them, or when the map will be used to hold a vendor to a scope. The value is in the questions asked, not the diagram.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
