Prozessanalyse: Definition, Methoden und Geschäftsanwendungsfälle

Die meisten Teams glauben, sie verstünden, wie ihre Prozesse funktionieren. Irgendwo gibt es eine dokumentierte Vorgehensweise, vielleicht eine Confluence-Seite, vielleicht eine ausgedruckte SOP aus dem Jahr 2019, die alle als verbindliche Grundlage behandeln. Dann bildet jemand tatsächlich ab, was in den Systemen passiert, und Dokumentation und Realität stimmen vielleicht bei 60 % der Schritte überein.

Genau diese Lücke soll Process Discovery schließen. Nicht, um einen besseren Prozess zu entwerfen, nicht, um ein Automatisierungsprojekt zu starten, und nicht, um die Liefer-Checkliste eines Beraters abzuhaken. Sondern einfach, um festzustellen, was tatsächlich passiert, bevor jemand etwas verändert. Das klingt nach einer niedrigen Hürde. Ist es nicht. Die meisten Unternehmen überspringen diesen Schritt oder führen ihn schlecht durch und verbringen dann Monate damit, das Falsche zu automatisieren oder etwas neu zu gestalten, das sie nie korrekt verstanden haben.

Die zentrale Aussage, die es zu verteidigen gilt: Process Discovery ist der notwendige Schritt, der funktionierende Automatisierungsprojekte von Projekten unterscheidet, die einen fehlerhaften Prozess skalieren. Sie können dagegen argumentieren. Manche Teams werden sagen, sie hätten ohne diesen Schritt erfolgreich automatisiert. Die meisten dieser Teams stellten später fest, dass sie einen Workaround statt eines Prozesses automatisiert hatten.

Was Teams zu spät lernen

• Process Discovery erzeugt ein Ist-Modell, keinen Plan zur Neugestaltung.
• Event-Logs machen sichtbar, was Interviews glätten: Abweichungen, Nacharbeitschleifen und Workarounds.
• Process Discovery findet vor Automatisierung oder Neugestaltung statt, nicht parallel dazu.
• Process Discovery ist eine Technik innerhalb von Process Mining, kein Synonym dafür.

Was Process Discovery tatsächlich bedeutet

Die akademische Einordnung aus der Process-Mining-Literatur ist präzise: Process Discovery ist die Erstellung eines Prozessmodells aus einem Event-Log ohne vorheriges Prozesswissen. Sie geben Daten darüber ein, was passiert ist. Daraus wird ein Modell des Prozesses erstellt. Sie gehen dabei nicht von einer angenommenen Struktur aus. Das ist die Definition.

In der praktischen Betriebssprache: Sie ziehen Datensätze darüber, was Ihre Systeme tatsächlich getan haben, und aus diesen Datensätzen entsteht ein Modell des realen Prozesses. Niemand musste sich darauf einigen, wie der Prozess aussehen sollte. Die Daten zeigen, wie er tatsächlich aussieht.

Dieser Leitfaden zu Process Discovery ist vor allem auf praktischer Ebene relevant. Das Ergebnis von Process Discovery ist ein Ist-Prozessmodell, das sich von einer Empfehlung zur Neugestaltung, einem Automatisierungsplan oder einer Gap-Analyse unterscheidet. Es ist eine Darstellung der aktuellen Prozessausführung, nicht mehr. Was Sie damit tun, folgt danach. Die Discovery selbst besteht darin, diese Sicht auf den aktuellen Zustand zu schaffen, bevor Verbesserungs- oder Automatisierungsarbeit beginnt.

Damit Process Discovery mit automatisierten Tools funktioniert, benötigen die zugrunde liegenden Prozessdaten eine Mindeststruktur. Nach Appians Einordnung der Anforderungen an Event-Logs braucht jeder Log-Eintrag mindestens drei Felder: einen Aktivitätsnamen (was passiert ist), einen Zeitstempel (wann es passiert ist) und eine Fallkennung (zu welcher Prozessinstanz dies gehört). Ohne alle drei können Sie aus dem Log kein schlüssiges Prozessmodell erstellen. Sie erhalten Fragmente.

Diese Mindestanforderung an die Daten sollten Sie vor dem Start prüfen. Ich sehe Initiativen zur Prozessverbesserung scheitern, weil das Team bereits mit Process Discovery begonnen hatte und dann mitten in der Analyse feststellte, dass seine Systemlogs zwar einen Zeitstempel und eine Aktivität, aber keine Fall-ID enthalten. Die Ereignisse lassen sich nicht über eine Prozessinstanz hinweg verbinden. Die Discovery erzeugt Rauschen statt eines Modells.

Damit automatisierte Discovery funktioniert, muss die Prozessausführung eine digitale Spur hinterlassen. Wo das nicht der Fall ist, schließen manuelle Methoden die Lücke. Beide haben ihre berechtigte Rolle.

Manuelle Process Discovery vs. automatisierte Business Process Discovery

