79 % der mittelständischen Unternehmen stufen Automatisierung als geschäftskritisch ein. Gleichzeitig scheitern 30 bis 50 % der ersten RPA-Projekte. Das ist kein Technologieproblem. Das ist ein Prozessproblem.

Die Unternehmen, die erfolgreich automatisieren, unterscheiden sich in einem Punkt von denen, die scheitern: Sie wissen, was tatsächlich passiert. Nicht was im Prozesshandbuch steht, nicht was die letzte ISO-Zertifizierung dokumentiert hat, sondern was jeden Tag auf dem Shopfloor, im Backoffice und zwischen den Abteilungen wirklich geschieht. Sie haben Prozessklarheit, bevor sie ein einziges Tool evaluieren.

Dieser Artikel zeigt, warum Automatisierung ohne diese Klarheit systematisch scheitert, welche drei Muster sich dabei immer wiederholen und was der Mittelstand stattdessen braucht.

Ihr dokumentierter Prozess ist eine Lüge

Harter Satz. Aber in unserer Projektarbeit bestätigt er sich immer wieder.

Die meisten Unternehmen haben Prozessdokumentation. Organigramme, Ablaufdiagramme, teilweise sogar ein QM-Handbuch. Das Problem: Diese Dokumente beschreiben den Soll-Zustand, nicht den Ist-Zustand. Und zwischen beiden liegen Welten.

In einem Fertigungsunternehmen mit 180 Mitarbeitern fanden wir 14 verschiedene Excel-Dateien, die denselben Kundenstamm verwalteten. Jede Abteilung hatte ihre eigene Version, mit eigenen Spalten, eigenen Workarounds, eigenen Makros. Der Geschäftsführer war überzeugt, das CRM sei das Problem. In Wahrheit war der Prozess nie definiert worden. Nur die Software.

Das ist kein Einzelfall. In nahezu jedem Projekt, das wir begleiten, zeigt sich dasselbe Bild: Die offizielle Dokumentation beschreibt einen Idealzustand, der mit der gelebten Realität wenig zu tun hat. Mitarbeiter haben über Jahre Workarounds entwickelt, Ausnahmen sind zur Norm geworden, und niemand hat die Prozessbeschreibung aktualisiert.

Die Gründe sind menschlich nachvollziehbar. Ein neuer Mitarbeiter findet heraus, dass der offizielle Prozess in der Praxis nicht funktioniert. Statt den Prozess zu eskalieren, baut er einen Workaround. Der Workaround funktioniert. Er wird zum Standard. Andere übernehmen ihn. Nach drei Jahren gibt es fünf verschiedene Varianten desselben Prozesses, alle undokumentiert, alle irgendwie funktional, keine davon offiziell.

Wenn Sie auf Basis der offiziellen Dokumentation automatisieren, passiert Folgendes: Sie automatisieren einen Prozess, den niemand so lebt. Das Ergebnis ist nicht Effizienz. Es ist ein automatisiertes Chaos, das schneller läuft als vorher. Der Bot macht in einer Stunde, wofür ein Mensch einen Tag braucht. Nur macht er jetzt die falschen Dinge in einer Stunde statt in einem Tag.

59 % der deutschen IT-Entscheider geben an, dass ihr Unternehmen noch nicht den Reifegrad für durchgängige Prozessautomatisierung erreicht hat. In Deutschland liegt dieser Wert signifikant über dem globalen Durchschnitt von 52 %. Der Grund ist nicht fehlendes Budget oder fehlende Technologie. Der Grund ist fehlende Prozesswahrheit.

Schnellere Automatisierung bedeutet schnelleres Scheitern

Zeitdruck ist der natürliche Feind der Prozessklarheit. Die Logik klingt nachvollziehbar: "Wir müssen jetzt Ergebnisse liefern. Eine saubere Ist-Aufnahme dauert zu lange. Lasst uns einfach starten."

