Warum Automatisierung an Prozessen scheitert, nicht an Tools

Die meisten Automatisierungsprojekte im Mittelstand scheitern nicht an der Software. Sie scheitern daran, dass der Prozess, den man automatisieren will, so nie aufgeschrieben wurde.

Der Ablauf ist fast immer derselbe. Jemand sieht eine Demo, in der ein Werkzeug Rechnungen ausliest und verbucht. Das Werkzeug wird gekauft. Drei Monate später liegt es brach, und der Schluss lautet: „Bei uns funktioniert das nicht.“

Meistens stimmt das sogar — nur liegt es nicht am Werkzeug. Es liegt daran, dass in der Demo ein sauber definierter Prozess automatisiert wurde und im Unternehmen ein gewachsener.

Der Prozess existiert nur in Köpfen

Fragen Sie drei Personen, wie eine Eingangsrechnung bei Ihnen bearbeitet wird, und Sie bekommen drei Antworten. Nicht weil jemand schlampt, sondern weil sich über Jahre Sonderfälle angesammelt haben: Der eine Lieferant schickt PDF, der andere Papier, bei Beträgen über einer bestimmten Grenze fragt man noch kurz nach. Nichts davon steht irgendwo. Automatisieren kann man aber nur, was beschrieben ist.

Sonderfälle sind der eigentliche Aufwand

Der Standardfall ist in wenigen Stunden gebaut. Die Arbeit steckt in den zwanzig Prozent, die anders laufen. Wer die vorher nicht kennt, kalkuliert das Projekt auf Basis des einfachen Falls — und stellt in der Umsetzung fest, dass die Hälfte der Vorgänge durchs Raster fällt. Ab da wird nachgebessert, bis niemand mehr weiß, was das System eigentlich tut.

Der Freigabeschritt gehört zum Prozess

In fast jedem Ablauf gibt es einen Punkt, an dem jemand Verantwortung übernimmt: eine Zahlung freigibt, ein Angebot bestätigt, eine Kündigung akzeptiert. Diesen Schritt wegzuautomatisieren spart ein paar Minuten und erzeugt ein Haftungsproblem. Gute Automatisierung bereitet solche Entscheidungen vor — trifft sie aber nicht.

Was stattdessen funktioniert

Vor jedem Tool steht die Aufnahme: Wer macht was, womit, wie oft, und wo bleibt es liegen? Zwei bis drei Tage reichen dafür in der Regel. Danach lässt sich beurteilen, welcher Schritt sich lohnt — oft ist es nicht der, den man erwartet hat. Und gelegentlich ist das Ergebnis, dass man den Prozess erst vereinfachen und dann gar nicht mehr automatisieren muss.

Die Reihenfolge, die sich bewährt hat

Erst beschreiben, dann vereinfachen, dann automatisieren, dann messen. Wer bei Schritt drei anfängt, baut die bestehende Unordnung in Software nach — und hat sie danach schneller, aber nicht besser.