(Or: Don’t force the software to fit your bad habits.)
ERP and other enterprise software ship with industry-standard processes for a reason. Vendors and platform teams have observed thousands of implementations and baked best practices into their products. Choosing to adopt those standards — or consciously departing from them — is a strategic decision. Treating it as an ideological one (“this is how we’ve always done it”) is where trouble starts.
Hard fact: ERP projects have a high failure rate when organizations over-customize or fail to align processes to the target system.
Below I explain why the standard is the standard, share two real-world cautionary examples, and give a short, practical playbook for how to adopt a new standard safely — plus the risks and opportunities you should be ready for.
Two cautionary examples
Haribo — mapping workflows went wrong
Haribo’s SAP S/4HANA migration exposed a painful truth: insufficient mapping of legacy processes to the new system led to inventory tracking failures and product shortages. The immediate business result was material sales disruption for a core product. This was not a technical bug in isolation — it was a failure to reconcile shop-floor reality with the ERP’s process model.
Target Canada — compressed timelines + new inventory system
Target’s ill-fated Canadian expansion is a textbook case where an aggressive go-live timetable and unready supply-chain systems produced empty shelves, wrong inventory counts and severe reputational damage. Analysts point to new inventory software, rushed cutover and data/operational misalignment as central causes. The lesson: implementing a new standard process at scale without adequate testing and paced rollout creates catastrophic operational risk.
Why the “standard” matters
- Embedded domain knowledge. Vendors encode patterns observed across many customers — they are not random. Using the standard leverages that collective learning.
- Lower TCO and faster upgrades. Less customization → fewer integration points → easier upgrades and lower long-term cost.
- Predictable behavior. Standardized processes are easier to test, monitor and govern at scale.
But standards are not gospel. You must evaluate where your business has a genuine, defensible reason to deviate — and where deviation is just legacy inertia.
When changing the standard makes sense (and when it doesn’t)
Change the standard if:
- You have a documented, recurring competitive practice that genuinely creates measurable differentiation (e.g., unique pricing model, proprietary manufacturing step).
- You can quantify the expected incremental margin or strategic benefit and it clearly outweighs the customization/maintenance cost.
- You have the resources and governance to carry forward custom code and test it across upgrades.
Don’t change the standard if:
- The reason is “this is how we’ve always done it.”
- The benefit is marginal and hard to measure.
- You can achieve equivalently with minor process redesign or a configuration (not customization).
What it takes to adopt a new standard — the execution checklist
- Executive decision & trade-off mandate
Senior leadership signs a clear “fit-to-standard” decision: we adopt vendor best practice except for pre-approved deltas. Document the business case for any deltas. - Fit-to-Standard workshops (Explore / sandbox)
Run structured sessions where the vendor shows the preconfigured process in a sandbox; identify gaps by capability (not by habit). Capture deltas explicitly. - Reference-class benchmarking
Compare your process metrics against industry peers to validate whether your way really delivers superior outcomes. - Delta-governance & gating
Only approved deltas proceed to build; each delta must include ROI, test plans, upgrade impact and a 3-year maintenance estimate. - Data & master-data cleaning
Heavy investment up front in data quality and master-data alignment (the most frequent root cause of go-live issues). - Pilot → scale approach
Pilot the standard (and any deltas) in representative sites (top & bottom performers) and validate operationally for a full business cycle before broad rollout. - Change management, training, and visual work instructions
The people side matters. Simple, local language instructions and on-the-job training reduce “workarounds” that reintroduce legacy behavior. - Smoke tests and rollback plans
Define success/failure criteria and automated smoke tests. Have rollback and fallback processes in place for critical customer-impact flows. - Upgrade & lifecycle plan
Treat customization as a product that must be supported through upgrades; budget and ownership must be explicit.
Risks (if you force the software to fit old ways)
- Integration fragility — custom code breaks more easily and increases TCO.
- Upgrade paralysis — future upgrades become expensive or impossible without full rework.
- Operational disruption — inventory, order-to-cash and manufacturing flows can fail, harming revenue. (See Haribo / Target.)
- Hidden governance costs — ongoing patches, vendor/sii disputes, and shadow IT.
Opportunities (if you adopt the standard sensibly)
- Faster time to value — fewer dev iterations, quicker stabilization.
- Lower long-term cost of ownership — predictable upgrades, smaller support footprint.
- Easier scaling — standardized operations are repeatable across sites/regions.
- Better analytics & transparency — consistent processes generate reliable KPIs.
Practical example: a recommended mini-roadmap (3 high-level milestones)
- Decision & Discovery (4–6 weeks) — Fit-to-Standard workshops, select pilots, map deltas and run ROI tests.
- Pilot & Validate (8–12 weeks) — Deploy standard + approved deltas in 2 representative sites (one top, one bottom), test hard for a full operating period.
- Scale & Govern (12–24 weeks) — staged rollout, training, governance, upgrade plan, and metrics dashboard.
A final, blunt thought
Industry-standard processes are not arbitrary. They’re codified experience. That doesn’t mean never customize — but it does mean you must choose customization deliberately, with full transparency on cost, upgrade-risk and operational testing. Too many high-profile failures (Haribo, Target Canada and others) began with the same human error: treating process as identity rather than as a lever to improve.
Want to talk through a concrete decision framework you can apply to your ERP or operating-model program? I can help you run a focused fit-to-standard workshop, identify defensible deltas, and design a pilot that protects the business while unlocking faster value. Connect with me on LinkedIn or by email: diethard.engel @ de-mcs.de.