OPERATIONS
Your ERP Is Not Your Operating Model
Why established B2B and manufacturing businesses need software that fits how work actually moves
On this page
Many leadership teams reach the same point as their business grows.
Spreadsheets become difficult to control. Customer information sits across email, sales tools, and individual files. Operations depend on people remembering what to do next. Reporting takes too long. Important decisions wait for someone to reconcile data from different systems.
The usual response is to buy an ERP, a CRM, a service platform, or another ready-made tool.
Sometimes that is the right decision. Sometimes it creates a new problem.
The company starts adapting its processes to the software. Teams create workarounds. People continue using private spreadsheets. Customer information becomes fragmented. The system is technically live, but the business still does not operate through it.
The problem is not always that the software is poor. The problem is that the software does not reflect how the business actually works.
Traditional ERPs solve important problems
SAP, ERPNext, and other ERP platforms can provide a strong operational foundation. They can help businesses manage finance, procurement, inventory, orders, reporting, and compliance through more structured systems.
That foundation matters. Most businesses should not build every common business function from scratch.
The difficulty begins when a company assumes that the ERP should also define every part of its operating model.
B2B and manufacturing businesses often have processes that are shaped by their specific customers, products, suppliers, approvals, production constraints, quality requirements, and commercial commitments. These processes may not fit neatly into standard modules.
A system can be powerful and still be a poor fit for a particular workflow.
Where the fit starts to break
The first signs are usually operational rather than technical.
A sales team exports information from the ERP to prepare a customer update. An operations manager maintains a second tracker because the official status is not detailed enough. A production team uses messages and spreadsheets to manage exceptions. Finance waits for several departments to confirm the same information before closing a report.
Over time, the business develops a shadow operating system around the official one.
This creates several costs:
- People enter the same information multiple times.
- Leaders receive reports after the decision window has passed.
- Teams rely on individual knowledge instead of shared visibility.
- Errors become difficult to trace.
- New employees take longer to become productive.
- The company becomes dependent on a few people who know how the work really gets done.
At that point, adding more features to the existing platform may not solve the underlying issue. The real issue is that the system does not represent the important decisions and handoffs in the business.
Why generic customer tools are often insufficient
The same problem appears with customer-facing tools.
A CRM may represent a customer through leads, opportunities, activities, and stages. A customer service platform may represent cases, tickets, and response times. These structures are useful for common scenarios.
But a B2B or manufacturing relationship is often more complicated.
A customer interaction may involve technical clarification, product configuration, pricing approval, credit checks, production planning, quality requirements, delivery coordination, installation, collections, and after-sales support.
When each part of that relationship sits in a different tool, the business loses context.
The sales team may not know what operations has committed to. Operations may not see the commercial history behind a request. Finance may lack visibility into the delivery conditions that affect payment. Customer service may not have access to the technical decisions that shaped the original order.
The result is not always a lack of effort. Often, the system has divided one customer relationship into several disconnected records.
Custom software does not mean rebuilding everything
The answer is not to reject SAP, ERPNext, CRM platforms, or packaged software.
The better question is: where should the business use standard software, and where does it need a system designed around its own way of working?
A useful approach is to separate processes into three groups.
First, there are common processes where standardization creates value. Finance, accounting, payroll, purchasing, and basic inventory management often belong here.
Second, there are business-specific workflows where the company creates its advantage. These may include complex quoting, production planning, field operations, quality approvals, dealer management, customer onboarding, or technical service.
Third, there are connecting layers that bring information from different systems into one usable operating view. This may include internal tools, workflow automation, dashboards, AI systems, or a custom interface for a specific team.
The goal is not maximum customization. It is appropriate customization.
The question is not whether the business should choose standard software or custom software. The question is where standardization improves the business and where it removes the detail that makes the business work.
What leadership teams should examine
Before approving another software purchase, leadership teams should ask:
- Which important workflows still happen outside the official system?
- Where does work wait for approval, clarification, or manual reconciliation?
- Which information is entered more than once?
- Where do teams maintain private trackers because the main system is not trusted?
- Which exceptions happen often enough to deserve a designed workflow?
- Where does customer context disappear between departments?
- Which decisions are delayed because the relevant information is not visible?
- Which parts of the process truly differentiate the business?
- What should the company own, and what should it continue licensing?
- How will adoption and business impact be measured after launch?
Build around the workflow, not the software category
A better system-building process starts with the business.
First, understand how work moves between people, teams, tools, and decisions. Then map where time, money, visibility, and output are being lost. Prioritize the opportunities based on business impact, implementation effort, adoption risk, and strategic value.
Only then should the team decide whether the answer is configuration, integration, automation, a new internal tool, or a larger custom system.
The first release should also be small enough to test in the real workflow.
A working system used by a team is more valuable than a large implementation that exists mainly in presentations. Leadership should look for evidence at every stage: a clearer operating map, a working release, measurable usage, or a confident decision not to build.
This approach also reduces the risk of creating technology that employees avoid. A system is successful only when it becomes part of the way the company operates.
The leadership decision
An ERP is a foundation. It is not automatically the operating model.
Established B2B and manufacturing businesses need reliable core systems, but they also need software that reflects their specific workflows and sources of value. In many cases, that means keeping the ERP at the centre while building focused systems around the processes where the business is most complex or most differentiated.
The strongest technology decisions are rarely about buying the most advanced platform.
They are about understanding the business clearly enough to know what should be standardized, what should be redesigned, and what should be built around the company itself.
The right starting point is usually one important workflow.
Find where execution is leaking. Understand why. Build the smallest useful system around it. Then expand only when the business has evidence that the system is improving the way work gets done.