Transformationsprojekte – ob Digitalisierungsvorhaben, Reorganisationen oder die Einführung neuer Systeme – scheitern seltener an der Technologie als an den Menschen und der Kommunikation. Das ist keine neue Erkenntnis, und trotzdem werden dieselben Fehler immer wieder gemacht. Dieser Beitrag beschreibt die häufigsten davon – ohne Anspruch auf Vollständigkeit, aber mit dem Ziel, sie frühzeitig erkennbar zu machen.

Fehler 1: Der Wandel wird verordnet, nicht erklärt

In vielen Organisationen wird eine Veränderung von oben beschlossen und dann nach unten weitergegeben – mit der impliziten Erwartung, dass die Mitarbeitenden mitziehen. Das funktioniert selten gut.

Menschen folgen einer Veränderung dann, wenn sie verstehen, warum sie notwendig ist. Nicht als Pflicht, sondern als nachvollziehbare Konsequenz aus einer Lage, die sie selbst einschätzen können. Wenn das Warum fehlt oder ausweichend kommuniziert wird, entstehen Misstrauen und Widerstand – auch bei Mitarbeitenden, die der Veränderung grundsätzlich offen gegenüberstehen.

Kommunikation in Transformationsprojekten ist keine einmalige Aufgabe zu Projektbeginn. Sie ist ein kontinuierlicher Prozess, der die gesamte Laufzeit des Projekts begleitet.

Fehler 2: Betroffene werden nicht zu Beteiligten gemacht

Ein klassisches Muster: Eine kleine Gruppe erarbeitet ein neues Konzept, präsentiert es den Betroffenen – und wundert sich dann über mangelnde Akzeptanz. Dabei ist das Problem oft nicht das Konzept selbst, sondern der Prozess, durch den es entstanden ist.

Menschen, die an der Entwicklung einer Lösung beteiligt waren, identifizieren sich mit ihr. Sie kennen die Überlegungen dahinter, haben eigene Gedanken eingebracht und fühlen sich als Teil der Lösung. Menschen, denen eine fertige Lösung präsentiert wird, sind zunächst Zuschauende – und reagieren entsprechend.

Das bedeutet nicht, dass alle alles mitentscheiden müssen. Es bedeutet, dass Mitarbeitende frühzeitig eingebunden werden sollten – bei der Problemanalyse, bei der Bewertung von Optionen, bei der Ausgestaltung von Details. Das kostet Zeit, spart sie aber in der Umsetzung.

Fehler 3: Rollen und Verantwortlichkeiten bleiben unklar

Transformationsprojekte berühren fast immer bestehende Strukturen. Wer war bisher für was zuständig? Wer ist es künftig? Welche Aufgaben entfallen, welche kommen neu hinzu? Wenn diese Fragen offen bleiben, entstehen Unsicherheit, Doppelarbeit und Lücken.

Besonders heikel: Wenn neue Systeme oder Prozesse eingeführt werden, ohne dass die betroffenen Rollen angepasst werden. Das neue System läuft dann neben dem alten her – weil niemand klar gesagt hat, welches ab wann gilt, und wer im Zweifel entscheidet.

Klare Rollenbilder und Verantwortlichkeiten sind keine bürokratische Pflicht. Sie sind eine Voraussetzung dafür, dass eine Organisation im Alltag funktioniert.

Fehler 4: Der Zeitplan ist unrealistisch

Transformationsprojekte dauern länger als geplant. Das ist so verbreitet, dass es beinahe als Naturgesetz gilt – und trotzdem werden Zeitpläne immer wieder zu optimistisch gestaltet.

Die Gründe dafür sind vielfältig: politischer Druck, mangelnde Erfahrung mit ähnlichen Projekten, Unterschätzung der organisatorischen Komplexität oder schlicht der Wunsch, positiv zu klingen. Das Ergebnis ist in allen Fällen ähnlich: Druck auf das Team, Qualitätseinbußen, übersprungene Testphasen und eine schlechtere Ausgangslage für die Einführung.

Ein realistischer Zeitplan, der Puffer für Unvorhergesehenes enthält, ist kein Zeichen von Schwäche. Er ist ein Zeichen von Erfahrung.

Fehler 5: Erfolg wird nicht definiert

