Ihr Ticketsystem protokolliert jeden Statuswechsel. Der Export liegt bereit. Nun soll eine KI zeigen, warum Vorgänge so lange dauern. Das klingt nach einem kurzen Weg von der Tabelle zur Verbesserung. Häufig liegt die wichtigste Arbeit aber vor der ersten Auswertung: Was bedeutet eine Zeile, welcher Vorgang gehört wohin und wann wurde tatsächlich gearbeitet?
Gerade für kleinere Unternehmen ist diese Vorarbeit lohnend. Sie benötigen nicht sofort eine große Analyseplattform. Sie benötigen zunächst einen sauber abgegrenzten Prozess und Daten, deren Bedeutung Sie erklären können. Wir zeigen an einer fiktiven Rechnungsfreigabe, wie Sie diesen Einstieg gestalten und welche Aufgaben KI dabei übernehmen kann.
Kurz erklärt
Process Mining rekonstruiert Abläufe aus Ereignisdaten. Für einen sinnvollen Einstieg brauchen Sie eindeutige Fallkennungen, klar benannte Aktivitäten und verlässliche Zeitstempel. KI kann bei Datenprüfung und Auswertung helfen; fehlende Ereignisse oder unbelegte Bearbeitungszeiten darf sie nicht ergänzen.
Ein Sprachmodell ist noch kein Process-Mining-Verfahren
Wenn Sie eine Prozessbeschreibung in einen Chat kopieren, erhalten Sie eine sprachliche Analyse dieser Beschreibung. Das ist etwas anderes als die Rekonstruktion tatsächlich aufgezeichneter Ablaufvarianten. Ein Process-Mining-Werkzeug verarbeitet die Ereignisse vieler Fälle nach definierten Regeln und macht beispielsweise Schleifen oder unterschiedliche Reihenfolgen sichtbar.
Beide Ansätze können zusammenarbeiten. Ein Sprachmodell kann helfen, eine Abfrage zu formulieren, Bezeichnungen zu vereinheitlichen oder Auffälligkeiten verständlich zu erläutern. Die Kennzahlen sollten jedoch durch nachvollziehbare Berechnungen aus den Daten entstehen. Speichern Sie Abfragen, Filter und Ergebnisse so, dass eine zweite Person sie reproduzieren kann.
Für den ersten Versuch reicht möglicherweise eine Tabellenkalkulation oder eine Datenbankabfrage. Wenn Fälle viele Varianten, parallele Schritte und häufige Rücksprünge enthalten, kann eine spezialisierte Anwendung hilfreicher werden. Entscheidend ist der Analysebedarf. Ein zusätzliches Werkzeug macht unklare Zeitstempel nicht automatisch aussagekräftiger.
Die drei Angaben, ohne die der Ablauf unscharf bleibt
Microsoft nennt für die Ereignisdaten seiner Process-Mining-Funktion Fallkennung, Aktivitätsname und Zeitstempel als zentrale Angaben. Bei Ereignissen gibt es einen Zeitpunkt, bei Aktivitäten können Beginn und Ende getrennt vorliegen.1
In unserem Beispiel ist die Fallkennung die einzelne Rechnung. „Eingegangen“, „Rückfrage gestellt“ und „Freigegeben“ sind Ereignisse. Eine Lieferantennummer wäre hier kein geeigneter Ersatz für die Fallkennung, weil derselbe Lieferant viele Rechnungen stellen kann. Deren Abläufe würden sonst miteinander vermischt.
Prüfen Sie außerdem, ob eine Rechnung Teilfreigaben oder mehrere Bestellungen enthält. Dann kann ein einzelner Fall parallele Vorgänge verdecken. Für den Einstieg wählen Sie einen Ausschnitt, dessen Zuordnung eindeutig ist. Dokumentieren Sie ausgeschlossene Sonderfälle, statt sie still aus dem Export zu entfernen.
Tabelle seitlich scrollen, um alle Spalten zu sehen.
| Fall | Aktivität | Zeitpunkt |
|---|---|---|
| R-104 | Eingegangen | Montag, 09:00 |
| R-104 | Rückfrage gestellt | Montag, 11:00 |
| R-104 | Freigegeben | Dienstag, 15:00 |
30 Stunden Durchlaufzeit sind keine 30 Stunden Arbeit
Zwischen dem ersten und letzten Ereignis unseres Beispiels liegen 30 Kalenderstunden. Daraus können Sie die Durchlaufzeit dieses Ausschnitts berechnen. Sie wissen aber nicht, ob jemand fünf Minuten, eine Stunde oder den ganzen Vormittag an der Rechnung gearbeitet hat.
Auch die zwei Stunden zwischen Eingang und Rückfrage sind nicht automatisch Bearbeitungszeit. Möglicherweise lag der Vorgang zunächst im Postkorb. Um aktive Arbeit zu messen, benötigen Sie geeignete Start- und Endsignale oder eine gesonderte Erhebung. Ohne diese Grundlage sollten Sie die Zeit nicht als Personalkostenersparnis bewerten.
Entscheiden Sie bewusst zwischen Kalenderzeit und Geschäftszeit. Aus Kundensicht kann das Wochenende Teil der Wartezeit sein, intern wird vielleicht mit Arbeitsstunden geplant. Beides ist möglich, solange Sie es sauber benennen und nicht in derselben Kennzahl vermischen. Halten Sie Zeitzonen und Sommerzeitwechsel ebenfalls in der Messdefinition fest.
30 Stunden zwischen Ereignissen. Arbeitszeit unbekannt.
- Eingegangen↓ 2 Stunden bis zum nächsten Ereignis
- Rückfrage gestellt↓ 28 Stunden bis zum nächsten Ereignis
- Freigegeben
Offen: aktive Arbeit und tatsächliche Warteanteile.
Prüfen Sie den Export, bevor Sie Engpässe benennen
Beginnen Sie mit einfachen Plausibilitätsprüfungen: Fehlen Fallkennungen? Gibt es doppelte Ereignisse? Steht eine Freigabe vor dem Eingang? Sind zwei Aktivitäten exakt gleichzeitig protokolliert? Solche Muster können reale Besonderheiten zeigen, aber auch Importfehler oder nachträgliche Sammelbuchungen.
Betrachten Sie den Rand Ihres Zeitfensters. Ein im Oktober abgeschlossener Vorgang kann im September begonnen haben. Exportieren Sie nur Oktoberereignisse, fehlt sein Beginn. Umgekehrt fehlen bei noch offenen Fällen die Abschlusszeiten. Ein Vergleich nur abgeschlossener Fälle kann dadurch die längsten Wartezeiten unterschätzen.
Führen Sie ausgeschlossene und unvollständige Fälle in einer eigenen Übersicht. Die Entscheidung „Wir analysieren zunächst nur vollständig protokollierte Standardrechnungen“ kann sinnvoll sein. Sie muss aber sichtbar bleiben. Ihre Ergebnisse gelten dann für diesen Ausschnitt und nicht automatisch für den gesamten Rechnungseingang.
- Fallbezug prüfen: Gehören alle Ereignisse wirklich zum selben Prozessobjekt?
- Zeitbezug prüfen: Was löst den Zeitstempel aus, und in welcher Zeitzone liegt er vor?
- Abdeckung prüfen: Welche Schritte finden außerhalb des Systems statt?
- Auswahl prüfen: Welche Vorgänge fehlen wegen Zeitraum, Status oder Filter?
Wobei ein KI-Assistent konkret helfen kann
Geben Sie dem Assistenten zunächst das Spaltenschema, die Definitionen und künstliche Beispielzeilen. Bitten Sie um einen Prüfplan: „Welche Datenfehler würden die Durchlaufzeit verfälschen? Formuliere für jeden Fehler eine prüfbare Regel. Unterstelle keine zusätzlichen Spalten und erfinde keine fehlenden Ereignisse.“
Wenn die KI SQL oder ein Skript vorschlägt, testen Sie die Berechnung an wenigen Fällen, deren Ergebnis Sie von Hand kennen. Prüfen Sie insbesondere, ob doppelte Ereignisse mehrfach gezählt, Zeitstempel als Text sortiert oder leere Abschlusswerte still ersetzt werden. Erst danach wenden Sie dieselbe Logik auf den größeren Export an.
Für die Ergebnisinterpretation geben Sie aggregierte Kennzahlen und die bekannten Einschränkungen mit. Verlangen Sie getrennt eine Beschreibung der Beobachtung und mögliche Erklärungen. „Fälle mit Rückfragen dauern länger“ kann eine Beobachtung sein. „Rückfragen verursachen die gesamte Verzögerung“ geht ohne weitere Untersuchung darüber hinaus.
Vier Auswertungen für einen überschaubaren Einstieg
Erstens: Wie lange dauern Fälle vom definierten Beginn bis zum Abschluss? Zeigen Sie neben dem Mittelwert auch Median und einen oberen Quantilwert, etwa das 90. Perzentil. So bleibt sichtbar, ob wenige sehr langsame Vorgänge das Bild prägen. Schreiben Sie die Zahl der betrachteten Fälle dazu.
Zweitens: Welcher Anteil durchläuft eine Rückfrage? Drittens: Wie oft wird derselbe Schritt wiederholt? Viertens: Welche Ablaufvarianten treten häufig auf? Für jede Kennzahl legen Sie den Nenner fest. Drei Rückfragen innerhalb eines Falls sind etwas anderes als drei verschiedene Fälle mit jeweils einer Rückfrage.
Vergleichen Sie sinnvolle Fallgruppen, beispielsweise Standardrechnungen und Rechnungen ohne Bestellbezug. Ein besonders langer Zeitabstand markiert zunächst eine Stelle für die Untersuchung. Ob dort tatsächlich ein kapazitätsbedingter Engpass liegt, klären Sie mit Warteschlangen, Arbeitsvolumen und den Menschen, die den Schritt bearbeiten.
Die Prozesskarte führt zurück zu den Beteiligten
Nehmen Sie einige auffällige Fälle mit in ein Gespräch. Was geschah außerhalb des Systems? Wurde telefonisch geklärt, eine Unterlage nachgereicht oder eine Freigabe aus gutem Grund zurückgestellt? Eine digitale Spur zeigt nur das, was erfasst wurde. Der Austausch ergänzt die Bedeutung, die in einer Statusbezeichnung fehlen kann.
Vermeiden Sie eine Rangliste vermeintlich langsamer Mitarbeiter. Unterschiedliche Aufgaben, Vertretungen und schwierige Fälle können Bearbeiternamen mit langen Zeiten verbinden, ohne dass deren Arbeitsweise die Ursache ist. Für die erste Verbesserung ist eine Prozessgruppe häufig die geeignetere Betrachtungsebene als eine einzelne Person.
Vereinbaren Sie anschließend eine begrenzte Veränderung und dieselbe Messung für die Folgeperiode. Bleiben Fallauswahl und Messdefinition gleich? Hat sich das Volumen verschoben? Wenn Sie diese Fragen beantworten können, entsteht aus einem Datenexport ein brauchbarer Verbesserungszyklus. Genau diese Verbindung von Messung, Analyse und Anwendung macht den Ansatz für Green-Belt-Projekte interessant.
Bevor Sie Ihre Ereignisdaten von einer KI erklären lassen, erklären Sie selbst ihre Bedeutung. Eine kleine, sauber definierte Auswertung ist der bessere Anfang als eine große Prozesskarte mit unklarer Datengrundlage.
Häufige Fragen
Kann ich mit einer Excel-Datei anfangen?
Ja, wenn sie Ereignisse eindeutig einem Fall zuordnet und verlässliche Aktivitätsnamen sowie Zeitstempel enthält. Eine Liste mit nur dem aktuellen Status bildet frühere Übergaben dagegen nicht automatisch ab.
Darf die KI fehlende Zeitstempel schätzen?
Für eine Untersuchung realer Durchlaufzeiten sollten geschätzte Ereignisse nicht als gemessene Daten behandelt werden. Kennzeichnen Sie fehlende Werte und entscheiden Sie nachvollziehbar, welche Fälle auswertbar sind.
Ist eine lange Wartezeit immer ein Engpass?
Nein. Sie kann beispielsweise durch Rückfragen, vereinbarte Fristen oder Sammelverarbeitung entstehen. Ein kapazitätsbedingter Engpass benötigt eine weitergehende Prüfung von Arbeitsvolumen, Warteschlange und verfügbarer Leistung.
Green Belt
Sie lernen, eigene Projekte zur Prozessoptimierung systematisch zu bearbeiten: Prozesse analysieren, Daten einordnen und begründete Lösungen entwickeln.
Fußnoten und Quellen
Verlinkte Primärquellen, geprüft am 19.10.2026. Methodische Empfehlungen und eigene Einordnungen stammen aus der Campus-Redaktion. Fiktive Beispiele und Rechenannahmen sind im Text gekennzeichnet; Anbieterangaben können sich ändern.