Die Wahl zwischen manueller und automatisierter Business Process Discovery (ABPD) ist nicht wirklich eine Frage der Präferenz. Sie hängt davon ab, welche Daten vorhanden sind und welches Genauigkeitsniveau Sie benötigen. So unterscheiden sich beide Ansätze anhand der Kriterien, die wirklich relevant sind, wenn Sie bewerten, welcher zu Ihrer Situation passt.

Traditionelle Ansätze zur Prozessdokumentation bevorzugen die manuelle Seite. Automatisierte Discovery extrahiert Daten direkt aus den Systemen. Für die meisten realen Prozesse ist keiner der Ansätze für sich allein vollständig. Deshalb werden beide Methoden häufig kombiniert, statt als Konkurrenz betrachtet zu werden.

Wann manuelle Process Discovery weiterhin sinnvoll ist

Manuelle Process Discovery wird schneller abgetan, als sie sollte. Workshops und Stakeholder-Interviews sind langsam, chaotisch und anfällig für dieselben Verzerrungen wie alle selbstberichteten Daten. Ich erlebe das immer wieder in Support-Gesprächen mit Operations-Teams, die eine schmerzhafte manuelle Discovery durchlaufen haben und wissen möchten, ob sie die nächste einfach automatisieren können. Manchmal können sie das. Manchmal nicht.

Die berechtigte Rolle manueller Methoden betrifft Arbeit, die keine digitale Spur hinterlässt. Die Einordnung von Automation Anywhere zu Task Mining bringt das gut auf den Punkt: Nicht jede bedeutsame Interaktion zwischen Mensch und System landet in Backend-Logs. Ein Kundendienstmitarbeiter, der fünf Anwendungen öffnet, um ein einziges Ticket zu beantworten, Informationen manuell zwischen Fenstern kopiert und eine papierbasierte Checkliste zur Abschlussprüfung verwendet, folgt einem Prozess, den das System bestenfalls teilweise protokolliert. Fachanwender in diesen Rollen verfügen über Prozesswissen, das kein Event-Log sichtbar macht. Die Ineffizienz ist real. Das Log erkennt sie nicht.

Workshops und Interviews bleiben auch dann das richtige Tool, wenn das Ziel darin besteht, implizites Wissen von Stakeholdern sichtbar zu machen, die einen Prozess seit Jahren informell betreiben. Das Problem des institutionellen Wissens ist real. Ein guter Interviewer fördert Workarounds, informelle Eskalationswege und Ermessensentscheidungen zutage, die es nie in die SOP geschafft haben. All das bleibt für automatisierte Tools unsichtbar.

Wie KI-gestützte Process Discovery die Situation verändert

Das Kernproblem manueller Workshops ist der Beobachtereffekt. Wenn Sie jemanden fragen, wie ein Prozess abläuft, beschreibt diese Person eine Version davon. Diese Version wird davon geprägt, was sie glaubt, dass Sie hören möchten, woran sie sich erinnert und wie der Prozess eigentlich ablaufen sollte, statt wie er tatsächlich abläuft. Genau diese Lücke versucht Process Discovery zu schließen, und manuelle Workshops schließen sie nur teilweise.

KI-gestützte Process-Discovery-Tools gehen einen anderen Weg. Sie extrahieren Prozessabläufe direkt aus Geschäftssystemen, sodass das Modell die tatsächliche statt die erinnerte Ausführung abbildet. Die Einordnung von Celonis dazu ist zutreffend: Die direkte Extraktion aus Systemen erzeugt eine Echtzeitansicht der Prozessausführung, die genauer ist als jedes Workshop-Ergebnis. Ein Event-Log unterliegt keinem Beobachterbias. Das System hat aufgezeichnet, was wann passiert ist, ohne dass jemand entscheiden musste, was aufgenommen wird.

Diese Tools sind jedoch datengetrieben, wodurch eine eigene Einschränkung entsteht: Sie sehen nur, was protokolliert wird. Ein Prozessschritt, der in einer Tabelle, in einem Telefonat oder auf einer Haftnotiz stattfindet, bleibt für automatisierte Discovery unsichtbar. KI- und Process-Discovery-Tools sind stark bei transaktionaler, systemvermittelter Arbeit. Menschliches Urteilsvermögen, informelle Abstimmung und Schritte außerhalb der Systeme erfordern weiterhin eine manuelle Ergänzung. Die Kombination beider Ansätze ist in der Regel genauer als jeder einzelne für sich.

Wie Business Process Discovery funktioniert: Von Event-Logs zum Prozessmodell

Das Verständnis des Mechanismus ist wichtig, bevor Sie bewerten, ob Process Discovery zu Ihrer Situation passt. Hier ist, was tatsächlich passiert, Schritt für Schritt und ohne Vertriebsnarrativ.

