How do Event Graphs help analyzing Event Data over Multiple Entities?

Classical event logs have the fundamental shortcoming of describing process behavior only in isolated process executions from the viewpoint of a single case entity. Most real-life processes involve multiple entities and process executions are not isolated but tightly connected – through actors and entities involved in multiple executions. This post summarizes how event graphs are a better model to describe and query such dynamics. I explain the basic ideas and how to construct a graph from an ordinary event table. By Dirk Fahland.

Classical event logs – the basis for all process mining – use a case identifier attribute to study the behavior in a trace: group all events with the same case identifier value and order them by time. We then can study the temporal ordering of process activities along the sequence of events to get insights into the process. The most basic temporal relation is the directly-follows relation: in a trace <e1,e2,e3,e4,e5,…> event e4 directly follows event e3.

But most real-life event data has more than one case identifier attribute. This forces to either leave out events or directly-follows relations or to squeeze events under a case identifier where they don’t really belong.

Sequential Event Logs over Multiple Entities

Consider the event table shown below. It has the standard event log attributes: action, time(stamp), but lacks a case identifier column that is defined for every event.

Event Tables of IT Servicing Process

Most real-life event data is like this in their source system. The event data above most likely originates from three different tables

  • Component
  • Ticket with a foreign key to Component
  • Change with a foreign key to Component

Creating a classical event log that contains all the events is impossible – unless one is willing to accept false information such as event duplication, or false directly-follows relations. For example, if we engineered a case identifier that separates events according to the horizontal line in the above table,

  • there seems to be rework with Update twice in the second case while the Update events occur on two different Components thus only on Hotspot 36 the activity Update is repeated,
  • there seems to be an Update in the first case after Close Ticket already occurred
  • the Update event in Change C4 at 21-06-2020 11:10 would no longer directly follow the Update event in Change C4 at 20-06-2020 10:40.

All this together makes it hard to answer the following question: Which problems preceded (possibly caused) the final Update on Laptop 24?

In the following, we explain how a graph-based structure based on the concept of Labeled Property Graphs allows to naturally describe this data. With the graph-based model, we can avoid introducing false information and better answer questions like the cause for the final update on Laptop 24.

What is a labeled property graph?

A labeled property graph has nodes and edges (called relationships).

  • Each node has one or more Labels that give the node a type. We will use the labels Event and Entity to model events and entities.
  • Each edge (relationship) has a Label that semantics to the relation between nodes. We will use the labels DF (one Event node directly follows another Event node) and CORR (one Event node is correlated to a specific Entity node).
  • Each node and each relationship can have multiple properties (attribute-value pairs)

By using relationships between nodes in a graph, each Event can be correlated to multiple Entity node and each Event nodes can have multiple preceding and succeeding Event nodes (via DF) allowing model multiple DF-paths (one per entity).

Here is how you can construct such an event graph using these concepts.

Step 1: Import all events

Every event record in the input event table becomes an Event node. Every attribute of the event record becomes a property. We get the following graph of just Event nodes with properties.

Event Graph after importing event records into Event nodes

Step 2: identify and materialize entities

In classical event log construction, we now would pick a unique case identifier column.

In event graph construction, we now identify which attributes refer to entities – and there can be multiple in the data. We pick the ones we are interested in.

  • In our example, we pick Ticket, Component, Change as entity identifier attributes.
  • For each value of an entity identifier attribute, we create an Entity node of this type and id, and
  • For each Event node referring to this entity, we create a CORR edge (relationship) from the Event node to the corresponding Entity node.

This results in the following graph.

Event graph after adding Entity nodes with CORR relationships.

Note how most events are correlated to more than one entity.

Step 3: construct directly-follow edges per entity

In classical event logs, all events related to the same case identifier are ordered by time into a trace.

In an event graph, all events correlated to the same Entity node (via CORR edges) are ordered by time and we create a directly-follows DF edge between any two subsequent events. We store in the DF edge properties for which entity each DF edge holds. Doing this for the Entity node for Ticket = 11 results in the following graph.

Event graph after adding DF edges for Entity Ticket=11

We obtain a DF-path over three events from Problem Report via Investigate to Close Ticket. This DF-path states: “Entity Ticket=11 observed the sequence <Problem Report, Investigate, Close Ticket>”.

We have to do this for each Entity node for which we want to study behavior. The image below shows all resulting DF-paths over all events for all entities, but for readability we show only the CORR edge to the first event of a path.

