Before I review any software a company is about to buy, I ask for one thing first. I ask someone to walk me through the process, step by step, exactly as it happens today. Over 15 years and more than 500 projects, I have found that process mapping before software selection is the single most reliable way to protect a technology budget, and it is also the step most companies are tempted to skip because the new system promises to solve everything anyway.
I mean the real version of the process, not the version in the operations manual. I want the spreadsheet that sits in the middle of the workflow, the email that gets forwarded to three people before anything moves, and the colleague everyone messages when the numbers do not match. That colleague is usually the most important part of the process, and they almost never appear on a vendor’s implementation plan.
That walkthrough is often the most valuable hour of the whole engagement. It regularly saves more money than any negotiation with the software vendor, because it changes what the company is actually buying. Sometimes it changes whether the company needs to buy anything at all.
Most leaders who have run this calculation are surprised by where the real cost sits.
Why Software Cannot Fix a Process Nobody Has Written Down
New software carries an understandable appeal for leadership teams. It feels like decisive action, it comes with a clear price and a clear timeline, and the demo always shows a clean workflow where every step connects neatly to the next. The difficulty is that software automates whatever process it is given. If that process is inconsistent, undocumented, or held together by workarounds, the new system will faithfully automate the confusion.
In our engineering reviews across SuperBotics’ projects in more than 14 countries, I have watched this play out with ERP rollouts, CRM migrations, Odoo implementations, and custom platform builds. The pattern is consistent. Six months after go live, the team is still using the old spreadsheet alongside the new system, the vendor is being asked for customisations that nobody anticipated, and leadership is wondering why the investment has not delivered what the business case promised.
The root cause is rarely the software. It is that the company bought a solution before agreeing on the problem. When the process was never written down, every stakeholder carried a slightly different picture of it in their head, and the software was configured to match whichever picture happened to be in the room during requirements gathering.
The hidden risk: a software purchase made before the process is documented tends to lock in the current workarounds permanently. Once they are configured into a system, they become far more expensive to remove than they ever were in a spreadsheet.
The Three Voices Walkthrough: A Field Framework
Quite often, when I ask three people to describe the same process, I hear three different versions. Each of them is right about their own part. The finance lead describes the approval steps accurately, the operations manager knows exactly how orders are handled, and the customer service lead understands every exception. What none of them has seen is the whole process end to end, because nobody has ever needed to look at it that way.
That observation led me to a method I now use in almost every software decision, which I call the Three Voices Walkthrough. It is simple enough to run in a week and structured enough to produce a document the whole leadership team can agree on. I have used it with companies from 40 people to several thousand, and it scales well because it relies on conversation rather than tooling.
- Select three voices: choose one person who starts the process, one who works in the middle of it, and one who deals with its outcome.
- Walk separately: ask each person to describe the process individually, as it truly happens, including every workaround and handoff.
- Map the differences: lay the three descriptions side by side and mark every step where they disagree or where information changes hands.
- Agree one version: bring the three voices together to agree a single written process that all of them recognise as accurate.
- Remove habit steps: identify steps that exist only out of habit, and remove them before any software is discussed.
The fourth step is where the real value appears. When people who have worked alongside each other for years see their descriptions laid side by side, they often discover handoffs they did not know existed. I have seen teams realise that a report they spent hours preparing each week was being read by nobody, or that two departments were entering the same data into separate systems. Those discoveries are worth more than any feature list.
What Process Mapping Before Software Selection Changes
Once the process is written down and agreed, the software conversation begins, and it is usually a smaller, simpler one. The requirements are clearer because they describe a real process rather than a collection of individual preferences. Vendors can be evaluated against what the business actually does, and implementation estimates become more accurate because there are fewer surprises waiting in the workflow.
| Decision Area | Software First | Process First |
|---|---|---|
| Requirements | Wish lists from each department | One agreed, written process |
| Vendor evaluation | Driven by the most impressive demo | Driven by fit with the real workflow |
| Customisation | Discovered during implementation | Identified and scoped before signing |
| Adoption | Old spreadsheets survive alongside | Team recognises its own process |
| Purchase scope | Often larger than needed | Frequently smaller and simpler |
That last row surprises many leadership teams. Once habit steps are removed and the process is agreed, a significant portion of what the company thought it needed from new software turns out to be unnecessary. In some cases, the existing system can handle the cleaned process perfectly well. In others, a much smaller purchase replaces what was originally scoped as a major platform investment.
This connects closely to a theme I return to often with clients. Technology rarely fixes an organisational problem on its own, and that is as true of AI as it is of ERP. I explored the same idea in why AI will not fix a company that has not fixed its processes first, because the discipline required is identical regardless of the technology involved.
The People Behind the Process
It is worth saying clearly that process mapping is not an audit of people’s performance. The workarounds I find in almost every walkthrough were created by capable people solving real problems with the tools available to them. The colleague everyone messages when the numbers do not match is not a weakness in the process. They are the reason the process has kept working at all.
Treating the walkthrough with that respect changes how openly people describe their work. When team members feel that the exercise is about understanding rather than judging, they share the workarounds they would otherwise hide. Those hidden workarounds are exactly the details that determine whether new software succeeds or fails, so creating an environment where they surface safely is part of the job.
This is also where an experienced outside perspective helps. As a Fractional CTO and executive technology coach, I am not part of the internal history of how a process evolved, which makes it easier for people to describe it honestly. I can ask the obvious questions that insiders stopped asking years ago, and I can help the leadership team separate the steps that protect the business from the steps that simply persist.
Settling the Process Before the Next Purchase
Every significant software decision is really two decisions, which is why process mapping before software selection matters so much. The first is how the business wants a process to work. The second is which tool best supports that process. Most companies make the second decision first and then spend months trying to reverse engineer the first one during implementation. Reversing that order is one of the simplest and most valuable changes a leadership team can make to how it spends on technology.
If your business model has shifted since your current systems were chosen, the question becomes even more important. I discussed that situation in why your platform may not be outdated at all, and process mapping before software selection is usually the first step in working out which of the two is actually true.
Before your next software purchase, ask one quiet question inside the leadership team. Could the three people who run your most important process describe it the same way? If they could, you are ready to evaluate software with confidence. If they could not, the most valuable investment you can make this quarter costs almost nothing, because the clearest software requirement any company will ever write is a process its own people already agree on.
The gap between a full-time CTO and a Fractional one is rarely what organisations expect before they see the numbers.