Schritt 1: Sammlung von Event-Logs. Ausgangspunkt ist die Extraktion eines Logs der Prozessausführung aus den beteiligten Systemen. Jeder Log-Eintrag repräsentiert ein Ereignis innerhalb einer Prozessinstanz. Gemäß den in der Appian-Dokumentation festgelegten Mindestdatenanforderungen benötigt jeder Eintrag einen Aktivitätsnamen, einen Zeitstempel und eine Fallkennung. Die Fallkennung ermöglicht es dem Algorithmus, eine Ereignisabfolge als einzelne Prozessspur statt als unverbundene Liste von Aktivitäten zu rekonstruieren. Wenn Ihr CRM „Opportunity erstellt“, „Angebot gesendet“ und „Deal abgeschlossen“ erfasst, diese jedoch nicht mit derselben Opportunity-ID verknüpft, können Sie den Vertriebsprozess nicht rekonstruieren. Sie haben Ereignisse ohne Prozess.

Schritt 2: Erstellung des Prozessmodells. Discovery-Algorithmen analysieren das Event-Log, um Muster über viele Prozessspuren hinweg zu finden. Welche Aktivitäten treten typischerweise nacheinander auf? Welche Aktivitäten erscheinen manchmal, aber nicht immer? Wo treten Schleifen auf, also Wiederholungen eines Schritts, bevor der Prozess weiterläuft? Das Ergebnis ist ein Prozessmodell: eine strukturierte Darstellung der tatsächlichen Prozessschritte, Entscheidungspunkte und in den Daten beobachteten Pfade. Dies ist das Ist-Prozessmodell. Es zeigt den Prozess, wie er tatsächlich abläuft, und nicht, wie ihn sich jemand vorgestellt hat.

Schritt 3: Detaillierte Prozessanalyse und menschliche Prüfung. Ein aus einem Event-Log generiertes Prozessmodell erfordert menschliche Interpretation. Der Algorithmus findet Muster. Er unterscheidet nicht zwischen einer Schleife, die echte Nacharbeit darstellt, und einer Schleife, die eine Eigenheit der Protokollierung im System widerspiegelt. Fachexperten müssen das Modell prüfen, die Aktivitätsnamen validieren und bestätigen, dass die Fallkennungen die Prozessinstanzen korrekt abgrenzen. Dieser Schritt klärt auch Fragen zur Prozessdefinition: Handelt es sich um einen oder zwei Prozesse? Sind dies Varianten desselben Ablaufs oder tatsächlich unterschiedliche Prozesse?

Was Event-Logs erfassen, das Interviews übersehen

Hier lohnt es sich, genauer hinzusehen. Wenn Sie jemanden bitten, den Ablauf eines Prozesses zu beschreiben, schildert die Person den Weg, der normalerweise funktioniert. Sie beschreibt die Hauptabfolge: Anfrage erhalten, validieren, genehmigen, abschließen. Was sie nicht beschreibt, zumindest nicht ohne gezielte Nachfrage, sind die Rückschleifen, die Schritte, die sie unter Zeitdruck überspringt, oder der Workaround, den sie vor sechs Monaten erfunden hat und inzwischen als offizielle Methode betrachtet.

Event-Logs zeigen ein anderes Bild. Ein Bestellprozess, den das Team als „drei Genehmigungen, dann wird die Bestellung erstellt“ beschreibt, könnte im Log so aussehen: drei Genehmigungen, Bestellung erstellt, korrigiert, erneut erstellt, sekundäre Genehmigung, Bestellung erneut erstellt. Diese Nacharbeitschleife steht für reale Zeit, reale Kosten und reale Prozessvariationen. Der Engpass ist in den Log-Daten auf eine Weise sichtbar, wie er es in einem Workshop nie wäre.

Die Einordnung von Automation Anywhere zu Task Mining geht noch weiter: Selbst Benutzeroberflächeninteraktionen außerhalb von Backend-Logs können durch die Aufzeichnung von Interaktionen erfasst werden. Ein Datenerfassungsmitarbeiter, der Informationen manuell zwischen zwei nicht verbundenen Systemen kopiert, hinterlässt in keinem Event-Log der beiden Systeme eine Spur, wohl aber in einer Bildschirmaufzeichnung. Genau diese Art unsichtbarer Arbeit erzeugt die Lücke zwischen dem, wie Geschäftsabläufe auf dem Papier aussehen, und den tatsächlichen Kosten in der Praxis. Ohne ihre Erfassung bleibt Discovery unvollständig.

Die Ist-Prozesskarte erstellen, bevor Sie etwas verändern

Das konkrete Ergebnis, auf das Sie hinarbeiten, ist eine Ist-Prozesskarte: eine visuelle oder strukturierte Darstellung, wie der Prozess tatsächlich ausgeführt wird, einschließlich Hauptpfad, Varianten, Schleifen und Ausnahmebehandlung. Das unterscheidet sich von einem Prozessdesigndokument, das zeigt, wie jemand den Prozess gestalten möchte. Die Ist-Karte zeigt, was aktuell tatsächlich läuft.

