Autor: Diethard Engel

(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

1. Embedded domain knowledge. Vendors encode patterns observed across many customers — they are not random. Using the standard leverages that collective learning.
2. Lower TCO and faster upgrades. Less customization → fewer integration points → easier upgrades and lower long-term cost.
3. 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

1. 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.
2. 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.
3. Reference-class benchmarking
   Compare your process metrics against industry peers to validate whether your way really delivers superior outcomes.
4. Delta-governance & gating
   Only approved deltas proceed to build; each delta must include ROI, test plans, upgrade impact and a 3-year maintenance estimate.
5. Data & master-data cleaning
   Heavy investment up front in data quality and master-data alignment (the most frequent root cause of go-live issues).
6. 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.
7. 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.
8. 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.
9. 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)

1. Decision & Discovery (4–6 weeks) — Fit-to-Standard workshops, select pilots, map deltas and run ROI tests.
2. Pilot & Validate (8–12 weeks) — Deploy standard + approved deltas in 2 representative sites (one top, one bottom), test hard for a full operating period.
3. 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.

J.C. Penney’s $1B loss under a celebrated CEO wasn’t about strategy—it was about overconfidence. The Dunning–Kruger Effect shows up in change management more often than we admit: leaders underestimate complexity, teams assume they’ll “figure it out,” and culture gets sidelined.

In my new article, I explore how this bias derails transformations—and what to do instead.

Another Cautionary Tale: The Dunning–Kruger Effect in Change Management — When Overconfidence Derails Transformation

Consider J.C. Penney’s 2012–13 transformation under CEO Ron Johnson—a proven executive from Apple and Target. He confidently rolled out “fair and square” pricing and drastically redesigned stores. But he underestimated how deeply customers valued coupons and markdowns. He moved fast, but without testing or aligning with the brand’s culture. Within 14 months, revenue had fallen 25%, the company lost nearly $1 billion, and thousands of jobs were cut.

This dismissal of core stakeholders and cultural dynamics is a textbook case of the Dunning-Kruger Effect in transformation initiatives.

---

What Is the Dunning–Kruger Effect?

At its core, it’s a cognitive bias: those with limited knowledge often overestimate their competence, while experts tend to underestimate it.

In transformation contexts:

• Leaders may assume change is simple: “just tweak processes,” or “everyone will adapt.”
• Teams may overload under the assumption that “we’ll figure it out.”

---

Why It Matters in Change Management

Change is complex, high-stakes, and fraught with resistance.

The Dunning–Kruger Effect manifests as:

• Ignoring stakeholder pushback
• Rushing without embedding governance or testing
• Overconfidence in “patch-on-the-fly” solutions

And the consequences? Delayed returns, broken morale, failed programs.

---

A Framework to Mitigate It

1. Diagnose before you decide—use structured interviews, quick diagnostic sprints to ground assumptions.
2. Surface hidden risks—on culture, governance, stakeholder alignment.
3. Bring in experienced leadership early—not just internal availability.
4. Test early, iterate fast—pilot first, scale later.
5. Stay humble—be prepared to course correct mid-transformation.

---

Why Familiarity Matters

Transformations often fail not for lack of intent, but because they’re treated like “change on the side.” The Dunning–Kruger trap lies in ignoring the hidden layers—culture, governance, resistance, and BAU alignment.

Skill, experience, and discipline are not optional. Without them, transformation becomes a mirage.

Transformation doesn’t fail because of strategy. It fails because the business can’t execute change while keeping day-to-day operations running.

I’ve seen this pattern again and again:

• Management is already at 120% capacity.
• A major transformation or integration lands on top.
• Leadership is expected to run BAU and lead the program. The result? Delays, firefighting, stalled projects, missed synergies — and, most critically, lost business performance.

That’s why I built the Operate-while-Transform capacity model. It protects BAU while accelerating transformation.

---

The Core Idea

Business-as-usual must not suffer because of transformation. Shareholders expect performance and change. To deliver both, we need a deliberate capacity model that frees bandwidth for transformation without risking revenue, customers, or employees.

---

How it Works

1. Capacity Scan Map management workload. Where is leadership consumed by routine? Where is true change capability hidden?

2. Offload Routine Work Shift recurring or transactional activities (reporting, approvals, admin) downward or outward. Create air cover for managers.

3. Sharpen Decision Forums Redesign meeting cadence and governance so leaders spend time on decisions and priorities, not updates or firefighting.

4. External Program Muscle Bring in experienced transformation leaders to drive structure, speed, and orchestration. Execution discipline comes from outside, not from overstretched insiders.

5. BAU Health Check Track operational KPIs (OTD, revenue, customer metrics) in parallel with transformation KPIs. If BAU slips, you re-balance early.

---

What It Takes

Even the best-designed capacity model fails without top management’s true commitment.

• Leaders must prioritize change alongside BAU, not treat it as optional.
• They must protect time and attention, resisting the temptation to drown the program in unnecessary meetings, reviews, or politics.
• They must walk the talk: if management drags its feet, employees will too.

In short: Operate-while-Transform works only if leaders want it to work.

---

Why It Works

• Speed: Freed-up capacity accelerates execution.
• Focus: Leaders can actually lead transformation instead of juggling tasks.
• Security: BAU KPIs stay in view — ensuring no loss of revenue or customers.
• ROI: Faster execution means faster synergies, earlier cash impact, and higher deal value.

---

The Payoff

When you protect BAU and accelerate transformation, value lands earlier:

• Synergies realized faster
• Costs reduced earlier
• Growth captured without losing customers
• Employees stay engaged — because daily work doesn’t collapse under the weight of change

---

💡 Operate-while-Transform isn’t about working harder. It’s about designing capacity deliberately so transformation can succeed without breaking the business you’re transforming.