Ereigniszählung

Überblick

Die Ereigniszählung ist ein grundlegender Statistikoperator, der die Anzahl der Ereignisse innerhalb jedes Falls in Ihrem Prozessdatensatz zählt. Diese Anreicherung liefert wichtige Kennzahlen zum Verständnis der Fallkomplexität, Prozessvariationen und der Arbeitslastverteilung in Ihren Geschäftsprozessen. Im Unterschied zur einfachen Fallzählung zählt dieser Operator die einzelnen Aktivitäten oder Ereignisse, die jeden Fall ausmachen, und bietet so Einblicke in die Fallgranularität und Prozessintensität.

Die Ereigniszählung wird besonders leistungsfähig, wenn sie mit Filtern kombiniert wird, die es ermöglichen, nur bestimmte Ereignistypen oder Aktivitäten, die definierte Kriterien erfüllen, zu zählen. Beispielsweise können Sie nur manuelle Aktivitäten, Systemereignisse oder Aktivitäten zählen, die von bestimmten Ressourcen ausgeführt werden. Diese gezielte Zählung ermöglicht eine differenzierte Analyse der Prozessverhaltenmuster und hilft dabei, Fälle zu identifizieren, die von normalen Ereignisfrequenzverteilungen abweichen.

Häufige Anwendungen

  • Analyse der Prozesskomplexität: Messen Sie die Komplexität einzelner Fälle, indem Sie deren Gesamtanzahl an Ereignissen zählen
  • Arbeitslastbewertung: Identifizieren Sie Fälle mit ungewöhnlich hohen oder niedrigen Ereigniszahlen, um die Arbeitslastverteilung zu verstehen
  • Qualitätskontrolle: Zählen Sie Inspektions- oder Überprüfungsereignisse, um die Einhaltung von Qualitätsstandards sicherzustellen
  • Automatisierungspotenziale: Zählen Sie manuelle gegenüber automatisierten Ereignissen, um Automatisierungsmöglichkeiten zu erkennen
  • Leistungsbenchmarking: Vergleichen Sie Ereigniszahlen über unterschiedliche Falltypen, Regionen oder Zeiträume hinweg
  • Ausnahmeerkennung: Identifizieren Sie Ausreißerfälle mit abnormalen Ereignishäufigkeiten, die auf Prozessprobleme hinweisen können
  • Ressourcenplanung: Verstehen Sie Ereignisvolumen zur besseren Zuweisung von Ressourcen und Kapazitäten

Einstellungen

Filter: Optionale Filterkonfiguration, mit der Sie nur bestimmte Ereignisse zählen können, die definierte Kriterien erfüllen. Wenn kein Filter gesetzt ist, werden alle Ereignisse in jedem Fall gezählt. Verwenden Sie Filter, um Ereignisse basierend auf Aktivitätsnamen, Zeitstempeln, Ressourcen oder anderen Ereignisattributen zu zählen. Diese Einstellung ermöglicht gezielte Analysen, etwa das Zählen nur manueller Aktivitäten, Fehlerereignisse oder Aktivitäten, die während bestimmter Schichten ausgeführt werden.

Neuer Attributname: Der Name des neuen Fallattributs, das den Ereigniszählwert speichern wird. Dieses Attribut wird Ihrer Faltabelle als Integer-Feld hinzugefügt. Wählen Sie einen beschreibenden Namen, der klar angibt, welche Ereignisse gezählt werden, insbesondere bei Verwendung von Filtern. Zum Beispiel "Total_Event_Count" für alle Ereignisse, "Manual_Activity_Count" für gefilterte manuelle Aktivitäten oder "Error_Event_Count" für fehlerbezogene Ereignisse.

Beispiele

Beispiel 1: Gesamte Ereigniszählung bei Bestellungen

Szenario: Ein Beschaffungsteam möchte die Komplexität ihrer Bestellprozesse verstehen, indem es die Gesamtzahl der Ereignisse in jedem Fall zählt, um zu identifizieren, welche Bestellungen den größten Verarbeitungsaufwand erfordern.

Einstellungen:

  • Filter: Keiner (alle Ereignisse zählen)
  • Neuer Attributname: Total_PO_Events

Ausgabe: Die Anreicherung erstellt ein neues Fallattribut "Total_PO_Events" mit ganzzahligen Werten:

  • Standardbestellungen: 8-12 Ereignisse (Erstellen, Freigeben, An Vendor senden, Wareneingang, Rechnung, Zahlung)
  • Komplexe Bestellungen: 25-40 Ereignisse (mehrfache Freigaben, Änderungsanforderungen, Teillieferungen, Streitfälle)
  • Eilbestellungen: 5-7 Ereignisse (strafferer Prozess mit weniger Schritten)

