Warum Automatisierungen scheitern
Automatisierungen scheitern selten an der Technik. Sie scheitern daran, dass ein Ablauf automatisiert wird, den es im Betrieb so gar nicht gibt - oder einer, den man vorher hätte abschaffen sollen. Vier Muster, die sich in Projekten immer wieder zeigen, und die Frage, die man vorher stellen muss.
Wenn eine Automatisierung nicht funktioniert, fällt der Verdacht zuerst auf die Software. Das ist fast immer die falsche Fährte. In den Projekten, die wir übernehmen oder sanieren, war die Technik selten das Problem - die Regel lief genau so, wie sie eingerichtet war. Falsch war die Annahme darüber, wie im Betrieb tatsächlich gearbeitet wird.
Vier Muster kehren dabei so regelmässig wieder, dass man sie vorher erkennen kann.
Muster 1: Automatisiert wird ein Ablauf, den es so nicht gibt
Am Anfang steht meist eine Beschreibung: So läuft die Auftragsbearbeitung bei uns. Diese Beschreibung stammt aus einem Workshop, einem Handbuch oder aus dem Kopf einer Führungskraft - und sie ist selten identisch mit dem, was in der Abteilung tatsächlich passiert.
Der Unterschied ist meistens nicht Nachlässigkeit, sondern angesammelte Erfahrung: Ein Schritt wird übersprungen, weil er nichts bringt. Zwei Kunden werden anders behandelt, weil es historische Gründe gibt. Eine Freigabe holt man mündlich ein, weil das Formular zu lange dauert. Nichts davon steht in der Beschreibung.
Wird der beschriebene Ablauf automatisiert, entsteht eine Automatisierung für einen Prozess, den es nicht gibt. Sie greift in den einfachen Fällen und läuft im Rest leer - und die Leute bauen daneben still weiter ihren echten Weg.
Muster 2: Ein Umweg wird schneller, statt zu verschwinden
Das zweite Muster ist teurer, weil es zunächst wie ein Erfolg aussieht. Ein Ablauf, der drei Freigaben und zwei Übertragungen zwischen Systemen enthält, wird automatisiert - und läuft danach tatsächlich schneller.
Die Frage, die niemand gestellt hat: Braucht es diese drei Freigaben überhaupt? In vielen Fällen stammen sie aus einer Zeit, in der es keine Auswertungen gab und Kontrolle nur durch Unterschriften möglich war. Wer diesen Ablauf automatisiert, schreibt ihn fest. Danach ist er schwerer zu ändern als vorher, weil an ihm jetzt eine Konfiguration hängt.
Kurz gesagt: Automatisierung macht einen Ablauf schneller, nicht besser. Ein guter Prozess wird dadurch günstiger, ein schlechter wird zementiert - und zwar in einer Form, die sich anschliessend nur noch mit Projektaufwand korrigieren lässt.
Deshalb gilt die Reihenfolge, die sich in jedem funktionierenden Projekt zeigt: erst den Ablauf klären und entrümpeln, dann automatisieren. Wer diese Reihenfolge dreht, kauft sich seine Umwege in Software ein. Welche Abläufe sich überhaupt eignen, steht in Welche Prozesse sich überhaupt automatisieren lassen; die Begriffe dahinter klärt Digitalisierung, Automatisierung und KI.
Muster 3: Die Ausnahme ist der Normalfall
Eine Regel wird für den Standardfall gebaut. In der Präsentation deckt sie 90 Prozent ab, in der Praxis 60. Der Rest sind Sonderfälle: der Kunde mit der abweichenden Rechnungsstellung, das Produkt mit der besonderen Prüfung, der Auftrag, der über zwei Standorte läuft.
Für diese 40 Prozent entsteht ein zweiter Weg - eine Liste, eine Mail, ein Anruf. Und weil dieser zweite Weg für alles funktioniert, wandern nach und nach auch Fälle dorthin, die die Regel eigentlich abdecken würde. Am Ende laufen zwei Prozesse parallel, und niemand weiss mehr, welcher der massgebliche ist.
Eine Automatisierung, die 60 Prozent abdeckt, spart keine 60 Prozent der Arbeit - sie erzeugt einen zweiten Prozess daneben.
Die Lehre ist nicht, dass man alles abdecken muss. Sie ist, dass man die Ausnahmen vorher zählen sollte. Liegt der Anteil hoch, ist der Ablauf noch nicht reif für eine Regel - dann ist der ehrlichere Schritt, zuerst die Sonderfälle zu reduzieren.
Muster 4: Die Regel hat keinen Eigentümer
Das vierte Muster fällt erst nach Monaten auf. Eine Automatisierung läuft, jemand hat sie eingerichtet - ein externer Partner, ein Mitarbeitender, der das Thema damals übernommen hat. Danach ändert sich etwas: ein neues Produkt, ein anderer Ablauf im Verkauf, eine zusätzliche Niederlassung.
Jetzt stimmt die Regel nicht mehr. Nur weiss das niemand, weil sich niemand zuständig fühlt. Was passiert, ist berechenbar: Man arbeitet um sie herum. Die Automatisierung läuft weiter, produziert Ergebnisse, die stillschweigend korrigiert werden - und ihr eigentlicher Effekt ist nur noch, dass eine zusätzliche Kontrolle nötig geworden ist.
Jede Automatisierung braucht deshalb eine benannte Person, die sie ändern darf und die es merkt, wenn sich die Grundlage verschiebt. Das ist keine technische, sondern eine organisatorische Frage.
Das gemeinsame Muster hinter den vier Mustern
Alle vier führen auf denselben Punkt zurück: Die Software kam vor dem Prozess. In Muster 1 fehlte die Kenntnis des echten Ablaufs, in Muster 2 die Bereitschaft, ihn zu ändern, in Muster 3 der Blick auf seine Streuung, in Muster 4 die Zuständigkeit dafür.
Das ist der Grund, warum Automatisierung fast nie ein Software-Projekt ist. Der Aufwand liegt nicht im Einrichten der Regel - das ist in modernen Systemen eine Sache von Stunden. Er liegt davor: verstehen, wie tatsächlich gearbeitet wird, entscheiden, was davon bleiben soll, und festlegen, wer es künftig verantwortet.
Woran sich ein gefährdetes Vorhaben früh erkennen lässt
Vier Fragen genügen meistens, und man kann sie stellen, bevor irgendetwas eingerichtet wird:
- Wer hat den Ablauf zuletzt am Arbeitsplatz beobachtet, nicht beschrieben bekommen? Gibt es darauf keine Antwort, ist Muster 1 wahrscheinlich.
- Welcher Schritt fällt durch die Automatisierung weg? Fällt keiner weg, wird nur beschleunigt - Muster 2.
- Wie viele der letzten fünfzig Fälle waren Sonderfälle? Wer das nicht beziffern kann, kennt die Streuung nicht - Muster 3.
- Wer darf die Regel ändern, und wer merkt es, wenn sie nicht mehr passt? Ohne Namen ist Muster 4 nur eine Frage der Zeit.
Was das für ein Odoo-Projekt bedeutet
In Odoo sind Automatisierungen bewusst niederschwellig: Regeln nach dem Muster “wenn dies, dann das”, zeitgesteuerte Aktionen, Genehmigungswege - das meiste davon eingerichtet statt programmiert. Diese Leichtigkeit ist ein Vorteil und zugleich die Einladung zu genau den vier Mustern oben, weil sich eine Regel schneller anlegen als durchdenken lässt.
Praktisch heisst das zweierlei. Erstens: Die Prozessarbeit vor der Einführung ist nicht der lästige Teil, sondern der eigentliche - sie entscheidet, ob die Automatisierung später trägt. Zweitens: Weil das Einrichten so wenig kostet, ist der Rückbau einer Regel ebenfalls billig. Eine Automatisierung, die nicht funktioniert, sollte man abschalten statt umbauen. Was Odoo im Einzelnen anbietet und wo die Grenze zur Programmierung verläuft, steht in Automatisierungen mit Odoo.
Fazit
Automatisierungen scheitern an vier wiederkehrenden Mustern: an einem Ablauf, den es so nicht gibt; an einem Umweg, der bloss schneller wird; an Ausnahmen, die den Normalfall bilden; und an Regeln, für die sich niemand zuständig fühlt. Alle vier haben dieselbe Wurzel - die Software kam vor dem Prozess.
Die vier Fragen oben kosten eine Stunde. Sie ersparen im Zweifel ein Projekt, das am Ende zu einem zweiten Prozess neben dem eigentlichen führt.
Weiterführend: Themenwelt Automatisierung & Künstliche Intelligenz. Den nächsten Schritt machen Sie mit dem kostenlosen Projekt-Check.
Welche Automatisierung würde bei Ihnen wirklich tragen?
Im kostenlosen Projekt-Check schauen wir uns Ihre Abläufe an - und sagen ehrlich, wo Automatisierung hilft und wo sie ein Problem festschreibt.