Die Einordnung von Nintex, wonach Process Discovery ein notwendiger erster Schritt ist, ist aus einem konkreten Grund richtig. Teams, die diesen Schritt überspringen und direkt zur Automatisierung oder Neugestaltung übergehen, treffen Entscheidungen ohne Ausgangsbasis. Sie automatisieren, was ihrer Meinung nach passiert. Wenn die Automatisierung sich unerwartet verhält, wissen sie nicht, ob es sich um ein technisches Problem oder ein Discovery-Problem handelt, weil sie nie präzise abgebildet haben, was sie automatisieren. Dieser Diagnoseschritt wird später teuer.

Effektive Process Discovery erzeugt eine Karte, die Stakeholder aus Operations, Automatisierung und Compliance gleichermaßen lesen und bewerten können. Bevor Arbeiten zur Geschäftsprozessverbesserung beginnen, muss diese Karte existieren. Neugestaltung, Automatisierungsplan und Compliance-Prüfung hängen alle davon ab. Teams, die ohne sie starten, gestalten im Grunde auf Basis von Annahmen neu. Ich habe erlebt, dass dies auf zwei Arten endet: Entweder entdecken sie den Prozess auf die harte Tour neu, nachdem die Automatisierung scheitert, oder sie erkennen nie, was ihnen entgangen ist, und leben einfach mit einem suboptimalen Ergebnis.

Die Ist-Karte ist nicht das Ziel. Sie ist die Grundlage für alles, was danach kommt.

Vorteile von Process Discovery, die über das Finden von Automatisierungspotenzialen hinausgehen

Hier möchte ich der üblichen Einordnung von Process Discovery widersprechen. Die meisten Artikel dazu, einschließlich vieler Anbieterinhalte, behandeln sie als ersten Schritt eines Automatisierungsprojekts. Identifizieren, was automatisiert werden soll, und dann automatisieren. Diese Einordnung ist zutreffend, aber unvollständig. Und diese Unvollständigkeit schafft ein konkretes Problem: Teams führen Process Discovery einmal durch, extrahieren die Automatisierungskandidaten und machen weiter. Sie verpassen die beiden anderen Erkenntnisse, die dabei sichtbar wurden.

Laut Appians Darstellung der tatsächlichen Einsatzbereiche von Process Discovery gibt es drei primäre Anwendungen: Automatisierungspotenziale identifizieren, Compliance- und Kontrollprobleme sichtbar machen sowie Prozessvariationen diagnostizieren, die die operative Leistung beeinflussen. In dieser dritten Kategorie, Prozessleistung und Prozessvariation, bleibt viel bedeutender Wert ungenutzt.

Prozessexzellenz durch Variationsanalyse. Jeder Prozess, der im großen Maßstab läuft, entwickelt Varianten: Unterschiedliche Teams führen denselben Schritt unterschiedlich aus, es gibt geografische oder produktlinienbezogene Unterschiede, die niemand dokumentiert hat, oder informelle Anpassungen entstanden, weil der offizielle Weg zu langsam war. Diese Variationen stehen nicht immer für Ineffizienz. Manchmal sind sie nützliche Anpassungen. Aber Sie können das erst beurteilen, wenn Sie sie identifiziert haben. Process Discovery bringt diese Varianten als natürliches Ergebnis der Modellerstellung ans Licht. Teams, die diese Informationen nutzen, verbessern die Prozessstandardisierung und verringern die Leistungsspanne zwischen leistungsstarken und leistungsschwachen Instanzen.

Erkennung von Compliance-Lücken. Dieser Anwendungsfall wird durchgehend unterbewertet. Besonders in regulierten Branchen müssen der Prozess, der in den Systemen läuft, und der in den Richtliniendokumenten beschriebene Prozess übereinstimmen. Process Discovery macht diese Übereinstimmung überprüfbar. Wenn das Event-Log zeigt, dass ein verpflichtender Genehmigungsschritt in 23 % der Fälle übersprungen wird, handelt es sich um eine Compliance-Lücke. Sie ist gerade deshalb sichtbar, weil die Discovery ein Modell erzeugt hat, das mit dem erwarteten Pfad verglichen werden kann. Teams, die Automatisierungspotenziale identifizieren, aber nie eine Konformitätsprüfung durchführen, übersehen dies vollständig.

Identifizierung von Ineffizienzen und Leistungsengpässen. Nacharbeitschleifen, Verzögerungen bei Übergaben und Wartezeiten zwischen Schritten sind in Event-Log-Daten auf eine Weise sichtbar, die Interviews und Beobachtungen übersehen. Sie zu finden, dient nicht nur der Automatisierung. Manchmal ist die richtige Lösung eine Prozessänderung, eine Trainingsmaßnahme oder ein Problem beim Tool-Zugriff. Keines davon erfordert den Aufbau einer Automatisierung.

