Diagnose the process before you buy or build anything. Most "we need a new system" requests are process problems wearing a software costume: unclear ownership, messy handoffs, or bad data that no tool will fix on its own. Run a short operational check first. It tells you whether the real issue is process, people, data, or a genuine tooling gap, and it changes what you spend money on.
Software vendors are happy to sell you a solution before anyone has named the problem. That is not a criticism of the software. It is a warning about the brief. When a team says "the current system is terrible" or "we should build something custom", they are usually describing symptoms, not causes. Buy on the symptom and you often end up automating the very thing that was slowing you down.
Why do most "we need new software" briefs turn out to be process problems?
Because the pain shows up at the tool, but it starts upstream. A finance lead sees late reports and blames the reporting system. An operations manager sees missed orders and blames the order platform. In both cases the tool is where the problem becomes visible, not where it is created. The report is late because three people touch the numbers with no clear owner. The order is missed because a handoff between sales and the floor relies on someone remembering to forward an email.
New software does nothing for either of those. If anything it makes them worse, because now the unclear ownership and the fragile handoff are encoded into a system that is expensive to change. You have spent six figures to make a broken process run faster. That is the trap. Automating a process you have not fixed just industrialises the mess.
The alternative is not "never buy software". Sometimes a tool is exactly what you need. The point is to know which situation you are in before you commit. That is what a diagnosis gives you.
What is the five-question operational check?
Before you approve a purchase or a build, walk the team through these five questions. Answer them honestly and in order. They are designed to separate process, people and data problems from real tooling gaps.
- Can you map how the work actually moves today, end to end? Not the diagram on the wall. The real path, including the workarounds. If nobody can draw it in one sitting, you do not have a tooling problem yet. You have a clarity problem, and no software fixes an undefined process.
- Where do handoffs and rework happen? Every point where work passes between people, teams or systems is a place where things stall, get dropped or get redone. Count them. Handoffs and rework are where most of the lost time and errors live, and they are almost always process, not tooling.
- What would you still have to fix in the process even if the new software were perfect? Imagine the ideal tool arrives tomorrow, fully configured. List what would still be broken. If that list is long, the tool was never the answer.
- Is the current tool unused because it is wrong, or because the workflow does not match how work happens? Low adoption is a symptom, not a verdict. A tool people avoid is often a tool built around an idealised process nobody follows. Before you replace it, check whether the workflow it assumes is real.
- If you doubled tomorrow, which step breaks first? Growth exposes the weakest link. Naming the step that fails under twice the volume tells you where the real constraint is. Sometimes that is capacity a tool can absorb. Often it is a manual handoff or a single overloaded person, which is a process and structure problem.
If your answers keep landing on ownership, handoffs, rework and unclear steps, the problem is process. If the process is clean, well owned and stable, and you are still constrained by volume, integration or data you cannot get to, then you have a genuine tooling gap and buying makes sense.
Process problem or tooling gap: how to read the signals
The same complaint can point to either cause. The difference is in the pattern underneath it.
| Signal | Points to a process problem | Points to a genuine tooling gap |
|---|---|---|
| No one can map the workflow end to end | Yes, clarity and ownership | No |
| Frequent handoffs, rework, chasing | Yes | No |
| Tool exists but people avoid it | Usually, workflow mismatch | Sometimes, if the tool genuinely lacks a capability |
| Data is inconsistent or entered twice | Yes, definition and discipline | Only if systems truly cannot integrate |
| Manual work grows linearly with volume | Sometimes | Yes, automation would help |
| Process is clean but capacity is capped | No | Yes |
Read the whole column, not one row. Most real cases are mixed, but the weight usually falls clearly to one side once you have mapped the work.
A worked example: the manufacturer who thought they needed a new system
Consider a mid-sized manufacturer we might work with. They came in certain they needed to replace their production planning software. Orders were slipping, the floor was firefighting, and the existing tool was the obvious culprit. The brief was already written: scope a replacement, ideally something custom.
We ran the five questions before scoping anything. Question one broke down almost immediately. Nobody could map how an order moved from sales confirmation to the production schedule without three people talking over each other. Question two found the real issue. Between sales taking the order and the floor scheduling it, there was a handoff that depended on one planner manually re-entering details from an email into the system. When that planner was busy or away, orders sat unscheduled for a day or more. Question three sealed it: even with a perfect new tool, that manual re-entry and the missing owner for the sales-to-floor handoff would still be there.
The problem was not the software. It was a handoff with no owner and no defined trigger. We fixed the process first: one clear owner for the sales-to-production handoff, a defined point at which an order moves, and a simple rule for what "confirmed" means. The slipping orders largely stopped before any new software was discussed. When the tooling conversation did come back, it was much smaller and cheaper, because the process it needed to support was finally clear. Had they bought first, they would have automated the re-entry step and kept the ownership gap, and the orders would still be slipping.
This is the discipline behind our process assessment and mapping work: understand how the work actually moves before deciding what, if anything, to build.
How do you avoid automating a broken process?
Fix the process to the point where it is clear, owned and stable, then decide on tooling. In practice that means naming an owner for every step and handoff, removing steps that only exist because of how the old tool worked, and agreeing on shared definitions for the data so it is not entered or interpreted twice. Only once the process holds up under the five questions should you specify a tool, and by then you will know exactly what it has to do.
This order matters because software is a multiplier. It multiplies a good process into leverage, and a bad one into expensive, hard-to-unwind problems. Diagnosis first is not caution for its own sake. It is how you make sure the money you spend goes to the thing that is actually broken.
If you are staring at a "we need a new system" brief and are not certain the problem is really the system, book a discovery call. We will help you run the check and tell you honestly whether you need software, a process fix, or both.
Frequently asked questions
How do I know if I actually need new software or just a better process?
Map how the work moves end to end first. If you cannot draw that map, or if the same map shows unclear ownership, repeated handoffs and manual rework, the problem is process, not tooling. New software only helps once the underlying workflow is clear and stable. If the process is sound and the constraint is genuinely capacity, integration or data, then a tool is the right answer.
Why do teams reject software that was supposed to fix their problem?
Usually because the tool assumes a workflow that does not match how the work actually happens. People revert to spreadsheets and email because those are faster for the real process, even if they are messier. Before blaming adoption, check whether the tool was configured around the real workflow or around an idealised one that nobody follows.
What does it mean to automate a broken process?
It means putting technology on top of a workflow that has unclear ownership, redundant steps or bad data, so the problems run faster and harder to see. You get the same errors and rework, now buried inside a system that is expensive to change. Fixing the process first means automation reinforces good behaviour instead of preserving the mess.
How long does an operational diagnosis usually take?
For a single process or workflow, a focused assessment often takes two to four weeks: mapping the current state, sitting with the people who do the work, and pressure testing where it breaks. It is a small fraction of the cost of a system you would otherwise buy, and it changes what you buy, or whether you buy at all.