Das Ergebnis kennen wir aus Dutzenden Gesprächen mit Operations-Verantwortlichen. Nach drei Monaten läuft ein Bot, der einen halbverstandenen Prozess abarbeitet. Sechs Monate später ist der Bot abgeschaltet, weil sich der Prozess in der Zwischenzeit verändert hat oder weil Mitarbeiter Workarounds um den Bot herum gebaut haben. Die Investition ist verloren, das Vertrauen in Automatisierung beschädigt.

Und dieses beschädigte Vertrauen ist das eigentlich teure Ergebnis. Nicht die 50.000 oder 100.000 Euro für das gescheiterte Pilotprojekt. Sondern die Tatsache, dass die Organisation jetzt glaubt, Automatisierung funktioniere bei ihnen nicht. Das nächste Projekt, das den Fehler hätte vermeiden können, wird nicht genehmigt. Der Vorstand hat gelernt: "Automatisierung bringt nichts." Eine Schlussfolgerung, die auf einem einzigen, schlecht durchgeführten Versuch basiert.

Wer drei Wochen investiert, um den Ist-Zustand sauber zu erheben, spart sechs Monate Nacharbeit. Das ist keine Theorie. Das ist Projektmathematik.

Der Druck, schnell zu automatisieren, kommt häufig von zwei Seiten: von der Geschäftsführung, die ROI sehen will, und von IT-Teams, die endlich moderne Tools einsetzen möchten. Beide haben recht. Aber beide überspringen den entscheidenden Schritt.

Ohne zu wissen, wie ein Prozess heute wirklich funktioniert, können Sie weder den richtigen Automatisierungsgrad bestimmen noch den ROI realistisch prognostizieren. Sie schätzen, statt zu messen. Und Schätzungen werden in der Vorstandspräsentation zum Versprechen, das die Realität nicht einlöst. Ein solider Business Case braucht belastbare Zahlen, keine Hoffnungswerte.

Besonders gefährlich wird es, wenn der Zeitdruck dazu führt, dass Pilotprojekte bewusst auf den einfachsten Prozess angesetzt werden. Der Pilot gelingt, alle feiern. Dann soll das Modell auf komplexere Prozesse skaliert werden. Und genau dort scheitert es, weil die Voraussetzungen nie geschaffen wurden. Der einfache Prozess hatte zwei Schritte und keine Ausnahmen. Der komplexe Prozess hat zwölf Varianten, vier beteiligte Abteilungen und Entscheidungslogik, die in keinem Diagramm steht.

Die drei Failure Modes, die sich in jedem gescheiterten Projekt wiederholen

In unserer Arbeit mit mittelständischen Unternehmen sehen wir drei Muster, die gescheiterte Automatisierungsprojekte zuverlässig erklären. Sie treten selten einzeln auf. Meistens verstärken sie sich gegenseitig.

1. Die Insellösung

Eine Abteilung automatisiert ihren Teil des Prozesses. Isoliert betrachtet funktioniert das. Aber der Gesamtprozess wird fragmentierter, nicht effizienter. Die Hälfte aller mittelständischen Prozesse ist von Medienbrüchen betroffen. Insellösungen schaffen neue.

Ein Logistikunternehmen automatisierte die Auftragserfassung per RPA. Der Bot las E-Mails, extrahierte Daten, füllte das ERP-System. Technisch sauber. Aber die Disposition arbeitete weiter mit einer separaten Excel-Liste, weil das ERP-Modul für ihre Anforderungen nicht konfiguriert war. Der Bot fütterte ein System, das niemand für den nächsten Prozessschritt nutzte.

Das Ergebnis: Doppelarbeit statt Zeitersparnis. Der Bot lief, aber der Prozess war gebrochen. Die Abteilung, die den Bot eingeführt hatte, meldete Erfolg. Die nächste Abteilung in der Prozesskette merkte keinen Unterschied.

