Dauer Zwischen Zwei Ereignisattributen

Überblick

Das Enrichment "Dauer Zwischen Zwei Ereignisattributen" berechnet die Zeitdifferenz zwischen zwei Zeitstempel- oder Zeitspanenfeldern innerhalb desselben Ereignisdatensatzes. Dieses leistungsstarke Enrichment ermöglicht es Ihnen, die verstrichene Zeit zwischen zusammenhängenden temporalen Datenpunkten zu messen, die auf einzelnen Ereignissen vorhanden sind, wie zum Beispiel die Zeit zwischen einem geplanten Termin und dem tatsächlichen Eintreffen oder zwischen Antragseinreichung und Genehmigung innerhalb eines einzelnen Transaktionsdatensatzes.

Im Gegensatz zu Enrichments, die die Dauer über verschiedene Ereignisse in einem Fall messen, arbeitet dieser Operator ausschließlich auf Ereignisebene, indem er zwei Datums-/Zeit- oder Zeitspenenattribute vergleicht, die bereits auf jedem Ereignis vorhanden sind. Dies macht ihn besonders wertvoll für die Analyse von Verzögerungen, Durchlaufzeiten und Bearbeitungszeiten, bei denen sowohl der Start- als auch der Endzeitstempel als separate Felder in Ihrem Quellsystem erfasst werden. Das Enrichment unterstützt sowohl DateTime- als auch TimeSpan-Attributtypen und bietet maximale Flexibilität für unterschiedliche Zeit-Szenarien.

Das Enrichment erzeugt ein neues ereignisebenes TimeSpan-Attribut, das die berechnete Dauer enthält, welche dann in Filtern, Visualisierungen und Leistungsanalysen verwendet werden kann, um Engpässe zu identifizieren, die Einhaltung von Service-Level-Agreements zu messen und Zeitabweichungen über Ihre Prozessinstanzen hinweg zu verstehen. Die Berechnung erfolgt als (Attribute Last - Attribute First), was sowohl positive Dauern (wenn Ereignisse verspätet ablaufen) als auch negative Dauern (wenn Ereignisse frühzeitig abgeschlossen oder vorzeitig eintreffen) ermöglicht.

Häufige Anwendungsfälle

  • Berechnung der Verspätung eines Termins durch Messung der Zeit zwischen geplantem Termin und tatsächlicher Patientenankunft in Gesundheitsprozessen
  • Messung der Bearbeitungszeit einer Genehmigung durch Vergleich des Zeitstempels der Antragseinreichung mit dem Genehmigungszeitstempel im selben Transaktionsdatensatz
  • Verfolgung von Versandverzögerungen durch Berechnung der Differenz zwischen zugesagtem Lieferdatum und tatsächlichem Lieferdatum
  • Analyse der Reaktionszeit durch Messung der Dauer zwischen Kundenanfrage-Zeitstempel und erstem Antwort-Zeitstempel
  • Bewertung der Termineinhaltung durch Vergleich der geplanten Startzeit mit der tatsächlichen Startzeit von Wartungsarbeiten
  • Messung der Verarbeitungseffizienz durch Berechnung der Zeit zwischen Dokumenteneingang und Abschluss der Verarbeitung
  • Überwachung der SLA-Einhaltung durch Messung der Zeit zwischen Ticketerstellung und erster Antwort in Support-Ticket-Datensätzen
  • Verfolgung von Fertigungsplanabweichungen durch Vergleich von geplanten und tatsächlichen Produktionsstartzeiten

Einstellungen

Neuer Attributname: Der Name des neuen Ereignisattributs, das die berechnete Zeitdifferenz speichert. Dieses Attribut wird als TimeSpan-Datentyp erstellt und erscheint in Ihrer Ereignistabelle neben anderen Ereignisattributen. Wählen Sie einen beschreibenden Namen, der klar angibt, welche Dauer gemessen wird, wie z.B. "Genehmigungsverzögerung", "Lieferabweichung" oder "Verarbeitungszeit". Der Attributname sollte den Namenskonventionen Ihrer Organisation entsprechen und in Filtern und Visualisierungen aussagekräftig sein. Dieses Feld akzeptiert jeden gültigen Attributnamen und wird zum Bezeichner für den Zugriff auf die berechnete Dauer in nachfolgenden Analyse-Schritten.

