Standardize Without Creating Shadow Work: ERP Customization and the Cost of Forcing the Wrong Fit

The standardization debate is usually framed too narrowly

Most ERP programs eventually reach the same argument. One side says: stay standard, reduce technical debt and protect upgradeability. The other says: the business is different and the process has to work in real life. Both sides can be right.

Standardization is one of the most important sources of ERP value. It reduces unnecessary variation, simplifies support and forces the organization to question legacy habits. But an enterprise system exists to support a real operating model. If the standard process creates an operational burden the business cannot absorb, the complexity does not disappear. It moves.

In many organizations in our region, that new address is not another application approved by architecture. It is an Excel file, an offline approval, a local reporting workbook, a manual reconciliation or a process that depends on one experienced person remembering what to do.

Standard should be the default - not a religion

Earlier in my implementation career, I was more rigid about this. Keep the system standard and make users adapt. Customer-side work changed the question I ask.

Now I ask: if we reject this requirement, where will the work go? If the answer is a governed process change, good. If the answer is a spreadsheet, an email chain or an undocumented manual control, technical purity may be creating enterprise complexity somewhere else.

Customization may still be the wrong answer, but the trade-off is now complete.

Start with the reason for the requirement

When a user asks for a customization, the first answer should not automatically be yes or no. The first question is why.

Some requests are legacy habits. Some disappear once the team understands the standard. Some compensate for poor master data or an unresolved policy. Some are regulatory. Some support a genuinely differentiating capability. Some are not system requirements at all.

Separate the business need from the requested technical solution. A request for a report may really be a missing decision right, a data requirement, a process gap or a control problem.

Measure the cost of forcing the standard

Teams are usually good at estimating the visible cost of customization: development, testing, lifecycle support, upgrade impact and technical debt. They are less disciplined about estimating the cost of refusing it.

That cost may be additional manual work, slower cycle time, duplicated data, more reconciliation, more training burden, weaker control, reduced adoption or a shadow process that becomes permanent.

The decision authority should compare two complete options, not one visible technical cost against one invisible operating cost.

Shadow work is unmanaged customization

A spreadsheet with business logic is a form of customization. An informal approval chain is a workflow. A manually maintained mapping is master data. A local database is an application. The difference is that these assets often have weaker controls, weak traceability, unclear ownership and no lifecycle governance.

ISACA's 2024 discussion of shadow IT highlights the same risks from another angle: data inconsistency, compliance exposure, lack of visibility and operational inefficiency. That is why I do not treat off-system work as free simply because it did not create a development object in the ERP.

The architecture can look cleaner while the enterprise becomes more complex.

Shadow work also becomes AI-readiness debt

The next generation of ERP raises the stakes. AI assistants and agents need governed data, clear process context, reliable authorizations and visible business rules. If critical logic lives in personal spreadsheets, chat approvals or undocumented manual bridges, the AI layer sees only part of the enterprise.

So the standardization decision is no longer only about upgrades and maintenance. It is also about whether the company is creating a reliable digital representation of how work actually happens.

Use a governance decision, not a consultant-user negotiation

Material deviations from standard should not be decided informally between one consultant and one key user. A design authority or steering mechanism should see the business requirement, the standard option, process or policy changes required, operating burden, extension approach, long-term maintenance, control implications and the risk of shadow work.

The customer should own the decision. The implementation partner provides technical and process advice. Architecture protects long-term integrity. Business owners accept the operating consequences.

If neither side is prepared to own the consequence, the design decision is not ready.

Closing takeaway

The goal of ERP standardization is not to win an argument against customization. It is to reduce unnecessary complexity while creating an operating model the business can actually sustain.

Standard should be the default. But if protecting the technical core forces the business to build an uncontrolled operating system around it, the enterprise has not become simpler. The complexity has simply changed address.

For the SAP-specific treatment of Fit-to-Standard and Clean Core, see the related insight From Vision to Value: Avoiding Common Pitfalls in SAP S/4HANA Transformations.