Automatisierung, die bleibt: Warum die meisten Projekte nach 12 Monaten stagnieren

Automatisierung, die bleibt: Warum die meisten Projekte nach 12 Monaten stagnieren

Letzten Herbst rief mich ein Kunde an. Geschäftsführer eines Logistikdienstleisters mit 80 Mitarbeitern. Er hatte vor anderthalb Jahren eine Automatisierungsinitiative gestartet: automatische Auftragsbestätigungen, wöchentliche Berichte, Kunden-E-Mails. Der Pilot lief erfolgreich. Das Team war begeistert.

Dann rief er mich an, um zu fragen, warum nichts mehr läuft.

Die Antwort ist dieselbe, die ich seitdem einem Dutzend Kunden gegeben habe: Weil die Initiative nach dem Pilot aufgehört hat. Und Automatisierung kein Einmalvorhaben ist.

Das ist kein Einzelfall. Es ist ein Muster. Wer es nicht versteht, erlebt dasselbe.

Die Kurve nach dem Pilot

Automatisierungsprojekte folgen einem vorhersagbaren Verlauf. In der ersten Phase, dem Pilot, läuft alles gut. Es gibt klare Ziele, begrenzten Umfang, motivierte Beteiligte. Die Ergebnisse sind sichtbar.

Dann kommt Phase zwei: der Betrieb. Und da sieht es anders aus.

Die Mitarbeiterin, die den Workflow gebaut hat, hat das Unternehmen gewechselt. Der Anbieter hat sein Preismodell geändert. Die API eines Drittanbieters hat sich still aktualisiert, und plötzlich kommen keine Auftragsbestätigungen mehr an. Niemand weiß genau, was dieser Workflow macht, weil die Dokumentation aus drei Stickies in Notion bestand.

Kein böser Wille. Kein technisches Versagen. Nur die natürliche Erosion von Systemen, die niemand als eigenständige Verantwortlichkeit behandelt hat.

Das Problem ist nicht die Technologie. Das Problem ist die Governance.

Was Automatisierung von klassischen IT-Projekten unterscheidet

Wer aus dem klassischen IT-Projektmanagement kommt, denkt in Phasen: Anforderungsaufnahme, Entwicklung, Abnahme, Betrieb. Das Projekt endet mit der Abnahme.

Automatisierung funktioniert anders. Ein Workflow ist kein abgeschlossenes System. Er verbindet lebende Prozesse: APIs, die sich ändern. Organisationsstrukturen, die sich wandeln. Mitarbeiter, die kommen und gehen.

Das bedeutet: Ein Workflow, der heute läuft, kann morgen kaputt sein — nicht weil jemand etwas falsch gemacht hat, sondern weil sich das Umfeld verändert hat. Wer nicht regelmäßig hinschaut, erfährt den Fehler erst, wenn der Schaden groß ist.

Das ist ein grundlegend anderes Betriebsmodell als ein klassisches IT-System. Die meisten Unternehmen haben es noch nicht internalisiert.

Fünf Muster, die ich immer wieder sehe

Es gibt fünf Ursachen, die fast immer auftauchen, wenn Automatisierungsprojekte nach dem Pilot einschlafen.

1. Pilot-only-Denken: Der Erfolg wird als Ende behandelt

Das häufigste Muster: Das Unternehmen behandelt den Pilot als Ziel, nicht als Startpunkt. Man baut drei, vier Workflows. Man zeigt den Entscheidern, was möglich ist. Und dann? Nichts.

Warum? Weil nach dem Pilot kein Folgeprojekt definiert wurde. Weil niemand gefragt hat: Welche Prozesse kommen als nächstes? Wer ist zuständig für die Pflege der bestehenden Workflows?

Der Pilot war so erfolgreich, dass niemand mehr darüber gesprochen hat. Er ist still in den Hintergrund getreten — bis irgendetwas kaputt geht.

Das zeigt ein fundamentales Missverständnis: Automatisierung ist kein Projekt, das man abschließt. Es ist eine Kompetenz, die man aufbaut. Die Frage nach dem Pilot ist nicht: "Hat das funktioniert?" Die richtige Frage ist: "Wie machen wir daraus ein dauerhaftes Betriebsmodell?"