Am Ende eines Transformationsprojekts stellt sich die Frage: War es erfolgreich? Häufig gibt es darauf keine klare Antwort – weil zu Beginn niemand festgelegt hat, was Erfolg konkret bedeuten soll.

Ohne messbare Ziele gibt es keine Möglichkeit, den Fortschritt zu beurteilen, Korrekturen vorzunehmen oder den Projekterfolg nach außen darzustellen. Das führt dazu, dass Projekte entweder als Erfolg gefeiert werden, obwohl die Kernprobleme ungelöst sind – oder als gescheitert abgehakt werden, obwohl wesentliche Verbesserungen erreicht wurden.

Messbare Ziele vor Projektbeginn zu definieren ist unbequem, weil es Verantwortlichkeit schafft. Aber genau das ist der Punkt.

Fehler 6: Nach dem Go-live ist vor dem Go-live

Viele Projekte enden mit dem Go-live. Das System ist eingeführt, die Präsentation gehalten, das Team aufgelöst. Was danach passiert – wie das System im Alltag genutzt wird, welche Probleme auftauchen, wie Mitarbeitende damit umgehen –, fällt oft unter den Tisch.

Tatsächlich beginnt die eigentliche Bewährungsprobe einer Veränderung erst nach der Einführung. Gewohnheiten ändern sich langsam. Neue Prozesse brauchen Zeit, bis sie selbstverständlich werden. Systeme müssen auf Basis erster Erfahrungen angepasst werden.

Wer nach dem Go-live sofort das nächste Projekt startet, ohne die Einführung zu begleiten und zu stabilisieren, riskiert, dass die Veränderung auf dem Papier existiert – aber nicht im Alltag ankommt.

Was hilft

Die beschriebenen Fehler lassen sich nicht vollständig vermeiden – aber man kann die Wahrscheinlichkeit ihres Auftretens reduzieren. Einige Ansätze, die sich in der Praxis als hilfreich erwiesen haben:

• Frühe und ehrliche Kommunikation: Warum wird die Veränderung vorgenommen? Was bleibt unsicher? Wann gibt es neue Informationen? Lieber unbequeme Wahrheiten früh als beruhigende Halbwahrheiten, die später einholen.
• Echte Beteiligung statt Scheinbeteiligung: Mitarbeitende einbeziehen, wenn es noch etwas zu gestalten gibt – nicht erst, wenn die Entscheidungen gefallen sind.
• Klare Rollenklärung vor der Einführung: Wer macht was ab wann? Welche Entscheidungen liegen wo? Das klärt man besser vor dem Go-live als danach.
• Realistische Zeitplanung mit Puffern: Besser einen Termin nach hinten schieben als mit einem halben Produkt live gehen.
• Erfolgskriterien vor Projektbeginn: Was muss sich wie verändern, damit das Projekt als erfolgreich gilt? Konkret, messbar, vereinbart.
• Stabilisierungsphase nach dem Go-live: Mindestens vier bis acht Wochen intensives Monitoring, Nachschulung und Anpassung einplanen.

Fazit

Transformationsprojekte scheitern selten an der Technologie. Sie scheitern an Kommunikation, Einbindung, Klarheit und Nachsorge. Das sind keine neuen Erkenntnisse – sie sind nur schwieriger umzusetzen als die Installation eines neuen Systems. Wer die beschriebenen Muster kennt und früh gegensteuert, verbessert die Ausgangslage für eine Veränderung erheblich.

Nicht jedes Projekt läuft glatt. Aber viele der häufigsten Probleme sind vorhersehbar – und damit auch adressierbar.

Business Process Management – kurz BPM – und die dazugehörige Modellierungssprache BPMN gelten vielerorts als Pflichtprogramm für Organisationen, die ihre Prozesse verbessern wollen. In der Praxis führt der Einsatz von Prozessmodellen aber nicht selten zu aufwändigen Dokumentationsprojekten, die am Ende in Schubladen verschwinden. Wann lohnt sich der Aufwand – und wann reicht eine einfachere Lösung?

Was Prozessmodellierung leistet

Prozessmodelle haben einen klaren Zweck: Sie schaffen ein gemeinsames Verständnis darüber, wie Arbeit abläuft. Das klingt simpel, ist in der Praxis aber eine erhebliche Leistung. In den meisten Organisationen existiert kein einheitliches Bild davon, was zwischen Auftragseingang und Lieferung tatsächlich passiert. Jede Abteilung kennt ihren Teil – das Gesamtbild fehlt.

