Wiederholte Aktivitäten entfernen

Übersicht

Die Bereicherung „Wiederholte Aktivitäten entfernen“ vereinfacht Ihren Prozess, indem aufeinanderfolgende doppelte Aktivitäten zu einzelnen Vorkommnissen zusammengefasst werden, während wichtige Informationen darüber erhalten bleiben, wie oft jede Aktivität wiederholt wurde. Dieses leistungsstarke Tool zur Datenbereinigung ist essenziell für die Analyse von Prozessen, bei denen dieselbe Aktivität mehrfach hintereinander ausgeführt werden kann – entweder aufgrund von Systemverhalten, Benutzeraktionen oder Prozessgestaltung.

Wenn Aktivitäten in einem Fall nacheinander wiederholt werden, können sie den tatsächlichen Prozessfluss verschleiern und es erschweren, aussagekräftige Muster zu erkennen. Diese Bereicherung beseitigt das Rauschen, indem sie wiederholte Aktivitäten zusammenfasst und dabei ein Zählattribut erstellt, das verfolgt, wie oft die Aktivität auftrat. Sie können auch wählen, ob Sie Attributwerte auf Ereignisebene aus den wiederholten Aktivitäten durch Verkettung bewahren möchten, sodass keine wichtigen Informationen während der Konsolidierung verloren gehen.

Die Bereicherung bietet zwei Betriebsmodi: strikte aufeinanderfolgende Wiederholung (bei der Aktivitäten direkt aufeinander folgen müssen) oder flexible Wiederholung (bei der alle Instanzen einer Aktivität unabhängig von dazwischenliegenden Aktivitäten zusammengefasst werden). Diese Flexibilität ermöglicht es Ihnen, die Bereicherung genau auf Ihre spezifischen Prozessanalyseanforderungen anzupassen.

Häufige Anwendungsfälle

Vereinfachung von Prozessabläufen durch Entfernung von Stottermustern, die durch automatisierte Wiederholungslogik entstehen
Bereinigung von Ereignisprotokollen, in denen Benutzer wiederholt Schaltflächen klicken oder Seiten aktualisieren
Zusammenfassung von aufeinanderfolgenden Abfrage- oder Statusprüfaktivitäten
Reduzierung der Prozesskomplexität bei der Analyse von häufigen Überwachungsaktivitäten
Vorbereitung der Daten für die Prozessentdeckung durch Eliminierung repetitiver Störgeräusche
Nachverfolgung, wie oft Aktivitäten wiederholt wurden, bevor der nächste Schritt erfolgte
Bewahrung von Attributwerten aus wiederholten Aktivitäten durch Verkettung für Audit-Trails

Einstellungen

Activity Name: Wählen Sie die Aktivität aus, die Sie bei aufeinanderfolgender Wiederholung zusammenfassen möchten. Die Bereicherung erkennt alle Fälle, in denen diese Aktivität mehrfach auftritt und fasst sie zu einem einzigen Ereignis zusammen. Wählen Sie Aktivitäten aus, die in Ihrem Prozess bekannt dafür sind, sich zu wiederholen, wie z. B. Wiederholungsversuche, Statusprüfungen oder Benutzerinteraktionen.

Count Column Name: Geben Sie den Namen des neuen Attributs an, das die Anzahl der Wiederholungen dieser Aktivität speichert. Dieses Attribut wird automatisch mit der Anzahl der zusammengefassten aufeinanderfolgenden Vorkommnisse befüllt. Das Standardbenennungsschema ist „[Activity Name]_Count“, kann aber an die Namenskonventionen Ihres Unternehmens angepasst werden. Zum Beispiel könnte bei der Entfernung wiederholter „Payment Retry“-Aktivitäten dieser „Payment_Retry_Attempts“ genannt werden.

Concatenate Attributes (Optional): Wählen Sie ein oder mehrere Ereignis-String-Attribute aus, deren Werte Sie aus den wiederholten Aktivitäten erhalten möchten. Wenn mehrere Instanzen zusammengefasst werden, werden die Werte dieser Attribute mit Kommas getrennt verkettet. Dies ist besonders nützlich, wenn jede Wiederholung unterschiedliche kontextuelle Informationen enthält, z. B. Fehlermeldungen, Zeitstempel oder Benutzer-IDs. Es stehen nur String-Ereignisattribute zur Verkettung zur Verfügung, die nicht berechnet und nicht ausgeblendet sind.

