8. April 2026Coaching Digitalisierung Transformation

Digitale Transformation: Warum Kompetenz vor Technologie kommtDigital transformation: why competence comes before technology

800.000 euro in ein neues ERP-system. 14 monate später: eine akzeptanzrate von unter 40 prozent, spürbare produktivitätsverluste und frust auf allen unternehmensebenen. eine geschichte, die sich in deutschen unternehmen …An 800,000-euro ERP rollout still failed because competence was missing, not the software. The article explains which skills actually drive adoption.

kurz gesagt

800.000 Euro in ein neues ERP-System, 14 Monate später unter 40 Prozent Akzeptanz. Die Software war technisch einwandfrei. Das Problem lag woanders.
Resilienz, Lernkompetenz und kritisches Denken fehlten strukturell. Die Mitarbeitenden hatten keine Werkzeuge, um mit der Unsicherheit der Systemveränderung umzugehen.
Nach sechs Monaten gezieltem Kompetenzaufbau: 78 Prozent Akzeptanz. Nicht durch eine neue Software, sondern durch neue Fähigkeiten.

Das Ausgangsbild: Technisch einwandfrei, menschlich gescheitert

800.000 Euro in ein neues ERP-System. Eine ausführliche Einführungsschulung, ein professionelles Implementierungsteam, ein klarer Zeitplan. 14 Monate später lag die Akzeptanzrate bei unter 40 Prozent. Mitarbeitende griffen auf alte Abläufe zurück, Produktivität stagnierte, Führungskräfte fragten sich, was schiefgelaufen war.

Das System war technisch einwandfrei. Die Implementierung verlief nach Plan. Was fehlte, wurde erst im Coaching sichtbar: Die Mitarbeitenden hatten strukturell keine Fähigkeiten entwickelt, mit der Unsicherheit umzugehen, die jede größere Systemveränderung mitbringt.

Das eigentliche Problem: Fehlende Annahmen über Selbsterklärung

Viele Transformationsprojekte starten mit demselben Grundfehler. Die Software wird eingeführt, eine gründliche Schulung wird organisiert, und danach erwartet man Adoption. Was dabei übersehen wird: Ein System, egal wie intuitiv gestaltet, trifft auf Menschen mit unterschiedlichen Lernbiografien, Stressmustern und individuellen Reaktionen auf Veränderung.

Im beschriebenen Fall war keines davon ein persönliches Versagen. Die Mitarbeitenden hatten schlicht keine Übung darin, mit einem neuen System zu arbeiten, während der laufende Betrieb weiterging. Resilienz, Lernkompetenz und kritisches Denken standen nicht zur Verfügung. Wer in dieser Situation Fehler macht, greift auf das Bewährte zurück. Das ist kein Widerstand. Es ist Schutzverhalten.

Warum das strukturell immer wieder passiert und was die konzeptionelle Antwort ist, erklärt Digitale Transformation: Warum Kompetenz entscheidet.

Was die Wende brachte: Kompetenzaufbau statt Tool-Schulung

Die Entscheidung nach der Analyse: Weitere Tool-Schulungen würden das Problem nicht lösen. Stattdessen wurde ein begleitetes Kompetenzentwicklungsprogramm aufgesetzt, eingebettet in den laufenden Arbeitsalltag, nicht als Zusatzbelastung neben der Arbeit.

Das Programm adressierte drei Bereiche: Lernkompetenz (neues Wissen aktiv einordnen und anwenden), Resilienz (mit Fehlern und Rückschlägen produktiv umgehen) und kritisches Denken (Prozesse hinterfragen, statt sie zu reproduzieren). Nach sechs Monaten stieg die Akzeptanzrate von unter 40 auf 78 Prozent.

Das System hatte sich nicht verändert. Die Menschen hatten gelernt, mit ihm und mit Veränderung generell anders umzugehen.

Vorgehen: Was Kompetenzaufbau vor der ERP-Einführung erleichtert

Den Ist-Prozess aufnehmen, bevor die Software kommt. Wer weiß, wie heute gearbeitet wird, erkennt, wo das neue System auf bewährte Abläufe trifft. Diese Reibungspunkte sind die wichtigsten Lernorte. Wie die Aufnahme gelingt, zeigt Prozesse sichtbar machen.
Frühzeitig ein Pilotteam aufbauen. Wenige Menschen, die das System vor dem großen Rollout intensiv testen und Feedback geben. Ihr Wissen verbessert die Einführung und ihre Erfahrung überzeugt Kollegen mehr als jede Präsentation.
Fehler als Trainingsaufgaben rahmen. Wenn jemand mit dem neuen System nicht zurechtkommt, ist das Information, keine Schwäche. Teams, die das wissen, melden früh.
Fortschritt am Ablauf messen, nicht an der Nutzungsrate. Der Ablauf, den das System verbessern soll, ist die richtige Kennzahl. Wer dort Verbesserung sieht, bleibt dabei.

Einordnung in core+

In core+ gehört dieser Ansatz zum Feld enable & support: die Befähigung der Menschen, in einer neuen Struktur wirksam zu werden. Werkzeuge einzuführen ohne dieses Feld zu bearbeiten, führt ins beschriebene Muster. Wer erst die Menschen vorbereitet und dann die Software einführt, zahlt weniger für die Einführung als für das Reparieren danach.

Drei Entscheidungsfragen