Erkenntnisse: Die Analyse zeigt, dass 15 % der Bestellungen mehr als 25 Ereignisse haben, was auf komplexe Verarbeitung hinweist. Diese Fälle mit hoher Ereignisanzahl korrelieren mit Bestellungen, die mehrere Verhandlungsrunden mit Lieferanten und Eskalationen der Freigabe erfordern, was auf Optimierungsmöglichkeiten im Prozess hinweist.

Beispiel 2: Manuelle Aktivitäten bei Versicherungsansprüchen

Szenario: Ein Versicherungsunternehmen möchte den manuellen Aufwand bei der Bearbeitung von Ansprüchen messen, indem nur Aktivitäten gezählt werden, die von menschlichen Agenten ausgeführt wurden, automatisierte Systemereignisse werden ausgeschlossen.

Einstellungen:

  • Filter: Activity Type equals "Manual" OR Resource Not equals "System"
  • Neuer Attributname: Manual_Activity_Count

Ausgabe: Die Anreicherung erzeugt "Manual_Activity_Count" mit Werten, die menschliche Bearbeitungsschritte darstellen:

  • Auto-freigegebene Ansprüche: 2-3 manuelle Aktivitäten (Erstprüfung, Endfreigabe)
  • Standardansprüche: 6-10 manuelle Aktivitäten (Prüfung, Untersuchung, Anpassung, Freigabe)
  • Komplexe Ansprüche: 15-25 manuelle Aktivitäten (mehrfache Überprüfungen, Felduntersuchungen, Verhandlungen)
  • Betrugsfälle: 30+ manuelle Aktivitäten (umfangreiche Untersuchungs- und Kontrollzyklen)

Erkenntnisse: Ansprüche mit mehr als 20 manuellen Aktivitäten verursachen dreimal längere Bearbeitungszeiten und doppelt so hohe Kosten. Der Einsatz automatisierter Dokumentenprüfung könnte bei Standardansprüchen manuelle Aktivitäten um 40 % reduzieren.

Beispiel 3: Fehlerereignisse in der Fertigung

Szenario: Ein Fertigungswerk möchte Qualitätskontrollfehler und Fehlerereignisse in ihrem Produktionsprozess zählen, um problematische Produktionsläufe zu erkennen, die besondere Aufmerksamkeit erfordern.

Einstellungen:

  • Filter: Activity enthält "Error" OR Activity enthält "Reject" OR Activity enthält "Rework"
  • Neuer Attributname: Quality_Issue_Count

Ausgabe: Die Anreicherung erzeugt "Quality_Issue_Count", das die Fehlerhäufigkeit je Produktionscharge anzeigt:

  • Hochwertige Chargen: 0-1 Fehlerereignisse
  • Standardchargen: 2-4 Fehlerereignisse (geringe Nachjustierungen)
  • Problematische Chargen: 8-15 Fehlerereignisse (mehrfache Qualitätsprobleme)
  • Fehlgeschlagene Chargen: 20+ Fehlerereignisse (umfangreicher Nacharbeitungsbedarf)

Erkenntnisse: Chargen mit mehr als 10 Fehlerereignissen korrelieren zu 90 % mit bestimmten Maschinen oder Schichtmustern. Frühe Eingriffe, wenn die Fehlerzahl 5 überschreitet, verhindern 60 % der gesamten Chargenfehler.

Beispiel 4: Kundeninteraktionszählung im Service Desk

Szenario: Ein Service Desk möchte die Intensität der Kundeninteraktion messen, indem alle Ereignisse gezählt werden, bei denen Kunden direkt mit dem Supportsystem interagieren, interne Verarbeitungsschritte werden ausgeschlossen.

Einstellungen:

  • Filter: Resource enthält "Customer" OR Activity enthält "Customer" OR Activity in ["Email Received", "Chat Started", "Call Logged", "Feedback Submitted"]
  • Neuer Attributname: Customer_Touch_Points

Ausgabe: Erzeugt das Attribut "Customer_Touch_Points" mit Interaktionszahlen:

  • Self-Service-Lösung: 1-2 Interaktionen (nur Anfangsanfrage)
  • Standard-Support: 3-5 Interaktionen (Anfrage, Klärung, Bestätigung der Lösung)
  • Eskalierte Fälle: 8-12 Interaktionen (mehrfache Nachfragen und Klärungen)
  • Kritische Vorfälle: 15+ Interaktionen (kontinuierliche Updates und Kommunikation)