Event graph after adding all DF-paths for all entities Ticket 11,12, and Component Laptop 24, Hotspot 36, Hotspot 36-2, and Change C2, C4

Done. This graph fully describes the behavioral information contained in the original event table using local DF-relations per entity.

What does the event graph show?

Looking at the DF-paths, we can directly see

  • We have 2 similar Ticket paths <Problem Report, Investigate, Close Ticket> and <Problem Report, Investigate, Investigate, Close Ticket>
  • We have 2 Change paths only involving Update events but differing in the number of Update events.
  • we have 3 separate Component paths following 3 completely different variants <Problem Reported, Investigate, Update, Update, Update>, <Problem Reported, Investigate, Update>, and <Update, Update, Investigate>

The striking difference in complexity of paths for the three different component types can be explained by the very different nature of the entities.

  • A Ticket is what is closest to a classical case entity describing a process execution for a relatively structured process, i.e., it captures the problem analysis process triggered by a user until the problem is solved.
  • A Component is not a typical case entity because it is a persistent object that exists beyond process executions. It typically comes back in many different process executions. Just our example is a bit too short to show another problem, say with Laptop 24. Also actors/resources fall into this category. As a result, their DF-paths will most likely follow more unique variants – requiring other kinds of analysis than typical process discovery.
  • A Change is a bit similar to a process execution entity, but a change behaves differently than a Ticket. It is more unstructured (various kinds of Update events further specified by the Note attribute).

We do see the different natures back in the way the different DF-paths synchronize in the graph.

  • A component is “visited” by Tickets and Changes at various points/moments, e.g., Hotspot 36-2 is first visited by Change and then by a Ticket, while Laptop 24 and Hotspot 36 are first visited by a Ticket followed by a Change.
  • A Ticket path (starting with Problem Reported) leads to a Change path starting two events later on the same Component.
  • Tickets can work on a single Component (11 -> Laptop 24) or on multiple Components (12 -> Hotspot 36, Hotspot 36-2).
  • While the first Change path (C2) only touches a single Component, the second Change path (C4) touches three different Components. Rework happens when a Change path touches the same Component multiple times (in this example even on 2 directly-following events).

There is more behavioral information that can be inferred in this graph, for example the dependency of Close Ticket for Ticket=12 on the final Update event of Laptop 24. Doing so requires to infer relationships between two Entity nodes and to materialize a relationship as a new derived Entity node, say between Ticket 12 and Laptop 24. We then can analyze the behavioral dependencies between two entities. How to do this is explained in this paper:

Can we query the graph?

Event graphs based on labeled property graphs can be stored in a graph database system such as neo4j, which allows to query the graph using a graph query language.

For example, if we want to answer our earlier question “Which problems preceded (possibly caused) the final Update on Laptop 24?” we can write the following Cypher query

(e1:Event {Action:”Problem Reported”})-[:DF*]->(e2:Event {Action:”Update”}),
(e1) -[:CORR]-> (t1:Entity {type:”Ticket”}),
(e1) -[:CORR]-> (c1:Entity {type:”Component”}),
(e2) -[:CORR]-> (c2:Entity {type:”Component”})


NOT EXISTS (e2) -[:DF]-> (:Event)

RETURN e1,e2,t1,c1,c2

This query matches a DF-path from a Problem Reported event e1 to an Update event e2 where e2 may not have any subsequent event (there is no outgoing DF relationship). It returns e1,e2 and the ticket t1 and component c1 correlated to e1 and the component c2 related to e2.

Applied on our example graph, it will return two matches as highlighted below: e1 matches once with Problem Reported for Ticket 11 and once with Problem Reported for Ticket 12.

Problem Reported events which are a possible cause for the final update event

Note that the first matching path only uses DF-edges of one entity (Laptop 24) while the second matching path uses DF-edges of two different Entities (Change C4 and Component 36).

The above query is very limited: it works only for one specific Update event, it does not return the actual paths, and it does not collect the different results. All of these limitations can be overcome by extending the Cypher query.

How can I get started? What else can I do?

The following open access paper

  • Defines the full model of event graphs. It gives precise semantics to the labels Event, Entity, DF, CORR (and several others).
  • Provides Cypher query templates to construct event graphs from ordinary event tables.
  • to query event graphs for behavioral properties and
  • to construct directly-follows models over multiple entities in a graph database.

A complete implementation for importing 5 public event logs into event graphs is available here:

