Contents

A weak ERP business case usually starts with the vendor's world: modules, features, workflows, integrations, implementation phases, and user licenses. Unfortunately, that is where many ERP projects lose approval, because the case starts with software instead of the business problem and metrics leadership already cares about.

This article shows how to build a manufacturing ERP business case around the numbers that actually move a leadership committee, often called a CODIR: hours recovered, margin leakage stopped, and risk reduced. It also shows how to pressure-test the assumptions to build a rock-solid case.

Why most ERP business cases fail

The argument for an ERP must be around the fact that the current operating model is costing the company money, slowing growth, hiding margin problems, or putting customer promises at risk.

Therefore, a stronger business case starts with the cost of the current system:

How many hours does the team lose every week to manual work?
Where does margin disappear because the company sees problems too late?
Which risks become more expensive if the company keeps running operations through spreadsheets, paper, memory, disconnected tools, or a legacy ERP?

That framing changes the conversation. The project is no longer "we want to buy ERP" or "we want to change ERP." It becomes "we are already paying $X for the absence of a proper operating system."

The 3 numbers your CODIR actually cares about

Most models for return on investment (ROI) for ERP become too wide too quickly. They try to quantify every possible benefit, which makes the model look precise yet strangely unconvincing at the same time.

Better to focus on just three numbers:

1. Hours recovered per week

Start with the work people are already doing because the system doesn't. The most common examples are production follow-up, stock checks, planning updates, duplicate data entry, purchasing reminders, quality tracking, reporting, and reconciliation between operations and finance.

Do not only count obvious admin but the operational interruptions, too. For example, a planner who spends two hours rebuilding the schedule is easy to model. A production manager who gets interrupted 12 times a day because nobody trusts the stock number is harder, but the cost is real. So is the time a buyer spends chasing shortages the system should have surfaced earlier.

The cleanest way to estimate this is by role:

Planner: hours spent updating plans, checking constraints, and reconciling changes
Production manager: hours spent chasing status, correcting data, and answering repeated questions
Operators: time spent writing information on paper plus time spent updating a system later
Purchasing: time spent following up on shortages, late suppliers, and unclear needs
Finance or management: time spent rebuilding production cost, margin, or stock information

Once the weekly hours are visible, convert them into annual value. But be careful with the language: not every hour recovered becomes a cash saving, some of it becomes capacity, i.e., the same team can absorb more volume, answer faster, reduce errors, or spend time improving the business instead of holding it together manually. That distinction makes the model more credible.

2. Margin leakage you can stop

Manufacturers lose margin when the team discovers problems after the decision window has closed. For example:

A material cost changed, but sales quoted from the old cost
A batch consumed more input than expected, but finance only sees the variance at month-end
Production ran late, so the company paid for urgent transport
Stock looked available, but the warehouse found out too late that it was blocked, expired, reserved, or simply wrong

None of those losses usually appear under one neat budget line called "ERP problem." They show up as scrap, rework, urgent purchasing, late shipments, excess inventory, missed delivery promises, unexplained variance, and management time spent investigating what happened.

A good business case does not need to pretend ERP will recover every point of margin, but it should identify the few key leakage points that could be obviously solved by a better system.

3. Risk cost if you do nothing

The third number is the one teams often avoid because it is at the same time uncomfortable and hard to quantify. What happens if the company does not act?

ERP projects are often treated as risky because implementation requires money, attention, and change, all of which is true. But keeping the current system also carries risk.

For some manufacturers, the risk is customer-facing: late orders, lost service levels, penalties, or a major customer losing confidence. For others, the risk sits in quality, traceability, compliance, or key-person dependency. Sometimes the risk is strategic: the company wants to grow, open a new factory, launch a new channel, or serve larger customers, but the operating system cannot support the next stage.

This number will never be as clean as labor hours, our first number, and to some extent that's ok. The goal is not false precision, but rather to show leadership that the status quo has a cost curve, too.

How to build the model without pretending the math is perfect

Your ERP business case does not have to be perfect, but it does have to be something leadership can both challenge and still believe.

Instead of boiling the ocean to start, it can be helpful to start by digging in to three to five operational flows. For each flow, capture four things:

What manual work happens today?
Who does it, and how often?
What does that work cost in time, margin, or risk?
What would change if the work moved into a shared operational system?

Then separate the benefits into categories. Hard savings are costs the company can reduce directly. Capacity gains are hours the team can redirect toward higher-value work. Margin improvement comes from preventing leakage, not magically raising prices. Risk reduction comes from lowering exposure, even if the exact financial value is a range.

It can also be helpful to use three scenarios to map out that range:

Conservative: only benefits the team is highly confident it can capture (this should be strong enough to justify the project)
Likely: benefits based on current observed work and realistic adoption
Ambitious: benefits if the system is adopted broadly and operational habits change; the ambitious case should show what becomes possible if the company uses the ERP as a real operating system, not just a database

How to pressure-test the assumptions before your CODIR does

A good CODIR will challenge the model, and that is its job. That challenge isn't a threat, but an invitation to build the pressure test into the business case from the start.

Start by labeling the confidence level of each input. Observed numbers are obviously the strongest, and they come from time tracking, exports, production logs, purchasing records, quality reports, customer penalties, stock corrections, or actual margin variance.

Estimated numbers are still useful, but they need owners. For example, if the production manager estimates 10 hours a week of reporting work, say that. If finance estimates margin leakage from urgent purchasing, show the calculation and the source.

Assumptions are the weakest, so make them visible and do not hide them in the calculation. Leadership will trust a model more when it can see where judgment was used.

From there, ask the uncomfortable questions:

Which benefits depend on adoption by operators, planners, or buyers?
Which savings are cash savings, and which are capacity gains?
Which part of the model would finance challenge first?
Which operational problems will still exist after the ERP project?
What needs to be true for the conservative case to fail?
What would the business lose if it waits 12 more months?

That last question is a really important one to call out, because ERP business cases are often judged as if the alternative were free. It is not. The alternative is the current system, with all the manual work, leakage, and risk that comes with it.

Example: production reporting

Let's look at everything we've been talking about with a practical example. Imagine a 100-person manufacturer where production reporting still depends on a mix of paper notes, shift-end updates, spreadsheet corrections, and questions passed through the production manager. Operators record what happened during the run, but the information reaches planning, purchasing, finance, or management late enough that the team is often reacting after the fact.

That workflow is a good candidate for the business case because it creates all three forms of value at once. The team can recover time from manual reporting, protect margin by seeing production variance earlier, and reduce risk because leadership no longer depends on one or two people to reconstruct what happened on the floor.

The numbers below are not benchmarks but rather meant to show how to model one process in a way your CODIR can challenge.

Value driver	Input type	Conservative case	Likely case	Ambitious case
Hours recovered	Estimated from operator and manager interviews, then checked against one week of observed reporting work.	8 hrs/week recovered by reducing paper notes, late data entry, and manual status checks.	20 hrs/week recovered because production updates move into the normal flow of work.	30 hrs/week recovered because production, planning, and management no longer rebuild status across files and meetings.
Margin leakage reduced	Estimated from recent rework, late corrections, urgent purchases, and production variance.	0.2 margin points protected by catching obvious reporting gaps earlier.	0.5 margin points protected by reducing rework, late corrections, and variance discovered after production.	1 margin point protected because production data becomes reliable enough to act on before month-end.
Risk lowered	Assumption based on the current cost of late visibility, key-person dependency, and customer escalation risk.	Fewer reporting errors and less dependency on one person knowing what happened on the floor.	Less delay between production reality and system data, so managers see blocked orders, overruns, or missing updates earlier.	Live production visibility lowers the risk of late orders, customer escalation, and margin surprises as volume grows.

Notice that the model does not treat every input as equally certain. Hours recovered can often be estimated from interviews and checked against a short observation period. Margin leakage, on the other hand, may be estimated from recent operational events and finance data. Risk reduction is usually more assumption-led, so it should be written as a range and tied to a specific event the company wants to avoid.

The objections you need to pre-empt

ERP resistance is often rational, as many leadership teams have seen expensive projects run late, disappoint users, or leave the company with a rigid system that still needs spreadsheets to function.

Here are some common objections and suggested objection handling:

"Implementation will distract the team"

