Guten Morgen, Leute! Ein weiterer Monat, ein weiteres Feature-Highlight! Die eingefleischten Leser werden wissen, dass wir vor ein paar Monaten in unserem technischen Whitepaper über unseren Causal Process Mining-Ansatz gesprochen haben. Jetzt möchte ich euch endlich den Entity Graph Builder vorstellen.
Um kurz zusammenzufassen – anstelle eines traditionellen Event Logs erstellt Noreja einen digitalen Zwilling der Daten in deiner Organisation. Das umfasst Aktivitäten und andere Prozessobjekte, aber auch alle peripheren Daten, die wir benötigen, wie Mitarbeiter, Standorte und sogar externe Preisindizes. Diese Struktur nennen wir den Entity Graph, und sie ermöglicht es uns, echtes Full-Context Process Mining und Root Cause Analysis durchzuführen, indem alle Kontextfaktoren berücksichtigt werden. Schauen wir uns an, wie das funktioniert, indem wir ein Entity Graph für unser übliches Testdatenset, den Quote-to-Order-Prozess, konfigurieren.
Das hier ist die Entity Graph-Liste. Hier siehst du jeden Entity Graph, den du mit Noreja erstellt hast, und aus welchen Datenquellen er gespeist wird. Jeder Entity Graph kann mehrere Quellen haben, was dir ermöglicht, Daten aus verschiedenen fragmentierten Systemen zu ziehen und eine End-to-End-Kette durch deine Datenlandschaft zu ziehen. Für dieses Beispiel haben wir es einfach gehalten und einen Graph pro Quelle konfiguriert.
Öffnen wir den Builder für unser typisches, auf RS2 basierendes Datenset, treffen wir zuerst auf den Data Object-Selektor. Für die technisch Versierten unter uns handelt es sich hierbei beispielsweise um relationale Datenbanktabellen; für den Rest stellt dies dar, wie Daten im Quellsystem strukturiert sind. Da wir idealerweise direkt an die Quellsysteme anbinden, erhalten wir oft mehr Daten, als wir tatsächlich benötigen oder empfehlen, dem Entity Graph hinzuzufügen. Hier wählen wir also nur die Tabellen aus, die wir für unseren Use Case brauchen, was in diesem Fall nur die Zuordnung der Quote-to-Order-Dimension ist.
Im Modellierungsschritt angekommen, haben wir eine Leinwand vor uns, auf der wir anfangen können, das Gerüst unseres Entity Graph zu erstellen. Auf der linken Seite können wir die Datenobjekte, die wir im vorherigen Schritt ausgewählt haben, hineinziehen und dann Verbindungen zwischen ihnen ziehen. Im Wesentlichen sagen wir Noreja hiermit, welche Identifikatoren die bedeutungsvollen Verbindungen zwischen den Objekten abbilden – wenn die Bestell-ID das ist, was ein Objekt mit einem anderen verbindet, geben wir dies hier an. Das ist anfangs etwas knifflig, aber Usability-Tests haben gezeigt, dass es nicht lange dauert, bis man anfängt, in Daten zu denken, wenn man diesen Ansatz verfolgt.
Bei der Konfiguration einer Aktivität – denkt daran, das ist eine Art von Entity, die wir in unserem Graph haben können, und die wichtigste für unseren Use Case, da sie unsere Dimensionen bildet – finden wir einige Dinge, die wir tun können. Zunächst können wir ihr einen sinnvollen Namen geben. V_RECH sagt uns wahrscheinlich nicht viel über die Aktivität, es sei denn, wir sind Datenbank-Admins, aber „Rechnung versenden“ schon eher. Zweitens können wir den Timestamp-Standort festlegen, an dem Noreja das Wann jeder Instanz der Aktivität findet.
Dann können wir Noreja auch mitteilen, welche Kontextdaten, die wir hier als Properties bezeichnen, es beim Abrufen der Daten aus den Quellen mitnehmen soll – so minimieren wir die Komplexität, da nicht alle unsere Kontextdaten ein eigenes Objekt benötigen. Schließlich können wir benutzerdefinierte SQL-Abfragen hinzufügen, um die Aktivität auf einen bestimmten Datenbereich im Quellobjekt zu spezialisieren oder um über JOINs zusätzliche Kontextdaten aus anderen Tabellen hinzuzufügen.
Puh, das war eine Menge auf einmal! Keine Sorge, wir sind fast fertig.
Abschließend sehen wir die vollständige Konfiguration eines einfachen Entity Graph, der auf den Quote-to-Order-Use Case fokussiert ist. Das Wichtige hier ist – wir benötigen keine direkte Verbindung zwischen zwei Objekten, um ihre „Zusammengehörigkeit“ abzubilden. Noreja ist darauf ausgelegt, die gesamte Daisy-Chain zu durchforsten, um diese Verbindungen zu finden, falls sie existieren. So kann jedes einzelne Objekt in diesem Netzwerk seine einzigartigen Beziehungen zu jedem anderen Objekt finden.
Die Idee dahinter ist, dass dieses Netzwerk im Laufe der Zeit wächst, wenn du mehr Daten findest, die du in deiner Organisation analysieren möchtest. Wir nennen dies Process Mining Maturity – wie viel deiner Organisationslandschaft du digitalisiert und für das Process Mining verfügbar gemacht hast. Starte einfach, wie hier, und erweitere es nach und nach. Und keine Sorge, wir haben auch eine komplette Suite an Validierungen und Support-Tools, damit du genau weißt, wann etwas nicht wie beabsichtigt funktioniert – wir haben nur bereits das Wortlimit für diesen Artikel überschritten, daher kann ich nicht im Detail darauf eingehen.
Der Entity Builder ist ein mächtiges Werkzeug, aber für sich genommen ist es zunächst und vor allem ein Enabler-Feature, das es der restlichen Technologie ermöglicht, nahtlos zu funktionieren. Trotzdem bietet unser spezieller Ansatz einige wichtige Anwendungsfälle und Vorteile:
Während du diese Informationen verarbeitest, überlege dir die folgenden weiterführenden Fragen:
Das Nachdenken über diese Fragen kann dir helfen, die Fähigkeiten des Entity Graph Builders besser mit den Zielen und Herausforderungen deiner Organisation in Einklang zu bringen. Es geht nicht nur um die Tools, die du verwendest, sondern darum, wie du sie einsetzt, um sinnvolle Verbesserungen und strategische Vorteile zu erzielen. Wenn das für dich interessant klingt – melde dich und buche eine kostenlose Demo bei uns. Wir freuen uns darauf, von deinen spezifischen Herausforderungen zu hören!
Wusstest du, dass man unseren LinkedIn-Newsletter hier abonnieren kann, um die neuesten Updates direkt per E-Mail zu erhalten?