Im Microsoft-Umfeld lässt sich eine solche Analyse unter anderem mit den Process-Mining-Funktionen von Power Automate aufbauen. Daten können beispielsweise aus ERP-, CRM-, Service- oder Fachanwendungen stammen und zur weiteren Berichterstattung mit Microsoft-Werkzeugen verbunden werden. Welche Funktionen im eigenen Mandanten verfügbar sind, hängt von Lizenz, Region, Umgebung und Freigaben der Organisation ab. Maßgeblich sind deshalb die Produkt- und Lizenzinformationen im Microsoft-365-Verwaltungsbereich sowie die Process-Mining-Dokumentation von Power Automate.
Was die Software aus Prozessdaten tatsächlich ermittelt
Ein normaler Bericht beantwortet meist Fragen wie: Wie viele Aufträge wurden abgeschlossen, wie lange dauerte die Bearbeitung im Durchschnitt und wie viele Fälle sind offen? Process Mining geht einen Schritt weiter. Die Software ordnet alle protokollierten Aktivitäten je Vorgang zeitlich und erzeugt daraus den tatsächlich durchlaufenen Prozess.
Bei einer Bestellung könnten die Aktivitäten etwa Auftrag angelegt, Bonität geprüft, Freigabe erteilt, Ware kommissioniert und Rechnung erstellt heißen. Die Prozessansicht zeigt nicht nur diesen gewünschten Weg, sondern auch Varianten: Eine Bestellung springt möglicherweise von der Freigabe zurück zur Erfassung, eine andere wartet mehrere Tage vor der Kommissionierung, eine dritte wird nach einer Korrektur erneut geprüft.
Vier Auswertungen sind für die Suche nach Zeitverlust besonders nützlich:
- Durchlaufzeit: Zeit vom definierten Start bis zum Ende eines Vorgangs.
- Wartezeit zwischen Aktivitäten: Zeitspanne, in der keine protokollierte Folgeaktivität stattfindet.
- Prozessvarianten: Unterschiedliche Reihenfolgen, die Vorgänge tatsächlich nehmen.
- Abweichungsprüfung: Vergleich des beobachteten Verlaufs mit einem vorgegebenen Sollprozess, häufig als Conformance Checking bezeichnet.
Die Darstellung belegt zunächst nur, was im Ereignisprotokoll sichtbar ist. Eine lange Lücke kann auf einen Engpass hindeuten, aber ebenso durch eine fehlende Schnittstelle, eine nächtliche Datenübertragung oder einen fachlich erforderlichen Prüfschritt entstehen. Process Mining liefert damit einen belastbaren Ausgangspunkt für die Untersuchung, jedoch nicht automatisch die Ursache.
Ohne sauberes Ereignisprotokoll wird die Prozesskarte irreführend
Die wichtigste Vorarbeit findet nicht in einer grafischen Prozesskarte statt, sondern in der Datentabelle. Für jeden analysierten Vorgang benötigt die Software mindestens drei Felder:
- eine gleichbleibende Vorgangskennung, häufig Case ID genannt,
- die Bezeichnung der ausgeführten Aktivität,
- einen auswertbaren Zeitstempel.
Zusätzliche Felder erhöhen den Erkenntniswert. Dazu gehören Bearbeitungsgruppe, Standort, Produktklasse, Kanal, Status, Betrag oder eingesetztes System. Personenbezogene Merkmale sollten nur einbezogen werden, wenn hierfür ein klarer Zweck und eine zulässige Grundlage bestehen. Für viele Engpassanalysen genügt eine Rolle oder Organisationseinheit; der Name eines Beschäftigten ist dafür nicht erforderlich.
Ein brauchbarer Ausschnitt könnte logisch so aufgebaut sein:
Vorgang;Aktivität;Zeitpunkt;Team
A-1048;Antrag eingegangen;2026-02-03 08:41;Eingang
A-1048;Vollständigkeit geprüft;2026-02-03 10:12;Prüfung
A-1048;Rückfrage gesendet;2026-02-03 10:19;Prüfung
A-1048;Unterlagen ergänzt;2026-02-06 09:07;Eingang
A-1048;Antrag freigegeben;2026-02-06 11:24;FreigabeIn diesem Vorgang liegt die größte Zeitspanne zwischen Rückfrage und Ergänzung. Das ist noch kein Beweis für einen internen Zeitfresser: Die Antwort könnte außerhalb des Unternehmens gelegen haben. Ein zusätzliches Feld für interne und externe Wartezustände oder eine passende Statuslogik verhindert eine falsche Zuordnung.
Vor dem Import sollten Unternehmen außerdem Zeitzonen, Datumsformate und doppelte Ereignisse kontrollieren. Haben mehrere Aktivitäten denselben Zeitstempel, braucht die Software gegebenenfalls ein weiteres Sortiermerkmal. Fehlt eine Case ID oder wird dieselbe Kennung später neu vergeben, verbindet das System möglicherweise Ereignisse, die fachlich nicht zusammengehören.
Die richtige Prüfreihenfolge führt vom Engpass zur Ursache
Eine farbige Prozesskarte verleitet dazu, sofort den auffälligsten Pfad zu bewerten. Aussagekräftiger ist eine feste Reihenfolge, bei der Datenfehler, Häufigkeit und betriebliche Wirkung getrennt geprüft werden.
- Prozessgrenze festlegen: Start- und Endereignis müssen fachlich eindeutig sein. Bei einer Rechnungsprüfung kann der Start der Rechnungseingang und das Ende die Zahlungsfreigabe sein. Ohne feste Grenzen lassen sich Durchlaufzeiten nicht sinnvoll vergleichen.
- Datenabdeckung kontrollieren: Prüfe, welcher Zeitraum und welche Vorgangsarten enthalten sind. Wenn manuelle Arbeitsschritte oder ein Altsystem fehlen, bildet die Karte nur einen Ausschnitt ab.
- Häufige Varianten zuerst ansehen: Ein ungewöhnlicher Einzelfall ist selten der beste Ansatzpunkt. Ein kleiner Zeitverlust in Tausenden Vorgängen kann wichtiger sein als eine sehr lange Verzögerung in wenigen Sonderfällen.
- Warte- und Bearbeitungszeit trennen: Lange Durchlaufzeit bedeutet nicht automatisch lange Arbeitszeit. Liegt ein Vorgang zwei Tage in einer Warteschlange und wird zehn Minuten bearbeitet, liegt der Hebel eher bei Übergabe, Priorisierung oder Kapazität.
- Schleifen und Rücksprünge filtern: Wiederholte Freigaben, Korrekturen oder erneute Dateneingaben weisen häufig auf unvollständige Eingaben, unklare Regeln oder Medienbrüche hin.
- Hypothese außerhalb der Software prüfen: Sprich mit den beteiligten Rollen und untersuche einige betroffene Vorgänge. Erst dieser Abgleich zeigt, ob die Abweichung vermeidbar, vorgeschrieben oder nur technisch falsch protokolliert ist.
Die Auswertung führt damit zu einer klaren Wenn-dann-Entscheidung: Tritt eine Verzögerung häufig an derselben Übergabe auf, sind Zuständigkeit, Warteschlange und Übergaberegeln zu prüfen. Entsteht sie nur bei einer bestimmten Fallklasse, sollte diese Klasse separat betrachtet werden. Verschwindet die Auffälligkeit nach einer Bereinigung der Zeitstempel, war sie ein Datenproblem und kein Prozessproblem.
Typische Zeitfresser haben unterschiedliche Datenspuren
Nicht jede Schwachstelle sieht in Process-Mining-Software gleich aus. Die Form der Abweichung gibt einen Hinweis darauf, welche Gegenprobe sinnvoll ist.
Warteschlangen zwischen zwei Teams
Viele Fälle erreichen eine bestimmte Aktivität schnell, bleiben aber vor dem nächsten Schritt überdurchschnittlich lange liegen. Wenn die Verzögerung vor allem an Arbeitstagen und bei hohem Volumen auftritt, kommen Kapazität oder Priorisierung als Ursache infrage. Tritt sie unabhängig vom Volumen auf, sind feste Sammelläufe, Freigabetermine oder Schnittstellen eher zu untersuchen.
Rücksprünge und Nacharbeit
Ein Vorgang kehrt wiederholt zu einer bereits abgeschlossenen Aktivität zurück. Das kann durch fehlende Pflichtangaben, missverständliche Eingabemasken oder unterschiedliche Prüfkriterien entstehen. Vor einer Automatisierung sollte geklärt werden, ob die Nacharbeit fachlich erforderlich ist. Sonst beschleunigt eine Automatisierung lediglich einen fehlerhaften Ablauf.
Medienbrüche zwischen Anwendungen
Ein Ereignis endet in einem System, während die nächste Aktivität erst deutlich später in einer anderen Anwendung auftaucht. Als Ursache kommen manuelle Übertragung, Datei-Exporte, E-Mail-Freigaben oder verzögerte Synchronisation infrage. Die Gegenprobe besteht darin, eine kleine Zahl betroffener Vorgänge systemübergreifend nachzuverfolgen. Fehlt der Zwischenschritt vollständig im Protokoll, muss zuerst die Datenbasis erweitert werden.
Seltene Sonderwege mit hoher Wirkung
Manche Varianten betreffen nur wenige Fälle, verursachen aber hohe Kosten, lange Lieferverzögerungen oder Compliance-Risiken. Eine reine Sortierung nach Häufigkeit würde sie ausblenden. Sinnvoll ist eine zweite Betrachtung nach geschäftlicher Wirkung, beispielsweise nach Auftragsklasse, Betrag oder Eskalationsstatus. Solche Merkmale müssen aus dem Quellsystem stammen; Process Mining kann fehlende Geschäftsdaten nicht nachträglich ableiten.
Process Mining, Task Mining und klassische Berichte erfüllen andere Aufgaben
Process Mining betrachtet den Ablauf über mehrere Ereignisse und Systeme hinweg. Task Mining untersucht dagegen eher einzelne Arbeitsschritte am Desktop, beispielsweise wiederkehrende Klicks, Eingaben oder Wechsel zwischen Anwendungen. Klassische Business-Intelligence-Berichte verdichten Kennzahlen, bilden aber nicht zwangsläufig die Reihenfolge jedes einzelnen Vorgangs ab.
Für die Auswahl hilft eine einfache Abgrenzung:
- Wenn Vorgangskennungen und Zeitstempel in Fachsystemen vorhanden sind, ist Process Mining der naheliegende Ansatz.
- Wenn die eigentliche Arbeit vor allem aus nicht protokollierten Desktop-Handgriffen besteht, kann Task Mining ergänzende Hinweise liefern.
- Wenn nur bekannte Kennzahlen überwacht werden sollen, genügt häufig ein Bericht in einer BI-Lösung.
- Wenn weder Ereignisdaten noch ein stabiler Ablauf vorhanden sind, sollte das Unternehmen zuerst Prozessgrenzen und Protokollierung ordnen.
Task Mining kann besonders sensible Nutzungsdaten erzeugen. Die Erfassung von Bildschirminhalten oder Interaktionen erfordert eine sorgfältige technische, organisatorische und datenschutzrechtliche Bewertung. Berechtigungen, Aufbewahrung und Sichtbarkeit müssen vor dem Einsatz geklärt sein. Eine verdeckte Leistungs- oder Verhaltenskontrolle ist kein legitimer Ersatz für eine offen definierte Prozessanalyse.
Microsoft-Werkzeuge in die Analyse einordnen
Power Automate verbindet Automatisierung und Prozessanalyse innerhalb der Microsoft-Plattform. Die Process-Mining-Funktionen können Ereignisdaten zu Prozessmodellen aufbereiten und Varianten, Kennzahlen sowie Engpässe sichtbar machen. Für eine Entscheidung reicht der Produktname jedoch nicht aus: Unternehmen müssen im eigenen Microsoft-Mandanten prüfen, welche Funktionen, Datenkapazitäten, Umgebungen und Lizenzrechte bereitstehen.
Power BI kann Ergebnisse ergänzend visualisieren und mit betrieblichen Kennzahlen verbinden. Es ersetzt das Prozessmodell nicht automatisch, ist aber nützlich, wenn Durchlaufzeiten nach Standort, Produktgruppe oder Zeitraum betrachtet werden sollen. Excel eignet sich für eine erste Kontrolle kleiner Exportdateien, etwa um leere Vorgangskennungen, uneinheitliche Aktivitätsnamen oder fehlerhafte Zeitstempel zu finden. Bei großen Ereignismengen und vielen Varianten wird eine manuelle Excel-Auswertung schnell unübersichtlich.
Microsoft ist nicht die einzige Plattform in diesem Bereich. Celonis und SAP Signavio sind ebenfalls bekannte Process-Mining- beziehungsweise Prozessanalyseangebote. Eine belastbare Auswahl darf aber nicht allein nach Funktionslisten erfolgen. Dieselben Kriterien sollten für jeden Kandidaten geprüft werden:
- Anbindung an die tatsächlich verwendeten Quellsysteme,
- Aufbereitung und Aktualisierung der Ereignisdaten,
- Filterung, Variantenanalyse und Soll-Ist-Abgleich,
- Rollen, Berechtigungen und Protokollierung von Zugriffen,
- Betriebsmodell, Datenstandort und organisatorische Vorgaben,
- Lizenzmodell im Verhältnis zu Datenmenge und Nutzerkreis.
Ohne gleichartige Testdaten lässt sich kein seriöser Sieger bestimmen. Ein sinnvoller Pilot verwendet deshalb denselben abgegrenzten Prozess und dieselben Erfolgskriterien für alle betrachteten Lösungen.
Ein Pilotprojekt muss eine prüfbare Geschäftsfrage beantworten
Der Einstieg gelingt besser mit einem begrenzten Ablauf als mit dem Anspruch, das gesamte Unternehmen abzubilden. Geeignet ist ein Prozess mit wiederkehrenden Fällen, digital verfügbaren Ereignissen und einem bekannten Problem, dessen Wirkung messbar ist. Beispiele sind Bestellfreigaben, Rechnungsklärungen, Serviceanfragen oder standardisierte Antragsprozesse.
Die Frage sollte enger sein als Bearbeitung beschleunigen. Besser ist etwa: An welcher Übergabe entstehen die längsten internen Wartezeiten, und welcher Anteil der Vorgänge durchläuft dort eine erneute Prüfung? Damit stehen Prozessgrenze, Messgröße und Untersuchungsziel fest.
Für den Pilot sind sechs Arbeitspakete zweckmäßig:
- Prozessverantwortung und beteiligte Rollen festlegen.
- Start, Ende und relevante Fallklassen definieren.
- Ereignisdaten extrahieren und ihre Vollständigkeit testen.
- Prozessmodell erzeugen und auffällige Varianten priorisieren.
- Ursachen mit Fachabteilung und ausgewählten Vorgängen validieren.
- Eine Änderung umsetzen und denselben Messzeitraum erneut auswerten.
Der letzte Punkt trennt eine ansprechende Visualisierung von einer wirksamen Verbesserung. Nach einer Maßnahme sollte nicht nur der Mittelwert betrachtet werden. Median, Streuung, Fallzahl und Anteil der betroffenen Variante helfen zu erkennen, ob sich der Ablauf insgesamt verbessert hat oder lediglich wenige Extremfälle verschwunden sind.
Automatisierung folgt erst nach der Ursachenprüfung
Process Mining und Automatisierung ergänzen sich, sind aber nicht derselbe Schritt. Eine häufige manuelle Übergabe kann sich für einen Power-Automate-Flow oder eine andere Workflow-Automatisierung eignen. Vorher müssen Eingaben, Ausnahmen, Berechtigungen und Fehlerwege stabil sein.
Wenn eine Aktivität nur deshalb wiederholt wird, weil Daten an der Quelle fehlen, sollte die Eingabe verbessert werden. Wenn eine Freigabe gesetzlich, vertraglich oder organisatorisch erforderlich ist, darf ihre Dauer nicht durch ersatzloses Entfernen verkürzt werden. Wenn eine Schnittstelle regelmäßig fehlschlägt, ist deren technische Stabilisierung wichtiger als eine zusätzliche Automatisierungsschicht.
Eine Maßnahme ist erst dann erfolgreich, wenn der neue Prozess auch außerhalb der Software funktioniert. Dazu gehören klare Verantwortlichkeiten, ein kontrollierter Umgang mit Ausnahmen und eine Rückfallmöglichkeit bei technischen Fehlern. Die erneute Prozessanalyse zeigt anschließend, ob Wartezeit oder Nacharbeit wirklich gesunken sind und ob an anderer Stelle ein neuer Engpass entstanden ist.
Datenschutz und Berechtigungen gehören in das Datenmodell
Ereignisprotokolle können Beschäftigten-, Kunden- oder Geschäftsdaten enthalten. Bereits eine Kombination aus Benutzerkennung, Zeitstempel und Aktivität kann Rückschlüsse auf einzelne Personen erlauben. Unternehmen sollten daher nur Merkmale übernehmen, die für die definierte Fragestellung erforderlich sind, und Zugriffe nach Rollen begrenzen.
Zur technischen Planung gehören Pseudonymisierung oder Aggregation, getrennte Entwicklungs- und Produktivumgebungen, festgelegte Aufbewahrungszeiten sowie eine Dokumentation der Datenquellen. Exporte auf lokale Windows-PCs benötigen denselben Schutz wie die Ursprungsdaten. Unkontrollierte CSV-Dateien in Download-Ordnern oder gemeinsam genutzten Verzeichnissen unterlaufen ein sonst ordentliches Berechtigungskonzept.
Vor einer breiten Einführung sind Datenschutz, Informationssicherheit, betriebliche Mitbestimmung und die zuständigen Prozessverantwortlichen einzubeziehen. Welche Anforderungen gelten, hängt vom Datenbestand, Einsatzland und Verwendungszweck ab. Die Analyse sollte auf Prozessverbesserung ausgerichtet und technisch so gestaltet sein, dass personenbezogene Detaildaten nicht vorsorglich gesammelt werden.
Woran sich ein belastbares Ergebnis erkennen lässt
Eine gute Process-Mining-Auswertung liefert mehr als eine komplexe Grafik. Sie macht sichtbar, welche Daten enthalten sind, wie Start und Ende definiert wurden, wie viele Fälle eine Auffälligkeit betrifft und welche Gegenprobe die vermutete Ursache stützt. Außerdem bleibt nachvollziehbar, welche Fälle wegen fehlender oder widersprüchlicher Daten ausgeschlossen wurden.
Für Unternehmen ergibt sich daraus eine klare Entscheidung: Ist die Auffälligkeit häufig, wirtschaftlich relevant und fachlich vermeidbar, folgt eine priorisierte Verbesserungsmaßnahme. Ist sie vorgeschrieben oder durch externe Wartezeit bedingt, wird sie getrennt ausgewiesen statt fälschlich als interner Leistungsfehler behandelt. Ist die Datenqualität unzureichend, hat die Verbesserung der Protokollierung Vorrang vor weiteren Prozesskarten.
