There Is No Such Thing as “No Design” in an ERP Implementation
ERP projects rarely fail because the technology is wrong. They fail because the business never made its decisions explicit.
One of the most persistent myths in ERP implementations is the idea that you can “avoid design” by going out of the box. That if you resist customisation and stick to standard workflows, somehow you bypass the need to think too hard about how the business actually runs.
You can’t because… there is no such thing as no design. There is either explicit design or accidental design.
“Out of the Box” is still a Set of Decisions
When implementation partners talk about “out of the box,” what they usually mean is minimal customisation, standard workflows, and vendor-defined best practice. What they never mean is no decisions.
Even the most vanilla ERP implementation requires choices. Revenue has to be recognised somewhere, costs have to land somewhere and approvals have to trigger (or not!). Surely your reports have to show something to the board.
Those choices are design, whether you label them that way or not. If these decisions aren’t made deliberately, they won’t just disappear. They simply get made implicitly through configuration defaults, legacy habits, or assumptions carried over from another client’s implementations.
This is still design but with no ownership.
“Best Practice” is not Singular
One of the most dangerous phrases in ERP is “Best Practice”.
Because best practice for whom?
ERP vendors define best practice based on broad averages and global applicability. IT is designed to offend as few organisations as possible, not to optimise your operating model, risk appetite or growth strategy.
Treating best practice as objective truth is how finance teams end up with over-engineered processes, frustrated users and workarounds appearing before go-live has even landed.
Configuration is Business Policy
This is the point most CFOs instinctively understand, but ERP projects often ignore.
Every configuration decision encodes policy; who can post journals, when revenue moves from accrued to recognised, and what control is mandatory.
If these policies aren’t agreed before configuration they will get decided by whoever is in the room, optimising for system logic rather than business intent.
Once embedded this is surprisingly hard to unwind. At this point, the ERP is no longer supporting the business. The business is contorting itself around the ERP.
Your Implementation Partner can’t Guess how you want to Run the Business
Even excellent implementation partners have blind spots because they don’t sit in your board meetings, they don’t own your covenant risk and they don’t carry your exit timeline.
When decisions are left implicit, partners will do what any rational delivery team does: default to what they’ve seen before and optimise speed and completion.
The burden sist with leadership to be explicit about what matters commercially, where flexibility is required and where compromise is not acceptable.
Silence is still a decision made out of your control.
ERP Complexity comes From Ambiguity, not Business Sophistication
This is one of the biggest misconceptions I see. ERP implementations don’t become complex because the business is “too complicated”.
In reality, complexity emerges when decisions are postponed and alignment is assumed instead of tested.
Ambiguity multiplies effort: rework appears, exceptions proliferate, shadow processes emerge, and post-go-live “fixes” become the norm.
Clarity simplifies systems even in complex organisations.
If you don’t like “Design,” Call it a Decision Phase
Some organisations resist the idea of a design phase because it sounds slow, theoretical, or like something a consultant would insist on!
Fine then. Don’t call it design.
Call it what it actually is: a decision phase.
A structured point where leadership explicitly agrees how the business wants to operate, which trade-offs it is willing to accept, and what the ERP must enable and what it must not constrain.
This doesn’t slow ERP projects down. It prevents them slowing down later, when change is far more expensive and far more political.
The CFO’s Role: Making the Implicit Explicit
For CFOs and PE sponsors, the real risk in ERP isn’t technology. It’s allowing assumptions and historical compromises to continue to harden into the future operating model without ever being examined.
ERP is not just a system implementation. It’s a crystallisation of how the business believes it should run.
The only real question is whether that belief was examined or accidental.
A Practical Takeaway: How to Spot Accidental Design Early
If you want something concrete to take into an ERP programme, here are a few signals I use to spot when accidental design is creeping in:
- Decisions are being described as “system constraints” rather than business choices
- “We’ll sort that out later” appears regularly in workshops
- Best practice is cited without anyone articulating why it suits this business
- Configuration workshops feel operational, but no one can explain the policy they’re encoding
- The finance team starts talking about workarounds before go-live
If you recognise more than one of these the issue isn’t the ERP, it’s that decisions are still implicit.
A Simple ERP Decision Readiness Check
Before configuration begins, leadership should be able to answer in plain language:
- What commercial outcomes matter most over the next 2–3 years?
- Where are we optimising for control, and where for speed?
- What flexibility do we need to preserve post–go-live?
- Which policies are non-negotiable, even if the system makes them harder?
- What are we explicitly choosing not to optimise for right now?
If those answers aren’t clear, no amount of “out of the box” will save the project.
If this resonates and you want support making these decisions explicit before they get locked into a system, explore our Finance Transformation services.