Entity Builder: Erstelle deinen digitalen Zwilling

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 Feature

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.

Use Cases

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:

• Daten-De-Fragmentierung: Im Gegensatz zu anderen Tools ist es uns egal, wie viele Systeme die Quelldaten verteilen – wir können nahtlos Verbindungen zwischen den Systemen herstellen, als wäre die gesamte Landschaft ein einziges System.
• Data Science: Technisch gesehen ist Process Mining nur ein Anwendungsfall, der auf die Daten im Entity Graph angewendet wird. Deshalb haben wir ein Jupyter Notebook-gesteuertes Workbench in die Anwendung eingebettet – so kannst du alle Data Science-Auswertungen durchführen, die du für deinen spezifischen Use Case und Kontext auf dem von dir konfigurierten Entity Graph benötigst.
• Segmentierung von Expertenbedürfnissen: Der oben beschriebene Prozess ist natürlich ziemlich technisch und erfordert jemanden, der die Quell-Datenbankstrukturen versteht. Wir haben jedoch genau diese technische Komplexität nur auf die Konfiguration des Entity Graphs beschränkt. Nach diesem Schritt erfordert der Rest unserer Anwendung höchstens einen Process Analyst, wenn nicht sogar einfach nur jemanden, der ein gutes Verständnis dafür hat, wie Geschäftsprozesse ablaufen.

Denkanstöße

Während du diese Informationen verarbeitest, überlege dir die folgenden weiterführenden Fragen:

• Wie getrennt sind unsere Datenquellen? Ist traditionelles Process Mining mit meinen Daten möglich? Kann ich von diesem Multi-Source-Ansatz in mehr als nur Process Mining profitieren?
• Was ist eine schlanke Initialkonfiguration des Entity Graphs, die meinem Use Case zugutekommt? Die erste Iteration muss nicht das vollständige Netzwerk deiner gesamten Organisation abbilden. Wie viel müssen wir tun, um die ersten wertvollen Ergebnisse zu erzielen?
• Welche Kontextdaten würden deine Entscheidungsfindung beeinflussen, wenn sie verfügbar wären? Wir können Verbindungen zwischen jedem einzelnen Datenpunkt in deiner Organisation und jedem anderen herstellen, ohne die typische AI Black-Box. Würde es dir helfen, den Stahlpreisindex zum Zeitpunkt einer bestimmten Lieferantenbestellung zu kennen?

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?