🤔 Moment.
Teams, die auf Automatisierungsinitiativen fokussiert sind, führen Process Discovery oft einmal durch und extrahieren nur die Liste der Automatisierungskandidaten. Die Compliance-Abweichungen und Signale zu Prozessvariationen waren die ganze Zeit im selben Modell enthalten. Die Discovery-Ergebnisse sechs Monate später mit einer Compliance-Perspektive erneut zu prüfen, ist eine zweite Analyse, die eigentlich die erste hätte sein sollen.

Process Discovery für Automatisierungspotenziale

Die Identifizierung von Automatisierungspotenzialen ist der Anwendungsfall, der die meisten Teams überhaupt erst zu Process Discovery führt. Der Wert liegt hier in der Präzision: Statt Prozesse anhand der Intuition einer Person zu automatisieren, was repetitiv sei, zeigt das Discovery-Modell, welche Workflows tatsächlich ein hohes Volumen haben, konsistent strukturiert sind und einem vorhersehbaren Pfad folgen, den ein regelbasiertes System zuverlässig verarbeiten kann.

Die Einordnung von Nintex zur Nutzung von Discovery für Automatisierung im großen Maßstab ist hier relevant. Bevor Sie RPA-Ressourcen einsetzen oder eine Workflow-Automatisierung entwickeln, zeigt Ihnen die Prozesskarte, ob der Prozess stabil genug für eine Automatisierung ist. Ein Prozess mit hoher Variation, häufigen Ausnahmepfaden und umfangreicher Nacharbeit im Event-Log ist unabhängig von seinem Volumen ein schlechter Automatisierungskandidat. Um ihn zuverlässig zu automatisieren, müssten Sie jede Variante abdecken, und Sie wissen nun, wie viele Varianten es gibt. Das verändert die Kosten-Nutzen-Analyse vor dem Start, also genau zu dem Zeitpunkt, an dem sie sich ändern sollte.

Process Discovery für Compliance und Prozessvariationen

Audit-, Risiko- und Compliance-Teams nutzen Process Discovery aus einem Grund, der nichts mit Automatisierung zu tun hat: Sie müssen Abweichungen von erwarteten Prozesspfaden erkennen, bevor ein Auditor dies tut.

Appians Einordnung des Anwendungsfalls ist eindeutig. Process Discovery erzeugt ein sichtbares Modell dessen, was tatsächlich abläuft. Dieses Modell kann mit dem Kontrollrahmen, der Richtliniendokumentation oder regulatorischen Anforderungen verglichen werden. Wo diese voneinander abweichen, liegt eine Kontrolllücke vor. Die Lücke kann harmlos sein: ein informeller Workaround, der über einen anderen Pfad zum gleichen Ergebnis führt. Oder sie kann eine tatsächliche Risikoexposition bedeuten. In jedem Fall ist ihre Identifizierung Aufgabe des Compliance-Teams, und Process Discovery macht sie auf eine Weise sichtbar, die manuelle Transaktionsstichproben nie vollständig erreichen.

Die Annahme, Process Discovery sei nur ein Tool für Automatisierung, ist in diesem Kontext besonders schädlich. Compliance-Teams, die „Process Discovery“ hören und davon ausgehen, sie gehöre zum Automatisierungsteam, übersehen einen legitimen Anwendungsfall für ihre eigene Arbeit. Dasselbe Event-Log, das einen RPA-Kandidaten sichtbar macht, zeigt auch eine nicht genehmigte Umgehung eines Genehmigungsschritts. Beides ist im Modell enthalten. Was wichtiger ist, hängt vollständig davon ab, wer es liest.

Process Discovery vs. Process Mining: Woher die Verwirrung kommt

Ich sehe diese Gleichsetzung regelmäßig. Jemand fragt nach Process Mining und meint Process Discovery. Jemand spricht davon, „Process Discovery“ durchzuführen, beschreibt aber tatsächlich den vollständigen Process-Mining-Lebenszyklus. Die Begriffe werden so oft austauschbar verwendet, dass eine klare Einordnung ihres Verhältnisses wichtig ist.

Process Discovery ist eine Technik innerhalb der umfassenderen Disziplin Process Mining. Sie ist kein Synonym für Process Mining und kein konkurrierender Ansatz dazu. Process Mining ist der Oberbegriff: Es umfasst Discovery, Konformitätsprüfung, also den Vergleich tatsächlicher Ausführung mit einem Referenzmodell, und Enhancement, also die Verbesserung eines Prozessmodells mit zusätzlichen Daten. Process Discovery ist die erste dieser drei Techniken und bildet die Grundlage, auf der die anderen aufbauen. Ohne ein ermitteltes Modell, mit dem verglichen werden kann, ist keine Konformitätsprüfung möglich.