Erkenntnisse: Tickets mit mehr als 8 Kundeninteraktionen weisen um 70 % niedrigere Zufriedenheitswerte auf. Proaktive Kommunikation nach 5 Interaktionen reduziert die Gesamtkontaktanzahl um 30 % und erhöht die Zufriedenheit.

Beispiel 5: Compliance-Prüfungen bei Finanztransaktionen

Szenario: Eine Bank muss die Zahl der Compliance- und Verifizierungsaktivitäten pro Transaktion zählen, um regulatorische Anforderungen einzuhalten und Transaktionen zu identifizieren, die eine verstärkte Prüfung erfordern.

Einstellungen:

  • Filter: Activity Type equals "Compliance" OR Activity enthält "Verify" OR Activity enthält "AML" OR Activity enthält "KYC"
  • Neuer Attributname: Compliance_Check_Count

Ausgabe: Die Anreicherung erzeugt "Compliance_Check_Count" mit Zählungen von Verifizierungsaktivitäten:

  • Standardtransaktionen: 2-3 Compliance-Prüfungen (grundlegendes AML, Sanktionsprüfung)
  • Hochwertige Transaktionen: 5-8 Compliance-Prüfungen (erweiterte Prüfung)
  • Internationale Überweisungen: 10-15 Compliance-Prüfungen (ländertypische Verifizierungen)
  • Markierte Transaktionen: 20+ Compliance-Prüfungen (vollständiges Untersuchungsprotokoll)

Erkenntnisse: Transaktionen mit weniger als 2 Compliance-Prüfungen bergen regulatorische Risiken. Transaktionen mit über 15 Prüfungen haben eine 5-fach längere Bearbeitungszeit, führen aber nur zu 2 % tatsächlichen Compliance-Problemen, was auf Überprüfung in bestimmten Fällen hinweist.

Ausgabe

Die Ereigniszählung erzeugt ein einzelnes neues ganzzahliges Attribut in Ihrer Faltabelle, das die Anzahl der Ereignisse pro Fall enthält. Das Attribut speichert ganze Zahlen, die die Gesamtanzahl der Ereignisse repräsentieren, die Ihren Filterkriterien entsprechen (oder alle Ereignisse, wenn kein Filter gesetzt ist). Dieses Attribut hat den Datentyp Int32 und das Anzeigeformat Zahl, um in Analysen und Dashboards eine korrekte numerische Darstellung zu gewährleisten.

Das neue Attribut kann sofort verwendet werden für:

  • Filter: Erstellen von Fallfiltern basierend auf Ereigniszählern (z. B. „Fälle mit hoher Komplexität“, wenn Ereigniszähler > 20)
  • Berechnungen: Verwendung der Zählwerte in mathematischen Ausdrücken, Mittelwerten oder statistischen Berechnungen
  • Kategorisierungen: Gruppierung von Fällen in Komplexitätskategorien basierend auf Ereignisschwellen
  • Visualisierungen: Anzeige von Ereigniszählverteilungen in Histogrammen, Boxplots oder Heatmaps
  • Korrelationen: Analyse von Zusammenhängen zwischen Ereigniszahlen und anderen Fallattributen wie Dauer, Kosten oder Ergebnis
  • Alarme: Einrichten von Überwachungsregeln basierend auf ungewöhnlichen Ereigniszählmustern

Das Ereigniszählattribut lässt sich nahtlos in andere mindzieStudio-Funktionen integrieren und ermöglicht die Kombination mit Dauermessungen, Kostenanalysen und Leistungskennzahlen für umfassende Prozessintelligenz.

Siehe auch

  • [[Count Activities]]: Zählt bestimmte Aktivitäten nach Name innerhalb jedes Falls
  • [[Case Duration]]: Berechnet zeitbasierte Kennzahlen, die häufig mit Ereigniszählungen korrelieren
  • [[Representative Case Attribute]]: Bestimmt die häufigsten Muster bei Fällen mit hoher oder niedriger Ereigniszählung
  • [[Filter Cases]]: Verwendet Ereigniszählungen zum Filtern und Segmentieren Ihrer Prozessdaten
  • [[Categorize Attribute Values]]: Erstellt Kategorien für Ereigniszählwerte (niedrige/mittlere/hohe Komplexität)

Diese Dokumentation ist Teil der mindzie Studio Process Mining Plattform.