Gute Prozessmodelle machen dieses Gesamtbild sichtbar. Sie zeigen Schnittstellen zwischen Bereichen, decken Redundanzen auf, benennen Verantwortlichkeiten und ermöglichen eine sachliche Diskussion über Verbesserungspotenziale. Ohne ein gemeinsames Modell ist diese Diskussion oft geprägt von Annahmen, Missverständnissen und Abteilungsdenken.

Darüber hinaus ist eine saubere Prozessdokumentation Voraussetzung für viele Folgeschritte: Zertifizierungen nach ISO-Normen, die Einführung von Softwaresystemen, die Einarbeitung neuer Mitarbeitender – oder die Automatisierung mit KI-Systemen.

Was Prozessmodellierung nicht leistet

Prozessmodelle verändern nichts, solange sie nur auf Papier oder in einem Tool existieren. Ein BPMN-Diagramm ist eine Beschreibung der Realität – es ist nicht die Realität selbst. Wer Prozesse verbessern will, kommt um die eigentliche Umsetzungsarbeit nicht herum: Verhaltensänderungen, Systemanpassungen, klare Verantwortlichkeiten im Tagesgeschäft.

Prozessmodelle lösen auch keine Konflikte. Häufig werden Modellierungsprojekte gestartet, weil es Reibung zwischen Abteilungen gibt. Das Modell beschreibt dann oft nur, wer in dem Konflikt recht hat – ohne den Konflikt selbst zu lösen. Dafür braucht es andere Ansätze.

Und: Prozessmodelle sind so gut wie die Menschen, die sie erstellen und pflegen. Ein Modell, das den Stand von vor zwei Jahren zeigt, ist in vielen Fällen problematischer als gar kein Modell – weil es falsche Sicherheit erzeugt.

BPMN: Wann sinnvoll, wann überdimensioniert?

BPMN 2.0 ist eine leistungsfähige, standardisierte Notation für die Prozessmodellierung. Sie ermöglicht präzise Beschreibungen komplexer Abläufe inklusive Verzweigungen, Ereignissen, parallelen Pfaden und systemübergreifenden Aktivitäten. Für technische Teams und Softwareprojekte ist BPMN häufig die richtige Wahl.

Für viele praktische Anwendungsfälle im Mittelstand ist BPMN allerdings überdimensioniert. Wenn es darum geht, den Ablauf einer Abteilung zu verstehen und mit dem Team zu diskutieren, ist ein einfaches Swimlane-Diagramm oder eine gut strukturierte Tabelle oft genauso wirksam – und in einem Bruchteil der Zeit erstellt.

Die sinnvolle Frage lautet deshalb nicht: „Nutzen wir BPMN?“ Sondern: „Welches Detailniveau brauchen wir, um das Problem zu lösen, das wir lösen wollen?“

Wann lohnt sich der Aufwand?

Prozessmodellierung lohnt sich, wenn mindestens einer der folgenden Punkte zutrifft:

• Schnittstellen sind unklar: Mehrere Bereiche, Systeme oder Standorte sind beteiligt, und niemand hat ein vollständiges Bild des Gesamtablaufs.
• Fehler treten systematisch auf: Wiederkehrende Fehler, die sich nicht auf einzelne Personen, sondern auf den Prozess selbst zurückführen lassen.
• Eine Veränderung steht bevor: Systemeinführung, Reorganisation, Wachstum – all das macht eine Bestandsaufnahme des Ist-Zustands sinnvoll.
• Wissen liegt bei Einzelpersonen: Wenn ein Prozess nur funktioniert, weil eine bestimmte Person weiß, wie es geht – und Risiken entstehen, wenn diese Person ausfällt oder das Unternehmen verlässt.
• Automatisierung ist geplant: Kein System und keine KI kann einen Prozess sinnvoll automatisieren, den niemand vollständig beschrieben hat.

Wann reicht eine einfachere Lösung?

Wenn der Prozess überschaubar ist, alle Beteiligten in einem Raum sitzen und das Problem klar ist, reicht oft ein gemeinsames Gespräch mit einer Whiteboard-Skizze. Der Aufwand einer formalen Modellierung wäre in solchen Fällen unverhältnismäßig.