Attributname First: Das Ereignisattribut, das den früheren Zeitstempel in der Dauermessung enthält. Dies muss ein vorhandenes DateTime- oder TimeSpan-Attribut in Ihrer Ereignistabelle sein. Das Enrichment verwendet dieses als Startpunkt für die Dauermessung. Beispielsweise wäre bei der Messung von Terminfverspätungen dies das Feld "Geplanter Termin". Die Dropdown-Liste filtert automatisch und zeigt nur gültige DateTime- und TimeSpan-Attribute aus Ihrer Ereignistabelle an, wobei berechnete und versteckte Attribute ausgeschlossen sind. So können Sie nur geeignete zeitliche Daten für die Berechnung auswählen.

Attributname Last: Das Ereignisattribut, das den späteren Zeitstempel in der Dauermessung enthält. Dies muss ein vorhandenes DateTime- oder TimeSpan-Attribut in Ihrer Ereignistabelle sein. Das Enrichment verwendet dieses als Endpunkt für die Dauermessung. Zum Beispiel wäre bei der Messung von Terminverzögerungen dies das Feld "Tatsächliche Ankunftszeit". Die Berechnung erfolgt als (Attributname Last - Attributname First), daher stellen Sie sicher, dass Sie hier den chronologisch späteren Wert auswählen. Positive Ergebnisse zeigen an, dass der zweite Zeitstempel nach dem ersten liegt (Verzögerung oder Dauer), während negative Ergebnisse anzeigen, dass der zweite Zeitstempel vor dem ersten liegt (frühzeitiger Abschluss).

Beispiele

Beispiel 1: Analyse der Verspätung bei Arztterminen

Szenario: Eine medizinische Klinik möchte Patiententerminverspätungen messen, indem geplante Termine mit tatsächlichen Ankunftszeiten verglichen werden. Beide Zeitstempel werden im Terminsystem als separate Felder bei jedem Terminereignis erfasst. Das Verständnis dieser Verspätungen hilft, die Terminplanung zu optimieren und die Patientenzufriedenheit zu verbessern.

Einstellungen:

  • Neuer Attributname: Appointment Delay
  • Attributname First: Scheduled Time
  • Attributname Last: Actual Arrival Time

Ausgabe: Das Enrichment erstellt ein neues Ereignisattribut namens "Appointment Delay", das TimeSpan-Werte enthält, die die Differenz zwischen geplantem und tatsächlichem Zeitpunkt darstellen:

  • Ereignisse mit frühzeitig ankommenden Patienten haben negative Dauern (z.B. -00:15:00 für 15 Minuten zu früh)
  • Ereignisse mit pünktlichen Patienten haben null oder nahe null Dauern (z.B. 00:02:00 für 2 Minuten verspätet)
  • Ereignisse mit verspäteten Patienten haben positive Dauern (z.B. 00:45:00 für 45 Minuten verspätet)

Beispieldaten: | Patient ID | Scheduled Time | Actual Arrival Time | Appointment Delay | |------------|----------------|---------------------|-------------------| | P-1001 | 2024-01-15 09:00 | 2024-01-15 09:12 | 00:12:00 | | P-1002 | 2024-01-15 10:30 | 2024-01-15 10:25 | -00:05:00 | | P-1003 | 2024-01-15 14:00 | 2024-01-15 14:38 | 00:38:00 |

Erkenntnisse: Die Klinik stellte fest, dass 35 % der Patienten für Nachmittagstermine mehr als 15 Minuten zu spät kommen, was zu kaskadierenden Verzögerungen im Zeitplan führt. Sie passten ihren Planungsalgorithmus an, um Pufferzeiten zwischen den Nachmittagsterminen hinzuzufügen, was die Wartezeiten um 22 % reduzierte.

