direkt zum inhalt

27. März 2026coachingdigitalisierungtransformation

Digitalisierung scheitert an Menschen – nicht TechnologieDigitization fails on people, not technology

Wenn 1,2 Millionen Euro nicht reichen – warum Digitalisierung ohne Kompetenzaufbau scheitert Ein mittelständisches Unternehmen investiert 1,2 Millionen Euro in eine neue ERP-Plattform. Achtzehn Monate später liegt die …1.2 million euros went into a new ERP platform, yet adoption still sits below 40 percent. The article explains why digitization keeps failing without real competence building.

kurz gesagt

  • Technologie ist selten das Problem. Scheiternde Digitalisierungsprojekte haben meistens keinen technischen Fehler, sondern einen strukturellen: fehlender Kompetenzaufbau.
  • Schulung ist kein Kompetenzaufbau. Wer sein Team einmal durch eine Einführungsveranstaltung schickt, befähigt niemanden wirklich, mit dem neuen Werkzeug zu arbeiten.
  • Akzeptanz lässt sich nicht anordnen. Sie entsteht, wenn Menschen die Lösung mitgestaltet haben und den Nutzen für ihre eigene Arbeit sehen.

Wenn 1,2 Millionen Euro nicht reichen

Ein mittelständisches Unternehmen investiert 1,2 Millionen Euro in eine neue ERP-Plattform. Die Implementierung läuft nach Plan, der Go-Live findet pünktlich statt. Achtzehn Monate später nutzen weniger als vier von zehn Mitarbeitenden das System produktiv. Die anderen arbeiten mit Parallelwegen, Tabellen und gewohnten Umwegen.

Die Antwort auf die Frage, was schiefgelaufen ist, fällt unbequem aus: Die Technologie war in Ordnung. Was gefehlt hat, war ein durchdachtes Programm, das Menschen befähigt, mit dem neuen Werkzeug tatsächlich zu arbeiten und es als Verbesserung zu erleben.

Dieses Muster wiederholt sich in Unternehmen aller Branchen, oft mit ähnlichem Verlauf: Das Budget für Software, Hardware und Implementierung ist vorhanden. Das Budget für echten Kompetenzaufbau fehlt. Dabei ist genau das der entscheidende Faktor für den Erfolg jeder digitalen Transformation.

Der Unterschied zwischen Schulung und Kompetenzaufbau

Was viele Unternehmen als Schulung bezeichnen, ist oft eine Einführungsveranstaltung von ein oder zwei Tagen. Danach ist die Software erklärt. Ob die Menschen wissen, wie sie damit ihre eigene Arbeit effizienter gestalten, steht auf einem anderen Blatt.

Echter Kompetenzaufbau umfasst drei Dimensionen, die über Technikkenntnis hinausgehen:

  • Anwendungskompetenz: verstehen, wie das System die eigene Arbeit verändert, über die Bedienung hinaus
  • Prozesskompetenz: verstehen, welche Abläufe sich durch das System ändern, und diese Änderungen mitgestalten können
  • Veränderungskompetenz: mit Unsicherheit und Rückschlägen umgehen, ohne ins alte Muster zu fallen

Wer nur die erste Dimension abdeckt, bekommt technisch ausgebildete Mitarbeitende, die das System trotzdem meiden.

Warum Akzeptanz nicht entsteht, wenn sie angeordnet wird

Akzeptanz ist ein Ergebnis, kein Beschluss. Sie entsteht, wenn Menschen die Lösung als hilfreich für ihre eigene Arbeit erleben. Das passiert selten beim klassischen Top-Down-Rollout.

Das Bild kennt fast jede Führungskraft: Oben wird entschieden, eine Beratung liefert Konzepte, dann beginnt das Rollout. Die Mitarbeitenden sollen sich anpassen. Ein paar Monate später laufen die alten Abläufe weiter, diesmal mit neuen Systemschritten daneben. Der eigentliche Wandel findet nicht statt.

Wer hingegen die Menschen, die täglich im System arbeiten werden, bereits bei der Konzeption einbezieht, hört ihre Einwände als Information statt als Widerstand. Und wer mitgebaut hat, verteidigt das Ergebnis.

Was du vor dem nächsten Projekt prüfen solltest

  1. Ist der Ist-Ablauf bekannt? Bevor ein neues System eingeführt wird, sollte klar sein, wie der heutige Prozess wirklich läuft, nicht wie er laufen soll. Was das für die Praxis bedeutet, steht im Beitrag Prozessanalyse im KMU.
  2. Wer gestaltet die Lösung mit? Die Menschen mit dem meisten Prozesswissen sind selten im Projektteam. Das sollte sich ändern.
  3. Was ist der messbare Nutzen für die Nutzenden? Nicht für das Unternehmen als Ganzes, sondern für diejenigen, die das System täglich bedienen. Wenn sie diese Frage nicht beantworten können, ist Widerstand vorprogrammiert.
  4. Ist Kompetenzaufbau ein Posten im Budget? Nicht als Anhang, sondern als Teil des Projekts von Anfang an.

Einordnung in core+

In core+ ist Kompetenzaufbau ein eigenes Feld: enable & support. Digitalisierungsprojekte, die dort keine Antwort haben, landen meistens im Feld „Technologie eingekauft, Wandel nicht eingetreten“. Mehr zum Ansatz steht im Beitrag Digitale Transformation: Warum Kompetenz über Erfolg entscheidet.

