Automatisierungs-Playbook
Die meisten Automatisierungsprojekte scheitern nicht an der Technologie, sondern am Projektablauf. Dieses Playbook gibt Ihnen die exakte Sequenz, die in über 100 Mittelstandsprojekten funktioniert hat — von der Auswahl des ersten Prozesses bis zur unternehmensweiten Skalierung in 12 Monaten. Pragmatisch, mit Zahlen, ohne Beratungsfolien. Basis: reale Prozessautomation-Projekte in DACH.
Die Ausgangslage
Branchenstudien geben die Misserfolgsrate von Automatisierungsprojekten im Mittelstand mit 60–70 % an. Die Gründe sind bemerkenswert konsistent: Zu breiter Scope, schwammiger ROI, Technologie vor Prozessverständnis gewählt, kein klarer Owner im Unternehmen. Automatisierung als Thema ist reif — die Projekte drumherum sind es nicht.
Die gute Nachricht: Die Fehlermuster sind vorhersagbar, der Fix auch. Erfolgreiche Programme folgen einer engen Sequenz, die Technologie-Entscheidungen verschiebt, bis Prozess und Wertversprechen klar sind. Sie starten mit einem klar definierten Workflow, beweisen den Erfolg und expandieren von einer stabilen Basis. Klingt offensichtlich. Trotzdem fangen die meisten Projekte mit Tools und Dashboards an — die Versuchung ist groß.
Phase 1
Der erste Prozess entscheidet, ob das Programm weiterläuft oder nach dem Pilot stehen bleibt. Wählen Sie den falschen, und Sie produzieren ein Quartal lang ein funktionierendes Tool, das niemanden interessiert. Drei Kriterien schärfen die Auswahl.
Der Prozess sollte signifikante Stunden pro Woche fressen. Faustregel: mindestens 40 Personenstunden pro Monat manuelle Arbeit oder ein Dutzend frustrierte Stakeholder. Unter dieser Schwelle wiegt die operative Unruhe der Einführung den Nutzen im ersten Jahr selten auf.
Vermeiden Sie Prozesse, die vier Abteilungen umspannen und auf undokumentiertem Tribal-Knowledge basieren. Der richtige Erst-Use-Case hat einen klaren Trigger, ein definiertes Ergebnis und eine kleine Gruppe Menschen, die in unter einer Stunde jeden Schritt durchgehen können. Komplexität kommt später.
Sie brauchen eine Zahl davor und danach: Rechnungen pro Tag, Antwortzeit in Stunden, Fehlerquote in Prozent. Wenn der Wert der Automatisierung in vager „Effizienz" lebt, verliert das Projekt Luft, sobald ein Geschäftsführer Beweise verlangt.
Phase 2
Zwei Wochen Prozess-Mapping ersparen drei Monate Umbau. Das Ergebnis dieser Phase ist kein Visio-Diagramm — es ist ein klares Bild dessen, was wirklich passiert, inklusive der Ausnahmen und Workarounds, von denen offiziell niemand spricht.
Setzen Sie sich einen ganzen Tag zu den Menschen, die die Arbeit machen. Erfassen Sie jeden Klick, jede Wartezeit, jeden Slack-Ping, jedes „normalerweise kopiere ich das einfach aus dem letzten Monat". Prozesse, die als sauberer 4-Schritte-Flow beschrieben werden, entpuppen sich oft als 11 reale Schritte, von denen 3 nur existieren, weil 2019 eine Systemlimitation einen Workaround erzwungen hat. Diese Schritte sind das Gold — Automatisierung, die sie ersetzt, liefert sofort sichtbaren ROI.
Output dieser Phase: ein Schritt-für-Schritt-Prozessdokument, eine Baseline-Messung des Ist-Zustands, eine Liste zu behandelnder Ausnahmen (und welche zu ignorieren sind), und ein klares „Definition of Done" für den automatisierten Soll-Zustand. Damit fällt die Technologie-Wahl fast von selbst.
Phase 3
Erst jetzt kommt Technologie ins Spiel. Die meisten realen Automatisierungen kombinieren zwei oder drei Kategorien: eine Workflow-Plattform zur Orchestrierung, ein KI-Modell für unstrukturierten Input, API-Aufrufe an die führenden Systeme. Reines RPA ist heute selten die richtige Wahl — es verdient seinen Platz nur dort, wo Legacy-Systeme überhaupt keine API haben.
Pragmatische Standard-Auswahl für den Mittelstand: n8n oder Power Automate als Orchestrierer, GPT-4 oder ein lokales Llama-Modell für Schritte mit unstrukturiertem Input, direkte API-Integration mit ERP/CRM/DMS für deterministische Schritte. Diese Kombination deckt 80 % realer Automatisierungs-Bedarfe ab — zu einem Bruchteil der Kosten von Enterprise-RPA-Suiten. Seitenvergleich der Optionen im Tool-Vergleich Make vs. Zapier und im tieferen RPA-vs-KI-Breakdown.
Phase 4
Die Build-Phase ist bewusst kurz. Acht Wochen vom ersten Build zum Live-Betrieb erzwingen echte Entscheidungen und verhindern Perfektionismus. Die Taktung zählt mehr als die Technologie.
Den Standardfall end-to-end mit echten Daten zum Laufen bringen, auch wenn das UI rau ist und Edge-Cases unbehandelt. Den Workflow vom Trigger zum Ergebnis zu sehen alignt alle schneller als jedes Dokument.
Jetzt die unscheinbare aber essenzielle Arbeit: Validierungsregeln, Fehlerbehandlung, Audit-Trail, Ausnahme-Routing. Hier entsteht der Unterschied zwischen Demo und Produktivsystem.
Die Automatisierung parallel zum manuellen Prozess laufen lassen. Outputs täglich vergleichen. Prompts und Regeln basierend auf realer Divergenz tunen. Die meisten Diskrepanzen entpuppen sich als Edge-Cases, die niemand dokumentiert hatte — hier findet man sie.
Die Automatisierung auf Primary schalten, manuellen Fallback zwei Wochen verfügbar halten. Metriken täglich monitoren. Das Team auf den neuen Flow schulen, besonders auf Exception-Handling. Ab hier läuft die Automatisierung und das Team owned sie.
Phase 5
Ein einzelner automatisierter Prozess ist ein Tool. Drei verbundene werden zu einer Plattform. Der Shift von Projekt zu Programm passiert um den dritten Use-Case herum — dann fängt die geteilte Infrastruktur (Logging, Monitoring, Prompt-Management, System-Integrationen) an, sich über Use-Cases hinweg zu rechnen.
Die richtige Sequenz: Use-Case 1 beweist den Wert, Use-Case 2 beweist die Wiederholbarkeit durchs Team, Use-Case 3 beweist die Infrastruktur-Skalierung. Spätestens dann haben die meisten Unternehmen eine klare Pipeline nächster Kandidaten und die interne Glaubwürdigkeit, weiterzumachen. Mehr zur KI-Automatisierungs-Roadmap im Mittelstand.
Häufige Fragen