Good morning, folks! Another month, another feature highlight! The die-hard readers will know that we talked about our Causal Process Mining approach in our technical whitepaper a few months ago. Now, I’d finally like to present the Entity Graph Builder.
To quickly recap – instead of a traditional event log, Noreja creates a digital twin of the data in your organization. This includes Activities and other process objects, but also any peripheral data that we need, such as employees, locations and even external price indices. We call this structure the Entity Graph, and it allows us to do truly full-context process mining and root cause analysis, accounting for all context factors. Let’s dive into how it works by looking at how we can configure an Entity Graph for our usual test dataset – the Quote-to-Order process.
This is the Entity Graph list. Here, you can see every Entity Graph that you’ve built using Noreja and which data sources it feeds itself from. Every Entity Graph can have multiple Sources, which lets you pull data from multiple fragmented systems, drawing an end-to-end chain throughout your data landscape. For this Example, we’ve kept it simple and configured one Graph per source.
Opening the Builder for our typical RS2-based Dataset, we’re met first with the Data Object selector. For people more technically-versed, these are for example relational database tables; for the rest, this represents how data is structured in the source system. Since, ideally, we connect directly to the source systems, we often get more than we strictly need or recommend for adding to the Entity Graph, so here we select just the tables that we need for our use-case, which is, for now, just mapping the Quote-to-Order dimension.
Going into the model building step, we are faced with a canvas where we can start constructing the scaffolding of our Entity Graph. From the left-hand side, we can pull in data objects that we selected in the previous step, and then draw connections between them. In effect, what we’re doing here is telling Noreja which identifiers map the meaningful connections between the objects – if the Order ID is what maps one object to another, that’s what we tell it to look for. It’s a little tricky at first, but user tests have shown us that it doesn’t take long to start thinking in data with this approach.
Going into the configuration for an Activity – remember, this is one type of Entity we can have in our Graph, but also the most important for our Use-Case, since it’s what our Dimensions will consist of – we find a few things we can do. First, we can give it a meaningful name. V_RECH probably doesn’t tell us much about the activity unless we’re database admins, but “Rechnung versenden”, German for Send Invoice, does. Second, we can set the timestamp location, where Noreja finds the when of each instance of the activity.
Then, we can also tell Noreja which context data, which we refer to here as Properties, it should take with it when pulling data from the sources – in this way, we minimize complexity, because not all of our context data might need its own object. Finally, we can add custom SQL queries to specialize the activity to a specific subset of the data in the source object, or to add more context data from other tables via JOINs.
Phew, this was a lot in one go! Don’t worry, though, we’re nearly done.
Finally, we see the full configuration for a simple Entity Graph focused on the Quote-to-Order use-case. The important thing to note here is – we don’t need a direct connection between two objects to map their “belonging together.” Noreja is designed to crawl over the entire daisy chain to find these connections, should they exist. Thus every single object in this network can find its unique relationships to every single other object.
The idea here is that this network will grow over time as you find more data that you want to analyze in your organization. We refer to this as process mining maturity – how much of your organization’s landscape you’ve digitalized and made available for process mining. Start simple, like this, and then expand as you go. And don’t worry, we also have a full suite of validations and support tools to make sure you know exactly when something doesn’t work as intended – we’ve just already gone over the word count budget for this article, so I can’t go through them in detail now.
The Entity Builder is a powerful tool, but by itself it’s first and foremost an enabler feature that allows the rest of our technology to function seamlessly. Nevertheless, our particular approach offers a few key use-cases and benefits:
As you digest this information, consider asking yourself the following follow-up questions:
Reflecting on these questions can help you better align the capabilities of the Entity Graph Builder with your organizational goals and challenges. It’s not just about the tools you use, but how you leverage them to drive meaningful improvements and strategic advantage. If this sounds interesting to you – reach out and book a free demo with us. We look forward to hearing about your specific challenges!
Did you know that you can subscribe our LinkedIn newsletter here in order to get the latest updates directly via Email?