Why software does not fix a broken process

A new system is one of the easiest decisions for a leadership team to agree on. It is visible, it is budgetable, and it comes with a demo that makes the current way of working look dated by comparison. It is also, on its own, one of the least reliable ways to fix an operational problem.

That is not an argument against new systems. Sometimes a genuine technology gap exists and a new or better-configured tool is exactly the right answer. The issue is that "buy a system" is often reached for before anyone has established which of four quite different problems is actually in play.

Four failure modes that look similar from a distance

Unclear ownership. Nobody is clearly accountable for a piece of work end to end, so it gets picked up inconsistently, or dropped between teams. A new system will faithfully digitise that same ambiguity.

Poor workflow design. The steps themselves do not make sense: approvals that do not need to happen, information captured twice, handovers with no clear trigger. Software configured around a bad workflow will simply make the bad workflow faster.

An adoption problem. The existing tool would do the job perfectly well, but people were never properly trained on it, do not trust the data in it, or have quietly reverted to spreadsheets because that felt safer under deadline pressure. Replacing the tool does not touch any of that.

A genuine technology gap. The tools available cannot do what the business now needs: they do not connect, they cannot scale, or the functionality simply does not exist. This is the one case where new or reconfigured technology is the direct answer.

The answer is not automatically a new system. Establish what the business needs, what existing tools can do, and where the real constraint sits.

Questions worth asking before any procurement conversation

• If we implemented the proposed system perfectly, would the underlying problem actually go away?
• Is there a version of this process, using what we already have, that would work if ownership and steps were clearer?
• Where does the current tool sit unused, under-used, or actively worked around, and why?
• Whose job would it be to make sure the new system gets adopted properly, and do they have the time to do that alongside everything else?

None of these questions are arguments against change. They are a way of making sure the change that gets funded is the one that actually solves the problem, rather than the one that is easiest to put in a business case.

Where this leaves technology and AI

Getting more value from an existing ERP, CRM or line-of-business platform is very often available before any new procurement is needed. Automation and AI can genuinely help too, but only once there is a defined use case and a process worth automating. Applying either to a process nobody has properly designed just makes an unclear way of working faster and harder to unwind later.

The practical approach is to establish what the business needs first, be honest about what the existing tools already can do, and then decide (deliberately, rather than by default) whether the answer is configuration, integration, a change in ownership, a redesigned workflow, or a new system after all.