Ein Prozess ist automatisierungsreif, wenn sich drei Dinge trennen lassen: der Regelfall, die Ausnahme und der Nachweis, dass beides so gelaufen ist. Fehlt eine dieser Trennungen, ist nicht die Technik das Problem. Der Ablauf ist dann noch keine Strecke, sondern eine Gewohnheit, die jemand beherrscht.
Das ist eine Entscheidungsfrage, keine Reifegradskala. Sie lässt sich an einem benannten Vorgang beantworten, ohne ein Werkzeug zu kaufen und ohne die Organisation vorher „digitalreif“ zu machen. Die Merkmale, an denen sich Automatisierungsreife festmachen lässt, stehen auf der Seite Prozessautomatisierung. Dieser Beitrag beantwortet die Suchfrage im Einzelfall: Woran erkenne ich das — und wann ist die ehrliche Antwort „noch nicht“.
Die Frage entscheidet über ein Vorhaben, nicht über ein Werkzeug
Wer diese Frage stellt, hat in der Regel schon einen Kandidaten. Jemand überträgt Daten zwischen zwei Systemen, setzt montags einen Bericht zusammen oder erzeugt Dokumente aus Tabellen. Der Ärger ist sichtbar. Sichtbarer Ärger ist kein Entscheidungskriterium. Er sagt, dass der Ablauf stört. Er sagt nicht, ob sich derselbe Ablauf als Strecke bauen lässt, ohne dass die Fehler schneller werden.
Automatisierungsreif ist ein Prozess dann, wenn sich die Entscheidung vorher schreiben lässt: derselbe Eingang erzeugt denselben Ausgang, oder er erzeugt eine benannte Ausnahme mit einem benannten nächsten Schritt. Was sich erst erklären lässt, während der Fall auf dem Tisch liegt, ist Ermessen. Ermessen lässt sich unterstützen. Es lässt sich nicht ersetzen, ohne dass in einem Teil der Fälle eine Regel entscheidet, die niemand so gemeint hat.
Die drei Kriterien darunter sind Prüfungen, keine Checkliste zum Abhaken. Ein Kriterium, das nicht greift, ist ein Befund. Es ist kein Grund, die anderen zu ignorieren.
Drei Entscheidungskriterien
Derselbe Eingang erzeugt denselben Ausgang
Die Decision Model and Notation (DMN) 1.5 der Object Management Group trennt die Entscheidung vom Ablauf. Abschnitt 5.2.2 beschreibt ausdrücklich die Modellierung von Anforderungen an automatisierte Entscheidungen: Eingaben, Wissen und Ergebnis müssen so gefasst sein, dass eine Maschine sie anwenden kann. Dafür kennt DMN Entscheidungstabellen mit einer Hit Policy — Unique, First, Priority, Collect. Die Policy ist keine technische Spielerei. Sie zwingt die Frage: Was gilt, wenn zwei Zeilen passen? Wer diese Frage nicht beantworten kann, hat keine Entscheidung, sondern eine Besprechung.
Denselben Schnitt macht die Business Process Model and Notation (BPMN) 2.0.2 am Exclusive Gateway: Genau ein Ausgang wird gewählt, und die Bedingung muss sich auswerten lassen, bevor der Fall eintrifft. Ein Gateway ohne Bedingung ist in einem ausführbaren Modell kein Gateway, sondern eine Lücke.
Die praktische Prüfung braucht keine Modellierungssprache. Nehmen Sie drei abgeschlossene Vorgänge des letzten Monats und decken Sie die Namen ab. Kann eine zweite Person aus denselben Unterlagen dasselbe Ergebnis rekonstruieren — ohne nachzufragen, „wer der Kunde ist“ und ohne zu wissen, „wie wir das immer machen“? Wenn ja, liegt eine Regel vor. Wenn nein, liegt Erfahrung vor. Erfahrung ist wertvoll. Sie ist nicht automatisierungsreif.
Ein Rabatt, der „wichtigen Kunden“ zusteht, ohne dass schriftlich steht, woran sich diese Wichtigkeit festmacht, fällt durch. Eine Vollständigkeitsprüfung, die benannte Felder gegen benannte Schwellen hält, besteht. Der Unterschied ist nicht die Branche. Der Unterschied ist, ob das Ergebnis im Eingang schon steckt.
Der Fehlerfall ist entworfen, bevor der Regelfall gebaut wird
Ein Ablauf, der nur den glatten Weg beschreibt, ist nicht automatisierungsreif. Er ist ein Wunschbild. Jede Strecke trifft früher oder später auf einen Fall, den die Regel nicht abdeckt: ein leeres Pflichtfeld, eine zweite Währung, eine Kundennummer, die im Zielsystem nicht existiert. Wenn dieser Fall nicht vorher einen Ort hat, verschwindet er — in einer stillen Ausnahme, in einem Logfile, das niemand liest, oder in einem Datensatz, der falsch, aber vollständig aussieht.
Die Prüfung ist ein Satz mit zwei Lücken: „Wenn dieser Schritt nicht entscheiden kann, wandert der Vorgang zu ___ und ist sichtbar als ___.“ Lassen sich die Lücken nicht füllen, endet die Prüfung hier. Eine Automatisierung ohne sichtbare Warteschlange erzeugt keine Entlastung. Sie erzeugt eine Störung, die erst auffällt, wenn ein Kunde, ein Prüfer oder die Buchhaltung sie findet.
Das ist eine andere Frage als die nach der fachlichen Zuständigkeit für den Prozess. Zuständigkeit ohne entworfenen Fehlerfall bleibt Absicht. Der Fehlerfall ohne Zuständigkeit bleibt ein Postfach. Beides zusammen — benannte Person, benannte Warteschlange, benanntes Signal, wenn nichts ankommt — ist die Bedingung, unter der sich der Regelfall überhaupt bauen lässt.
Der Ablauf hinterlässt Ereignisse, sonst ist Erfolg nicht nachweisbar
Eine Strecke, deren Erfolg sich nur erfragen lässt, ist nach dem Bau nicht prüfbar. Das Process Mining Manifesto der IEEE Task Force on Process Mining setzt genau dort an. Leitprinzip GP1 verlangt, Ereignisdaten als Gegenstand eigener Qualität zu behandeln, nicht als Nebenprodukt der Software. Ein Ereignis braucht mindestens einen Zeitpunkt, einen Vorgang und eine Tätigkeit. Fehlt das, lässt sich später weder rekonstruieren, was geschehen ist, noch feststellen, ob die Automatisierung noch das tut, wofür sie gebaut wurde.
Die praktische Prüfung: Lassen sich für die letzten zehn Vorgänge Start, Schritte und Ausgang aus Systemen rekonstruieren — ohne eine Person zu fragen? Wenn die Antwort in Postfächern, lokalen Tabellen oder in dem Satz „das weiß eine Kollegin“ liegt, ist nicht zuerst eine Strecke zu bauen. Zuerst muss der Vorgang Spuren hinterlassen, die ein System lesen kann.
Das ist keine Forderung nach einem Process-Mining-Werkzeug. Es ist die Mindestbedingung dafür, dass „es läuft“ eine nachprüfbare Aussage wird. Eine Automatisierung ohne diese Spuren verschiebt die Unsicherheit: Vorher wusste man nicht, wie lange der Mensch braucht. Nachher weiß man nicht, ob die Maschine noch arbeitet.
Beispiele: reif, reif wirkend, noch nicht
Reif. Aus Stammdaten und einem geschriebenen Regelwerk entsteht ein Dokument fester Form — eine Preisliste, eine Auftragsbestätigung, ein Datenblatt. Derselbe Eingang erzeugt dieselbe Ausgabe. Was sich gegenüber der letzten Fassung geändert hat, prüft ein Mensch; die Erzeugung selbst nicht. In einer veröffentlichten Fallstudie erzeugt ein Konfigurator druckfertige Preislisten aus denselben Daten, die der Vertrieb ohnehin pflegt. Die Freigabe blieb bewusst beim Fachbereich: Preislisten, die sich selbst erzeugen. Automatisierungsreif war hier nicht „das Dokument“. Automatisierungsreif war die Trennung von Regel, Vorlage und Kontrolle.
Reif wirkend, aber nicht reif. Derselbe Vorgang, nur ohne führende Daten. Die Preisliste lebt in einer Tabelle, von der Kopien per E-Mail kursieren. Jede Beteiligte weiß, welche Datei „die aktuelle“ ist, und diese Gewissheit widerspricht sich. Der Ablauf sieht aus wie der erste Fall: Werte eintragen, prüfen, als PDF ausgeben. Es fehlt der eine Eingang. Automatisierung würde hier die jeweils geöffnete Datei beschleunigen — und den Streit darüber, welche die richtige war, in die Systeme tragen.
Noch nicht, obwohl der Ärger groß ist. Zahlen aus mehreren Marken oder Bereichen sollen in einer Auswertung zusammenlaufen. Die Wörter sind dieselben, die Bedeutungen nicht. Was die eine Seite als Kontakt zählt, ist auf der anderen erst nach einer Bestätigung ein Kontakt. Solange das nicht schriftlich auseinandergezogen ist, erzeugt jede Automatisierung eine Summe, die niemand nachrechnen kann. Die zugehörige Fallstudie beginnt deshalb mit einem Begriffsverzeichnis, nicht mit einer Pipeline: Kampagnendaten aus fünf Automarken. Der Ärger war berechtigt. Der Prozess war es noch nicht.
Die Frage greift nicht. Die jährliche Nachverhandlung eines Rahmenvertrags, das Gespräch mit einem Kunden, der kündigen will, die Entscheidung, ob ein Grenzfall kulant behandelt wird. Das sind Vorgänge mit Anfang und oft auch mit einem Dokument am Ende. Sie haben keinen Ausgang, der im Eingang schon liegt. Wer sie trotzdem als Strecke behandelt, ersetzt Urteil durch eine Regel, die im Streitfall nicht haltbar ist.
Was die Frage nicht beantwortet
Automatisierungsreife gilt für diesen Ablauf, nicht für das Unternehmen. Ein fertiger Kandidat neben einer unklaren Schnittstelle bleibt ein halber Kandidat: Die Regel kann stehen und der Fehlerfall entworfen sein, und trotzdem fehlt der Weg, auf dem ein System die Daten lesen kann. Das ist kein Widerspruch zu den drei Kriterien. Es ist ihre Reihenfolge. Zuerst die Entscheidung, dann der Ort, an dem sie Spuren hinterlässt.
Die Frage sagt auch nichts über den Rest der Landschaft. Ein reifer Prozess in einem Bereich rechtfertigt nicht das Vorhaben, „die Abläufe“ zu automatisieren. Reife ist lokal. Ein Programm, das viele Strecken auf einmal verspricht, braucht viele einzelne Ja — und die kommen selten am selben Tag.
Schließlich verfällt die Antwort. Ein Ja von heute gilt für den Ablauf, wie er heute geschnitten ist. Ändert sich Zuständigkeit, System oder Schnitt des Vorgangs, muss die Frage neu gestellt werden — nicht, weil Automatisierung verboten wäre, sondern weil die drei Kriterien dann einen anderen Gegenstand haben.
Für wen das nicht gilt
Dieser Beitrag gilt nicht für Teams, die den Ablauf noch erfinden. Solange Angebot, Zuständigkeit oder Ergebnis wöchentlich neu geschnitten werden, gibt es keinen Eingang, der sich wiederholen ließe. Zuerst muss der Vorgang stabil werden. Automatisierung danach.
Er gilt nicht, wo der Ablauf selbst das Unterscheidungsmerkmal ist und sich noch ändert — die Art, wie beraten, kalkuliert oder zugeschnitten wird, bevor das zur Regel geworden ist. Was Sie von anderen trennt, sollten Sie nicht festschreiben, solange Sie es noch suchen.
Er gilt nicht für einmalige Vorhaben: eine Migration, eine Datenbereinigung, ein Umzug. Das sind Projekte. Sie können Werkzeuge brauchen. Sie sind keine wiederkehrende Strecke.
Er gilt nicht als Begründung für eine schon gekaufte Plattform. Wer ein Werkzeug hat und nachträglich Kandidaten sucht, dreht die Reihenfolge um. Die Kriterien oben prüfen einen Prozess. Sie prüfen kein Lizenzmodell.
Und er gilt nicht als Folie für ein Lenkungsgremium, das eine Zahl zwischen eins und fünf erwartet. Automatisierungsreife ist ja, nein oder noch nicht — bezogen auf einen benannten Ablauf. Eine Skala, die das Mittel über viele Abläufe zieht, erzeugt genau die Unschärfe, die die Frage auflösen soll.
Wenn die drei Kriterien für einen benannten Ablauf greifen, ist der nächste Schritt die Aufnahme, wie er wirklich läuft — nicht die Auswahl einer Plattform. Vorgehen, Grenzen und Kostenrahmen stehen unter Prozessautomatisierung.
Quellen