Here are 5 fully prepared event graphs from 5 different public event logs, both as Neo4j database dump and as GraphML file to import and analyze.

This paper uses event graphs to identify task patterns in processes by analyzing how DF-paths along cases and DF-paths along resources synchronize.

This paper uses event graphs to model and analyze patient care pathways with multi-morbid patients.

Guide to Multi… Process Mining talks at ICPM 2021 workshops

Process Mining over multiple perspectives, dimensions, objects, entities, abstraction levels, etc. is gaining a lot of attention in the process mining field in 2021. If you want to learn more about the emerging topics in Multi… Process Mining, this short guide has you covered for the workshop day (1st Nov 2021) of the 3rd International Conference on Process Mining 2021 in Eindhoven By Dirk Fahland

I may have missed a talk. I made this overview is to the best of my understanding of the various announcements or prior knowledge on the presenters’ works. Let me know if I missed your talk that is also related to Multi… Process Mining.

The morning 9:00-10:15

ML4PM, 1st Nov 09:00 – 10:15

Mahsa Pourbafrani, Shreya Kar, Wil van der Aalst and Sebastian Kaiser. Remaining Time Prediction for Processes with Inter-Case Dynamics,

Andrea Chiorrini, Claudia Diamantini, Alex Mircoli and Domenico Potena. Exploiting Instance Graphs and Graph Neural Networks for next activity prediction,

PODS4H,, 1st Nov, 9:00-10:15

Verifying Guideline Compliance in Clinical Treatment using Multi-Perspective Conformance Checking: a Case Study.” By Joscha Grüger, Tobias Geyer, Martin Kuhn, Ralph Bergmann and Stephan Alexander Braun.

The morning 11:00-12:15

ML4PM, 1st Nov 11:00 – 12:15

Mahmoud Shoush and Marlon Dumas. Prescriptive Process Monitoring Under Resource Constraints: A Causal Inference Approach,

EdbA, 1st Nov, 11:00-12:15

Tobias Brockhoff, Merih Seran Uysal, Isabelle Terrier, Heiko Göhner and Wil van der Aalst. Analyzing Multi-level BOM-structured Event Data.

SA4PM 11:00-11:25

PErrCas: Process Error Cascade Mining in Trace Streams, Anna Wimbauer, Florian Richter, and Thomas Seidl,

PODS4H,, 1st Nov, 11:00-12:15

Discovering care pathways for multi-morbid patients using event graphs.” By Milad Naeimaei Aali, Felix Mannhardt and Pieter Jelle Toussaint.

The afternoon 14:00-15:00

PQMI2021,, 1st Nov, 14:00-15:00

Celonis PQL: A Query Language for Process Mining, Jessica Ambros

The afternoon 15:45-16:15

PQMI2021,, 1st Nov, 15:45-16:05

An Event Data Extraction Approach from SAP ERP for Process Mining, Alessandro Berti, Gyunam Park, Majid Rafiei and Wil van der Aalst,

EdbA, 1st Nov, 15:45 – 17:15

Plenary Workshop Discussion on behavioral analytics and event data beyond classical event logs.

The only problem with this fully packed workshop program is: it’s impossible to follow all talks as a single person.

There is a lot more on Multi… Process Mining coming on the other days of the conference in research, tool demos, the industry day l, the XES 2.0 workshop, and at the vendor booths.

Multi… Process Mining at ICPM 2020 shown by Industry

By Dirk Fahland.

Here is a list of activites by the Process Mining vendors at ICPM that I have seen in the program that – in my view – will have a relation or show use cases for Multi… Process Mining.

  • ABBYY, Thursday, October 8 – 12:30h: “Logistics – Application of process intelligence beyond one system of record”
  • Celonis, Thursday, October 8 – 13:00 “Language for Processes” (Celonis’ process query language inevitably will touch on looking beyond event data in a trace). 15:45h: “New Teaching Case Studies for Process Mining in Audit and Accounting”. Possibly also Celonis’ Process Query
  • EY, Thursday October 8 12:45 “Process Mining in auditing”, 16:15 “Working Capital Management” (repeated Firday October 9 twice)
  • MyInvenio, Presenting Multi-Level Process Mining throughout their product demos on 7th, 8th, and 9th October
  • UiPath, Thursday Oct 8 13:00-13:30 – Data Transformation & Connectors (data extraction and transformation from complex source systems for process analysis)
  • LanaLabs, Thursday Oct 8, 1.30pm – 1.50pm: Use Case P2P & LANA Connect (data extraction and transformation from complex source systems for process analysis) + Oct 9 on-demand Tool Demos.