Auch wiederkehrende, gut bekannte Standardprozesse ohne nennenswerte Varianz brauchen keine aufwändige Dokumentation – es sei denn, externe Anforderungen wie Zertifizierungen machen sie notwendig.

Prozessarbeit als kontinuierliche Aufgabe

Ein verbreitetes Missverständnis ist, dass Prozessmodellierung ein einmaliges Projekt ist: Man modelliert, verbessert, ist fertig. Tatsächlich sind Prozesse lebendig. Sie verändern sich mit dem Unternehmen, den Systemen und den Anforderungen.

Organisationen, die dauerhaft von Prozessarbeit profitieren, behandeln sie nicht als Einmalprojekt, sondern als kontinuierliche Praxis. Das bedeutet nicht, dass ständig neu modelliert wird – aber es bedeutet, dass Veränderungen dokumentiert, Modelle aktuell gehalten und Prozessverantwortlichkeiten klar sind.

Fazit

Prozessmodellierung ist ein nützliches Werkzeug – aber kein Allheilmittel. Sie schafft Klarheit und Grundlage für Verbesserungen, ersetzt aber nicht die Umsetzungsarbeit. Wer den Aufwand sinnvoll einsetzen möchte, stellt sich vor dem Projekt eine einfache Frage: Welche Entscheidung oder Maßnahme soll das Modell ermöglichen? Wenn die Antwort klar ist, lohnt sich der Aufwand. Wenn nicht, ist ein einfacherer Ansatz oft wirksamer.

Künstliche Intelligenz ist in aller Munde. Kaum ein Unternehmen, das nicht über KI-Piloten, Automatisierungsprojekte oder den Einsatz großer Sprachmodelle nachdenkt. Gleichzeitig hört man in Gesprächen mit Geschäftsführern und IT-Leitern immer wieder: „Wir haben es versucht – es hat nicht funktioniert.“ Dieses Muster ist kein Zufall.

Das Technologie-Problem, das keines ist

Wenn KI-Projekte scheitern, wird die Ursache häufig in der Technologie gesucht: Das Modell war nicht gut genug, die Daten zu schlecht, die Integration zu komplex. Tatsächlich sind technische Probleme aber in den wenigsten Fällen der eigentliche Grund für das Scheitern.

Viel häufiger liegt das Problem eine Ebene davor: im Prozessverständnis. Wer eine Aufgabe automatisieren will, muss sie zunächst vollständig verstanden und beschrieben haben. Wer das nicht kann – oder wessen Prozesse zu unstrukturiert sind –, übergibt der KI ein im Grunde unlösbares Problem.

Ein Beispiel aus der Praxis: Ein Unternehmen möchte die Bearbeitung eingehender E-Mails automatisieren. Klingt machbar. Doch schon bei der ersten Bestandsaufnahme zeigt sich: Niemand hat je systematisch erfasst, welche Arten von E-Mails überhaupt eingehen, welche Kriterien die Weiterleitung bestimmen, und was „korrekt bearbeitet“ konkret bedeutet. Diese Unklarheit lässt sich durch kein KI-Modell kompensieren.

Die häufigsten Ursachen für gescheiterte KI-Projekte

In der Beratungspraxis zeigen sich immer wieder ähnliche Muster. Die folgenden Punkte sind keine vollständige Analyse, sondern Beobachtungen aus konkreten Projektsituationen.

1. Fehlende Prozessdokumentation

KI-Systeme lernen aus Daten und Mustern. Wenn Arbeitsabläufe nirgendwo strukturiert beschrieben sind – wenn jede Mitarbeiterin und jeder Mitarbeiter „seinen Weg“ hat und Ausnahmen die Regel sind –, gibt es keine belastbare Grundlage für eine Automatisierung. Das Ergebnis: Das System lernt das Chaos, nicht die Lösung.

Bevor KI sinnvoll eingesetzt werden kann, muss der Ist-Zustand eines Prozesses beschrieben, bewertet und bereinigt sein. Das ist nicht glamourös, aber notwendig.

2. Unklare Erfolgskriterien

„Die KI soll das besser machen“ ist kein messbares Ziel. Was bedeutet besser? Schneller? Fehlerärmer? Kostenreduzierter? Welche Fehlerquote ist akzeptabel? Ab wann gilt ein Pilot als erfolgreich?