This objection is fair. ERP implementation takes attention from the people who already have jobs to do. Even when implementation is fast, as is the case with Bonx at about one to three months, it still requires focus and effort from the team.

The answer is not to pretend the project will require no work but to show the implementation scope clearly: which flows come first, who owns the project internally, which data needs preparation, and how the team will avoid turning the ERP project into a year of workshops before value appears.

If the business case includes internal team time as a cost, it becomes more credible. It also forces the vendor conversation to stay practical. A vendor who needs six months of discovery before showing operational value should be judged differently from one that can start with the flows creating cost today.

"We tried ERP implementation before"

This objection is not about software but about trust. If the company has tried ERP before and the project failed, the business case has to name what will be different this time; usually just choosing a different vendor is not enough.

Was the last project too finance-led? Did it try to model the whole company upfront? Did operators avoid the system because it slowed them down? Did the implementation freeze processes that kept changing? Did the vendor force the company into workflows that looked clean in a demo but failed during real production?

A credible business case explains the failure mode, then shows how the new project avoids repeating it.

"The team will not adopt it"

Teams do not reject systems because they enjoy manual work, but they do reject systems that make their job harder.

The adoption argument should therefore focus on the work itself. Which tasks become easier? Which duplicate entries disappear? Which questions no longer require asking the same person? Which production updates happen during the normal flow of work instead of after the shift?

Adoption is not a communication plan but rather a product of whether the ERP actually helps people do their job.

"The savings are too theoretical"

This is why the model should separate hard savings, capacity gains, margin improvement, and risk reduction. If leadership wants only hard savings, be honest about what the model can prove. But do not let that narrow definition erase value the business clearly needs.

A planner who gets 10 hours back each week may not reduce payroll. But if that time means better scheduling, fewer shortages, faster customer answers, and less firefighting, it still has business value. The model should say that clearly instead of pretending every recovered hour is a direct cost reduction.

"This is an operations project, not a company priority"

That objection usually means the business case has stayed too close to the factory floor.

Operations is where the cost appears first, but the impact reaches the whole business. For example, unreliable stock affects sales promises, late production affects revenue, poor traceability affects risk, manual reporting affects management, and fragile systems affect growth.

The ERP business case should connect operational work to company-level outcomes without turning the argument into a generic transformation pitch.

How to present the business case so it gets approved

Begin with the business cost, not with software. A strong presentation for an ERP business case usually follows this sequence:

Name the operational problem in plain language.
Show the current cost in hours, margin, and risk.
Present the conservative ROI model first.
Explain the assumptions and confidence level.
Show the implementation scope and internal effort required.
Address the objections before they are raised.
End with the decision: approve, delay, or accept the cost of the current operating model.

The people in the room matter as much as what's being presented. A manufacturing ERP business case cannot be owned by one department alone. If operations builds the business case without finance, the numbers may be challenged. If finance builds the ERP business case without operations, the model may miss the work that creates value. If leadership is absent until the end, the project can become a software discussion instead of a business decision.

Bottom line: The business case is not for buying software

A manufacturing ERP business case is not really asking leadership to approve software. It is asking a much more confronting question: can the current operating model bring us to the next stage of the company?

If the answer is yes, the ERP project can wait. If the team can still answer operational questions quickly, trust stock, explain margin, keep delivery promises, and grow without adding layers of manual coordination, forcing an ERP project may be premature.

But if the company is already paying through manual work, late decisions, unclear margin, fragile traceability, or operational knowledge trapped in a few people's heads, the business case is not speculative.

Bonx is the AI-native manufacturing ERP proving that implementation does not have to mean years of consulting before value appears and that ERP does not have to become another system the team spends its life feeding.

Many ERP business cases fail on timing. If value only appears after a long implementation, leadership discounts the return. If the system can start removing manual work earlier, the business case becomes easier to defend.

Bonx customers go live in 1 to 3 months, connect operations to the tools already in their stack, and use Bonx across order management, inventory, purchasing and supplier management, planning, production, quality, traceability, and logistics.

At the end of the day, the strongest ERP business case does not say, "This software has ROI." It says, "The way we run operations today already has a cost. Here is what it is, here is what we can recover, and here is what we risk if we keep pretending the current system is free."