Direkt zum Inhalt

23. April 2026DigitalisierungMindsetTransformation

Digitale Transformation: Warum Kompetenz über Erfolg entscheidetDigital Transformation: Why Competence Decides

Digitale Transformation scheitert selten an der Technologie. Sie scheitert daran, dass der entscheidende Faktor übersehen wird: menschliche Kompetenz. Was das bedeutet und wie du es aufbaust.Digital transformation rarely fails because of technology. The real factor is human competence. Here is what that means and how to build it.

kurz gesagt

  • Technologie ist ein Werkzeug. Ohne die Kompetenz der Menschen, es sinnvoll einzusetzen, bleibt es ein teures Pilotprojekt.
  • Der Engpass liegt selten im Budget oder der Software, sondern in der Fähigkeit der Organisation, mit Veränderung umzugehen.
  • Kompetenz lässt sich nicht installieren. Sie entsteht durch Erfahrung, Einbindung und einen Rahmen, in dem Fehler erlaubt sind.

Warum Investitionen allein nicht reichen

Unternehmen investieren in ERP-Systeme, KI-Lösungen und Cloud-Infrastrukturen. Implementierungsteams arbeiten auf Hochtouren, Roadmaps werden erstellt, Berater engagiert. Nach 18 Monaten ist von der erhofften Transformation häufig wenig zu sehen. Produktivität stagniert, Mitarbeitende sind frustriert, und niemand weiß genau, wo das Budget geblieben ist.

Die Antwort ist unbequem: Kompetenz lässt sich nicht mit einem Software-Update installieren. Wer glaubt, dass ein besseres Tool automatisch zu besserer Arbeit führt, unterschätzt die Anpassungsleistung, die jede größere Systemänderung von Menschen verlangt.

Was Kompetenz hier bedeutet

Kompetenz in der digitalen Transformation ist keine technische Frage. Sie ist die Fähigkeit, mit Veränderung umzugehen: neue Werkzeuge nicht als Bedrohung zu erleben, sondern als Erweiterung. Fehler in einer neuen Umgebung zu machen und daraus zu lernen. Prozesse zu hinterfragen, statt sie zu digitalisieren.

Die viel zitierte Scheiterquote bei digitalen Transformationen schwankt je nach Quelle erheblich und ist methodisch schwer zu belegen. Wie belastbar solche Zahlen sind und was sie wirklich messen, erklärt dieser Beitrag zur Scheiterquoten-Debatte. Was dahinter steckt, ist klar: Die meisten Projekte scheitern nicht an der Technik, sondern an der fehlenden Kompetenz, mit ihr zu arbeiten. Das gilt für ERP-Einführungen genauso wie für KI-Tools, Cloud-Systeme und jede andere Plattform, die tief in bestehende Arbeitsabläufe eingreift und dort auf gewachsene Gewohnheiten trifft.

Der Unterschied zwischen Schulung und Kompetenzaufbau

Schulungen vermitteln Wissen: Wie klicke ich das? Was gibt es hier? Kompetenzaufbau ist etwas anderes. Er adressiert: Wie gehe ich mit Unsicherheit um? Wie überzeuge ich mich selbst, dass ein neuer Ablauf besser ist, auch wenn er sich am Anfang schwerer anfühlt?

Diese zweite Frage lässt sich nicht in einem Handbuch beantworten. Sie braucht eine Umgebung, in der Ausprobieren erlaubt ist, in der Einwände gehört werden, und in der Fortschritt sichtbar wird. Das ist kein weicher Faktor. Es ist eine strukturelle Entscheidung.

Was die fünf konkreten Kompetenzen sind, die über Erfolg entscheiden, beschreibt Digitale Transformation: fünf Kompetenzen die zählen.

Was Kompetenz in der Praxis erfordert

  1. Den Prozess vor der Software verstehen. Wer einen Ablauf digitalisiert, ohne ihn vorher sichtbar gemacht zu haben, automatisiert die Probleme gleich mit. Wie das gelingt, zeigt Prozesse sichtbar machen.
  2. Lerngelegenheiten in den Alltag einbauen. Nicht als Zusatzprogramm neben der Arbeit, sondern als Teil des neuen Ablaufs selbst.
  3. Einen messbaren Fortschritt definieren. Nicht "das neue System wird genutzt", sondern: Dieser Vorgang dauert jetzt kürzer, diese Fehlerquelle ist verschwunden. Was sich nicht messen lässt, wird nicht sichtbar verfolgt.
  4. Fehler als Informationsquelle behandeln. Teams, die Fehler mit neuen Werkzeugen melden, liefern das beste Feedback für die nächste Anpassung. Teams, die schweigen, entwickeln Umgehungslösungen.

Einordnung in core+

In core+ steht Kompetenz im Feld enable & support: die Befähigung der Menschen, in neuen Strukturen wirksam zu werden. Das ist kein Abschnitt, der am Ende kommt. Er ist die Voraussetzung dafür, dass execute & scale trägt. Technologie ist ein Hebel, Kompetenz ist das Fundament.