Welches System habt ihr eingeführt, das weniger genutzt wird als erwartet, und wurde der Kompetenzaufbau damals explizit adressiert?
Wer in deinem Unternehmen hat die größte Erfahrung mit Systemveränderungen, und kannst du diese Person für die nächste Einführung als erste einbinden?
Was wäre das Zeichen, das dir in vier Wochen zeigt, dass ein Pilotteam mit dem neuen System wirklich umgehen kann?

Welche fünf Kompetenzen dabei konkret zählen, erklärt Digitale Transformation: fünf Kompetenzen die zählen. Mehr zu Beratung und Coaching unter Coaching. Förderung über BAFA. Mehr unter Digitalisierung und Transformation.

in short

800,000 euros in a new ERP system, 14 months later under 40 percent adoption. The software was technically flawless. The problem lay elsewhere.
Resilience, learning competence and critical thinking were structurally absent. Employees had no tools to handle the uncertainty that comes with major system changes.
After six months of targeted competence development: 78 percent adoption. Not through new software, but through new capabilities.

The starting picture: technically flawless, humanly failed

800,000 euros in a new ERP system. A thorough onboarding training, a professional implementation team, a clear timeline. 14 months later, the adoption rate was under 40 percent. Employees fell back on old processes, productivity stagnated, and managers asked themselves what had gone wrong.

The system was technically flawless. The implementation went according to plan. What was missing only became visible through coaching: employees had not structurally developed the skills to handle the uncertainty that any major system change brings with it.

The real problem: missing assumptions about self-explanation

Many transformation projects start with the same basic error. The software is introduced, thorough training is organized, and adoption is expected to follow. What is overlooked: a system, however intuitively designed, meets people with different learning histories, stress patterns and individual responses to change.

In the case described, none of that was personal failure. Employees simply had no practice working with a new system while the ongoing operation continued. Resilience, learning competence and critical thinking were not available. Someone who makes mistakes in that situation falls back on what is proven. That is not resistance. It is self-protection.

Why this happens structurally again and again, and what the conceptual answer is, is explained in digital transformation: why competence decides.

What turned things around: competence development instead of tool training

The decision after the analysis: more tool training would not solve the problem. Instead, a guided competence development program was set up, embedded in daily work, not as an extra burden alongside it.

The program addressed three areas: learning competence (actively integrating and applying new knowledge), resilience (dealing productively with mistakes and setbacks) and critical thinking (questioning processes rather than reproducing them). After six months, the adoption rate rose from under 40 to 78 percent.

The system had not changed. The people had learned to work with it and with change in general differently.

How competence development makes ERP introduction easier

Map the current process before the software arrives. Knowing how people work today reveals where the new system will meet established habits. These friction points are the most important learning sites. The article making processes visible shows how to do the mapping.
Build a pilot team early. A small group who tests the system intensively before the full rollout and gives feedback. Their knowledge improves the introduction and their experience convinces colleagues more than any presentation.
Frame mistakes as training tasks. When someone struggles with the new system, that is information, not weakness. Teams that know this report early.
Measure progress on the process, not on the usage rate. The process the system is supposed to improve is the right metric. Seeing improvement there keeps people engaged.

How this fits in core+

In core+, this approach belongs to the enable & support field: equipping people to be effective in a new structure. Introducing tools without working on this field leads to the pattern described. Preparing people first and then introducing the software costs less than the repair afterwards.

Three questions for your initiative

Which system has lower adoption than expected, and was competence development explicitly addressed during the introduction?
Who in your organization has the most experience with system changes, and could you involve that person first in the next introduction?
What would be the sign, visible within four weeks, that a pilot team can genuinely work with the new system?

Which five competencies specifically matter is explained in digital transformation: 5 competencies that count. More on consulting and coaching under coaching. Funding via BAFA. More under digitalisation and transformation.

Häufige FragenFrequently asked questions

Kann ein Kompetenzprogramm auch bei einer bereits gescheiterten ERP-Einführung noch helfen?Can a competence program still help after an ERP introduction that has already failed?

Ja, das beschriebene Fallbeispiel zeigt genau das. Der Startpunkt war eine Akzeptanzrate von unter 40 Prozent, 14 Monate nach Go-live. Kompetenzaufbau hat dort noch gedreht. Je früher er beginnt, desto günstiger, aber er hilft auch im Nachgang.Yes, the case described shows exactly that. The starting point was under 40 percent adoption 14 months after go-live. Competence development still turned it around. The earlier it starts the cheaper, but it also helps after the fact.

Welche Rolle spielt Coaching dabei?What role does coaching play?

Coaching adressiert die individuelle Ebene: Wie geht jemand persönlich mit Veränderung um, wo liegen Blockaden? In Kombination mit einem strukturellen Kompetenzprogramm entsteht ein Rahmen, der sowohl das Team als auch Einzelpersonen trägt.Coaching addresses the individual level: how does someone personally handle change, where are the blockages? Combined with a structural competence program, it creates a frame that supports both the team and individuals.

Wie lange dauert ein Kompetenzprogramm typischerweise?How long does a competence program typically take?

Das hängt von der Tiefe der Veränderung ab. Im beschriebenen Fall waren sechs Monate nötig, um von unter 40 auf 78 Prozent Akzeptanz zu kommen. Für kleinere Systemänderungen kann ein gut begleitetes Pilotquartal ausreichen.It depends on the depth of the change. In the case described, six months were needed to go from under 40 to 78 percent adoption. For smaller system changes, a well-supported pilot quarter can be enough.

WeiterlesenKeep reading

← zurück zum herrlichblog← back to the herrlichblog