direkt zum inhalt

30. März 2026coachingdigitalisierungtransformation

Digitale Transformation: Warum Kompetenz wichtiger ist als TechnologieDigital transformation: why competence matters more than technology

Wenn die Software nicht das Problem ist – ein Praxisfall aus der digitalen Transformation 400 Mitarbeitende. Zwei Jahre Projektlaufzeit. Eine massive Investition in ein neues ERP-System. Und am Ende? Eine …400 employees, two years of rollout, and still only 40 percent adoption, because the software was never the real problem. The article shows what a real competence strategy has to deliver.

kurz gesagt

  • Die Software war nicht schuld. 400 Mitarbeitende, zwei Jahre Projektlaufzeit, eine Einführungsrate von unter 40 Prozent, und das System funktionierte einwandfrei.
  • Was fehlte, war Kompetenzstrategie: ein strukturiertes Programm, das Resilienz, Lernagiliät und begleitetes Lernen aufbaut, bevor die Einführung beginnt.
  • Wissen erzeugt keine Verhaltensänderung. Eine Schulung erklärt Bedienung. Sie nimmt keine Unsicherheit, baut keine Routine und verankert keine neue Arbeitsweise.

Wenn die Software nicht das Problem ist

400 Mitarbeitende. Zwei Jahre Projektlaufzeit. Eine massive Investition in ein neues ERP-System. Das Ergebnis: eine Einführungsrate von unter 40 Prozent, kein technischer Defekt, keine fehlerhafte Implementierung. Das System funktionierte einwandfrei. Was fehlte, war Kompetenzstrategie als Fundament der digitalen Transformation.

Dieses Szenario wiederholt sich immer dann, wenn Digitalisierung als Technologieprojekt behandelt wird, statt als tiefen Wandel in den Kompetenzen der Menschen zu begreifen. Die Werkzeuge stehen bereit, aber die Belegschaft ist nicht vorbereitet.

Warum Schulungen nicht reichen

In der Praxis läuft es immer wieder gleich: Schulungstage werden durchgeführt, Handbücher verteilt, Testsysteme bereitgestellt. Im Arbeitsalltag verändert sich wenig. Neue Werkzeuge werden gemieden, Workarounds entstehen, alte Abläufe kehren zurück.

Der Grund: Wissen allein erzeugt keine Verhaltensänderung. Eine Schulung erklärt, wie ein System bedient wird. Sie erklärt nicht, warum der vertraute Ablauf von heute auf morgen nicht mehr gilt. Und sie nimmt keine Unsicherheit weg, die entsteht, wenn eingespieltes Verhalten plötzlich infrage steht.

Drei Bausteine, die im Praxisfall fehlten

Resilienz im mittleren Management. Führungskräfte, die selbst unter Druck stehen, können Veränderung nicht vorleben. Das mittlere Management ist Verstärker oder Flaschenhals. Wer dort nicht ansetzt, verliert den Boden unter dem Rollout.

Lernagiliät in den Teams. Die Fähigkeit, sich schnell auf neue Werkzeuge einzustellen, ist keine Selbstverständlichkeit. Sie muss geübt werden, nicht vorausgesetzt. Teams, die nicht gelernt haben zu lernen, bauen neben dem neuen System schnell parallele Excel-Listen auf.

Ein echtes Kompetenzentwicklungsprogramm. Kein einmaliger Schulungstag, sondern ein begleiteter Lernprozess, der im Alltag verankert ist. Wiederholung und Feedback machen den Unterschied zwischen Training und Können.

Was eine Kompetenzstrategie konkret leistet

  1. Ist-Stand bestimmen. Welche Kompetenzen sind vorhanden, welche fehlen? Ein halber Tag mit den betroffenen Teams reicht für ein belastbares Bild.
  2. Führungskräfte zuerst abholen. Wer im mittleren Management die neue Arbeitsweise nicht kennt, kann sie nicht einfordern. Führungsvorbereitung kommt vor dem Flächenrollout.
  3. Lernen in den Alltag einbauen. Kurze Übungseinheiten im echten Prozess wirken besser als Schulungsblöcke, die danach verblassen.
  4. Fortschritt messen. Nutzungsraten, Fehlerquoten, Bearbeitungszeiten zeigen, ob die Kompetenzlücke sich schließt. Ohne Kennzahl bleibt es Hoffnung.

Wie ein ins Stocken geratener ERP-Rollout noch gerettet werden kann, zeigt der Beitrag ERP-Rollout retten. Welche Kompetenzen Mitarbeitende individuell brauchen, beschreibt der Beitrag Warum Menschen entscheiden.

Einordnung in core+

Im core+-Modell fällt dieser Baustein unter "enable & support": Menschen befähigen, damit Transformation trägt. Der Schritt kommt nach "clarity & diagnostics", weil erst der Ist-Stand zeigen muss, was fehlt. core+ behandelt Kompetenzaufbau nicht als Softfaktor, sondern als Voraussetzung, ohne die kein Strukturwandel hält. Mehr zum Beratungsansatz unter coaching.

Was das für die Praxis bedeutet

Die meisten Unternehmen beginnen Kompetenzentwicklung zu spät: wenn das System schon eingeführt ist und die Lücken sichtbar werden. Der effektivere Weg beginnt früher, im Moment der Systementscheidung. Wer damals benennt, was fehlt, kann gezielt aufbauen statt später reparieren. Konkret heißt das: Kompetenzentwicklung läuft nicht nach der Einführung, sondern parallel zu ihr. Die Belegschaft kommt am Go-Live-Tag nicht beim System an, sondern mit ihm. Und wer von Anfang an in Kompetenzaufbau investiert, hat sechs Monate später höhere Nutzungsraten, weniger Rückfragen und keine parallelen Excel-Listen.