Ohne klare Kriterien gibt es keine Möglichkeit, den Projekterfolg zu beurteilen – und damit auch keine Grundlage, um Entscheidungen sachlich zu treffen.

3. Zu frühe Skalierung

Viele Organisationen starten mit einem Piloten, der in einer kontrollierten Umgebung funktioniert – und skalieren dann zu schnell. Die Besonderheiten des Pilotbereichs (spezifische Datenqualität, motivierte Mitarbeitende, enge Betreuung) lassen sich nicht ohne Weiteres auf andere Unternehmensbereiche übertragen.

Skalierung braucht Zeit, Anpassung und systematisches Lernen aus dem Piloten. Was in einer Abteilung funktioniert, muss für eine andere neu bewertet werden.

4. Fehlende Akzeptanz im Team

KI-Systeme werden von Menschen bedient, gepflegt und bewertet. Wenn das Team die Einführung als Bedrohung wahrnimmt – weil Kommunikation fehlt, Rollen unklar sind oder Ängste nicht adressiert werden –, wird das System im Alltag umgangen, ignoriert oder schlicht nicht genutzt.

Change Management ist kein „nice to have“ bei KI-Projekten. Es ist ein zentraler Faktor dafür, ob eine Einführung im Tagesgeschäft ankommt.

5. Tool-Entscheidungen ohne Strategie

Viele Unternehmen wählen KI-Tools nach Demos und Vertriebspräsentationen – ohne zu prüfen, welche Abhängigkeiten entstehen. Was passiert, wenn der Anbieter die Preise erhöht? Was bedeutet es für die Datensouveränität, wenn sensible Unternehmensdaten in eine Cloud-Plattform fließen?

Eine Tool-Entscheidung ist immer auch eine strategische Entscheidung. Sie sollte als solche behandelt werden.

Was vorher geklärt sein sollte

Bevor ein Unternehmen in die konkrete Umsetzung eines KI-Projekts geht, lohnt es sich, einige grundlegende Fragen zu beantworten:

• Welches Problem soll gelöst werden? Nicht: „Wir wollen KI einsetzen.“ Sondern: „Wir verlieren X Stunden pro Woche mit Aufgabe Y, weil Z.“
• Ist der Prozess beschrieben und stabil? Kann eine neue Mitarbeiterin oder ein neuer Mitarbeiter den Prozess anhand einer Dokumentation nachvollziehen? Wenn nicht, ist Prozessarbeit vor KI-Arbeit sinnvoll.
• Welche Daten stehen zur Verfügung? Menge, Qualität, Zugänglichkeit, Datenschutzrelevanz.
• Wer trägt Verantwortung? Gibt es eine interne Person, die das Projekt fachlich führt und langfristig betreut?
• Wie wird Erfolg gemessen? Konkrete, messbare Kennzahlen vor Projektbeginn festlegen.
• Was passiert im Fehlerfall? Wie wird mit Fehlern des Systems umgegangen? Wer entscheidet bei Grenzfällen?

Der richtige Einstieg

Für die meisten mittelständischen Unternehmen ist ein kleiner, klar abgegrenzter Pilot der sinnvollste Einstieg – nicht das ambitionierteste Projekt, sondern das, bei dem Aufwand und Erkenntnisgewinn in einem guten Verhältnis stehen.

Ein sinnvoller Pilot hat folgende Eigenschaften: Er bearbeitet ein reales, schmerzhaftes Problem. Der Prozess ist gut genug verstanden. Es gibt eine messbare Ausgangsgröße. Das Team ist informiert und eingebunden. Und: Es gibt einen klaren Abbruchplan, wenn der Pilot nicht die erwarteten Ergebnisse liefert.

Fazit

KI-Projekte scheitern selten an der Technologie. Sie scheitern an unklaren Prozessen, fehlender Vorbereitung, zu schneller Skalierung und mangelnder Einbindung der Mitarbeitenden. Wer diese Faktoren adressiert, schafft eine deutlich bessere Ausgangssituation – unabhängig davon, welche KI-Lösung am Ende zum Einsatz kommt.

Der erste Schritt ist nicht die Auswahl eines Tools. Der erste Schritt ist Klarheit über das Problem.