Beispiel 2: Durchlaufzeit bei Bestellgenehmigungen

Szenario: Die Einkaufsabteilung muss die Zeit zwischen Einreichung einer Bestellung und deren Genehmigung messen. Beide Zeitstempel sind im ERP-System als separate Felder in jedem Bestellauftrag vorhanden. Die Nachverfolgung dieser Durchlaufzeit hilft, Genehmigungsengpässe zu erkennen und rechtzeitige Einkaufsentscheidungen sicherzustellen.

Einstellungen:

  • Neuer Attributname: Approval Turnaround Time
  • Attributname First: Submission DateTime
  • Attributname Last: Approval DateTime

Ausgabe: Ein neues Ereignisattribut "Approval Turnaround Time" zeigt die verstrichene Zeit für jede Bestellgenehmigung:

  • Schnelle Genehmigungen: 00:15:30 (15 Minuten 30 Sekunden)
  • Standardgenehmigungen: 1.08:20:00 (1 Tag, 8 Stunden, 20 Minuten)
  • Verzögerte Genehmigungen: 5.14:30:00 (5 Tage, 14 Stunden, 30 Minuten)

Beispieldaten: | PO Number | Amount | Submission DateTime | Approval DateTime | Approval Turnaround Time | |-----------|--------|---------------------|-------------------|--------------------------| | PO-8821 | $450 | 2024-02-10 08:30 | 2024-02-10 09:15 | 00:45:00 | | PO-8822 | $15,200 | 2024-02-10 10:00 | 2024-02-12 14:30 | 2.04:30:00 | | PO-8823 | $89,500 | 2024-02-10 11:20 | 2024-02-16 09:45 | 5.22:25:00 |

Erkenntnisse: Die Analyse ergab, dass Bestellungen über 50.000 \(im Durchschnitt 4,5 Tage für die Genehmigung benötigen, während Bestellungen unter 1.000\) in weniger als 2 Stunden genehmigt werden. Das Unternehmen implementierte automatisierte Genehmigungs-Workflows für geringwertige Einkäufe und reduzierte die Gesamtgenehmigungszeit um 40 %.

Beispiel 3: Einhaltung des Fertigungsplans

Szenario: Ein Fertigungswerk verfolgt geplante Startzeiten im Vergleich zu tatsächlichen Startzeiten von Produktionsläufen. Jede Produktionsauftragsnummer hat sowohl eine geplante Startzeit als auch eine tatsächliche Startzeit, die im MES (Manufacturing Execution System) erfasst sind. Die Messung dieser Abweichung hilft, die Genauigkeit der Planung und die Effektivität der Kapazitätsplanung zu bewerten.

Einstellungen:

  • Neuer Attributname: Start Time Variance
  • Attributname First: Planned Start Time
  • Attributname Last: Actual Start Time

Ausgabe: Das Attribut "Start Time Variance" zeigt an, ob Produktionsläufe früh (negativ), pünktlich (nahe null) oder spät (positiv) gestartet wurden:

  • Frühe Starts deuten auf verfügbare Kapazität oder Planungsspielraum hin
  • Späte Starts weisen auf Planungsprobleme oder Verzögerungen im Vorgang hin
  • Konsistente Muster helfen, die Produktionsplanung zu optimieren

Beispieldaten: | Work Order | Product Line | Planned Start Time | Actual Start Time | Start Time Variance | |------------|--------------|-------------------|-------------------|---------------------| | WO-5501 | Line A | 2024-03-05 06:00 | 2024-03-05 06:00 | 00:00:00 | | WO-5502 | Line B | 2024-03-05 08:00 | 2024-03-05 09:45 | 01:45:00 | | WO-5503 | Line C | 2024-03-05 12:00 | 2024-03-05 11:50 | -00:10:00 |

Erkenntnisse: Die Anlage stellte fest, dass Linie B aufgrund verlängerter Rüstzeiten in der vorherigen Schicht regelmäßig 1–2 Stunden später startet. Durch parallele Rüstprozesse konnte die mittlere Startzeitabweichung von 90 auf 15 Minuten reduziert werden, wodurch die tägliche Produktionskapazität um 8 % stieg.