It seems that Thursday 9th October 12:30-14:00 is high-noon for Multi…Process Mining of the process mining vendors at ICPM.

I may have missed some relevant events – if I did, let me know in the comments.

Artifact-Centric Process Mining for ERP-Systems with Multiple Case Identifiers

By Dirk Fahland.

Analyzing processes supported by an ERP system such as Order-to-Cash or Purchase-to-Pay are one of the most frequent use cases of process mining. At the same time, they are one of the most challenging, because the processes operate on multiple related data objects such as orders, invoices, and deliveries in n:m relations.

Event log extraction for process mining alays flattens the relational structures into a sequences of events. The top part of the following poster illustrates what goes wrong during this kind of event log extraction: events are duplicated and false behavioral dependencies are introduced.

Poster summarizing process mining on ERP systems

A possible way to prevent this flattening is to extract one event log per object or entity in the process: one log for all orders, one log for all invoices, one log for all deliveries. The result is a so-called artifact-centric process model that shows one “life-cycle model” describing the process activities per data object.

But analyzing the process over all objects also requires to extract event data about how objects “interact”. Technically, this can be done by extracting one event log per relation between two related data objects (or tables). From these, we can learn the flow and behavior dependencies over different data objects.

Decomposing the event data in this way into multiple event logs ensures that event sequences either follow one concrete data object or follow a concrete relation between two related related data objects. The resulting model only contains “valid flows”.


Performance Spectrum for Analyzing Business Processes

By Dirk Fahland.

In this post, I show how simple data visualizations help understanding the multi-dimensional nature of processes. Even the most simple classical business processes have important dynamics that cannot be understood by cases in isolation.

The Performance Spectrum was originally designed to deliver a useful process map for analyzing logistics processes over time. When applying the same technique to business process event data, the performance spectrum proves equally useful as it unveils process characteristics that were so far hidden by existing process mining tools:

  • performance of business processes actually varies greatly over time,
  • different cases are much more influencing each other (and are influenced by external mechanisms such as shared resources or policies) that previously shown,
  • processes not only have multiple variants in control-flow but also multiple, overlapping variants in performance,
  • different processes have very different performance spectra, but processes from a similar domain show similar performance spectra.

To support and trigger further research in this area, we released a smaller-scale version of the Performance Spectrum Miner enabling the analysis of business process event logs. The platform independent (requiring JRE8) tool is available as a

Examples of Performance Spectra

Below, we show some performance spectra of publicly available event logs.

Road Traffic Fine Management process

In the figure below, we see the typical process map or model of the Road Traffic Fines Management Process event log on the left. It describes the possible behavior of handling a single case (a traffic ticket). The arc width and annotations tell how long it takes a case to go from one activity to the next.

On the right we see the Performance Spectrum of this process. Each horizontal stripe describes the transition between two activities – called a segment. Each colored diagonal or vertical line is a case passing through this segment over time. The longer and more diagonal the line, the longer the case took.

Performance Spectrum of the main variants of the road traffic fine management process

We can immediately spot very different patterns in each of the segment, clearly showing that the cases are not handled in isolation, but something manages their progress. We can see

  • Payments from traffic offenders happening at various rates, and changing density
  • Multiple incoming cases being batched together during the “Send Fine” step and afterwards being processed individually (non-batched again)
  • While some “Send Fine” steps are being executed immediately
  • Penalty is being added after a fixed delay leading to a FIFO behavior in the process
  • However, cases arrive at the “Add Penalty” step in larger groups at irregular intervals leading to emergent batches of penalty notifications – with different success in the speed of payment
  • Credit collection always happening in larger batches for cases not paid 6 months prior

Looking at a single event log, we can see that even a classical process over a single entity (a traffic ticket) is subject to dynamics beyond the scope of a single case.

The Credit Application process of BPIC12

We can see

  • A weekly working pattern where most process steps are concluded on Monday-Friday the same day and mostly in FIFO order, though some work takes place for some steps on Saturdays
  • However several steps also show violations to the FIFO behavior and longer waiting times spanning more than one day
  • Cases and work that is coming in on the weekend and overnight is being processed the very next working day early on

