Many ERP projects begin with software requirements.
What modules do we need?
Which reports?
What integrations?
How should approvals work?
What should the system automate?
Those questions matter, but they are not the first questions leadership should answer. Before deciding how ERP should work, the company needs to decide how the business itself should work.
- Which processes should be standard?
- Where is variation justified?
- Who owns each end-to-end process?
- Who can approve what?
- How should exceptions be handled?
- What should critical business information mean across departments and locations?
- Which legacy processes should disappear instead of being recreated in a new system?
Those decisions form the ERP operating model. At Softengine, we view ERP configuration as the point where management decisions become operating rules. If those decisions are unresolved, the software project inherits the disagreement.
What an ERP Operating Model Actually Is
An ERP operating model is not a technical architecture. It is the business logic underneath the system.
It defines how work should move through the organization, who owns each process, where control is required, how decisions are made, and which information should be consistent across the company.
A practical ERP operating model addresses:
- Process ownership
- Standard workflows
- Roles and responsibilities
- Approval authority
- Decision rights
- Exception handling
- Master-data ownership
- Common business definitions
- Cross-functional handoffs
- Reporting responsibilities
- Control points
ERP eventually translates those choices into workflows, permissions, approval rules, data structures, reporting logic, and system behavior.
That is why many configuration questions are actually management questions.
Current-State Process Maps Are Only the Starting Point
Understanding how the company operates today is essential.
But documenting the current state is not the same as designing the future state.
A process-discovery exercise may reveal:
- Three different purchasing processes
- Duplicate customer records
- Department-specific spreadsheets
- Manual handoffs
- Repeated approvals
- Different definitions of the same KPI
- Workarounds created around legacy-system limitations
The wrong conclusion is:
“The new ERP needs to reproduce all of this.”
The better question is:
“Which parts of this process should still exist when we are finished?”
An ERP project is one of the few opportunities a growing company gets to challenge operating habits that accumulated over years.
If every current process automatically becomes a requirement, the new system can become a more expensive way to run the old business.
Standardize What Should Be Standard
Growing companies often reach a point where every location, department, or manager has developed a slightly different way of completing the same work.
That may feel flexible, but at scale, it creates friction.
Consider processes such as:
- Customer setup
- Vendor setup
- Item creation
- Purchase approvals
- Order entry
- Inventory transactions
- Project setup
- Month-end procedures
- Master-data maintenance
- KPI definitions
If there is no business reason for those processes to differ, leadership should question why they do.
Standardization makes training easier, controls clearer, reporting more consistent, and future expansion more manageable.
It also gives the ERP implementation team a much stronger design target.
Instead of asking the software to support five versions of the same workflow, the business can define the version it actually wants to scale.
Decide Where Variation Is Actually Justified
Standardization does not mean forcing every part of the company into identical processes.
Some variation is legitimate.
A regulatory requirement may differ by location.
A customer may require a specific fulfillment process.
One business unit may operate under a genuinely different model.
An international operation may have different legal or financial requirements.
The key question is:
Is the variation necessary, or is it simply historical?
That distinction matters.
“Location A has always done it this way” is not the same as “Location A must operate this way.”
A strong operating model standardizes intentionally while preserving differences that have a clear business reason.
Define Decision Rights Before You Define Workflow
Approval workflows often expose unresolved organizational questions.
Who can approve this purchase?
Who owns the customer-creation process?
Who can change item master data?
Who decides whether an exception is valid?
Who has final authority when finance and operations disagree?
ERP can route a transaction to an approver, but it cannot decide who should have that authority.
Leadership has to do that first.
Process ownership and decision rights should be explicit before detailed configuration begins. Otherwise, the ERP project becomes the setting where organizational ambiguity is turned into system complexity.
Design Exceptions Instead of Letting Them Evolve
No business process is completely standard.
There will always be exceptions.
The operating-model question is whether those exceptions are controlled.
Leadership should decide:
- What qualifies as a legitimate exception
- Who can approve it
- How it should be documented
- When escalation is required
- Whether recurring exceptions should be reviewed
Without those rules, people create their own paths around the system.
A spreadsheet appears.
An approval is bypassed.
A manual process becomes permanent.
Another customization is requested.
Over time, the standard workflow stops being standard.
Exceptions should be designed into the operating model; not improvised after go-live.
Agree on What the Data Means
- What is an active customer?
- What counts as available inventory?
- When is an order complete?
- What is committed cost?
- How is gross margin calculated?
- What qualifies as on-time delivery?
- Who owns the customer record?
- Who can create or change an item?
These are not reporting questions; they are operating-model questions.
The system can calculate a metric perfectly and still produce the wrong management conversation if different departments interpret it differently.
Good ERP design therefore requires both data ownership and common definitions.
The Operating Model Decisions That Shape ERP Configuration
| Operating Model Decision | Business Question | ERP Design Impact |
| Process standardization | Which workflows should work the same everywhere? | Workflow configuration |
| Process ownership | Who is accountable for the end-to-end process? | Governance and change control |
| Approval authority | Who can approve which transactions? | Approval rules and permissions |
| Master-data ownership | Who creates and maintains critical records? | Security and data controls |
| Exception policy | When can the standard process change? | Escalations and alternate workflows |
| Reporting definitions | What does each business metric mean? | Reporting logic |
| Local variation | Which differences are genuinely required? | Location or entity configuration |
| Role design | Who performs, reviews, and approves each activity? | Access and responsibility |
| Integration ownership | Which system owns each record? | Integration and data architecture |
The rule Softengine encourages companies to keep in mind is straightforward:
The configuration should implement a business decision, not substitute for one.
Why Weak Operating Models Create Over-Customization
One of the fastest ways to increase ERP complexity is to enter configuration with unresolved process differences.
Finance wants one process.
Operations wants another.
One location wants to preserve its spreadsheet.
Another wants an entirely different approval path.
No one has authority to define the standard.
The compromise becomes customization.
That does not mean customization is bad.
There are cases where unique processes create real competitive value and deserve specialized functionality.
The issue is using customization to preserve habits the business has never challenged.
Every unnecessary variation adds another process to train, test, maintain, support, and explain.
Before customizing ERP, leadership should ask:
Are we protecting a legitimate business requirement, or avoiding a difficult standardization decision?
Warning Signs You Are Configuring ERP Too Early
Several signals suggest the operating model needs more work:
- Every department submits its own requirements with no process owner
- Teams disagree about basic terminology
- Approval authority is unclear
- No one owns master data
- Locations use the same transaction differently
- Spreadsheets are treated as permanent requirements
- Exceptions outnumber standard workflows
- “We have always done it this way” drives design
- Customization discussions begin before process standardization
- Leadership expects the ERP implementation team to decide business policy
These are not primarily software problems.
They are leadership decisions that have not been made yet.
What Leadership Should Define Before ERP Configuration Starts
The goal is not another 100-line ERP checklist.
Leadership should establish the operating principles that will guide everything downstream.
- Which processes should become company standards?
- Where is variation justified?
- Who owns each process?
- Who owns critical data?
- Which approvals represent real business controls?
- How should exceptions be governed?
- Which metrics need one common definition?
- Which legacy processes should be retired?
- Which integrations are actually necessary?
- Where does the business genuinely need differentiated functionality?
Once these questions are answered, ERP design becomes much more focused.
The implementation team is no longer trying to discover how the business should operate while simultaneously configuring the software.
How Softengine Helps Connect ERP Design With the Operating Model
Growing companies often need help separating three things:
How the business works today.
How leadership wants it to work going forward.
How ERP should be configured to support that future state.
That can involve process discovery, future-state workflow design, requirements definition, role and approval design, master-data planning, reporting requirements, integration planning, ERP configuration, data migration, and user training.
The software matters.
But the strongest ERP foundation comes from making the operating decisions first.
ERP Should Support the Business You Intend to Run
ERP does not decide how the company should operate.
Leadership does.
The system eventually translates those choices into workflows, roles, permissions, approvals, data structures, controls, exceptions, and reporting.
If those decisions are unresolved, the ERP project becomes the place where organizational disagreements surface.
If they are clear, the implementation has a much stronger foundation.
Before asking how the software should be configured, start with the more important question:
How should the business itself work?
Then configure ERP around that answer.
Book a call with our team.
FAQs
1. What is an ERP operating model?
An ERP operating model defines how processes, ownership, decisions, approvals, exceptions, roles, data, controls, and reporting should work before those choices are translated into ERP configuration.
2. How is an ERP operating model different from an ERP strategy?
ERP strategy defines why the company is investing in ERP, the business outcomes it expects, and the overall direction of the program. The operating model defines how the company should actually work; who owns processes, what gets standardized, where variation is allowed, and how decisions are governed.
3. Why should process standardization happen before ERP configuration?
Because ERP configuration turns process decisions into system behavior. If the business has not agreed on the future process, configuration can preserve conflicting workflows, unnecessary approvals, legacy workarounds, or department-specific rules that increase complexity.
4. What should leadership define before choosing or configuring ERP software?
Leadership should define process standards, justified variations, process ownership, approval authority, master-data ownership, exception rules, common business definitions, reporting responsibilities, and which legacy processes should be retired.