Must Follow Directly: Steuert, wie die Bereicherung wiederholte Aktivitäten identifiziert:

Aktiviert (Standard): Entfernt nur Aktivitäten, die ohne Zwischenaktivitäten aufeinander folgen. Bei der Sequenz „A, B, B, B, C“ werden die drei aufeinanderfolgenden Bs zu einem B zusammengefasst. Dies ist der häufigste und konservativste Ansatz.
Deaktiviert: Entfernt alle Instanzen der ausgewählten Aktivität im gesamten Fall und behält nur das erste Vorkommnis, unabhängig davon, ob andere Aktivitäten dazwischenliegen. Bei der Sequenz „A, B, C, B, D, B“ wird nur das erste B behalten und die anderen entfernt. Dieser Modus sollte mit Vorsicht verwendet werden, da er den Prozessfluss grundlegend ändert.

Beispiele

Beispiel 1: Zahlungsausführungs-Wiederholungslogik

Szenario: Eine E-Commerce-Plattform verfügt über eine automatisierte Wiederholungslogik für Zahlungsvorgänge. Wenn eine Zahlung aufgrund von Netzwerkproblemen oder vorübergehenden Kartenauthorisationsproblemen fehlschlägt, versucht das System bis zu 5 Mal erneut, bevor es aufgibt. Diese Wiederholungsversuche überfrachten die Prozesskarte und erschweren die Nachverfolgung der tatsächlichen Customer Journey.

Einstellungen:

Activity Name: „Process Payment“
Count Column Name: „Payment_Retry_Count“
Concatenate Attributes: „Error_Message“, „Gateway_Response“
Must Follow Directly: Aktiviert

Ausgabe: Die Bereicherung fasst aufeinanderfolgende Zahlungsvorgänge zu einer einzigen „Process Payment“-Aktivität mit zusätzlichem Kontext zusammen:

Neues Attribut: „Payment_Retry_Count“ mit Werten wie 1 (keine Wiederholungen), 2 (ein Wiederholungsversuch) oder 5 (vier Wiederholungen)
Ereignisattribut „Error_Message“ enthält alle Fehlermeldungen verkettet: „Network timeout, Network timeout, Card declined“
Ereignisattribut „Gateway_Response“ enthält alle Antworten: „503, 503, 402“

Beispielhafte Falltransformation:

Vorher: Process Payment (fehlgeschlagen) -> Process Payment (fehlgeschlagen) -> Process Payment (fehlgeschlagen) -> Process Payment (erfolgreich)
Nachher: Process Payment (erfolgreich) mit Payment_Retry_Count = 4

Erkenntnisse: Das Unternehmen kann nun Zahlungserfolgsraten genauer analysieren, indem es sieht, wie viele Wiederholungsversuche erforderlich waren. Fälle mit hohen Wiederholungszahlen können auf Integrationsprobleme mit bestimmten Zahlungsgateways oder Probleme in Stoßzeiten hinweisen.

Beispiel 2: Statusprüfungen im Kundenservice

Szenario: Ein Ticketingsystem im Kundenservice prüft automatisiert alle 5 Minuten den Status eines Tickets, während auf eine Kundenreaktion gewartet wird. Diese Statusprüfungen erzeugen hunderte von Ereignissen in langlaufenden Fällen, was die Prozessanalyse nahezu unmöglich macht.

Einstellungen:

Activity Name: „Check Ticket Status“
Count Column Name: „Status_Check_Count“
Concatenate Attributes: (keine ausgewählt)
Must Follow Directly: Aktiviert

Ausgabe: Aufeinanderfolgende Statusprüfungen werden zu einzelnen Ereignissen zusammengefasst. Ein Fall mit 50 Statusprüfungen zwischen „Send Email to Customer“ und „Customer Response Received“ zeigt nun nur noch eine „Check Ticket Status“-Aktivität mit Status_Check_Count = 50.

