Der dokumentierte Prozess ist nicht der reale Prozess

Der dokumentierte Prozess ist nicht der reale Prozess

Fragen Sie ein Unternehmen, was Schritt eins eines Prozesses ist, und Sie bekommen fast immer eine saubere Antwort: Eine E-Mail kommt an. Fragen Sie die Person, die dieses Postfach tatsächlich öffnet, und die Antwort wird länger. Vierzig verschiedene Absender, keine zwei im selben Format, die Hälfte der Inhalte in PDF-Anhängen vergraben, und für die unklaren Fälle eine Routing-Entscheidung, die ausschließlich im Kopf einer einzelnen Person liegt, über Jahre aufgebaut und nirgends aufgeschrieben. Wer die Automatisierung auf die erste Antwort hin baut, baut sie für einen Prozess, den es nicht gibt.

Über die letzte Zeile lohnt es sich nachzudenken. Es sind nicht Ausnahmen im Allgemeinen, die einem Prozess schaden. Prozesse bewältigen bekannte Ausnahmen ständig, und zwar gut, weil jemand bereits daran gedacht hat, einen Pfad dafür zu bauen. Den Schaden richtet die Ausnahme an, die niemand aufgeschrieben hat, gerade weil nichts im System auf sie vorbereitet ist. Ein Automatisierungsprojekt erbt genau diese Verwundbarkeit, und zwar im großen Maßstab, sobald es auf einem Prozess live geht, der aus einem Gespräch statt aus der Arbeit selbst kartiert wurde.

Warum das Interview verlässlich die falsche Antwort liefert

Das ist kein Dokumentationsversagen, das sich mit besserer Dokumentation beheben ließe. Es ist strukturell. Eine Führungskraft beschreibt die Richtlinie, denn für die Richtlinie ist sie verantwortlich, und die Richtlinie kann sie in einem einstündigen Workshop sauber formulieren. Die Person, die die Arbeit jeden Tag macht, kennt die Richtlinie ebenfalls, aber sie kennt auch die zwei Dutzend Arten, auf die reale Eingaben nicht dazu passen, und die informellen Anpassungen, mit denen der Prozess trotzdem still und leise funktioniert. Die Forschung nennt diese zweite Kategorie Workarounds: zielgerichtete Abweichungen, mit denen Prozessbeteiligte ein Hindernis umgehen, das der dokumentierte Prozess nicht berücksichtigt. Eine Studie aus dem Jahr 2025 in Business & Information Systems Engineering stellte fest, dass Ereignisdaten aus der realen Prozessausführung häufig genau wegen dieses Musters nicht zum dokumentierten Modell passen, und dass diese Abweichung kein Rauschen ist, das man bereinigen müsste. In ihr steckt der tatsächliche Prozess.

Im Workshop lügt niemand. Die Antwort der Führungskraft stimmt für die Richtlinie. Sie stimmt nur nicht für die Arbeit, und die Lücke zwischen beiden bleibt unsichtbar, bis sich jemand lange genug mit dem Prozess beschäftigt, um zu sehen, wo die Wirklichkeit still von der Version im Organigramm abweicht.

Warum Process Mining diese Lücke allein nicht schließt

Process Mining, also die Disziplin, den tatsächlichen Ablauf eines Prozesses aus systemgenerierten Ereignisprotokollen statt aus Interviews zu rekonstruieren, ist ein echter Fortschritt gegenüber dem Workshop und überall dort sinnvoll, wo die Arbeit bereits eine saubere digitale Spur hinterlässt. Conformance Checking, seine Kerntechnik, vergleicht das dokumentierte Soll-Modell mit der in den Protokollen erfassten Ist-Ausführung und zeigt jede Stelle, an der beide auseinanderlaufen.