Das Celonis-Signal dazu, „wie Process Mining Process Discovery modernisiert“, verweist direkt auf diese Beziehung. Process-Mining-Software und Process-Mining-Lösungen bieten die vollständige Analysesuite: Discovery als Ausgangspunkt, darauf aufbauend Konformität und Enhancement. Wenn Anbieter über Process Intelligence sprechen, beschreiben sie in der Regel den vollständigen Process-Mining-Funktionsstack und nicht nur die Discovery-Ebene.

Warum ist die Verwirrung in der Praxis relevant? Weil Teams, die glauben, sie bräuchten „Process Mining“, obwohl sie eigentlich „Process Discovery“ benötigen, oft in Process-Mining-Tools mit Funktionen investieren, für deren Nutzung sie noch nicht bereit sind. Der Discovery-Prozess erzeugt das Ist-Modell. Für Phase eins ist das oft alles, was ein Team braucht. Die Funktionen zur Konformitätsprüfung und zum Enhancement einer vollständigen Process-Mining-Lösung sind wirklich nützlich, setzen jedoch voraus, dass das Team Discovery zuvor operativ etabliert hat.

Process Mining und Process Discovery sind keine Wettbewerber. Das eine ist eine Teildisziplin des anderen. Wer dies falsch einordnet, investiert entweder zu viel in Tools oder versteht zu wenig, was die Tools leisten.

Anwendungsfälle für Process Discovery in Operations-, Automatisierungs- und Compliance-Teams

Drei Teams treten am häufigsten als primäre Zielgruppen für Process-Discovery-Arbeit auf. Ihre Anwendungsfälle sind so unterschiedlich, dass es sinnvoll ist, für jedes Team ein konkretes Bild zu zeichnen, statt allgemein zu sagen, dass „verschiedene Teams profitieren“.

Die konkreten Anwendungsfälle hängen damit zusammen, was jedes Team mit dem Ergebnis macht. Denn genau dort liegt der tatsächliche Unterschied. Operations-, Automatisierungs- und Compliance-Teams führen dieselbe Discovery durch und treffen anschließend unterschiedliche Entscheidungen.

Ein konkretes Beispiel für Automatisierungsteams: Ein Automatisierungsverantwortlicher in einer mittelgroßen Operations-Abteilung bildet seinen Workflow zur Rechnungsverarbeitung mithilfe der Extraktion von Event-Logs ab und stellt fest, dass 40 % der Rechnungen einem Variantenpfad folgen, der einen manuellen Wiedereingabeschritt beinhaltet, der nicht in der SOP steht. Vor Process Discovery bestand der Plan darin, einen Workflow zur robotergestützten Prozessautomatisierung für den Hauptpfad aufzubauen. Nach der Discovery weiß das Team, dass der Variantenpfad existiert, kann sein Volumen schätzen und entscheiden, ob er in der Automatisierung abgedeckt oder zuerst die Ursache behoben werden soll. Diese Entscheidung ist nur möglich, weil die Ist-Prozesskarte existiert. In Latenode könnte ein Team, das eine solche strukturierte Discovery durchführt, einen wiederkehrenden Workflow erstellen, der Log-Exporte aus seinem ERP abruft, KI-basierte Zusammenfassungen zur Identifizierung von Aktivitätenmustern in Varianten ausführt und die strukturierte Ausgabe zur Prüfung an die Operations-Leitung weiterleitet – ohne eine separate Vektordatenbank zu pflegen oder von Grund auf einen individuellen Enrichment-Connector schreiben zu müssen.

Operations-Teams: Dokumentieren, was tatsächlich passiert, statt dessen, was die SOP vorgibt

Operations-Teams haben ein spezifisches Problem: Ihre Dokumentation zum Geschäftsprozessmanagement war irgendwann korrekt, möglicherweise vor Jahren. Seitdem hat sich das Team angepasst, Workarounds gefunden, Systembeschränkungen übernommen und informelle Praktiken angesammelt. Die SOP sagt das eine. Die Systemlogs zeigen etwas anderes. Niemand betrachtet diese Abweichung als Problem, bis ein neuer Mitarbeiter die SOP exakt befolgt und unerwartete Ergebnisse erzielt oder eine Verbesserungsinitiative zeigt, dass der „aktuelle Prozess“, den alle als Grundlage verwenden, gar nicht der aktuelle Prozess ist.

Für Operations geht es bei Process Discovery darum, die Sicht auf den aktuellen Zustand zu schaffen, bevor jede Diskussion über eine Neugestaltung beginnt. Optimieren Sie Prozesse anhand realer Ausführungsdaten, nicht anhand eines Dokuments, das möglicherweise 18 Monate veraltet ist. Geschäftsprozessmanagement im großen Maßstab hängt von einem präzisen Modell dessen ab, was tatsächlich läuft. Dieses Modell ist das Ergebnis der Discovery. Ohne es ist eine Neugestaltung fundiertes Rätselraten.

Automatisierungsteams: Die richtigen Prozesse für die Automatisierung finden