Insellösungen entstehen nicht aus böser Absicht. Sie entstehen, weil Abteilungen ihren eigenen Schmerz kennen, aber keinen Einblick in den Gesamtprozess haben. Jede Abteilung optimiert ihr Stück — und niemand optimiert das Ganze. Die Ironie: Je mehr Insellösungen entstehen, desto schwieriger wird es, den Gesamtprozess später zu verstehen. Jede Automatisierung schafft neue Abhängigkeiten, neue Schnittstellen, neue Stellen, an denen Daten verloren gehen oder transformiert werden.

Die Lösung liegt nicht darin, Abteilungen die Automatisierung zu verbieten. Sie liegt darin, vor der Automatisierung den End-to-End-Prozess sichtbar zu machen. Wer sieht, dass die Auftragserfassung, die Disposition und die Rechnungsstellung ein zusammenhängendes System sind, automatisiert anders als jemand, der nur seinen Abschnitt kennt. Prozessklarheit ist der Unterschied zwischen lokaler Optimierung und systemischer Verbesserung.

2. Der Tool-Bias

"Wir haben uns für Make entschieden, jetzt suchen wir Prozesse, die wir damit automatisieren können." Diesen Satz hören wir regelmäßig. Er ist das Gegenteil von dem, was funktioniert.

Erfolgreiche Automatisierung startet mit der Frage: Welcher Prozess verursacht den größten Schmerz, hat das höchste Volumen und die klarste Logik? Erst dann kommt die Toolfrage. Wer zuerst das Tool wählt, optimiert für die Fähigkeiten des Tools, nicht für die Anforderungen des Prozesses.

Das führt zu einer absurden Situation: Unternehmen automatisieren Prozesse, die sich leicht automatisieren lassen, statt Prozesse, deren Automatisierung den größten Hebel hätte. Die niedrig hängenden Früchte werden gepflückt, während die wirklichen Engpässe unangetastet bleiben.

Es gibt einen zweiten Effekt, der mindestens genauso schädlich ist: Tool-Proliferation. Wenn jede Abteilung ihr eigenes Lieblingstool mitbringt — Zapier hier, Power Automate dort, ein Python-Script im Controlling —, entsteht ein neuer Wildwuchs. Statt Prozesschaos haben Sie jetzt Prozesschaos plus Toolchaos. Die Wartungskosten steigen, das Wissen ist fragmentiert, und wenn der eine Mitarbeiter, der das Python-Script geschrieben hat, das Unternehmen verlässt, steht niemand bereit, es zu übernehmen.

In einem Fertigungsunternehmen, das wir begleiteten, hatte die IT-Abteilung in zwei Jahren sieben verschiedene Automatisierungstools eingeführt. Jedes löste ein spezifisches Problem. Keines war mit den anderen integriert. Das Ergebnis war ein Flickenteppich, dessen Gesamtbetriebskosten die eingesparte manuelle Arbeit überstiegen. Die richtige Reihenfolge wäre gewesen: erst verstehen, welche drei Prozesse den größten Hebel haben, dann ein Tool wählen, das alle drei abdeckt.

3. Die fehlende Baseline

Wenn Sie nicht wissen, wie lange ein Prozess heute dauert, wie viele Fehler er produziert und was er kostet, können Sie den Erfolg der Automatisierung nicht messen. Kein Vorher-Nachher, kein Business Case, kein Beweis für den Vorstand.

Und genau das passiert in der Mehrheit der Projekte: Es gibt keine Baseline-KPIs. Der "Erfolg" der Automatisierung wird an Bauchgefühl gemessen. Und wenn das Bauchgefühl nicht positiv ist, wird das Projekt als gescheitert erklärt — obwohl die Daten eine andere Sprache sprechen.

Noch schlimmer: Ohne Baseline können Sie nicht priorisieren. Sie wissen nicht, welcher Prozess die höchsten Kosten verursacht, wo die meisten Fehler entstehen oder wo die größte Zeitverschwendung stattfindet. Sie raten. Und Raten ist keine Strategie.

