You Don’t Need New Software. You Need to Use What You Already Have.

Before you spend five, six, or seven figures replacing a piece of business software, you should read this.

I’ve lost count of how many times I’ve heard a leader say “our ERP isn’t working.” But it’s not just ERPs. The same conversation happens with CRMs, with warehouse management systems, with inventory management tools, with accounting platforms, with manufacturing execution systems, with project management tools. The story changes by category. The pattern doesn’t.

Almost every time, the tool itself isn’t the problem. Most of the time, it is a planning, people, or process problem that shows up looking like a tool problem. Said a different way, the software is fine. The way it has been configured, implemented, and adopted is broken.

That is the conversation I want to have today, because it is the most expensive misdiagnosis I see in mid-market and growing businesses.

The Real Issue Isn’t the Tool

At their core, every business system you have ever used is a transaction aggregator. Your ERP records financial and operational transactions. Your CRM records customer interactions. Your WMS records warehouse movements. Your accounting platform records financial events. Each one takes inputs, processes them according to the business rules and configuration you set up, and reports outputs back to you.

None of them are smart on their own. None of them know what your business is supposed to do. None of them can compensate for a process that was never properly defined. They do exactly what they were configured to do, against exactly the inputs you give them, and produce outputs that reflect those two things.

If what you are recording does not reflect reality, or it is incomplete, inconsistent, or misunderstood, you will never get a “good output.” That is not the tool’s fault. That is the system around the tool failing to feed it the right inputs in the right way.

The Pattern Shows Up Everywhere

I see versions of the same misdiagnosis across categories. A few examples:

ERP. I worked with a company that had two distinct business models running inside the same ERP using the same configuration. They were a project-based engineer-to-order manufacturer that had grown into a parts-and-service operation supporting the equipment they sold. Different business models require different configurations. The processes that make a parts-and-service flow work are not the processes that make a project flow work. One flow was enabling the project business while making the parts business nearly impossible to operate effectively. The team thought they needed a new ERP. They did not. They needed the existing ERP reconfigured around how the second business actually worked. (For the detailed walkthrough of this case, including the operational impact and the fix, see the companion piece “Two Customers, Same Bolt: A Mid-Market Manufacturer’s ERP Misconfiguration Story.”)

CRM. A sales team I worked with was running shadow Excel pipelines alongside their CRM because the CRM had been configured around a sales motion they had outgrown two years earlier. The CRM was not broken. The configuration was set up for the way they sold in 2022. By 2024, they were running a different motion, and the system fields, stages, and reports no longer matched. The team built workarounds in Excel. Leadership saw low CRM utilization and started shopping for a different platform. The actual problem was a configuration that needed to evolve when the sales motion did, and it never did.

WMS. A warehouse team I worked with was running a parallel paper-based picking system because the WMS workflow assumed a picking pattern that did not match how the floor actually operated. The system thought picks happened in a sequence the team had never followed. Pickers worked from printed lists, marked them up, and somebody re-entered the data into the system afterward. Inventory accuracy was suffering. Leadership wanted to upgrade the WMS. The fix was reconfiguring the picking workflow to match how the floor actually picks.

The pattern is the same in every category. The tool is doing exactly what it was told. What it was told no longer matches what the business actually does. Replacing the tool without addressing the configuration just re-creates the same mismatch on a new platform.

Why So Many Miss the Mark

Configuration and implementation work hand in hand, and both are usually rushed.

The implementation team asks the team “how do you do it now” instead of “how should it work.” So the tools get built around existing habits, not future goals. Users rarely see the full capability of what they have. Leadership mistakes low utilization for tool failure. Frustration builds. The team starts complaining. The conversation turns to replacing the tool, when what is actually needed is training, process alignment, configuration adjustment, and more cross-functional collaboration on how the system should actually be used.

That is a utilization and adoption issue, not a software issue. It will follow you to whatever new tool you buy.

Shifting the Mindset

All tools depend on people and process first. The tools execute what has been defined upstream. If the upstream layers are not clear, the system cannot compensate.

So before you invest another five, six, or seven figures on a new system, ask three questions:

• Do we know what outcomes we are actually trying to achieve?
• Have we clearly mapped how our processes should work, not just how they happen to work today?
• Are we using the current system to its full capacity, or are we asking it to do something it was never configured to do?

I have seen teams unlock significant value just by doing structured interviews, mapping the workflows that actually run the business, and retraining the team on the system they already pay for. Most “broken” tools turn out to be underutilized, not outdated.

Red Flags of System Underutilization

You probably do not need a full audit to spot the signs. They show up in the same patterns regardless of which tool we are talking about:

• Everyone is living in spreadsheets that the system should be producing
• Data has to be cleaned before reports make sense
• You have bolt-on tools or shadow systems doing the main system’s job
• The team talks about “system issues” that are really workflow issues
• New hires spend weeks learning the system’s quirks instead of learning the business
• Critical knowledge of how the system actually works lives in one or two people’s heads

If three or more of these are true in your business, the conversation you should be having is not “what tool should we buy next” but “what is actually wrong with how we are using the one we already have.”

How to Fix It Without Buying a New One

Optimization starts with listening. Ask your team three simple questions:

• What bugs you about the current system?
• What takes forever?
• What would make your tasks easier?

Listen without defending the tool, the implementation, or the people who set it up. Just write down what you hear.

From there, fix what you can control: configuration, training, process documentation, and the KPIs that actually drive the right behavior. Once you get that foundation right, continuous improvement takes over. The system becomes the enabler instead of the obstacle.

This work is not glamorous. There is no demo for it. There is no sales pitch around it. But it is the work that actually changes how the system performs in your business.

When Replacement Actually Makes Sense

I want to be clear that the answer is never “never replace.” Sometimes replacement is the right move. Just not as often as people think.

Valid reasons to replace include:

• Vendor support has ended or your version is being sunset. You are forced into a transition. The decision is not whether, but when and how.
• Your business model has fundamentally changed and the current system cannot be reconfigured. Not “would be hard to reconfigure.” Cannot be reconfigured. There is a real architectural mismatch between what the system was built to do and what the business is now doing.
• You have grown beyond the system’s capabilities. Real growth, real architectural ceiling, not a configuration problem in disguise. This bucket is the one most people land in incorrectly. They think they have outgrown the tool when they have actually misconfigured it.

Even in those cases, the same rules apply. Define and optimize your processes first. Otherwise you carry the old problems into the new system, and you do it on a new invoice.

Final Thoughts

Most organizations do not need more tools. They need to use the ones they already have, properly configured to match the business they are actually running today.

If your data is bad, AI and automation will just make it worse, faster. Adding more software on top of a foundation that does not work just compounds the noise. Bolt-ons buy you a feeling of momentum, not actual operational improvement.

Start by fixing the root causes. Align your people and your processes. Then let your existing systems do their job: capture and report what is actually happening in your business.

That is the work. It is harder than picking a vendor. It is also what actually pays back.

That’s it for today.

See you all again next week.

Dave