2. Keine klare Eigentümerschaft

Während des Pilots ist die Verantwortung oft implizit. Jemand aus IT oder Operations treibt das voran. Wenn der Pilot endet, löst sich diese Verantwortung auf. Der Workflow läuft, also muss sich niemand darum kümmern. Bis er nicht mehr läuft.

Was fehlt, ist ein benannter Eigentümer: eine Person, die für den Workflow verantwortlich ist, regelmäßig prüft, ob er noch korrekt funktioniert, und weiß, was zu tun ist, wenn er ausfällt. Das muss kein Techniker sein. Eine Fachabteilungsmitarbeiterin, die den Prozess kennt, reicht vollständig aus.

Ohne diese Person ist der Workflow eine Blackbox. Er läuft, solange er läuft. Wenn er aufhört zu laufen, erfährt es niemand — bis ein Kunde sich beschwert.

In größeren Organisationen ist das Problem noch komplexer. Wenn drei Abteilungen an einem Workflow beteiligt sind, aber keine davon offiziell verantwortlich ist, passiert im Fehlerfall genau das, was man erwarten würde: alle warten, dass die anderen das Problem lösen.

3. Technische Schulden durch Geschwindigkeit

Automatisierung lebt von Geschwindigkeit. Der erste Workflow wird in einer Woche aufgebaut, der zweite in zwei Tagen. Das ist gut so. Iterieren ist besser als Theoretisieren.

Das Problem: Was schnell gebaut wird, wird oft nicht ordentlich dokumentiert. Bezeichnungen sind kryptisch. Logik ist implizit. Abhängigkeiten zu externen Systemen sind undokumentiert.

Ein Workflow, den die Person gebaut hat, die ihn heute noch erklärt, funktioniert ausgezeichnet. Derselbe Workflow, sechs Monate später, wenn diese Person im Urlaub oder im nächsten Job ist, ist ein Rätsel.

Technische Schulden in der Automatisierung sind tückischer als in klassischer Softwareentwicklung, weil sie oft unsichtbar bleiben. Der Workflow läuft — er läuft nur falsch. Er sendet E-Mails, die niemand liest. Er schreibt Datensätze in ein System, das niemand mehr überprüft.

Ich kenne ein Unternehmen, das einen Workflow hatte, der täglich Berichte erstellen und per E-Mail verschicken sollte. Der Workflow hatte einen Fehler in der E-Mail-Logik. Er erstellte die Berichte korrekt, verschickte sie aber an eine Adresse, die seit Monaten nicht mehr existierte. Niemand prüfte, ob die E-Mails ankamen. Fünf Monate lang produzierte das System täglich Berichte, die in einem leeren Postfach verschwanden.

Das ist keine Katastrophe. Aber es zeigt, was fehlt: ein grundlegendes Monitoring, das eine einfache Frage beantwortet — funktioniert dieses System noch so, wie es soll?

4. Kennzahlen, die nicht auf Betrieb ausgelegt sind

Automatisierungsprojekte werden fast immer mit Pilot-Metriken bewertet: Wie viele Stunden werden eingespart? Wie hoch ist der ROI?

Das sind legitime Fragen für den Pilot. Für den Betrieb sind sie unzureichend.

Was in der Betriebsphase fehlt, sind Fragen wie: Läuft der Workflow noch? Wie oft schlägt er fehl? Wie lange dauert es, bis jemand das bemerkt?

Ohne diese Metriken gibt es keine Sichtbarkeit auf den Betrieb. Und ohne Sichtbarkeit gibt es keine Grundlage für Eingriffe, Verbesserungen oder Budgetentscheidungen. Automatisierung, die niemand misst, verschwindet aus dem Bewusstsein — bis zum nächsten Ausfall.

5. Tool-Chaos: zu viele Werkzeuge, zu wenig Strategie

