Attribut-Aktivitäts-Matrix
Übersicht
Der Attribut-Aktivitäts-Matrix-Rechner bietet eine umfassende Kreuztabelle, die die Beziehung zwischen Attributen und Aktivitäten in Ihrem Ereignisprotokoll darstellt. Für jede Kombination aus Attribut und Aktivität zeigt er die Anzahl der Fälle an, bei denen Werte vorliegen. Dies hilft Administratoren, Muster der Datenvollständigkeit zu verstehen und Datenqualitätsprobleme zu identifizieren.
WICHTIG: Dies ist ein Rechner ausschließlich für Administratoren, der für technische Analysen und die Bewertung der Datenqualität konzipiert ist. Er erzeugt eine Matrix, die zeigt, wie Attribute über verschiedene Aktivitäten hinweg befüllt werden, was für das Verständnis von Datenextraktionsmustern, das Erkennen fehlender Daten und die Validierung der Ereignisprotokollstruktur unerlässlich ist.
Dieser Rechner wird hauptsächlich von Systemadministratoren und Datenqualitätsfachleuten genutzt, die Attribut-Besetzungsmuster über Prozessaktivitäten hinweg für Fehlerbehebung, Validierung oder Optimierung von Datensätzen verstehen müssen.
Häufige Anwendungsfälle
- Ermitteln, welche Aktivitäten bestimmte Attribute befüllen, um den Datenfluss im Prozess zu verstehen
- Fehlende Attributwerte für bestimmte Aktivitäten feststellen, die Daten enthalten sollten
- Validieren, dass kritische Attribute an den erwarteten Prozessphasen befüllt sind
- Datenextraktionsprobleme diagnostizieren, indem systematische Lücken bei der Attributbefüllung aufgedeckt werden
- Attributabhängigkeiten von bestimmten Aktivitäten für das ETL-Design verstehen
- Dokumentieren, welche Aktivitäten Daten zu welchen Attributen beitragen für technische Spezifikationen
Einstellungen
Dieser Rechner erfordert keine spezifischen Konfigurationseinstellungen. Beim Ausführen wird automatisch eine Matrix erzeugt, die alle Attribute (sowohl auf Fall- als auch auf Ereignisebene) gegenüber allen Aktivitäten darstellt, wobei die Zellenwerte die Anzahl der Fälle zeigen, bei denen das Attribut für die jeweilige Aktivität einen Wert hat.
Hinweis: Für Datensätze mit vielen Attributen und Aktivitäten kann diese Matrix sehr groß werden. Der Rechner zeigt die vollständige Matrix an, für deren Überprüfung ggf. gescrollt werden muss.
Beispiele
Beispiel 1: Validierung der Vollständigkeit von Genehmigungsdaten
Szenario: Sie haben ein neues System zur Genehmigungsverfolgung implementiert und möchten prüfen, ob genehmigungsbezogene Attribute in jeder Genehmigungsphase Ihres Bestellprozesses korrekt befüllt werden.
Einstellungen:
- Titel: "Analyse der Befüllung von Genehmigungsattributen"
- Beschreibung: "Validierung der Erfassung von Genehmigungsdaten im P2P-Prozess"
Ausgabe:
Der Rechner zeigt eine Matrix mit Aktivitäten als Spalten und Attributen als Zeilen. Für die genehmigungsbezogenen Attribute sehen Sie:
| Attribut | PO erstellen | Zur Genehmigung einreichen | L1 Genehmigung | L2 Genehmigung | Finanzfreigabe | An Lieferanten senden |
|---|---|---|---|---|---|---|
| ApproverName | 0 | 0 | 1.847 | 456 | 234 | 0 |
| ApprovalLevel | 0 | 0 | 1.847 | 456 | 234 | 0 |
| ApprovalTimestamp | 0 | 0 | 1.847 | 456 | 234 | 0 |
| ApprovalComments | 0 | 0 | 1.523 | 398 | 189 | 0 |
| DelegatedBy | 0 | 0 | 234 | 67 | 23 | 0 |
Erkenntnisse: Die Matrix bestätigt, dass Genehmigungsattribute nur während der Genehmigungsaktivitäten (L1, L2 und Finanzfreigabe) korrekt befüllt sind, während sie bei anderen Aktivitäten erwartungsgemäß auf null stehen. Alle 1.847 Fälle, die die L1-Genehmigung erreichen, haben ApproverName, ApprovalLevel und ApprovalTimestamp befüllt, was eine vollständige Datenerfassung anzeigt. ApprovalComments weist eine geringere Befüllung (1.523 Fälle statt 1.847 bei L1) auf, was bedeutet, dass 324 Fälle keine Kommentare zur Genehmigung enthalten – dies kann akzeptabel sein, wenn Kommentare optional sind, sollte aber überprüft werden. Das Attribut DelegatedBy erscheint nur bei einem Teil der Genehmigungen und erfasst korrekt Delegationsszenarien.
Beispiel 2: Identifizierung von Datenextraktionslücken
Szenario: Nachdem Sie Daten aus mehreren Quellsystemen in Ihrem Order-to-Cash-Prozess zusammengeführt haben, vermuten Sie, dass einige Attribute nicht durchgängig für alle erwarteten Aktivitäten befüllt werden.
Einstellungen:
- Titel: "Überprüfung der Datenvollständigkeit aus mehreren Quellen"
- Beschreibung: "Validierung der Attributbefüllung aus CRM-, ERP- und Versandssystemen"
Ausgabe:
| Attribut | Bestellung erstellen | Kreditprüfung | Artikel picken | Artikel verpacken | Versand | Rechnung erstellen | Zahlung empfangen |
|---|---|---|---|---|---|---|---|
| CustomerName | 2.456 | 2.456 | 2.456 | 2.456 | 2.456 | 2.456 | 2.456 |
| CreditScore | 2.456 | 2.456 | 2.456 | 2.456 | 2.456 | 2.456 | 2.456 |
| WarehouseLocation | 0 | 0 | 2.456 | 2.456 | 2.456 | 0 | 0 |
| CarrierName | 0 | 0 | 0 | 0 | 2.456 | 0 | 0 |
| TrackingNumber | 0 | 0 | 0 | 0 | 2.234 | 0 | 0 |
| InvoiceAmount | 0 | 0 | 0 | 0 | 0 | 2.456 | 2.456 |
| PaymentMethod | 0 | 0 | 0 | 0 | 0 | 0 | 1.987 |
Erkenntnisse: Die Matrix zeigt mehrere Datenqualitätsprobleme. CustomerName und CreditScore sind Attributen auf Fallebene (über alle Aktivitäten für alle Fälle befüllt), was erwartungsgemäß ist. WarehouseLocation taucht korrekt nur bei Warenlageraktivitäten (Pick, Pack, Ship) auf. TrackingNumber zeigt an der Versandaktivität nur 2.234 Fälle statt der erwarteten 2.456, was bedeutet, dass 222 Sendungen keine Sendungsverfolgungsnummer besitzen – eine kritische Lücke, die untersucht werden muss. PaymentMethod zeigt nur 1.987 Fälle bei Zahlung empfangen statt der erwarteten 2.456, was darauf hinweist, dass bei 469 Zahlungen die Zahlungsmethode fehlt, was auf ein Integrationsproblem mit dem Zahlungssystem hindeutet.
Beispiel 3: Verständnis des Attribut-Lebenszyklus
Szenario: Sie müssen dokumentieren, wann bestimmte Attribute im Lebenszyklus des Prozesses verfügbar werden, um nachgelagerte Analysen und Berichtserstellung zu steuern.
Einstellungen:
- Titel: "Dokumentation des Attribut-Lebenszyklus"
- Beschreibung: "Mapping, wann jedes Attribut in der Rechnungsverarbeitung befüllt wird"
Ausgabe:
| Attribut | Rechnung empfangen | Rechnung validieren | PO zuordnen | Zahlung genehmigen | Zahlung planen | Zahlung ausführen | Fall schließen |
|---|---|---|---|---|---|---|---|
| InvoiceNumber | 3.456 | 3.456 | 3.456 | 3.456 | 3.456 | 3.456 | 3.456 |
| VendorID | 3.456 | 3.456 | 3.456 | 3.456 | 3.456 | 3.456 | 3.456 |
| PONumber | 0 | 0 | 3.456 | 3.456 | 3.456 | 3.456 | 3.456 |
| MatchStatus | 0 | 0 | 3.456 | 3.456 | 3.456 | 3.456 | 3.456 |
| ApprovedAmount | 0 | 0 | 0 | 3.456 | 3.456 | 3.456 | 3.456 |
| PaymentDate | 0 | 0 | 0 | 0 | 3.456 | 3.456 | 3.456 |
| ActualPaymentDate | 0 | 0 | 0 | 0 | 0 | 3.456 | 3.456 |
| ClosureReason | 0 | 0 | 0 | 0 | 0 | 0 | 3.456 |
Erkenntnisse: Diese Matrix zeigt klar den Attribut-Lebenszyklus. InvoiceNumber und VendorID werden von Anfang an befüllt (Fallattribute beim Rechnungseingang). PONumber und MatchStatus werden erst nach der PO-Zuordnung verfügbar, sind somit für frühere Prozessphasen nicht verfügbar. ApprovedAmount erscheint bei Zahlung genehmigen und bleibt für nachfolgende Aktivitäten erhalten. PaymentDate (geplantes Datum) erscheint bei Zahlung planen, ActualPaymentDate nur bei Zahlung ausführen, wodurch geplante und tatsächliche Daten unterschieden werden. ClosureReason wird ausschließlich in der letzten Aktivität befüllt. Dieses Verständnis des Lebenszyklus ist essentiell für die Gestaltung attributabhängiger Analysen.
Beispiel 4: Erkennen systematischer Datenqualitätsprobleme
Szenario: Benutzer berichten von uneinheitlicher Datenverfügbarkeit in Analysen. Sie müssen feststellen, ob bestimmte Aktivitäten systematisch erwartete Attribute nicht befüllen.
Einstellungen:
- Titel: "Analyse systematischer Datenlücken"
- Beschreibung: "Identifizierung von Aktivitäten mit fehlender Attributbefüllung"
Ausgabe:
| Attribut | Anfrage prüfen | Ressource zuweisen | Arbeit starten | Qualitätsprüfung | Arbeit abschließen | Ergebnisse dokumentieren |
|---|---|---|---|---|---|---|
| RequestID | 5.678 | 5.678 | 5.678 | 5.678 | 5.678 | 5.678 |
| AssignedTo | 0 | 5.678 | 5.678 | 5.678 | 5.678 | 5.678 |
| WorkCategory | 0 | 5.678 | 5.678 | 5.678 | 5.678 | 5.678 |
| StartTime | 0 | 0 | 5.678 | 5.678 | 5.678 | 5.678 |
| QualityScore | 0 | 0 | 0 | 4.234 | 4.234 | 4.234 |
| CompletionNotes | 0 | 0 | 0 | 0 | 5.678 | 5.678 |
| DocumentationLink | 0 | 0 | 0 | 0 | 0 | 3.456 |
Erkenntnisse: Die Matrix zeigt ein kritisches Datenqualitätsproblem. QualityScore sollte bei Qualitätsprüfungen für alle Fälle (5.678) befüllt sein, aber nur 4.234 Fälle enthalten es, was bedeutet, dass 1.444 Fälle (25 %) Bewertungsnoten fehlen. Dies ist eine systematische Lücke, die auf Probleme bei der Qualitätsprüfung oder Datenextraktion hinweisen könnte. Außerdem fehlt DocumentationLink in 2.222 Fällen (39 %) beim Dokumentieren der Ergebnisse, was darauf hindeutet, dass die Dokumentation bei einem erheblichen Teil der Arbeiten ausgelassen wird. Diese systematischen Lücken erfordern sofortige Aufmerksamkeit zur Sicherstellung der Datenintegrität.
Beispiel 5: Validierung der Multi-System-Integration
Szenario: Ihr Prozess integriert Daten aus drei verschiedenen Systemen (CRM, ERP und Logistik), und Sie müssen prüfen, ob Attribute aus jedem System korrekt den entsprechenden Aktivitäten zugeordnet sind.
Einstellungen:
- Titel: "Validierung der Multi-System-Integration"
- Beschreibung: "Prüfung der Attributbefüllung aus CRM-, ERP- und Logistiksystemen"
Ausgabe:
| Attribut | Bestellung eingeben (CRM) | Bestand reservieren (ERP) | Bestand zuordnen (ERP) | Versand (Logistik) | Zustellung (Logistik) | Empfang bestätigen (CRM) |
|---|---|---|---|---|---|---|
| CustomerID (CRM) | 8.945 | 8.945 | 8.945 | 8.945 | 8.945 | 8.945 |
| SalesRepID (CRM) | 8.945 | 8.945 | 8.945 | 8.945 | 8.945 | 8.945 |
| SKU (ERP) | 8.945 | 8.945 | 8.945 | 8.945 | 8.945 | 8.945 |
| InventoryLocation (ERP) | 0 | 8.945 | 8.945 | 8.945 | 8.945 | 8.945 |
| StockLevel (ERP) | 0 | 8.945 | 8.945 | 8.945 | 8.945 | 8.945 |
| CarrierID (Logistik) | 0 | 0 | 0 | 8.945 | 8.945 | 8.945 |
| DeliveryStatus (Logistik) | 0 | 0 | 0 | 8.945 | 8.945 | 8.945 |
| ReceivedBy (CRM) | 0 | 0 | 0 | 0 | 0 | 7.234 |
Erkenntnisse: Die Matrix bestätigt, dass die meisten Systemintegrationen korrekt funktionieren. CRM-Attribute (CustomerID, SalesRepID) sind erwartungsgemäß während des gesamten Prozesses als Fallattribute verfügbar. ERP-Attribute (InventoryLocation, StockLevel) erscheinen korrekt ab der Aktivität Bestand reservieren. Logistik-Attribute (CarrierID, DeliveryStatus) tauchen ab Versand auf. Es gibt jedoch ein signifikantes Problem mit dem Attribut ReceivedBy – nur 7.234 von 8.945 Fällen haben dieses bei Empfang bestätigen befüllt, 1.711 Lieferungen (19 %) fehlen die Empfangsbestätigungen. Dies erfordert eine Untersuchung des CRM-Bestätigungsworkflows.
Beispiel 6: Planung einer Attributanreicherungsstrategie
Szenario: Sie möchten ermitteln, welche Attribute spärlich befüllt sind und von einer Anreicherung mit Referenzdaten oder verbesserten Erfassungsvorgängen profitieren könnten.
Einstellungen:
- Titel: "Analyse von Anreicherungsmöglichkeiten für Attribute"
- Beschreibung: "Ermittlung spärlicher Attribute, die eine Anreicherung benötigen"
Ausgabe:
| Attribut | Antrag einreichen | Dokumente prüfen | Schaden bewerten | Betrag genehmigen | Zahlung ausstellen | Antrag schließen |
|---|---|---|---|---|---|---|
| ClaimNumber | 12.456 | 12.456 | 12.456 | 12.456 | 12.456 | 12.456 |
| PolicyNumber | 12.456 | 12.456 | 12.456 | 12.456 | 12.456 | 12.456 |
| AdjusterID | 0 | 12.456 | 12.456 | 12.456 | 12.456 | 12.456 |
| AdjusterName | 0 | 0 | 0 | 0 | 0 | 0 |
| DamageCategory | 0 | 0 | 12.456 | 12.456 | 12.456 | 12.456 |
| EstimatedCost | 0 | 0 | 12.456 | 12.456 | 12.456 | 12.456 |
| ApprovalReason | 0 | 0 | 0 | 12.456 | 12.456 | 12.456 |
| PaymentMethodCode | 0 | 0 | 0 | 0 | 12.456 | 12.456 |
| PaymentMethodName | 0 | 0 | 0 | 0 | 0 | 0 |
Erkenntnisse: Die Matrix zeigt ausgezeichnete Möglichkeiten zur Anreicherung. AdjusterID wird bei allen Fällen ab Prüfung der Dokumente befüllt (12.456 Fälle), aber AdjusterName nie. Die Ergänzung von AdjusterID mit Namen aus einer Mitarbeiter-Tabelle würde Analysen benutzerfreundlicher machen. Ebenso ist PaymentMethodCode bei allen Zahlungen vorhanden (12.456 Fälle), während PaymentMethodName fehlt. Eine Anreicherung der Zahlungscodes mit beschreibenden Namen würde die Berichtserstellung deutlich lesbarer machen. Diese Ergänzungen würden einen erheblichen Wert mit minimalem Aufwand bieten, da die Referenz-IDs bereits vorliegen.
Ausgabe
Der Attribut-Aktivitäts-Matrix-Rechner zeigt eine umfassende Matrix-Tabelle mit folgender Struktur an:
Zeilen: Jede Zeile repräsentiert ein Attribut aus Ihrem Ereignisprotokoll, einschließlich Fall-Attribute (gelten für den gesamten Fall) und Ereignis-Attribute (variieren möglicherweise je Aktivität).
Spalten: Jede Spalte repräsentiert eine eindeutige Aktivität aus Ihrem Prozess.
Zellenwerte: Jede Zelle enthält eine Zahl, die angibt, wie viele Fälle für dieses Attribut bei dieser Aktivität einen Wert haben. Ein Wert von 0 bedeutet, dass das Attribut bei keiner Fall-Aktivitäts-Kombination befüllt ist.
Verständnis der Zellenwerte
Fallbezogene Attribute: Für fallbezogene Attribute (z. B. CustomerID, OrderNumber) ist der Zellenwert über alle Aktivitäten derselbe und zeigt die Gesamtzahl der Fälle mit Wert an.
Ereignisbezogene Attribute: Für ereignisbezogene Attribute (z. B. ApproverName, WarehouseLocation) variieren die Zellenwerte je nach Aktivität und zeigen, wo im Prozess das Attribut befüllt wird.
Nullwerte: Ein Wert von 0 zeigt an, dass das Attribut bei dieser Aktivität nie befüllt wird; dies kann erwartetes Verhalten sein oder ein Anzeichen für ein Datenqualitätsproblem, abhängig vom Prozess.
Interaktive Funktionen
Sortieren und Filtern: Klicken Sie auf die Spaltenüberschriften, um die Matrix nach Aktivitäten zu sortieren. Nutzen Sie die Browsersuche, um spezifische Attribute schnell zu finden.
Ergebnisse exportieren: Exportieren Sie die komplette Matrix nach Excel oder CSV für eine detaillierte Offline-Analyse, Dokumentation oder zum Teilen mit technischen Teams.
Große Matrizen: Bei Prozessen mit vielen Aktivitäten und Attributen kann die Matrix sehr groß sein. Verwenden Sie horizontales und vertikales Scrollen, um die gesamte Matrix zu durchsuchen.
Interpretation der Befüllungsmuster
Konsistente Befüllung: Wenn ein Attribut über alle Aktivitäten denselben Nicht-Null-Wert zeigt, handelt es sich um ein fallbezogenes Attribut, das früh im Prozess befüllt wird.
Progressive Befüllung: Wenn ein Attribut bei frühen Aktivitäten Null zeigt und erst bei späteren Aktivitäten Werte, wird das Attribut an einer bestimmten Prozessphase befüllt.
Teilweise Befüllung: Wenn die Werte kleiner als die Gesamtzahl der Fälle sind, fehlen bei einigen Fällen Attributwerte, was auf Datenqualitätsprobleme oder optionale Felder hinweisen kann.
Aktivitätsspezifische Befüllung: Wenn ein Attribut nur bei bestimmten Aktivitäten Werte zeigt, ist es ein ereignisbezogenes Attribut, das nur für diese Aktivitäten relevant ist.
Performanceüberlegungen
- Große Datensätze: Für Datensätze mit Hunderten von Attributen und Aktivitäten kann die Verarbeitung dieses Rechners viel Zeit benötigen
- Ressourcennutzung: Der Rechner prüft alle Attribut-Aktivitäts-Kombinationen, was rechenintensiv ist
- Beste Praxis: Führen Sie diesen Rechner bei sehr großen Datensätzen vorzugsweise außerhalb der Hauptarbeitszeiten aus
Administrativer Zugriff
Dieser Rechner ist auf Benutzer mit Administratorrolle beschränkt. Normale Benutzer, die Dataset-Charakteristika verstehen möchten, sollten stattdessen den Dataset-Informationen-Rechner verwenden, der Zusammenfassungsmetriken ohne detaillierte Attribut-Aktivitäts-Aufschlüsselung bietet.
Diese Dokumentation ist Teil der mindzie Studio Process-Mining-Plattform.