Hier ist der Fehler bei der Auswahl, den ich bei Automatisierungs- und RPA-Teams am häufigsten sehe: Sie wählen Automatisierungskandidaten danach aus, was jemand als „repetitiv und manuell“ beschreibt. Das ist zwar richtig, aber nicht ausreichend. Repetitiv und manuell bedeutet nicht automatisierbar. Ein Prozess, der repetitiv, manuell und gleichzeitig hochvariabel ist, weil jeder Fall unterschiedliche Ermessensentscheidungen erfordert, bleibt unabhängig vom Zeitaufwand ein schlechter Automatisierungskandidat.

Die Ergebnisse von Process Discovery liefern Automatisierungsteams drei nützliche Informationen: Wie häufig ein Prozess auf jedem Pfad ausgeführt wird, also das Volumen pro Variante; wie konsistent die Pfadstruktur ist, also ob sie regelbasiert genug für Automatisierung ist; und wo sich Ausnahmen konzentrieren, also was die Ausnahmebehandlung abdecken müsste. Eine gute Process-Discovery-Lösung macht dies sichtbar, bevor der Aufbau einer Automatisierung beginnt. Teams, die Discovery überspringen und anhand geschätzter Volumina automatisieren, verantworten oft am Ende eine Automatisierung, die den Hauptpfad bewältigt und bei jeder Variante hörbar scheitert. Die Entscheidung zur Priorisierung einer Automatisierung erfordert zuerst die Prozesskarte.

Die Task-Mining-Funktion von Automation Anywhere ist ein praktisches Beispiel dafür, wie Automatisierungsteams Discovery erweitern, um die Interaktionsebene zu erfassen, die Backend-Logs übersehen. Wenn der Prozess das Kopieren zwischen Anwendungen umfasst, zeichnet Task Mining dies auf. Das RPA-Skript kann es dann reproduzieren. Ohne diese Ebene wird die Automatisierung rund um die sichtbaren Systemereignisse aufgebaut, während die unsichtbaren manuellen Schritte sie im Produktivbetrieb unterbrechen.

Was einen effektiven Process-Discovery-Ansatz ausmacht

Effektive Process Discovery entsteht nicht durch die Auswahl des teuersten Tools. Sie entsteht durch den Einsatz der richtigen Methoden für die richtigen Daten mit den richtigen beteiligten Personen. Hier sind die Entscheidungsprüfungen, die Sie vor dem Start oder vor der Auswahl einer Process-Discovery-Lösung durchführen sollten.

• Prüfen Sie Ihre Event-Log-Struktur, bevor Sie sich für automatisierte Discovery entscheiden

  Der damit verhinderte Fehlermodus: Investitionen in ein Process-Mining-Tool oder einen ABPD-Workflow, nur um festzustellen, dass Ihren Logs Fallkennungen fehlen und die Modellerstellung dadurch unmöglich ist. Die praktische Prüfung: Ziehen Sie eine Stichprobe von 100 Log-Einträgen aus Ihrem Zielsystem und bestätigen Sie, dass jeder Eintrag über einen Aktivitätsnamen, einen Zeitstempel und eine eindeutige Fall- oder Instanzkennung verfügt. Fehlt ein Feld, beheben Sie dies an der Quelle, bevor Sie starten.

• Definieren Sie Prozessgrenzen, bevor das Modell erstellt wird

  Der Fehlermodus: Der Algorithmus erzeugt ein Modell, das mehrere unterschiedliche Prozesse umfasst, weil die Fallkennung einen zu breiten Umfang abdeckt, oder er verfehlt einen vollständigen Prozess, weil das Log systemübergreifend segmentiert ist und keinen gemeinsamen Schlüssel besitzt. Die praktische Prüfung: Dokumentieren Sie das Start- und Endereignis für den Prozess, den Sie ermitteln möchten, bevor Sie etwas ausführen. Bestätigen Sie, dass beide Ereignisse in Ihren Log-Daten enthalten sind.

• Verankern Sie die Stakeholder-Prüfung als klar benannten Schritt, nicht als nachträglichen Einfall

  Der Fehlermodus: Ein präzises Modell, dem niemand vertraut, weil die Fachexperten nicht an der Validierung von Aktivitätsnamen und Falldefinitionen beteiligt waren. Entscheidungen zur Prozessoptimierung auf Basis eines Modells, dem Operations-Teams nicht vertrauen, werden nicht umgesetzt. Die praktische Prüfung: Planen Sie Stakeholder-Review-Sitzungen vor dem Start der Discovery ein, nicht erst nachdem das Modell erstellt wurde.

• Nutzen Sie datengetriebene Discovery für Transaktionsprozesse und manuelle Methoden für implizites Wissen

  Der Fehlermodus bei der Wahl nur eines Ansatzes und der Ignorierung des anderen: entweder ein Modell, das die wichtigen informellen Schritte außerhalb der Systeme übersieht, oder eine workshopbasierte Beschreibung, die durch Erinnerung und sozialen Druck verzerrt ist. Die praktische Prüfung: Listen Sie jeden Prozessschritt auf und bestimmen Sie, welche Schritte eine Systemspur hinterlassen und welche nicht. Planen Sie die Discovery-Methode nach Schritttyp.