Beispiel 4: Reaktionszeit im Kundensupport

Szenario: Eine Kundensupportorganisation muss messen, wie schnell Agenten auf eingehende Tickets erstmals antworten. Ihr Ticketsystem erfasst sowohl den Zeitpunkt der Ticketerstellung als auch den der ersten Antwort als separate Felder. Die Überwachung dieser Reaktionszeit ist entscheidend für die SLA-Einhaltung und Kundenzufriedenheit.

Einstellungen:

  • Neuer Attributname: First Response Time
  • Attributname First: Ticket Created DateTime
  • Attributname Last: First Response DateTime

Ausgabe: Das Enrichment erzeugt ein Attribut "First Response Time", das die verstrichene Zeit bis zur ersten Antwort für jedes Ticket zeigt:

  • Hervorragende Reaktion: 00:08:30 (8 Minuten 30 Sekunden)
  • SLA-Erfüllung: 00:55:20 (55 Minuten 20 Sekunden)
  • SLA-Verstoß: 02:15:45 (2 Stunden 15 Minuten 45 Sekunden)

Beispieldaten: | Ticket ID | Priority | Created DateTime | First Response DateTime | First Response Time | |-----------|----------|------------------|-------------------------|---------------------| | TKT-9001 | High | 2024-04-12 10:22 | 2024-04-12 10:30 | 00:08:00 | | TKT-9002 | Medium | 2024-04-12 11:15 | 2024-04-12 12:05 | 00:50:00 | | TKT-9003 | Low | 2024-04-12 14:30 | 2024-04-12 16:55 | 02:25:00 |

Erkenntnisse: Das Support-Team stellte fest, dass hoch priorisierte Tickets durchschnittlich 12 Minuten bis zur ersten Antwort benötigen, was innerhalb der 30-minütigen SLA liegt, während mittel priorisierte Tickets mit 75 Minuten das 60-minütige Ziel überschreiten. Die Arbeitsabläufe und Personalbesetzung wurden angepasst, um mittel priorisierte Tickets zu priorisieren, wodurch die SLA-Einhaltung von 78 % auf 94 % verbessert wurde.

Beispiel 5: Logistik Lieferperformance

Szenario: Ein Logistikunternehmen muss die Lieferperformance analysieren, indem zugesagte Liefertermine mit den tatsächlichen Lieferdaten verglichen werden. Beide Daten werden im Sendungsverfolgungssystem bei Auftragserstellung und Lieferbestätigung erfasst. Das Verständnis der Lieferabweichungen hilft, Spediteurleistungen zu bewerten und Kundenerwartungen zu verbessern.

Einstellungen:

  • Neuer Attributname: Delivery Variance
  • Attributname First: Promised Delivery Date
  • Attributname Last: Actual Delivery Date

Ausgabe: Das Attribut "Delivery Variance" zeigt an, ob Lieferungen früh (negativ), pünktlich (null oder kleine positive Werte) oder spät (positiv) waren:

  • Frühe Lieferungen: -1.00:00:00 (1 Tag zu früh)
  • Pünktliche Lieferungen: 00:00:00 bis 04:00:00 (pünktlich bis 4 Stunden verspätet)
  • Verspätete Lieferungen: 2.08:30:00 (2 Tage, 8 Stunden, 30 Minuten verspätet)

Beispieldaten: | Shipment ID | Carrier | Promised Delivery | Actual Delivery | Delivery Variance | |-------------|---------|------------------|-----------------|-------------------| | SHP-7701 | FastShip | 2024-05-20 17:00 | 2024-05-20 15:30 | -01:30:00 | | SHP-7702 | QuickCargo | 2024-05-21 12:00 | 2024-05-21 11:45 | -00:15:00 | | SHP-7703 | StandardPost | 2024-05-22 10:00 | 2024-05-24 14:20 | 2.04:20:00 |

