When not to buy new software: A decision framework for operations leaders
The most valuable advice we give clients is often to not buy anything.
The most valuable advice we’ve given clients, dollar for dollar, may be this: don’t buy that.
We say it a few times a year. To clients who have already shortlisted vendors. To teams that have been building the business case for months. To leaders who are convinced that the right platform is the thing standing between them and better operations. Sometimes they listen. When they do, they save themselves two or three years of implementation pain and, usually, seven to fifteen million dollars.
The instinct toward new software.
There’s a reason operations leaders reach for new software when something isn’t working. Platforms have gotten genuinely better. The promise of modern supply chain technology, real-time visibility, AI-assisted planning, seamless integration, is real, and some of it has arrived.
And there’s something appealing about a clean break. A new system means a chance to redesign the process, to leave behind the workarounds and the technical debt, to start over with something built for the problem you have now. The problem is that new software often inherits the old process, just with a different interface. And it almost always reveals problems in your data, your organization, and your decision-making that the system itself can’t solve.
The framework we use.
When a client comes to us with a technology evaluation, we start with three questions.
Is the process broken, or is the tool broken? If the process is broken, new software will automate the broken process. Fix the process first.
Is the data clean enough to support a new system? Most enterprise software deployments surface data problems that were already there but invisible. A platform change without a data strategy is a very expensive way to find out you have a data problem.
Is the organization ready for the change? Change management is the most underestimated cost in any technology program. It’s not a line item on the project plan, it’s a capability that either exists or doesn’t. If the organization isn’t ready to adopt, the best platform in the market won’t get adopted.
When new software is the right answer.
There are cases where the existing system genuinely can’t do what the business needs, where the architecture is wrong, the support has lapsed, or the gaps are fundamental enough that no amount of configuration will close them. In those cases, a platform change is the right call.
But that determination should come from an honest diagnosis, not from a vendor’s discovery process or a conference presentation or the fact that your competitor just announced a new implementation.
The question isn’t “what’s the best supply chain platform?” It’s “what does this business need, and what’s the most efficient path to getting there?” The answer isn’t always software.
Working through a build-vs-buy decision?
We’ve run this analysis dozens of times. We’ll give you a straight answer.