In einem unserer Projekte bei einem Energieversorger mit 300 Mitarbeitern zeigte die Baseline-Erhebung, dass ein einziger Prozess — die monatliche Zählerstandsabrechnung — 40 % der manuellen Arbeitszeit im Backoffice verbrauchte. Das Management hatte diesen Prozess nicht auf dem Radar, weil er "schon immer so lief". Ohne Messung wäre die Automatisierung auf drei andere Prozesse gestartet worden, die zusammen nur 12 % der Arbeitszeit ausmachten. Die Baseline hat nicht nur die Prioritäten verschoben, sondern den gesamten Investitionsplan verändert.

Prozessklarheit ist keine Vorbereitung. Sie ist die Grundlage.

Viele Unternehmen behandeln Prozessanalyse als optionalen Vorbereitungsschritt. Etwas, das man macht, wenn noch Zeit und Budget übrig sind. Das ist ein Denkfehler.

Prozessklarheit ist Layer 1 eines dreistufigen Modells, ohne den die anderen beiden Layer nicht funktionieren:

Layer 1: Prozessfundament. Den Ist-Zustand erheben, wie er wirklich gelebt wird. Nicht das Organigramm, nicht die ISO-Dokumentation, sondern die Wahrheit. Wer macht was, wann, warum, und mit welchen Workarounds? Wo sind die Medienbrüche? Wo die Doppelarbeit? Wo die informellen Entscheidungswege, die in keinem Diagramm auftauchen?

Das klingt trivial. Ist es nicht. Die Erhebung erfordert Methodik — Prozessbegehungen, Interviews, Datenanalyse —, und sie erfordert die Bereitschaft, unbequeme Wahrheiten zu akzeptieren. In einem Unternehmen erfuhr der Geschäftsführer erst durch die Ist-Aufnahme, dass seine Mitarbeiter seit zwei Jahren einen Kernprozess über WhatsApp-Gruppen koordinierten, weil das offizielle System zu langsam war. Das war keine Sabotage. Das war Pragmatismus. Aber es war unsichtbar.

Layer 2: Automatisierung. Erst auf einem verstandenen, standardisierten Prozess bauen. Automatisierung ist kein Selbstzweck. Sie ist ein Werkzeug, das auf sauberer Prozesslogik aufsetzt. Wer Layer 1 überspringt, automatisiert Ineffizienz. Das bedeutet nicht, dass jeder Prozess perfekt sein muss, bevor Sie automatisieren. Es bedeutet, dass Sie verstehen müssen, was Sie automatisieren, warum, und welche Ausnahmen es gibt. Ein Prozess mit dokumentierten Ausnahmen ist automatisierbar. Ein Prozess mit undokumentierten Ausnahmen ist ein Risiko.

Layer 3: KPIs und Steuerung. Den automatisierten Prozess messbar und steuerbar machen. Ohne Layer 1 fehlt die Baseline. Ohne Layer 2 fehlt die Struktur. Ohne Layer 3 fehlt die Fähigkeit, den Prozess kontinuierlich zu verbessern. KPIs sind nicht das Sahnehäubchen. Sie sind das Steuerrad. Ohne sie fliegen Sie blind — und merken erst, dass etwas schiefläuft, wenn der Kunde anruft.

Der Übergang von Layer 1 zu Layer 2 ist der kritischste Moment. Hier entscheidet sich, ob das Prozesswissen aus der Ist-Aufnahme tatsächlich in die Automatisierungsarchitektur einfließt — oder ob es in einer PowerPoint-Präsentation versauert, die niemand mehr öffnet. Die besten Ergebnisse sehen wir bei Unternehmen, die Prozesslandkarte und Automatisierungsstrategie als ein zusammenhängendes Projekt behandeln, nicht als zwei aufeinanderfolgende Phasen mit verschiedenen Teams.