The same Credit Application process 5 years later in BPIC17

  • The weekly working patterns seen in BPIC17 remain, but more steps show
  • violations to the FIFO behavior.
  • In addition, we can observe batching, for example in the O_Accepted step taking place every month, although some cases are not included in the batch and processed immediately.
  • Cancellation after an offer was sent follows mostly a FIFO pattern, but with variable delays
  • The aggregated performance spectrum shows a lot of variability in the workload in the process, with some very unusual peaks in offers being created and later on cancelled over a longer period of time.
  • Towards the end of the dataset, the performance spectrum shows significant improvement in performance of the process across several steps (most cases there are now handled in the bottom quartile than in the top quartile)

The building permit processes of BPI15

  • The performance spectra of the two logs from two different municipalities are very similar to each other, but are very different from the previous logs.
  • The overall throughput per day is much lower.
  • Most cases are processed across the steps in a FIFO manner, though not following a strict working week pattern, and cases are handled on the same day across multiple steps.
  • Processing seems to happen in stages where certain steps are performed for all cases together for a certain period of time, while there is no activity in other steps at the same period.

Your turn!

What can you find in the Performance Spectra of the other public event logs, or your own data? Get the Performance Spectrum Miner from or from  and try it out!

The Performance Spectrum

Dirk Fahland

One of the core challenges of process analytics from event data is to enable an analyst to get a comprehensive understanding of the process and where problems reside.

In business process mining such an overview is obtained with a process map. It can be discovered from event data to visualize the flow in the process and highlight deviations and bottlenecks.

Process maps of logistics processes do not give these insights: they are too large to comprehend, the maps do not visualize how processing of materials influences each other, and – as they show an aggregate of all event data – they fail to visualize how performance and processing varies and changes over time.

In the “Process mining in Logistics” project by Eindhoven University of Technology and Vanderlande, we therefore developed a new visual analytics technique which we call the Performance Spectrum:

  • The performance spectrum maps out process dynamics for all steps and all cases over time, by adding a “time axis” to the process map.
  • The performance spectrum visualizes each case and each step over time individually allowing analysis to see how materials and cases of a process are handled together and how they influence each other.
  • The explicit visualization of all cases together reveals how process deviations and short- and long-term performance problems evolve over time and influence each other.

The image below shows the performance spectrum of a baggage handling system along a sequence of check-in lines over time. Bags are put into the system at point a1 and then are moved via conveyor belts to point a2. Each blue or orange line in the top-most segment a1:a2 in the performance spectrum shows the movement of one bag from point a1 to point a2 over time. The angle (and color) of the line indicates its speed.

Performance Spectrum of Check-in Aisles in a Baggage Handling System

As shown on the layout schema below, further bags enter the system from another check-in point a2 and are also moved to point a2, where both flows merge on the segment a2:a3, etc. All bags eventually reach the point “s” from where the bags are routed further into the baggage handling system. In the performance spectrum, we can see the movement of a bag over these segments through the consecutive lines.

Layout of Conveyor Belts in Check-in Area of a Baggage Handling System

As bags cannot overtake each other on a conveyor belt, we can immediately identify in the performance spectrum several behavioural patterns:

  • Normal operations, for example in the left part of the performance spectrum, show how bags flow tougher from the check-in points to point s, each segment having its own speed, and no bags are overtaking each other.
  • Repeated operational problems can be seen in the segment a2:a3 (orange-slanted lines) where the conveyor belts are halted for a certain period, leading to significantly delayed processing, to no flow in segments a3:a4 and a4:a5, and to backwards queuing in segment a1:a2, while segment a5:s is unaffected as the bags coming from a5 can move freely.
  • After the short-term performance problems are resolved, the system shows recovery behaviour under high-load as the system resumes to normal operations, visible by a large number of bags (many lines close together) moving two times slower than normal (light blue).
  • Moreover, the repeated performance problem was already briefly visible in a2:a3 in the initial phase (showing a group of bags moving 3x slower than normal).

The visualization allows process managers and engineers to both quickly locate the cause of the problem to prevent it happening in the future. In particular the briefly-visible performance problem in a2:a3 prior to the halt of the conveyor belt can be identified as an early warning signal to detect possible performance problems in the future, and also to understand and improve system recovery behavior.

We realized this technique in a high-performance visualization tool which we call the Performance Spectrum Miner. It has proven itself reliable to:

  • analyze very large amounts of event data (of over 100 million events),
  • quickly identify temporary process deviations in very large processes,
  • quickly locate short- and long-term performance problems as well as gradual and abrupt changes in process performance,
  • identify the root-cause of performance problems and deviations in logistics processes occurring only under certain conditions.