• Planen Sie für drei Anwendungsfälle, nicht nur für einen

  Der Fehlermodus: Eine Discovery, die nur auf Automatisierungskandidaten fokussiert ist und die Compliance-Abweichungssignale sowie Prozessvariationsdaten im selben Modell übersieht. Die praktische Prüfung: Beauftragen Sie jeweils eine Person damit, die Modellausgabe für jeden der drei primären Anwendungsfälle zu prüfen – Automatisierung, Compliance und Operations-Optimierung –, statt nur nach einem zu filtern. So wird Process-Discovery-Technologie in ihrem tatsächlichen Umfang eingesetzt.

• Betrachten Sie Discovery als wiederkehrende Maßnahme, nicht als einmalige Voraussetzung

  Der direkt mit Initiativen zur digitalen Transformation verbundene Fehlermodus: Teams führen Discovery durch, entwickeln die Automatisierung und prüfen sechs Monate später nie, ob der Prozess vom Modell abgewichen ist. Prozessvarianten nehmen zu. Das Modell veraltet. Die Automatisierung beginnt, Ausnahmen zu behandeln, für die sie nicht entwickelt wurde. Die praktische Prüfung: Planen Sie eine vierteljährliche oder halbjährliche Modellaktualisierung als Teil der Prozessmanagement-Routine ein, nicht nur zu Beginn eines Verbesserungsprojekts.

📊 In der Praxis:
Das minimal funktionsfähige Event-Log für den Start automatisierter Process Discovery hat genau drei Felder: Aktivitätsname, Zeitstempel und Fallkennung. Bevor Sie irgendeine Process-Discovery-Technologie auswählen oder Teamzeit für die Extraktion einplanen, öffnen Sie einen beispielhaften Log-Export und bestätigen Sie, dass alle drei vorhanden und konsistent ausgefüllt sind. Diese Prüfung dauert zehn Minuten. Sie zu überspringen hat Teams Wochen gekostet.

Was Teams mit den Ergebnissen von Process Discovery tun

Process Discovery erzeugt ein Modell. Das Modell ist nicht die Ziellinie. Was Teams in den darauffolgenden Wochen damit tun, entscheidet darüber, ob sich der Aufwand gelohnt hat.

Die erste Entscheidung betrifft die Priorisierung. Die Ist-Prozesskarte zeigt jeden Pfad, jede Variante und jeden Engpass. Nicht alle erfordern Maßnahmen. Automatisierungsteams nutzen die Karte, um Kandidaten zu bewerten: Hohes Volumen, geringe Variation und regelbasierte Schritte rücken an die Spitze des Automatisierungs-Backlogs. Kandidaten für eine Neugestaltung gehen an Operations-Verantwortliche. Compliance-Abweichungen gehen an die Risiko- oder Audit-Funktion. Eine Prozesskarte ohne diese Triage liegt in einem Ordner und wird bei der nächsten Quartalsprüfung als „etwas, das wir noch einmal ansehen sollten“ erwähnt.

Für Teams, die in Richtung Automatisierung gehen, fließt die Prozesskarte direkt in die Planung von robotergestützter Prozessautomatisierung oder Workflow-Automatisierung ein. Das ermittelte Modell, dargestellt als Geschäftsprozessmodell- und Notationsdiagramm oder als Prozessablaufspezifikation, bietet dem Implementierungsteam eine geprüfte Sicht darauf, worauf es aufbaut. Wenn die RPA oder der Workflow auf einen Ausnahmepfad trifft, weiß das Team bereits, dass er existiert, weil er in der Karte enthalten war. Dieses Wissen verändert, wie die Ausnahmebehandlung aufgebaut wird.

Der zweite große Ergebnispfad ist die Integration mit Process Mining. Teams, die fortlaufende Transparenz statt einer einmaligen Momentaufnahme wünschen, überführen das ermittelte Modell in eine Process-Mining-Plattform zur kontinuierlichen Konformitätsüberwachung. Das Modell wird zur Referenz. Abweichungen davon erscheinen nahezu in Echtzeit im Dashboard. Hier erweitern Task Mining und KI-gestützte Variantenanalyse die anfängliche Discovery zu einem kontinuierlichen Betrieb. Der Engpass, der in der ursprünglichen Karte sichtbar wurde, löst einen Echtzeit-Alert aus, wenn er drei Monate später nach einer Prozessänderung erneut auftritt.

Teams, die die Triage- und Überwachungsschritte überspringen, müssen die Discovery-Übung oft sechs Monate später erneut durchführen, nachdem sie beim ersten Mal weder die Compliance-Signale noch die Prozessvariationsdaten genutzt haben. Das ist eine teure Art zu lernen, dass Optimierung mehr als eine Karte erfordert.