Erkenntnisse: Analysten sehen jetzt den tatsächlichen Kundeninteraktionsfluss ohne das Störgeräusch automatisierter Abfragen. Die Anzahl der Statusprüfungen zeigt, wie lange Tickets typischerweise auf eine Kundenreaktion warten, was mit Bearbeitungszeiten und Kundenzufriedenheit korreliert werden kann.

Beispiel 3: Nachprüfungen bei der Qualitätskontrolle in der Fertigung

Szenario: In einem pharmazeutischen Fertigungsprozess führen Qualitätssicherungsfehler bis zu 3 unmittelbare Nachprüfungen aus, bevor die Charge verworfen wird. Das Unternehmen möchte nachvollziehen, wie viele Nachprüfungen stattfinden, dabei aber reine Prozessabläufe zur Analyse behalten.

Einstellungen:

Activity Name: „Quality Inspection“
Count Column Name: „Inspection_Attempts“
Concatenate Attributes: „Inspector_ID“, „Test_Results“, „Failure_Reason“
Must Follow Directly: Aktiviert

Ausgabe: Mehrere aufeinanderfolgende Qualitätskontrollen werden mit vollständigen Auditinformationen zusammengefasst:

Inspection_Attempts: Anzahl der Inspektionen der Charge (1-4)
Inspector_ID verkettet: „INSP_001, INSP_001, INSP_002“ (zeigt verschiedene Prüfer)
Test_Results verkettet: „FAIL, FAIL, PASS“ (zeigt den Verlauf)
Failure_Reason verkettet: „pH out of range, pH out of range, “ (zeigt Fehlerursachen)

Erkenntnisse: Das Unternehmen kann Erstraten (Inspection_Attempts = 1) und Nacharbeitsraten (Inspection_Attempts > 1) analysieren und dabei die lückenlose Rückverfolgbarkeit gewährleisten, wer geprüft hat und warum Tests fehlschlugen.

Beispiel 4: IT-Support-Ticket-Weiterleitungen

Szenario: Ein IT-Helpdesk hat das Problem, dass Support-Tickets mehrfach zwischen Agenten weitergeleitet werden, bevor sie gelöst werden. Jede Weiterleitung erzeugt eine „Reassign Ticket“-Aktivität, was die Analyse der eigentlichen Lösungsschritte erschwert.

Einstellungen:

Activity Name: „Reassign Ticket“
Count Column Name: „Reassignment_Count“
Concatenate Attributes: „Assigned_To“, „Reassignment_Reason“
Must Follow Directly: Aktiviert

Ausgabe: Mehrere aufeinanderfolgende Weiterleitungen werden zusammengefasst:

Reassignment_Count: Gesamtzahl der Weiterleitungen (zeigt Ticket-Pingpong)
Assigned_To verkettet: „Agent_A, Agent_B, Agent_C, Agent_D“ (zeigt Eskalationsverlauf)
Reassignment_Reason verkettet: „Wrong department, Requires senior agent, Requires system admin“ (zeigt Gründe)

Erkenntnisse: Hohe Weiterleitungszahlen deuten auf schlechte anfängliche Ticketzuteilung oder unklare Verantwortlichkeiten hin. Die verketteten Agentennamen zeigen häufige Eskalationsmuster und helfen bei der Optimierung von Verteilungsregeln.

Beispiel 5: Überarbeitungszyklen im Dokumentenfreigabe-Workflow

Szenario: Ein Dokumentenmanagementsystem erlaubt es Prüfern, Dokumente mehrfach zur Überarbeitung zurückzusenden. Die Organisation möchte die Überarbeitungszyklen verfolgen und gleichzeitig die Prozesskarten auf den Genehmigungsworkflow fokussieren.

Einstellungen:

Activity Name: „Request Revisions“
Count Column Name: „Revision_Cycles“
Concatenate Attributes: „Reviewer_Comments“
Must Follow Directly: Aktiviert

Ausgabe: Aufeinanderfolgende Überarbeitungsanforderungen werden zusammengefasst:

Revision_Cycles: Anzahl der Zurücksetzungen des Dokuments (Qualitätsindikator)
Reviewer_Comments verkettet: „Fix formatting, Update references, Correct calculations“ (volle Feedback-Historie)