We released a smaller-scale version of the tool (as a ProM plugin or as standalone tool) together with a manual on

More information

Multi-Dimensional Process Thinking

Dirk Fahland

I am trying to sketch the landscape of describing, analyzing, and managing processes outside the well-established paradigm of a “BPMN process” where a process is executed in instances, and each instance is completely isolated from all other instances.

Thinking about Processes

Let me introduce the term “process thinking”.

Process-thinking is the fundamental paradigm for understanding, designing, and implementing goal-oriented behaviors in social and technical systems and organizations of all kinds and sizes.

Process thinking structures the information flow between various actors and resources in terms of processes: several coherent steps designed to achieve common and individual goals together.

Throughout a process, multiple actors, resources, physical objects and information entities interact and synchronize with each other.

The scope of process thinking varies depending on the system and dynamics considered based on “how many dynamics to consider?” (outer scope) and “how many entities describe these dynamics?” (inner scope).

“BPMN Process Thinking” and Classical Process Mining
One Execution – Single Entity

BPMN and classical process mining focus primarily on describing and analyzing information handling dynamics as they are found in many administrative procedures, for instance in insurance companies or universities.

Processes are scoped in terms of individual cases (or documents) whose information is processed along a single process description independent of other cases, often in a workflow system. In terms of scoping, such processes encompass a single-dimensional inner scope (information processing) structured into a single-dimensional outer scope (along a single case).

One Execution – Multiple Entities

Most organizations operate multiple processes sharing data or materials which requires to consider multiple processes and objects and their interlinked dynamics together.

Process thinking around dynamics in manufacturing and retail organizations, such as Order-to-Cash or Purchase-to-Pay processes, is often supported by complex Enterprise Resource Planning (ERP) or Customer Relations Management (CRM) systems.

Processes here are centered around updating and managing a collection of shared and interlinked documents by various actors together leading to mutually dependent and interconnected dynamics of multiple objects and processes (multi-dimensional outer scope) with a focus on information processing (single dimensional inner scope).

Taking the system into the picture

While information processing is the dominant behavior analyzed in process mining, the dynamics of a process may also be characterized and analyzed in other dimensions.

For example, how actors and resources, physical materials, and the underlying systems participate in the processing of cases of the same process (inner scope of process thinking)

  • How are actors and resources involved in the dynamics – and how does the involvement of actors and resources influence the dynamics, for instance through availability, workload, and capabilities?
  • How are physical materials involved in the dynamics, for instance through transporting or storing large amounts of materials via conveyor belts or vehicles. How do their physical properties and constraints influences the dynamics?
  • How are the underlying systems are involved in the dynamics, and how do their capabilities and limitations influence the dynamics, for instance through queueing, prioritizing, and assigning of work or the (reliability of) automation of steps?

the progress of a case depends on availability of information, actors, and corresponding materials alike

In most processes, these different factors of processing are not independent but influence each other as the progress of a case depends on availability of information, actors, and corresponding materials alike, and is subject to limited availability of processing resources, and physical limitations of the supporting systems, which requires multiple dimensions to characterize a single dynamic (inner scope).

Multiple Executions – One Entity

Processes for manufacturing and logistics, such as baggage handling at airports combine information handling with material flows.

Physical items are processed along a logical process flow – and at the same time have to be moved around a physical environment of conveyor belts, carts, machines, and workers. Steadiness of flow is the central process objective.

In this characteristic, the processing of one material item depends not only on the logical process it has to go through but also on all other items that surround it: they together define whether work accumulates at a particular machine, work cannot be completed at the desired quality, or target deadlines are met. Did your bag reach the flight?

Call centers and hospitals are other examples where the processing of one case highly depends on what happens with other cases. A long waiting time in a queue can make a customer service contact go very differently. The quality and next steps in a medical treatment depend on how well the medical staff can focus on your case.

These phenomena cannot be observed, analyzed, and improved when studying each case in isolation.

Multiple Executions – Multiple Entities

More advanced logistics operations, such as warehouse automation and manufacturing systems, also consider material flows that are being merged together, through batch processing and manufacturing steps.

Analyzing and improving processes in such systems requires both a multi-dimensional inner scope and a multi-dimensional outer scope.

And now? Let’s talk…

What are your thoughts on this? Feel free to join and post a response here!