Die Grenze liegt nicht in der Technik, sondern davor. Process Mining kann nur rekonstruieren, was ein System protokolliert hat. Das meiste von dem, woran ein erster Automatisierungsversuch scheitert, passiert, bevor überhaupt etwas ein System berührt: ein Telefonat, eine Ermessensentscheidung beim Lesen eines PDFs, eine Ausnahme, die nach Gefühl statt nach einer dokumentierten Regel weitergeleitet wird. Ein Protokoll kann keine Entscheidung zeigen, die nie einen Protokolleintrag erzeugt hat. Diese Lücke schließt ein Mensch, der die tatsächliche Arbeit beobachtet, nicht ein besseres Dashboard über der Arbeit, die ohnehin schon erfasst war.

Was die Analyse tatsächlich liefert

Genau das spricht dafür, die Analyse als eigene, bezahlte Phase zu behandeln statt als Höflichkeitstermin, bevor die „eigentliche“ Arbeit beginnt. Ein fünftägiger Mapping-Sprint an der Seite der Menschen, die die Arbeit machen, statt in Interviews mit denen, die sie führen, liefert ein Ausnahmeregister: jede reale Abweichung vom dokumentierten Prozess, festgehalten im konkreten Moment und bei der konkreten Person, statt Wochen später in einem Workshop aus dem Gedächtnis rekonstruiert.

Dieses Register macht ein Festpreisangebot für die Umsetzung zu einer echten Zahl statt zu einer Schätzung mit Nachkommastellen. Wer die Umsetzung auf den dokumentierten Prozess hin plant, legt den Festpreis für eine Fiktion fest: Das System trifft am ersten Tag im Produktivbetrieb auf die undokumentierte Ausnahme statt während der Analyse, also genau an dem Punkt, an dem der Schaden laut der oben zitierten Forschung am größten ist, weil nichts in der Umsetzung darauf vorbereitet war. Wer den Umfang dagegen am Ausnahmeregister ausrichtet, bekommt einen Preis, der den Prozess widerspiegelt, der tatsächlich durch das System laufen wird, und nicht die Version, die sauber auf ein Whiteboard gepasst hat.

Der Test, ob Sie das brauchen

Nicht jeder Prozess braucht einen fünftägigen Sprint. Das Signal, dass einer ihn braucht, ist einfach: Fragen Sie die Person, die den Prozess verantwortet, was in dem Fall passiert, der nicht ins Muster passt, und achten Sie darauf, ob die Antwort eine dokumentierte Regel ist oder ein Achselzucken, gefolgt von „Das regeln wir einfach“. Wenn die ehrliche Antwort die zweite ist, sind dokumentierter und realer Prozess bereits auseinandergelaufen. Wer dann automatisiert, bevor diese Lücke geschlossen ist, entdeckt die Abweichung im Produktivbetrieb, dort, wo sie teuer zu beheben ist, statt günstig notiert zu werden.

Deshalb liegt das Risiko in dieser Phase auch bei uns und nicht bei Ihnen. Wenn der Mapping-Sprint nichts zutage fördert, was Sie nicht schon wussten, zahlen Sie nichts dafür. Das ist kein Marketingversprechen, sondern der eigentliche Test, ob die Analyse ihre Kosten wert war, und der Grund, warum das Artefakt wichtiger ist als die Übung: Es geht nicht darum, eine Analyse durchgeführt zu haben, sondern darum, mit einem Register herauszugehen, das auf keinem anderen Weg entstanden wäre. Wie dieses Register in das übrige Projekt passt, lesen Sie in So kaufen Sie KI-Umsetzung ein, die tatsächlich live geht, und wie die Umsetzung aussieht, sobald der Prozess wirklich bekannt ist, in warum der größte Teil des entstehenden Systems gar keine KI sein sollte.

Wie eine schriftliche Darstellung des realen Prozesses in der Praxis aussieht: ein geschwärztes Ausnahmeregister und eine KI-Grenzkarte aus der Auftragsabwicklung eines Herstellers, bei denen die Kundendetails geschwärzt statt erfunden wurden.

Quellen & Referenzen