Drei Entscheidungsfragen

  • Wer ist in deinem Unternehmen verantwortlich für den Kompetenzaufbau im Rahmen der Einführung, und hat diese Person ausreichend Einfluss?
  • Haben die Führungskräfte im mittleren Management die neuen Prozesse und Werkzeuge selbst erprobt?
  • Was ist der kleinste messbare Schritt, der in vier Wochen zeigt, ob der Kompetenzaufbau wirkt?

in short

  • The software was not to blame. 400 employees, two years of project work, an adoption rate of under 40 percent, and the system worked without fault.
  • What was missing was a competence strategy: a structured programme that builds resilience, learning agility and guided practice before the rollout begins.
  • Knowledge alone does not change behaviour. Training explains how to operate a system. It does not take away uncertainty, build routine or anchor a new way of working.

When the software is not the problem

400 employees. Two years of project work. A major investment in a new ERP system. The result: an adoption rate of under 40 percent, no technical defect, no faulty implementation. The system worked without fault. What was missing was competence strategy as the foundation of digital transformation.

This scenario repeats itself whenever digitalisation is treated as a technology project rather than understood as a deep change in the capabilities of the people involved.

Why training alone is not enough

In practice the pattern is always the same: training days are held, handbooks distributed, test systems set up. In daily work, little changes. New tools are avoided, workarounds appear, and old habits return.

The reason: knowledge alone does not change behaviour. Training explains how to use a system. It does not explain why a familiar routine is suddenly supposed to be obsolete. And it does not remove the uncertainty that arises when established behaviour is suddenly called into question.

Three building blocks that were missing in the case

Resilience in middle management. Managers who are under pressure themselves cannot model change. Middle management is either the amplifier or the bottleneck. If you do not start there, the rollout loses its footing.

Learning agility in teams. The ability to adapt quickly to new tools is not a given. It has to be practised, not assumed. Teams that have not learned how to learn quickly build parallel spreadsheets alongside the new system.

A real competence development programme. Not a one-off training day, but a guided learning process anchored in daily work. Repetition and feedback are what separate training from actual capability.

What a competence strategy concretely delivers

  1. Assess the current state. Which competencies exist, which are missing? Half a day with the affected teams is enough for a reliable picture.
  2. Prepare managers first. Anyone in middle management who does not know the new way of working cannot insist on it. Leadership preparation comes before the broad rollout.
  3. Build learning into daily work. Short practice sessions in the real process work better than training blocks that fade afterwards.
  4. Measure progress. Adoption rates, error rates, processing times show whether the competence gap is closing. Without a metric it stays wishful thinking.

The article saving an ERP rollout shows how a stalled rollout can still be rescued. The competencies individuals need are described in why people decide.

Where this fits in core+

In the core+ model this falls under "enable & support": enabling people so that transformation holds. The step comes after "clarity & diagnostics", because the current state must first show what is missing. core+ treats competence development not as a soft factor but as a prerequisite without which no structural change lasts. More on the consulting approach under coaching.

What this means in practice

Most companies start competence development too late: when the system is already live and the gaps become visible. The more effective approach begins earlier, at the moment of the system decision. Naming what is missing at that point means building deliberately rather than repairing later. Concretely: competence development runs in parallel with the rollout, not after it. The workforce arrives at go-live day not behind the system but alongside it.

Three questions to guide your decision

  • Who in your company is responsible for competence development as part of the rollout, and does that person have enough influence?
  • Have the managers in middle management personally tried out the new processes and tools?
  • What is the smallest measurable step that would show in four weeks whether the competence building is working?

häufige fragenfrequently asked questions

Was unterscheidet eine Kompetenzstrategie von einem Schulungsplan?What is the difference between a competence strategy and a training plan?

Ein Schulungsplan listet auf, wer wann was lernt. Eine Kompetenzstrategie fragt vorher, welche Fähigkeiten fehlen und wie sie im Alltag verankert werden. Der Unterschied liegt in der Diagnose und in der Konsequenz.A training plan lists who learns what and when. A competence strategy first asks which capabilities are missing and how they will be embedded in daily work. The difference lies in the diagnosis and in the follow-through.

Wann sollte die Kompetenzstrategie beginnen, vor oder nach der ERP-Auswahl?Should the competence strategy start before or after the ERP selection?

Vor der Auswahl. Wer weiß, welche Kompetenzen fehlen, kann ein System danach wählen, wie gut es zum vorhandenen Können passt. So vermeidest du, im Nachhinein auf ein System hin nachzurüsten.Before. Knowing which competencies are missing lets you choose a system based on how well it fits existing capabilities. That way you avoid retrofitting to a system after the fact.

Wie lange dauert der Aufbau einer Kompetenzstrategie für ein Unternehmen mit mehreren Hundert Mitarbeitenden?How long does building a competence strategy take for a company with several hundred employees?

Die Diagnose braucht etwa eine Woche, das Programm läuft parallel zur Einführung. Kompetenzaufbau ist kein Projekt mit Enddatum, sondern eine Praxis, die mit dem System mitreift.The diagnosis takes about a week, the programme runs in parallel with the rollout. Competence development is not a project with an end date but a practice that matures alongside the system.

geschrieben vonwritten by · business transformation, ki und führung im mittelstand. methode: core+.business transformation, ai and leadership for mid-sized companies. method: core+.

weiterlesenkeep reading

← zurück zum herrlichblog← back to the herrlichblog