ERP · Functional design
Is your ERP a catalyst or a straitjacket?
If the system feels rigid or “not made for us”, the problem is usually not the software. It is the functional logic. Here is how to tell the difference — and what to do about it.
There is a moment in many ERP programmes when the conversation changes from “how do we improve the business?” to “what does the system allow us to do?” That is the moment the system stops being a catalyst and starts becoming a straitjacket.
It rarely feels like a technology failure. The software is stable. The modules are live. The team is trained. And yet the chart of accounts does not reflect how management thinks about margin, the approval matrix breaks under urgency, and the board pack still gets rebuilt in a spreadsheet. The system is working as designed. The design is the problem.
Most ERP failures are not technology failures. They are functional-logic failures: the system does not match how the business actually works.
Functional design is the bridge
Functional design translates business reality into system rules. It decides how decisions are made, how value flows, where risk sits and how exceptions are handled. Those decisions then become the chart of accounts, dimensions, workflows, approvals, controls and reports.
When that translation is skipped, the implementation defaults to the software’s template. The result may be technically correct and operationally wrong.
The autopilot trap
Many teams go on autopilot during design. Instead of asking, “How does the business really work?”, they ask, “What does the system allow us to do?” The question feels pragmatic. It keeps the project moving. It also quietly transfers control of the operating model to the software vendor’s default.
Great implementations do the opposite. They start with reality — how decisions are made, how value flows, where risk sits — and then translate that into system rules, structures and controls.
Five straitjacket patterns
1. The chart of accounts mirrors the software template
If the chart of accounts reflects the vendor’s standard rather than how management thinks about margins, cost drivers, business units or products, every report becomes a manual translation. The ledger is technically tidy and commercially unhelpful.
2. Workflows ignore the real approval chain
The system may show a clean approval hierarchy, but the real decision may involve an informal influencer, a group CFO, a technical authority or a delegated limit that nobody configured. When the workflow does not match the real chain, people route around it.
3. The approval matrix breaks under urgency
A matrix that looks clean on paper often fails when a payment, purchase or payroll change is urgent. The business creates an exception outside the system, and the control disappears. Good design includes escalation and delegation without abandoning the audit trail.
4. Exception paths live outside the system
Email, WhatsApp and spreadsheets become the real workflow. The ERP records the normal path and ignores the exceptions. Over time, the exceptions become the operating model and the system becomes a reporting afterthought.
5. Reporting needs a monthly rebuild
If the board pack, segment profitability or cash report is rebuilt in Excel every month, the system is not producing the management view. The data model, dimensions or account structure is wrong for the decisions being made.
What catalyst design does differently
- Starts with decisions, not screens.
- Designs the normal path and the exception path.
- Keeps controls without blocking the business.
- Makes reporting a by-product of how transactions are structured.
- Treats configuration as an operating-model decision.
- Documents the logic so the business can change it deliberately.
The six-question test
Use these questions in a design review, a post-go-live audit or a rescue assessment. A “no” is not automatically a failure, but a pattern of “no” usually explains why the system feels rigid.
- Does the chart of accounts reflect how management thinks about margin, cost and performance?
- Do the workflows match the real approval chain, including delegated authority?
- Can urgency escalate without bypassing control?
- Are exception paths captured inside the system, with evidence?
- Can the board pack be produced without rebuilding it in a spreadsheet?
- Can the system absorb a new entity, product line or operating model without a rebuild?
The KSA/GCC context
Local operating reality makes functional design more important, not less. Saudi groups often combine family ownership, multiple entities, sponsorship-linked employee records, government contracts, Arabic documents and group-level reporting. ZATCA, WPS, GOSI, Qiwa and payroll controls add statutory requirements that a generic template may not reflect.
- Group reporting versus entity-level statutory records.
- Approval chains that cross entities, owners and delegated authorities.
- Project and contract profitability for government and enterprise work.
- Payroll, GOSI, WPS and end-of-service inside the same operating model.
- Arabic documents and local employee self-service.
- Multi-branch and multi-bank operations.
Reconfigure, rescue or replace?
Not every straitjacket needs a new system. The right response depends on where the constraint sits.
| Constraint | Likely response |
|---|---|
| Chart of accounts, dimensions and reports | Redesign the financial model and reporting structure. |
| Workflows, approvals and exceptions | Reconfigure rules and controls; test normal and exception paths. |
| Adoption and process discipline | Retrain, clarify ownership and reinforce the operating model. |
| Structural implementation failure | Independent rescue and remediation, or a controlled reimplementation. |
| Platform cannot support the model | Replace or re-platform with a clear functional design. |
How to fix it without automatically reimplementing
- Review how decisions are actually made and where approvals break.
- Map the real value flow, cost drivers and reporting needs.
- Document normal and exception paths, including urgency and delegation.
- Redesign the chart of accounts, dimensions and management reports.
- Reconfigure workflows, controls and approval rules.
- Test the normal path, the exception path and the audit trail.
- Retrain users and assign ownership of the operating model.
Where this fits
This is the design layer that sits before configuration and after strategy. It is different from an ERP readiness review, which focuses on data, stakeholders, personas and go-live readiness. It is also different from an ERP rescue, which diagnoses a live system that is already failing.
Read the ERP readiness guide if you are planning a new implementation, the 12-point ERP checklist if the system is already live, and Making ERPs Agentic for the layer that comes after a sound functional foundation.