A new ERP may be exactly what your business needs. But before the RFPs, software demonstrations and implementation proposals begin, leadership should answer a more fundamental question: Is the ERP actually the problem?
There is a familiar pattern in companies considering a major ERP investment. Inventory becomes increasingly difficult to trust, customer service teams build spreadsheets to compensate for gaps in the system, warehouse productivity begins to suffer, and reporting requires more manual effort than anyone thinks it should. As the business grows, those problems become more visible and the existing technology increasingly gets blamed. Eventually, someone says what everyone has been thinking: We need a new ERP. They may be right. Systems age, companies outgrow technology, and older platforms may no longer provide the functionality, integration or visibility a modern operation requires. But replacing an ERP is an enormously consequential decision, and too many companies begin evaluating software before they have clearly established what is actually causing the problems they are trying to solve.
Once an organization decides it needs a new ERP, the process can develop momentum surprisingly quickly. Requirements are gathered, RFPs are prepared, software companies are invited in and demonstrations begin. Implementation partners offer timelines, methodologies and estimates. Internal teams begin devoting significant time to the project, and before long the discussion has shifted from whether the company needs a new ERP to which ERP it should buy. At that point, an assumption has quietly become a strategy. The better place to start is not with the software. It is with the operation.
Understand the Problem Before Choosing the Solution
Technology problems and operational problems can look remarkably similar. An organization with poor inventory accuracy may have a systems problem, but it may also have inconsistent receiving practices, weak transaction discipline, inaccurate master data or poor cycle counting. A business struggling with reporting may have an outdated ERP, or it may have inconsistent definitions, fragmented processes and departments maintaining their own versions of the truth. A warehouse relying heavily on spreadsheets and workarounds may have exceeded the capabilities of its systems, but those workarounds may also have developed because the standard processes were never properly designed or enforced.
This distinction matters because a new system can provide better capabilities, but it cannot create operational discipline on its own. It will not automatically standardize processes across facilities, correct poor data, clarify decision rights or establish accountability. In some cases, replacing the technology without addressing the underlying operating issues simply transfers the same problems into a newer and considerably more expensive platform. The organization may spend millions of dollars and several years on a transformation only to discover that the software was never the only problem.
Understanding that requires looking beyond process maps and conference room discussions. There can be a significant difference between how a process is documented, how leadership believes it works and what actually happens in the operation every day. Follow an order from receipt through fulfillment and see where people leave the standard process. Watch how inventory actually moves through a facility. Understand why employees turn to spreadsheets or manual workarounds. Look at what information supervisors have when they begin a shift, what information planners use to make decisions and what managers cannot see without asking someone to build another report. Most importantly, talk to the people doing the work and understand not only what they are doing differently from the prescribed process, but why.
That kind of assessment can lead in several directions. It may confirm that the organization truly has outgrown its ERP and that replacement is necessary. It may reveal that the current platform has capabilities the company has never fully used, or that the warehouse management system, planning tools or another piece of the technology stack is the actual constraint. It may uncover significant problems with master data, process consistency, training or accountability that should be addressed regardless of which system the company ultimately uses. Any of those conclusions is valuable if it is reached before millions of dollars have been committed.
Why Independence Matters
Software companies sell software, and implementation partners implement it. That is not a criticism of either. Both play important roles and, when chosen well, bring expertise that is essential to a successful project. But neither has exactly the same responsibility as the company making the investment. The software provider knows its product. The implementation partner knows how to configure and deploy it. The company, however, has to live with the result long after the project team has moved on.
That creates a role for someone whose responsibility begins with the interests of the business rather than with a particular technology or implementation. An independent operational assessment should look across people, processes, data, systems and performance without beginning with a predetermined answer. The objective is not to build a case for replacing the ERP. It is to determine what needs to change and then establish what role technology should play in making that change possible.
That is the thinking behind our approach at Schrader Advisory. We begin with discovery and observation, move into diagnosis and establish a baseline before making recommendations. Sometimes the evidence may support a new ERP. In another business, the priority may be WMS, planning technology, data, process standardization or simply fixing the execution around systems already in place. A new ERP is one possible conclusion. It should not be the predetermined conclusion.
Independence also changes the quality of the conversation when the company does decide to go to market. Leadership enters an RFP knowing much more specifically what it expects technology to accomplish. Instead of allowing a software demonstration to define the possibilities, the company can evaluate each platform against operating requirements that have already been established. The question becomes less about what the software can do and more about whether it can support what the business needs to do.
Define the Business Case Before the Technology Case
That distinction is important because ERP selection naturally gravitates toward features and functionality. Companies compare modules, workflows, integrations, reporting capabilities and hundreds of individual requirements. All of those things matter, but the most important requirements should originate in the operation. What should order fulfillment look like? What level of inventory accuracy does the business require? How should planners identify and resolve exceptions? What information should supervisors have available when they begin a shift? Which processes need to be standardized across locations, and which legitimately need to remain different? What decisions should leadership be able to make faster or with greater confidence?
Those questions lead to another one that is often not answered nearly well enough before a major technology investment is approved: What measurable business outcomes are expected to improve? If the organization is investing in technology because it expects better inventory accuracy, higher service levels, improved productivity, greater visibility or lower operating costs, it should know precisely where those measures stand before implementation begins.
We refer to that as the Day Zero baseline. If inventory accuracy is expected to improve, document the current accuracy and understand how it is being measured. If productivity is part of the business case, establish the current performance and the conditions affecting it. If better visibility is one of the reasons for the investment, identify what information is unavailable today and what decisions the organization cannot make effectively because of it. A business case should create a set of measurable expectations that survive long after the project receives funding.
Without that baseline, a company can complete a multimillion dollar implementation and still struggle to answer a surprisingly basic question a year later: What did we actually improve? The project may have been delivered, the system may be operating and the implementation team may have moved on, but none of those things necessarily demonstrates that the investment produced the business value used to justify it.
Go Live Is a Milestone, Not the Return on Investment
I have written previously about why ERP implementations can struggle long before go live. Operational readiness, leadership, user adoption and process discipline all matter, and a technically successful implementation can still become an operational failure if the organization is not prepared to work differently. Those issues remain important once a company decides to move forward, but there is an even earlier decision that deserves the same level of attention: Should the organization be implementing this technology in the first place?
If the answer is yes, the company should enter the project knowing what the technology needs to accomplish, what operational changes must accompany it and how the results will ultimately be measured. That makes software selection more disciplined, gives implementation partners clearer requirements and gives leadership a much stronger basis for holding the investment accountable after go live. If the answer is no, discovering that before issuing an RFP or signing an implementation agreement may be one of the most valuable conclusions an independent assessment can produce.
Major ERP and operational technology investments can transform a business. They can also consume millions of dollars, thousands of employee hours and years of organizational attention. For that reason, the decision deserves more than a comparison of software platforms and implementation proposals. Leadership should understand what is happening in the operation, identify the root causes of the problems it is trying to solve, establish where performance stands today and define what better performance should look like tomorrow.
Only then should the technology discussion begin.
Before you buy the ERP, understand the operation.