Drei Fragen für dein nächstes Projekt

  • Wer aus deinem Team hat beim letzten IT-Projekt die Anforderungen definiert, und wer hätte sie eigentlich am besten kennen müssen?
  • Wie misst du bei laufenden Digitalisierungsvorhaben, ob das System wirklich genutzt wird?
  • Was bräuchten deine Mitarbeitenden, um das neue Werkzeug als Erleichterung zu erleben, statt als zusätzliche Aufgabe?

Förderung für Beratungsprojekte in diesem Bereich ist oft möglich über BAFA-Förderung.

in short

  • Technology is rarely the problem. Failing digitalisation projects almost never have a technical flaw. They have a structural one: missing competence building.
  • Training is not competence building. Sending your team through an introductory session does not truly enable anyone to work with a new tool.
  • Adoption cannot be ordered. It grows when people have helped shape the solution and can see the benefit for their own work.

When 1.2 million euros are not enough

A mid-sized company invests 1.2 million euros in a new ERP platform. Implementation runs to plan, the go-live happens on time. Eighteen months later, fewer than four in ten employees use the system productively. The others work with parallel paths, spreadsheets and familiar workarounds.

The answer to what went wrong is uncomfortable but clear: the technology was fine. What was missing was a thoughtful programme that enabled people to actually work with the new tool and experience it as an improvement.

This pattern repeats across industries, often with the same arc: the budget for software, hardware and implementation is there. The budget for real competence building is not. Yet that is precisely the deciding factor for any successful digital transformation.

The difference between training and competence building

What many companies call training is often a one- or two-day introductory event. After that, the software has been explained. Whether people know how to use it to make their own work more efficient is a separate question.

Real competence building covers three dimensions beyond technical knowledge:

  • Application competence: knowing not just how the system works, but how it changes your own work
  • Process competence: understanding which workflows change through the system and being able to shape those changes
  • Change competence: handling uncertainty and setbacks without falling back into old patterns

If you only cover the first dimension, you get technically trained employees who still avoid the system.

Why adoption does not come from being ordered

Adoption is an outcome, not a resolution. It grows when people experience the solution as genuinely helpful for their own work. That rarely happens in a classic top-down rollout.

Most managers recognise the pattern: a decision is made at the top, consultants deliver concepts, then the rollout begins. Employees are expected to adapt. A few months later the old workflows are still running, this time with new system steps alongside them. The actual change has not taken place.

When the people who will work in the system every day are included during the design phase, their objections arrive as information rather than resistance. Those who helped build something will defend the result.

What to check before the next project

  1. Is the current workflow known? Before introducing a new system, it should be clear how today's process actually runs, not how it is supposed to run. What that means in practice is covered in the article Process analysis in SMEs.
  2. Who is shaping the solution? The people with the deepest process knowledge are rarely on the project team. That should change.
  3. What is the measurable benefit for the users? Not for the organisation as a whole, but for the people who will run the system every day. If they cannot answer that question, resistance is predictable.
  4. Is competence building a line item in the budget? Not as an appendix, but as part of the project from the start.

Where this fits in core+

In core+, competence building is its own field: enable & support. Digitalisation projects with no answer there usually land in the category "technology purchased, change not achieved". More on the approach in the article Digital transformation: why competence decides success.

Three questions for your next project

  • Who from your team defined the requirements in the last IT project, and who should really have known them best?
  • How do you measure, in running digitalisation initiatives, whether the system is actually being used?
  • What would your employees need to experience the new tool as a relief rather than an additional task?

Funding for consulting projects in this area is often available through BAFA support.

häufige fragenfrequently asked questions

Was unterscheidet echten Kompetenzaufbau von einer Softwareschaulung?What separates real competence building from a software training?

Eine Schulung erklärt, wie das System funktioniert. Kompetenzaufbau befähigt Menschen, damit ihre eigene Arbeit effizienter zu gestalten, Prozessveränderungen zu verstehen und mit Rückschlägen umzugehen. Der Unterschied zeigt sich in den Monaten nach dem Go-Live.A training explains how the system works. Competence building enables people to make their own work more efficient, understand process changes and handle setbacks. The difference shows in the months after go-live.

Wann sollte der Kompetenzaufbau im Projekt beginnen?When should competence building begin in a project?

Vor dem Go-Live, nicht danach. Wer Kompetenzaufbau als Reaktion auf Akzeptanzprobleme startet, kämpft gegen Widerstände, die sich bereits verfestigt haben. Ziel ist, dass Menschen das System am ersten Tag als Werkzeug erleben, nicht als Aufgabe.Before go-live, not after. Starting it in response to adoption problems means fighting resistance that has already set in. The goal is for people to experience the system as a tool from day one, not as an assignment.

Wie messe ich, ob die Digitalisierung wirklich funktioniert?How do I measure whether digitalisation is actually working?

Nicht über den Go-Live-Status, sondern über die aktive Nutzungsrate. Wie viele der Betroffenen nutzen das System für ihre Hauptaufgaben, und wie hat sich die Durchlaufzeit des relevanten Prozesses verändert? Ohne diese zwei Werte bleibt der Projekterfolg ein Gefühl.Not through go-live status but through active usage rate. How many of the people affected use the system for their main tasks, and how has the lead time of the relevant process changed? Without these two numbers, project success remains a feeling.

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