Dieses Muster entsteht aus dem Erfolg, nicht aus dem Misserfolg. Eine Abteilung beginnt mit Zapier. Eine andere nutzt Make. Die IT setzt n8n auf. Der Vertrieb experimentiert mit einem weiteren Tool. Jedes Team hat seine eigene Toolbox, und niemand hat den Überblick.

Das klingt nach einem luxuriösen Problem. In der Praxis ist es ein Governance-Alptraum.

Erstens Sicherheit: Jeder neue Automatisierungs-Connector hat Zugriff auf Unternehmensdaten. Wer behält den Überblick, welche Daten wo fließen? Welche Tools haben Zugriff auf Kundendaten? Sind diese Zugriffe DSGVO-konform?

Zweitens Kompetenz: Wenn jede Abteilung ihr eigenes Tool nutzt, gibt es keine gemeinsame Lernkurve. Das Wissen bleibt fragmentiert. Die Person, die in Abteilung A Zapier-Experte ist, kann Abteilung B nicht helfen, weil Abteilung B Make verwendet.

Drittens Kosten: Fünf verschiedene Automatisierungstools kosten fünfmal so viel wie eines, liefern aber nicht fünfmal mehr Nutzen. Und wenn Konsolidierung ansteht, ist das ein Migrationsprojekt, das niemand geplant hat.

Das Ergebnis: viele Inseln, wenig Brücken. Automatisierung, die in Abteilungsgrenzen eingesperrt ist und nie skalieren kann.

Was nachhaltige Automatisierung ausmacht

Was haben Unternehmen gemeinsam, bei denen Automatisierung nicht nur als Pilot bekannt ist, sondern als dauerhafter Betrieb funktioniert?

Klare Verantwortlichkeiten

In diesen Unternehmen gibt es für jeden Workflow einen definierten Eigentümer. Nicht ein Team. Eine Person. Diese Person ist nicht zwingend technisch, aber sie versteht den Prozess, den der Workflow abbildet. Sie ist die erste Anlaufstelle, wenn etwas schiefläuft, und meldet Änderungsbedarf, wenn sich der zugrundeliegende Prozess verändert.

Das ist keine Vollzeitstelle. Es sind 30 Minuten pro Woche, wenn das System läuft. Und einige Stunden, wenn es nicht läuft.

Dokumentation, die jemand tatsächlich liest

Gute Automatisierungs-Dokumentation hat nichts mit langen Handbüchern zu tun. Es reicht, wenn für jeden Workflow drei Fragen beantwortet sind:

• Was macht dieser Workflow?
• Was passiert, wenn er fehlschlägt?
• Wer ist zuständig?

Das passt auf eine Seite. Das Format spielt keine Rolle. Was zählt, ist, dass diese Information existiert und aktuell gehalten wird.

Ein Workflow ohne diese drei Antworten ist eine tickende Zeitbombe — nicht weil er gleich ausfällt, sondern weil der Tag kommt, an dem jemand anderes ihn anfassen muss und nichts mehr versteht.

Monitoring, das aufwacht, bevor jemand anruft

Jeder laufende Workflow braucht eine Antwort auf die Frage: Wie erfahren wir, wenn er nicht mehr funktioniert?

Das muss kein hochentwickeltes System sein. Ein einfaches Alerting, das eine Slack-Nachricht schickt, wenn ein Workflow fehlschlägt oder seit X Stunden nicht ausgelöst wurde, reicht für die meisten Fälle. Viele Automatisierungsplattformen bieten das eingebaut.

Das Ziel: Der erste, der erfährt, dass etwas nicht stimmt, soll nicht der Endkunde sein.

Standardisierter Tech-Stack

Nachhaltiges Skalieren erfordert eine klare Entscheidung: Welche Tools verwenden wir — und welche nicht, egal wie attraktiv ein neues Feature wirkt?

Das schließt Flexibilität nicht aus. Aber neue Tools sollten durch einen kurzen Evaluationsprozess gehen. Drei Fragen genügen:

1. Löst das neue Tool ein Problem, das unser bestehendes nicht löst? 2. Welche Datenzugriffe erfordert es, und wie passt das zu unserer Datenschutzstrategie? 3. Wer übernimmt die Verantwortung für Betrieb und Schulung?

