The technical implementation of an ERP system handles the 'what' of transformation; change management handles the 'how' — preparing the organisation, stakeholders and users for the new way of working. Surveys consistently show that 60-70% of ERP implementations that underdeliver on business benefits do so because of weak change management, not weak technology. For DACH mid-market, change management is the single most underinvested area in ERP projects despite being one of the highest-leverage.
Core change-management components
Stakeholder analysis — identifying who is affected, their concerns and influence levels; tailoring engagement accordingly
Communication plan — structured communication of vision, timeline, impact, benefits across stakeholder groups
Training programme — user training matched to roles and competence levels, delivered through varied formats
Change agents and key users (see key-user concept) — respected internal champions driving adoption
Resistance management — identifying, understanding and addressing resistance before it becomes obstruction
Process documentation — new procedures documented, accessible, training-supported
Recognition and celebration — milestone achievements visible across the organisation
Change-management methodologies
Several methodologies provide structured frameworks. Prosci ADKAR: Awareness, Desire, Knowledge, Ability, Reinforcement — individual-level change framework, widely used in DACH ERP projects. Kotter's 8-step model: create urgency, build coalition, develop vision, communicate, empower action, generate quick wins, sustain momentum, anchor change — organisational-level approach. Lewin's 3-stage model: unfreeze-change-refreeze — classical foundation. McKinsey 7S framework: align strategy, structure, systems, shared values, skills, style, staff. ERP-implementation-partners often have their own methodologies (Accenture HR & Talent, Deloitte Adaptive Workforce). The right methodology matters less than the discipline of applying it consistently and integrating it with the technical implementation plan.
Common change-management problems
Recurring patterns of weakness in DACH ERP projects. (1) Late start: change management begins close to go-live, after key decisions have been made without affected stakeholder input. Resistance ferments. (2) Communication overload: high-volume but undifferentiated communication that stakeholders ignore. Better: targeted, role-relevant, consistent communication. (3) Training as afterthought: training designed and delivered in the last 2 months before go-live. Users absorb minimum information; go-live productivity drops severely. (4) Senior-management distance: executive sponsors absent from key communication, leaving the project team to carry the change message without senior authority. (5) Cultural blindness: methodology applied without adaptation to DACH-specific cultural factors (consensus orientation, hierarchical communication norms, works-council co-determination, regional differences within DACH).
Realistic change-management budget
Realistic change-management investment levels for DACH mid-market ERP projects. Minimum viable (small projects, simple operations): 5-10% of total implementation budget. Risk: change-related issues likely post-go-live. Standard (mid-market): 10-15% of total implementation budget. Reasonable for typical situations. Transformation-oriented (greenfield implementations, major process change): 15-25% of total implementation budget. Required for ambitious projects with significant business-process redesign. Crisis (turnaround scenarios): above 25%. The investment includes external change-management consultants, training development and delivery, communication campaigns, internal change agents' protected time. Companies investing the right level report substantially better adoption and business-benefit realisation than those underinvesting.
Practical recommendations
Five practical recommendations. (1) Home early: change management begins at project kick-off, not after design completion. Stakeholder engagement during design produces better requirements and reduces post-implementation resistance. (2) Identify and engage works councils: in Germany and Austria, works councils have legal co-determination rights on systems affecting employees. Early engagement and proper Betriebsvereinbarungen (works-council agreements) are essential. (3) Build a change-champion network: respected colleagues from each functional area act as change champions in addition to formal key users. Their peer credibility carries the message where official communications cannot. (4) Measure and adjust: structured measurement of adoption metrics, user-experience surveys, business-benefit indicators. Course correction based on data, not assumptions. (5) Invest in post-go-live support: the first 6-12 months after go-live are where adoption succeeds or fails. Maintain change-management capacity well beyond go-live, not just through the cutover weekend.
The ideal time is after internal requirements have been clarified and before the first vendor contact. Starting too early wastes vendor appointments; starting too late reduces your negotiating leeway. Clear signals to start are documented knock-out criteria and an internal project team with a decision-making mandate. A lead time of 4-8 weeks before vendor selection is common.
Who should be involved in ERP change management?
A mixed team of IT, business departments (accounting, sales, logistics depending on the module focus) and executive management. IT contributes the technical perspective, the business departments the process expertise, and management decides on budget and strategy. Ideally there is a dedicated project lead with 30-50% of their time available. Larger mid-market companies frequently also bring in external selection support — see selection advisory.
How long does ERP change management typically take?
The duration varies greatly with complexity: simple setups take 4-8 weeks, mid-market ERP projects 6-12 months, corporate group transitions 18-36 months. The functional preparation phase is frequently underestimated — it accounts for 30-40% of the total project time. Realistic timelines factor in holiday and quarter-end peaks as well as typical delays in data migration. A buffer of 20-30% on the initial plan is standard industry practice.
What typical mistakes occur in ERP change management?
Common pitfalls: no written requirements document, too few reference checks with vendors, underestimated data migration and a lack of change management for end users. Another mistake is committing to a vendor without a demo on your own data. Risk is minimised through a structured approach, written documentation and at least three vendors for comparison. External support significantly reduces the risk of wrong decisions.
Which tools or templates help with ERP change management?
Proven aids are a structured requirements document, a weighted vendor evaluation matrix, a demo script with your own data and a RACI model for role clarity. Templates are available at requirements document template. In addition, a project tracking tool (Jira, Asana, MS Project) with milestone tracking is worthwhile. Weekly status calls with an escalation path are mandatory in every project phase.