Erkenntnisse: Die Analyse zeigte, dass 18 % der Lieferungen mehr als 1 Tag verspätet waren, wobei StandardPost 65 % dieser Verzögerungen ausmacht. Das Unternehmen verhandelte neue Service-Level mit den Spediteuren und implementierte einen dynamischen Spediteursauswahl-Algorithmus basierend auf der historischen Leistung, wodurch verspätete Lieferungen von 18 % auf 7 % reduziert und die Kundenzufriedenheit um 15 Punkte gesteigert wurde.

Ausgabe

Das Enrichment "Dauer Zwischen Zwei Ereignisattributen" erzeugt ein einziges neues ereignisebenes Attribut mit folgenden Eigenschaften:

Datentyp: TimeSpan – Das neue Attribut speichert Dauern im TimeSpan-Format, das die Zeitdifferenz zwischen den zwei ausgewählten Attributen darstellt. TimeSpan-Werte können positiv (wenn der zweite Zeitstempel später ist), negativ (wenn der zweite Zeitstempel früher ist) oder null (wenn beide Zeitstempel identisch sind) sein.

Attributort: Das neue Attribut wird der Ereignistabelle hinzugefügt und erscheint neben anderen Ereignisattributen in Ihrem Datensatz. Es ist als abgeleitetes Attribut gekennzeichnet und wird in Ereignisfiltern, Attributlisten und kann mit statistischen Enrichments auch auf Fall-Ebene aggregiert werden.

Berechnungsmethode: Für jedes Ereignis berechnet das Enrichment: (Attributname Last - Attributname First). Wenn eines der Quellattribute für ein bestimmtes Ereignis null oder nicht vorhanden ist, bleibt das neue Attribut für dieses Ereignis ebenfalls null, um die Datenintegrität zu gewährleisten und falsche Nullwerte zu vermeiden.

Anzeigeformat: Die TimeSpan-Werte werden im Standard-Dauerformat (Tage.Stunden:Minuten:Sekunden) angezeigt. Zum Beispiel:

  • 00:15:30 steht für 15 Minuten und 30 Sekunden
  • 1.08:20:00 steht für 1 Tag, 8 Stunden und 20 Minuten
  • -00:05:00 steht für negative 5 Minuten (frühere Ankunft)

Integration mit anderen Funktionen: Das berechnete Dauerattribut kann auf vielfältige Weise genutzt werden:

  • Ereignisfilter: Filterung von Ereignissen basierend auf Dauer-Schwellwerten (z. B. nur Ereignisse mit Antwortzeit über 1 Stunde anzeigen)
  • Fall-Aggregationen: Verwendung von Summe, Durchschnitt, Minimum oder Maximum, um Ereignisdauern auf Fall-Ebene zu aggregieren
  • Leistungsanalyse: Visualisierung von Dauerverteilungen in Diagrammen und Identifikation von Ausreißern
  • Rechner: Verweis auf die Dauer in benutzerdefinierten Berechnungen für komplexe Geschäftslogik
  • Konformitätsprüfung: Definition von Regelwerken basierend auf akzeptablen Dauern

Abhängigkeiten: Das Enrichment hängt von den zwei angegebenen Quellattributen ab. Werden diese Quellattribute umbenannt, verborgen oder aus dem Datensatz entfernt, muss das berechnete Dauerattribut neu konfiguriert werden oder wird ungültig. Das Enrichment überwacht diese Abhängigkeiten und warnt Benutzer bei Änderungen.

Leistungsaspekte: Dieses Enrichment führt für jedes Ereignis eine simple Subtraktion durch und hat minimalen Performance-Einfluss, selbst bei großen Datensätzen mit Millionen von Ereignissen. Die Berechnung wird einmalig beim Ausführen des Enrichments durchgeführt, und die Ergebnisse gespeichert, sodass nachfolgende Analyseoperationen auf die vorab berechneten Werte zugreifen, ohne Neuberechnung.

Siehe auch

Diese Dokumentation ist Teil der mindzie Studio Process Mining Plattform.