Wenn diese Fragen keine klaren Antworten haben, ist das Tool noch nicht reif für den Einsatz.

Iteratives Wachstum statt Big-Bang

Organisationen, die Automatisierung dauerhaft betreiben, bauen inkrementell. Sie starten mit einem Workflow. Wenn der stabil läuft und verantwortet wird, folgt der nächste. Nicht zehn gleichzeitig.

Das klingt langsam. Es ist tatsächlich schneller — weil Stabilität von Anfang an im System ist, statt nachträglich aufwendig nachgerüstet werden zu müssen.

Ein Center of Excellence: Wann es sich lohnt und wann nicht

In Fachliteratur und Beratungsbroschüren liest man oft vom "Center of Excellence" (CoE) als Antwort auf Automatisierungsskalierung. Das klingt groß. In vielen Fällen ist es auch groß — und damit für kleinere Organisationen unrealistisch.

Für ein Unternehmen mit 50 Mitarbeitern brauchen Sie kein formales CoE. Sie brauchen eine Person, die diese Verantwortung trägt, und ein paar klare Prozesse.

Ab 200 bis 300 Mitarbeitern, wenn mehrere Abteilungen gleichzeitig automatisieren und die Anzahl der Workflows zweistellig wird, lohnt sich ein leichtgewichtiges CoE.

Was ein CoE tut: - Es setzt Standards für Tools, Sicherheit und Dokumentation - Es reviewed neue Workflows, bevor sie in Produktion gehen - Es bietet interne Beratung für Abteilungen, die automatisieren möchten - Es pflegt einen Katalog bestehender Workflows und vermeidet Duplikate

Was ein CoE nicht ist: - Es ist kein Gatekeeper, der jede Anfrage bremst - Es ist kein zentrales Entwicklungsteam, das alle Workflows baut - Es ist kein IT-Projekt mit einem Enddatum

Ein gutes CoE ist ein Enabler, kein Kontrollgremium. Es gibt den Abteilungen Fähigkeiten und Standards, um selbst zu automatisieren — auf einer gemeinsamen technischen Grundlage.

Die drei Entwicklungsphasen:

Phase 1 ist eine einzige Person, die die Verantwortung übernimmt. Das kann der Operations Manager sein, der IT-Leiter oder in kleinen Organisationen der Geschäftsführer selbst. Diese Person investiert 20 bis 30 Prozent ihrer Zeit, um bestehende Workflows zu dokumentieren und Standards zu definieren.

Phase 2 beginnt, wenn die Anzahl der Workflows 15 bis 20 überschreitet. Jetzt lohnt sich ein kleines Team: zwei bis drei Personen, die gemeinsam Betrieb, Evaluierung und Schulung verantworten.

Phase 3 — ein formales CoE mit dedizierten Rollen und Governance-Prozessen — ist für die meisten Organisationen erst ab 500 Mitarbeitern sinnvoll.

Der häufigste Fehler: Phase 3 als Ziel definieren und Phase 1 nie anfangen, weil das Gesamtbild zu groß wirkt.

Die richtige Reihenfolge: Was vor dem zweiten Workflow kommt

Bevor Sie das zweite Automatisierungsprojekt starten, klären Sie diese Fragen zum ersten:

Wer ist der Eigentümer dieses Workflows? Eine benannte Person, nicht ein Team.

Ist der Workflow dokumentiert? Nicht für eine Behörde — für den Fall, dass die Eigentümerin drei Wochen krank ist.

Was passiert bei einem Ausfall? Wer wird benachrichtigt? Gibt es eine manuelle Alternative?

Wie wird der Workflow gemonitort? Gibt es Alerting? Wer empfängt die Alerts?

Wie wird der Workflow gepflegt? Wann findet die nächste Überprüfung statt?

Wenn diese Fragen keine klaren Antworten haben, ist der erste Workflow noch nicht fertig — egal wie gut er technisch funktioniert.