Erkenntnisse: Dokumente mit vielen Überarbeitungszyklen deuten auf unklare Anforderungen oder unzureichende Initialprüfungen hin. Die verketteten Kommentare liefern eine vollständige Nachverfolgbarkeit des Prüfprozesses und halten die Prozesskarte sauber und analysierbar.

Ausgabe

Die Bereicherung „Wiederholte Aktivitäten entfernen“ verändert Ihr Ereignisprotokoll auf zwei wesentliche Arten:

Ereignisreduktion: Aufeinanderfolgende Vorkommnisse der ausgewählten Aktivität werden zu einem einzigen Ereignis zusammengefasst. Die Bereicherung behält das erste Vorkommnis und blendet alle weiteren Wiederholungen aus, wodurch die Gesamtzahl der Ereignisse in Ihrem Datensatz reduziert wird. Diese Konsolidierung erfolgt auf Fall-Ebene, sodass unterschiedliche Fälle je nach Wiederholungsmustern eine unterschiedliche Anzahl an entfernten Ereignissen aufweisen.

Neues Zählattribut: Es wird ein neues ganzzahliges Ereignisattribut mit dem in „Count Column Name“ angegebenen Namen erstellt. Dieses Attribut wird im konsolidierten Ereignis mit der Gesamtanzahl der zusammengefassten Vorkommnisse gefüllt. Bei Ereignissen ohne Wiederholung beträgt der Wert 1. Bei konsolidierten Ereignissen gibt der Wert an, wie oft die Aktivität nacheinander auftrat (z. B. 4 bedeutet, die Aktivität erfolgte 4 Mal hintereinander).

Verkettete Attributwerte: Wenn Sie Attribute zur Verkettung ausgewählt haben, werden die Werte aller wiederholten Ereignisse zu einem einzigen kommaseparierten String zusammengefasst und im konsolidierten Ereignis gespeichert. Dies bewahrt wichtige Kontextinformationen, die sich zwischen Wiederholungen unterscheiden können, wie Fehlermeldungen, Benutzer-IDs oder Zeitstempel. Die Verkettung erfolgt in chronologischer Reihenfolge, sodass Sie die Entwicklung der Werte über die Wiederholungen hinweg nachvollziehen können.

Auswirkung auf die Prozessansicht: Nach Anwendung dieser Bereicherung zeigen Ihre Prozesskarten und Varianten vereinfachte Abläufe ohne die wiederholenden Schleifen durch identische aufeinanderfolgende Aktivitäten. Fälle, die vorher „A -> B -> B -> B -> C“ zeigten, erscheinen nun als „A -> B -> C“, wodurch die Kernstruktur des Prozesses leichter erkennbar wird. Gleichzeitig behalten Sie die Möglichkeit, Wiederholungsmuster über das Zählattribut in Filtern und Kalkulatoren zu analysieren.

Verwendung des Zählattributs: Das neue Zählattribut kann verwendet werden in:

Filtern: „Zeige nur Fälle, bei denen Payment_Retry_Count > 3 ist“, um problematische Zahlungsvorgänge zu identifizieren
Kalkulatoren: Durchschnitt oder Summe der Zählwerte über Fälle hinweg zur Messung der Gesamtrate von Wiederholungen
Leistungsanalyse: Korrelation hoher Werte mit längeren Bearbeitungszeiten
Qualitätsmetriken: Erfassung von Erfolgsraten im ersten Durchlauf, indem Events mit count = 1 gezählt werden
Visualisierungen: Erstellung von Histogrammen für die Verteilung der Wiederholungsversuche

Datenintegrität: Die Bereicherung gewährleistet vollständige Datenintegrität durch Beibehaltung der Zeitstempelinformation (Verwendung des Zeitstempels des ersten Vorkommnisses) und ermöglicht die Verkettung wichtiger Attributwerte. Es werden keine Daten dauerhaft gelöscht; wiederholte Ereignisse werden als ausgeblendet markiert und können bei Bedarf durch Entfernung der Bereicherung wieder sichtbar gemacht werden.

Diese Dokumentation ist Teil der mindzieStudio Prozess-Mining-Plattform.