Unternehmen, die dieses Modell ernst nehmen, erreichen ihren Automatisierungs-ROI in unter 12 Monaten. Die anderen iterieren und zahlen doppelt: einmal für die gescheiterte Automatisierung, einmal für die Nacharbeit, die sie hätten vermeiden können.

Ist Ihr Prozess automatisierungsreif? Fünf Fragen, die Klarheit schaffen.

Bevor Sie ein Automatisierungsprojekt starten, stellen Sie sich diese fünf Fragen:

Die erste Frage ist ein Lackmustest. Wenn der Prozessverantwortliche fünf Minuten braucht, um zu erklären, was passiert, ist der Prozess zu komplex oder zu unklar für Automatisierung. Was Sie nicht erklären können, können Sie nicht sinnvoll automatisieren.

Ausnahmen sind der stille Killer. Wenn mehr als 20 % der Fälle Sonderbehandlung brauchen, müssen Sie erst standardisieren. Ein Bot, der jede fünfte Transaktion nicht verarbeiten kann, erzeugt mehr Arbeit, als er einspart. Die Ausnahmen landen dann bei den gleichen Mitarbeitern, die vorher den gesamten Prozess bearbeitet haben — nur dass sie jetzt zusätzlich die Bot-Fehler korrigieren müssen.

Die Frage nach der Baseline wird am häufigsten mit Schweigen beantwortet. Ohne zu wissen, wie lange ein Prozess dauert und was er kostet, gibt es keinen Business Case. Ohne Business Case keine nachhaltige Unterstützung vom Management. Und ohne Management-Support stirbt jedes Automatisierungsprojekt, sobald das nächste Quartal schlechte Zahlen bringt.

Die Realitätsprüfung erfordert Demut. Fragen Sie nicht den Prozessverantwortlichen. Fragen Sie die Mitarbeiter, die den Prozess täglich ausführen. Setzen Sie sich einen Tag lang daneben. Die Kluft zwischen Dokumentation und Realität wird Sie überraschen.

Und Stabilität ist nicht verhandelbar. Wenn sich der Prozess alle drei Monate verändert, automatisieren Sie ein bewegliches Ziel. Erst stabilisieren, dann automatisieren. Alles andere ist Geldverbrennung mit Technologie-Anstrich.

Wenn Sie drei oder mehr dieser Fragen mit Nein beantworten, sind Sie nicht bereit für Automatisierung. Sie sind bereit für Prozessklarheit.

Die Entscheidung, die vor Ihnen liegt

Die Frage ist nicht, ob Sie automatisieren werden. Automatisierung ist kein Trend mehr. Sie ist eine operative Notwendigkeit für jedes Unternehmen, das wettbewerbsfähig bleiben will. Ihre Wettbewerber automatisieren. Ihre Kunden erwarten schnellere Reaktionszeiten. Ihre Mitarbeiter wollen keine Daten mehr von einem System ins nächste kopieren.

Die eigentliche Frage ist: Automatisieren Sie, was wirklich passiert, oder automatisieren Sie, was Sie glauben, das passiert?

Der Unterschied zwischen diesen beiden Ansätzen ist nicht akademisch. Er entscheidet darüber, ob Ihr nächstes Automatisierungsprojekt den ROI in unter einem Jahr erreicht — oder ob es in der Schublade landet, zusammen mit dem letzten Digitalisierungsprojekt, das groß angekündigt und leise beerdigt wurde.

Der Weg zur erfolgreichen Automatisierung beginnt nicht mit einer Toolauswahl. Nicht mit einem Pilotprojekt. Nicht mit einer Vendor-Präsentation. Er beginnt mit einer ehrlichen Bestandsaufnahme. Wie sehen Ihre Prozesse wirklich aus? Nicht die Version im Handbuch. Die Version, die Ihre Mitarbeiter jeden Tag leben.

Prozessklarheit zuerst. Alles andere kommt danach.