Das klingt nach Aufwand. In der Praxis dauert die Beantwortung dieser fünf Fragen 30 Minuten. Die Kosten, sie nicht zu beantworten, sind Stunden der Fehlersuche zu einem späteren Zeitpunkt.

Wie viel lässt sich realistisch automatisieren?

Eine Frage, die ich oft höre: Was kann man eigentlich automatisieren?

Die ehrliche Antwort: Mehr, als die meisten Unternehmen annehmen. Weniger, als manche Präsentationen suggerieren.

Prozesse, die sich fast immer automatisieren lassen: - Wiederkehrend, mit identischer oder ähnlicher Struktur - Regelbasiert, ohne Ermessensspielraum - Datengetrieben, mit klaren Input- und Output-Formaten - Ausreichend häufig, um Aufwand und Ertrag zu rechtfertigen

Prozesse, die sich selten vollständig automatisieren lassen: - Hoher Ermessensspielraum, situative Entscheidungen - Sensible Kundeninteraktionen, bei denen Empathie entscheidend ist - Ausnahmen, die häufiger vorkommen als die Regel

Zwischen diesen Polen liegt das interessanteste Terrain: Prozesse, die teilweise automatisiert werden können. Menschen behalten die Kontrolle über Ausnahmen, während Routinearbeit im Hintergrund läuft.

Ein Vertriebsmitarbeiter, der KI-generierte Zusammenfassungen als Vorbereitung für Kundengespräche nutzt, ist eine hybride Automatisierung. Er trifft die Entscheidungen. Die Routine übernimmt die KI. Dieser Ansatz ist oft sinnvoller als das Streben nach vollständiger Automatisierung.

Was Sie in den nächsten 30 Tagen tun können

Automatisierungsgovernance klingt nach einem Großprojekt. Sie muss es nicht sein.

Woche 1: Inventur. Listen Sie alle laufenden Automatisierungen auf. Nicht nur die offiziellen. Auch die Zapier-Flows, die jemand privat angelegt hat. Auch die Excel-Makros. Das Ergebnis wird Sie wahrscheinlich überraschen.

Woche 2: Eigentümer benennen. Weisen Sie jedem Workflow einen Eigentümer zu. Auch den Workflows, die gut laufen — gerade für die ist es wichtig. Kommunizieren Sie diese Zuweisung explizit.

Woche 3: Steckbriefe anlegen. Für jeden Workflow: Was macht er? Was passiert bei Ausfall? Wer ist zuständig? Kein Handbuch. Eine Seite pro Workflow reicht.

Woche 4: Alerting prüfen. Für jeden geschäftskritischen Workflow: Gibt es eine Benachrichtigung bei Ausfall? Wenn nicht, einrichten. Die meisten Plattformen bieten das in wenigen Minuten.

Das ist keine Transformation. Es ist solide Betriebshygiene. Aber sie macht den Unterschied zwischen Automatisierung, die nach zwei Jahren noch läuft, und Automatisierung, die nach sechs Monaten einschläft.

Was Unternehmen, die skalieren, anders machen

Wenn ich auf Organisationen schaue, bei denen Automatisierung als dauerhafter Betrieb funktioniert, sehe ich nicht bessere Technologie. Ich sehe bessere Prinzipien.

Sie behandeln Automatisierung wie jedes andere Betriebssystem. Nicht wie ein Projekt, das man abschließt, sondern wie eine Funktion, die man managt. Sie haben Eigentümer. Sie haben Monitoring. Sie haben Standards. Und sie haben die Disziplin, neue Workflows erst dann einzuführen, wenn die bestehenden ordentlich betrieben werden.

Das erfordert eine Entscheidung: Automatisierung ist eine Betriebsaufgabe, keine Projektaufgabe.

Wer diese Entscheidung trifft, baut Automatisierung, die bleibt.

Wenn Sie wissen möchten, wie gut Ihre aktuelle Automatisierungsbasis aufgestellt ist, finden Sie im kostenlosen Automations-Check einen strukturierten Ausgangspunkt. In 30 Minuten klären wir gemeinsam, was läuft, was stagniert, und was als nächstes kommt.