Rund 80 % der CMMS-Implementierungen gelten als gescheitert. 94,7 % der befragten Instandhaltungsleiter geben an, ihr System nicht annähernd voll zu nutzen. Gleichzeitig steigen die Investitionen in CMMS/EAM-Systeme, Predictive Maintenance, RPA für Bestellprozesse und IoT-Sensorik weiter. Die Frage ist nicht, ob diese Zahlen stimmen. Die Frage ist, warum der Widerspruch zwischen Investitionsbereitschaft und Ergebnisqualität so beständig ist.
Die kurze Antwort: Automatisierung in der Instandhaltung vereinfacht nicht automatisch. Sie verlagert Komplexität. Wer diesen Mechanismus nicht erkennt, tauscht sichtbare, handhabbare Probleme gegen unsichtbare, schwerer steuerbare Abhängigkeiten ein.
Warum das Versprechen nicht aufgeht
Die Erwartungshaltung ist verständlich: Manuelle Prozesse kosten Zeit, erzeugen Fehler, binden Fachkräfte, die ohnehin fehlen. Ein System, das Ausfälle vorhersagt, Bestellungen automatisch auslöst oder Wartungsintervalle optimiert, klingt nach klarem Fortschritt. Das Problem liegt nicht in der Idee. Es liegt darin, was Automatisierung strukturell mit einem komplexen System macht.
Jedes neue Tool – ob CMMS, EAM-Plattform, IoT-Integration oder RPA-Bot – fügt dem bestehenden Systemgefüge neue Elemente hinzu: Schnittstellen, Datenflüsse, Rollen, Wartungsaufgaben für die Automatisierung selbst. Die Komplexität des Gesamtsystems steigt. Nur tut sie das unsichtbar, bis etwas bricht.
Charles Perrow hat diesen Zusammenhang bereits 1984 in Normal Accidents beschrieben: In eng gekoppelten Systemen mit hoher interaktiver Komplexität sind Fehler kein Ausnahmefall. Sie sind systemimmanent. Kein einzelner Akteur kann alle Wechselwirkungen überblicken und je mehr Schichten das System hat, desto mehr gilt das.
Drei Mechanismen, durch die Automatisierung Komplexität erzeugt
1. Systemkopplung und Schnittstellenmultiplikation
Ein CMMS, das Daten aus ERP, Sensorik und Wartungsprotokollen zusammenführen soll, klingt nach Konsolidierung. In der Praxis entstehen neue Abhängigkeiten: von Datenqualität, von Schnittstellenkompatibilität, von Integrationspartnern.
Die Anzahl möglicher Wechselwirkungen steigt nicht linear, sondern kombinatorisch. Jede neue Verbindung ist eine neue Fehlerquelle. Studien zeigen, dass 50–60 % des MRO-Bestands in typischen Fertigungsunternehmen überschüssig, veraltet oder kaum bewegt ist – ein Problem, das durch fehlerhafte Stammdaten in automatisierten Systemen nicht gelöst, sondern systematisch verdeckt wird.
In unseren Projekten beobachten wir, dass die eigentlichen Implementierungskosten häufig nicht die Softwarelizenzen sind. Es sind die Aufräumarbeiten: Stammdaten bereinigen, Schnittstellen stabilisieren, Prozesse klären – damit das System überhaupt sinnvolle Ausgaben erzeugt.
2. Kompetenzverlust: Die Bainbridge-Ironie
Lisanne Bainbridge hat 1983 ein Paradox beschrieben, das heute relevanter ist denn je: Je mehr Routineaufgaben automatisiert werden, desto seltener üben Mitarbeitende die Fähigkeiten, die genau dann gebraucht werden, wenn die Automatisierung versagt.
In der Instandhaltung ist das unmittelbar spürbar. Wenn ein Predictive-Maintenance-System Ausfälle vorhersagt, verlernen Techniker die diagnostische Kompetenz, die nötig wird, wenn das System einen Fehlertyp nicht erkennt oder falsch-negativ ausfällt.
Statt weniger Schulung zu erfordern, braucht Automatisierung mehr – und zwar für Situationen, die seltener eintreten und deshalb schwerer trainierbar sind. Die Zahlen bestätigen das: Organisationen, die 30–40 % ihrer Projektressourcen in organisatorische Anpassung und Kompetenzaufbau investieren, verzeichnen 3–4-mal niedrigere Ausfallraten als solche, die nur 10–15 % einplanen (McKinsey).
3. Technische Schulden und Prozessversteifung
RPA im MRO-Kontext – also automatisierte Bestellauslösungen, Freigabeprozesse, Statusmeldungen – hat einen systemischen Nachteil: Die Bots operieren auf Oberflächen bestehender Systeme und imitieren manuelle Klickpfade. Jede Änderung am Quellsystem kann die Automatisierung brechen.
Die Konsequenz: Wer RPA eingeführt hat, verliert Flexibilität. Prozessanpassungen werden aufwendiger, weil sie immer auch die Automatisierung anpassen müssen. Die Wartungskosten der Automatisierung selbst steigen. Das Ergebnis ist eine Organisation, die gleichzeitig „automatisiert“ und trotzdem fragil ist.
Warum das kein Implementierungsproblem ist
Die naheliegende Reaktion lautet: „Man muss es nur richtig machen.“ Das greift zu kurz.
Die drei Mechanismen sind keine Folge schlechter Planung oder mangelnder Kompetenz. Sie sind systemimmanente Eigenschaften von Automatisierung in komplexen Umgebungen. Perrows Kernargument gilt direkt: Zusätzliche Automatisierungsschichten erhöhen die Systemkomplexität und können neue Fehlerarten erzeugen, die vorher nicht existierten.
McKinsey zeigt: Unternehmen, die Predictive Maintenance mit klarer Struktur – inklusive Datenqualität, Systemintegration und organisatorischer Vorbereitung – einführen, realisieren 75–85 % des möglichen Nutzens. Isolierte Implementierungen bleiben bei 30–40 %.
Der Unterschied liegt nicht in der Technologie. Er liegt darin, ob die Komplexitätseffekte von Anfang an mitgedacht werden.
Was Unternehmen konkret tun können
Das bedeutet nicht, weniger zu automatisieren. Es bedeutet, bewusster zu automatisieren. Drei Leitfragen helfen dabei:
- Komplexitätsbilanz erstellen: Welche Komplexität entfällt tatsächlich – und welche kommt neu hinzu? Schnittstellen, Datenabhängigkeiten, neue Kompetenzanforderungen und der Wartungsaufwand der Automatisierung selbst müssen von Beginn an eingeplant werden.
- Degradationsfähigkeit sicherstellen: Was passiert, wenn die Automatisierung ausfällt oder fehlerhaft arbeitet? Kann die Organisation im Notfall manuell weiterarbeiten – und wird diese Fähigkeit aktiv erhalten?
- Investitionsverteilung prüfen: Wie viel des Projektbudgets fließt in Technologie, wie viel in organisatorische Anpassung, Datenqualität und Kompetenzaufbau? Die Evidenz deutet darauf hin, dass ein Verhältnis von mindestens 60:40 (Technologie : Organisation) die Erfolgswahrscheinlichkeit erheblich steigert.
In unseren Projekten beginnen wir deshalb nicht mit der Frage „Welches System passt?“ – sondern: „Welche neue Komplexität nehmen wir mit dieser Entscheidung in Kauf, und sind wir organisatorisch darauf vorbereitet, sie zu beherrschen?“
Fazit
Automatisierung in der Instandhaltung ist keine Frage des Ob, sondern des Wie, Wo und wie viel. Wer die drei Mechanismen – Schnittstellenmultiplikation, Kompetenzverlust und technische Schulden – von Projektbeginn an in die Planung einbezieht, trifft bessere Entscheidungen. Nicht weil er weniger automatisiert, sondern weil er bewusster automatisiert.
FAQ
Häufig gestellte Fragen:
Warum scheitern so viele CMMS-Implementierungen?
Die Hauptursachen liegen selten in der Software selbst. Fehlerhafte Stammdaten, ungeklärte Prozesse und fehlende organisatorische Vorbereitung sind die häufigsten Treiber. Ein System, das auf unklare Prozesse trifft, bildet Unklarheit nur schneller und systematischer ab.
Wie lange dauert es, bis eine Automatisierung in der Instandhaltung wirklich funktioniert?
Realistische Einführungszeiträume für integrierte CMMS/EAM-Systeme liegen bei 18–24 Monaten – inklusive Datenbereinigung, Schnittstellenstabilisierung und Schulungsaufwand. Projekte, die diesen Zeitrahmen deutlich unterschreiten wollen, sparen oft an genau den Stellen, die über Betriebserfolg oder -misserfolg entscheiden.
Was bedeutet „Degradationsfähigkeit“ in der Praxis?
Es geht darum, dass die Organisation auch ohne vollständige Systemunterstützung handlungsfähig bleibt: Techniker kennen kritische Anlagen aus Erfahrung, Notfallprozesse sind definiert und werden regelmäßig geübt. Automatisierung sollte menschliche Kompetenz ergänzen, nicht ersetzen.
Wann ist Automatisierung in der Instandhaltung sinnvoll?
Wenn drei Voraussetzungen erfüllt sind: Die relevanten Prozesse sind stabil und dokumentiert. Die Datenqualität ist ausreichend für verlässliche Systemausgaben. Und die Organisation hat die Kapazität, die neue Komplexität aktiv zu bewirtschaften.