Drei Entscheidungsfragen

  • Welches digitale Vorhaben in deinem Unternehmen hat weniger gebracht als erwartet, und was wurde konkret für den Kompetenzaufbau getan?
  • Woran würdest du erkennen, dass die Kompetenz nach der Einführung eines neuen Systems tatsächlich gestiegen ist?
  • Welcher Mitarbeitende in deinem Unternehmen wäre der erste, den du für eine neue digitale Rolle aufbauen würdest?

Den konkreten Fall eines ERP-Rollouts, der erst durch Kompetenzentwicklung gelang, beschreibt Kompetenz vor Technologie. Geförderte Beratung über BAFA. Mehr unter Digitalisierung und Transformation.

in short

  • Technology is a tool. Without the competence of the people using it, it remains an expensive pilot project.
  • The bottleneck is rarely in the budget or the software, but in the organization's ability to handle change.
  • Competence cannot be installed. It grows through experience, involvement and a frame where mistakes are allowed.

Why investment alone is not enough

Companies invest in ERP systems, AI solutions and cloud infrastructure. Implementation teams work flat out, roadmaps are drawn up, consultants engaged. After 18 months, the hoped-for transformation is often barely visible. Productivity stagnates, employees are frustrated and nobody is quite sure where the budget went.

The answer is uncomfortable: competence cannot be installed with a software update. Anyone who believes a better tool automatically leads to better work underestimates the adjustment that every major system change requires from people.

What competence means here

Competence in digital transformation is not a technical question. It is the ability to handle change: to experience new tools as an extension rather than a threat. To make mistakes in a new environment and learn from them. To question processes rather than digitise them.

The much-cited failure rate for digital transformations varies considerably by source and is methodologically hard to pin down. How reliable such figures are and what they actually measure is explained in this piece on the failure-rate debate. What lies behind it is clear: most projects fail not because of the technology but because of missing competence to work with it.

The difference between training and competence development

Training imparts knowledge: how do I click this? What is available here? Competence development is something different. It addresses: how do I handle uncertainty? How do I convince myself that a new process is better, even when it feels harder at first?

That second question cannot be answered in a manual. It needs an environment where trying things out is allowed, where objections are heard and where progress becomes visible. That is not a soft factor. It is a structural decision.

What the five concrete competencies that decide success look like is described in digital transformation: 5 competencies that count.

What competence requires in practice

  1. Understand the process before the software arrives. Digitising a process without first making it visible means automating the problems along with it. The article making processes visible shows how.
  2. Build learning opportunities into daily work. Not as a supplementary program alongside work, but as part of the new process itself.
  3. Define a measurable result. Not "the new system is being used" but: this task now takes less time, this source of error has gone. What cannot be measured will not be visibly tracked.
  4. Treat mistakes as information. Teams that report problems with new tools provide the best feedback for the next adjustment. Teams that stay quiet develop workarounds.

How this fits in core+

In core+, competence belongs to the enable & support field: equipping people to be effective in new structures. That is not a section that comes at the end. It is the precondition for execute & scale to hold. Technology is a lever, competence is the foundation.

Three questions for your initiative

  • Which digital initiative in your organization delivered less than expected, and what was specifically done to build competence?
  • How would you know, after introducing a new system, that competence had actually risen?
  • Which person in your organization would be the first you would develop for a new digital role?

The concrete case of an ERP rollout that only succeeded through competence development is described in competence before technology. Funded consulting via BAFA. More under digitalisation and transformation.

Häufige FragenFrequently asked questions

Wie messe ich, ob Kompetenz nach einer digitalen Einführung gestiegen ist?How do I measure whether competence has grown after a digital introduction?

Nicht über Nutzungsraten allein, sondern über den Ablauf, den das Tool verbessern sollte. Ist die Bearbeitungszeit kürzer? Gibt es weniger Rückfragen? Weniger Fehler? Diese Werte zeigen reale Kompetenzentwicklung, Klickzahlen nicht.Not through usage rates alone, but through the process the tool was meant to improve. Is the processing time shorter? Are there fewer queries? Fewer errors? Those figures show real competence development. Click counts do not.

Reicht ein gutes Onboarding, um Kompetenz aufzubauen?Is good onboarding enough to build competence?

Als Anfang ja. Als vollständige Antwort nein. Onboarding vermittelt Grundwissen. Kompetenz entsteht durch Anwenden unter realen Bedingungen, durch Fehler machen und durch einen Rahmen, in dem diese Fehler gemeldet werden können, ohne Folgen zu haben.As a start, yes. As a complete answer, no. Onboarding imparts basic knowledge. Competence comes from applying that knowledge under real conditions, from making mistakes, and from a frame where those mistakes can be reported without consequences.

Was tue ich, wenn das Budget für Kompetenzentwicklung fehlt?What do I do when there is no budget for competence development?

Mit dem Kleinstmöglichen anfangen: Ein Pilotteam, eine kurze wöchentliche Reflexion, ein Ansprechpartner für Fragen. Die Investition ist Zeit, nicht Geld. Und sie ist deutlich kleiner als das Budget, das ein gescheiterter Rollout kostet.Start with the smallest possible: a pilot team, a short weekly reflection, one person available for questions. The investment is time, not money. And it is significantly smaller than the budget a failed rollout costs.

WeiterlesenKeep reading

← zurück zum herrlichblog← back to the herrlichblog