Process Mining as Computational Process Intelligence
A formal and technical view of event-log analysis, object-centric process models, conformance checking, performance diagnosis, and enterprise applications
Process mining reconstructs operational behavior from event data rather than from procedural descriptions, making it a computational discipline for observing how enterprises actually execute their processes. This article develops process mining from first principles, starting from event-log construction, trace semantics, directly-follows relations, Petri-net models, variant analysis, behavioral entropy, conformance checking, performance mining, and Little’s Law. It then extends the classical case-centric model toward object-centric process mining, where events are related to multiple enterprise objects such as orders, deliveries, invoices, payments, materials, suppliers, and resources. The article frames process mining as a data-engineering, semantic-governance, and enterprise-architecture problem, because the validity of any discovered model depends on the correctness of the event-construction function. It discusses applications in order-to-cash, procure-to-pay, inventory, manufacturing, finance, audit, ERP migration, and digital transformation; examines Celonis as a commercial instantiation of process intelligence; and positions process mining as an architectural feedback mechanism for comparing intentional enterprise architecture with observed behavioral execution. The article also provides a practical roadmap for introducing process mining in a corporation, from scoped business questions and governed event models to dashboards, action models, scaling, and build-buy-hybrid decisions. Two mathematical appendices then extend the argument: the first formalizes process mining as system identification for dynamic resource allocation under forecasted demand; the second shows how process-mined parameters and structures can feed an integrated S&OP decision model, transforming process mining from descriptive analytics into empirical input for optimization, governance, and enterprise control.
digital transformation
enterprise architecture
essay
🇬🇧
Author
Affiliation
Antonio Montano
4M4
Published
October 22, 2023
Modified
April 9, 2026
Keywords
process mining, event logs, computational process intelligence, process discovery, conformance checking, performance mining, object-centric process mining, OCEL, XES, Petri nets, directly-follows graph, behavioral entropy, process variants, ERP, business process management, enterprise architecture, data engineering, process intelligence, task mining, process automation, operational excellence, digital transformation, internal control, audit, supply chain, order-to-cash, procure-to-pay
Process mining reconstructs operational behavior from event data rather than from procedural descriptions, making it a computational discipline for observing how enterprises actually execute their processes. This article develops process mining from first principles, starting from event-log construction, trace semantics, directly-follows relations, Petri-net models, variant analysis, behavioral entropy, conformance checking, performance mining, and Little’s Law. It then extends the classical case-centric model toward object-centric process mining, where events are related to multiple enterprise objects such as orders, deliveries, invoices, payments, materials, suppliers, and resources. The article frames process mining as a data-engineering, semantic-governance, and enterprise-architecture problem, because the validity of any discovered model depends on the correctness of the event-construction function. It discusses applications in order-to-cash, procure-to-pay, inventory, manufacturing, finance, audit, ERP migration, and digital transformation; examines Celonis as a commercial instantiation of process intelligence; and positions process mining as an architectural feedback mechanism for comparing intentional enterprise architecture with observed behavioral execution. The article also provides a practical roadmap for introducing process mining in a corporation, from scoped business questions and governed event models to dashboards, action models, scaling, and build-buy-hybrid decisions. Two mathematical appendices then extend the argument: the first formalizes process mining as system identification for dynamic resource allocation under forecasted demand; the second shows how process-mined parameters and structures can feed an integrated S&OP decision model, transforming process mining from descriptive analytics into empirical input for optimization, governance, and enterprise control.
From process descriptions to computational evidence
A business process is usually described as a normative abstraction: a purchase order is created, approved, received, invoiced, matched, and paid; a sales order is entered, confirmed, delivered, invoiced, and collected; a production order is planned, released, executed, confirmed, and closed. This representation is useful for governance, but it is not a measurement of operational reality. It is a model of intended behavior.
Process mining starts from a stricter premise. A process is not what a procedure says. A process is the set of temporally ordered state transitions that can be reconstructed from digital traces left by operational systems.
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
D["Raw operational data<br/>ERP, CRM, MES, WMS, logs"] --> PHI["Semantic extraction<br/>φ : D → L_E"]
PHI --> E["Event log or object-centric event structure"]
E --> A["Mining algorithms<br/>discovery, conformance, performance"]
A --> I["Process model and diagnostics"]
I --> G["Governed decisions and actions"]
G -. feedback .-> D
Figure 1: Process mining as an evidence pipeline. Raw operational data from enterprise systems are transformed into event logs or object-centric event structures, analyzed through process-mining algorithms, converted into diagnostics, and used to support governed decisions and actions.
The primitive object is therefore not a diagram, a procedure, or a workshop narrative. The primitive object is an event.
An event is an observed fact of the form:
e = (i, a, t, r, x)
where:
i is a case identifier or, in a more general formulation, a set of related business objects;
a is the activity or state transition observed;
t is a timestamp;
r is the resource, system, organizational unit, or agent responsible for the event;
x is a vector of attributes describing the event context.
The fundamental assumption is minimal: if an enterprise system records enough events with reliable ordering, then the operational process can be reconstructed empirically. The reconstructed process may contradict the designed process. That contradiction is not an error of the analytical method; it is the main object of analysis.
This shift is epistemologically important. Traditional process modeling is top-down and intentional. Process mining is bottom-up and evidential. The former asks what the organization believes should happen. The latter asks what the information systems prove has happened.
The technical discipline of process mining emerged around this exact distinction: event data are treated as first-class analytical objects, and process knowledge is extracted from event logs rather than inferred only from interviews, diagrams, or procedural documentation.12
Figure 2: Case-centric event-log structure. An event log is represented as a collection of traces, where each trace corresponds to one case and contains an ordered sequence of events with activity, timestamp, resource, and contextual attributes.
In classical case-centric process mining, an event log can be defined as a multiset of traces.3
L \in \mathcal{B}(\mathcal{A}^{*})
where:
\mathcal{A} is the finite set of activities;
\mathcal{A}^{*} is the set of all finite sequences over \mathcal{A};
\mathcal{B}(X) denotes the set of multisets over X.
A trace is a finite sequence:
\sigma = \langle a_1, a_2, \ldots, a_n \rangle
where each a_k \in \mathcal{A} corresponds to an activity executed for the same case.
More rigorously, an event log can be defined as a finite set of event identifiers E equipped with attribute functions:
case : E \rightarrow C,\quad act : E \rightarrow \mathcal{A},\quad time : E \rightarrow T,\quad res : E \rightarrow R,\quad attr : E \rightarrow X
where:
C is the set of cases;
\mathcal{A} is the activity alphabet;
T is a totally or partially ordered time domain;
R is the set of resources;
X is the attribute domain.
This formulation preserves event identity even when two events share the same case, activity, timestamp, resource, and attribute vector.
For a case c \in C, the observed trace is obtained by selecting all events associated with c and ordering them by timestamp:
This apparently simple definition hides several non-trivial problems:
Timestamps may be non-unique, inconsistent, delayed, batch-generated, or produced by different systems with different clock semantics.
The same business event may be represented by several technical records.
The case identifier may be ambiguous.
Some relevant events may be missing because they occur outside the transactional system, for example in emails, spreadsheets, manual controls, warehouse terminals, MES systems, supplier portals, banking systems, or desktop activity.
The quality of process mining is therefore bounded by the quality of event abstraction. Formally, if the source operational data are represented by a set of raw records D, event-log construction is a mapping:
\phi : D \rightarrow L_E
where L_E denotes the constructed event-log structure, including event identifiers, case assignments, activities, timestamps, resources, and attributes.
The mining problem is not only the discovery of a process model from L_E. It is also the correctness of \phi. A poor extraction function can create an apparently precise but semantically false process model.
This is why process mining is not merely an algorithmic discipline. It is also a data-engineering, semantic-modeling, and enterprise-architecture discipline.
Process discovery
Process discovery is the construction of a process model M from an event log L:
discover(L) = M
The model M can belong to several formalisms:
directed graphs;
directly-follows graphs;
Petri nets;
process trees;
BPMN-like models;
declarative constraint systems;
stochastic automata;
object-centric graphs.
The simplest representation is the directly-follows graph. Given an event log L, one defines a relation:
a >_L b
if there exists at least one trace \sigma \in L such that activity a is immediately followed by activity b in \sigma.
The frequency of the edge (a,b) is more precisely the number of observed adjacent occurrences of a followed by b across the multiset of traces:
F = \{(a,b) \in \mathcal{A} \times \mathcal{A} : a >_L b\}
This model is computationally simple and operationally useful. It shows frequent paths, rare paths, loops, skips, and variant structures. However, it is not always semantically precise. It may confuse concurrency with choice, and it may over-represent spurious behavior if the event log contains noise or incomplete traces.
For example, if two activities a and b are concurrent, one may observe both sequences:
\langle a,b \rangle
and:
\langle b,a \rangle
A directly-follows graph may represent this as two causal paths, even though the correct interpretation may be parallelism rather than mutual causality.
More expressive discovery algorithms therefore try to infer constructs such as sequence, choice, concurrency, loop, silent transition, and synchronization. In Petri-net terms4, a discovered model can be represented as:
N = (P, T_N, F, M_0, M_f)
where:
P is the set of places;
T_N is the set of transitions;
F \subseteq (P \times T_N) \cup (T_N \times P) is the flow relation;
M_0 is the initial marking;
M_f is the final marking.
The value of Petri nets is that they provide formal execution semantics. A transition is enabled only when the required input tokens exist. This makes it possible to reason rigorously about reachability, deadlocks, soundness, concurrency, and conformance.
Variants and behavioral entropy
A process variant is a distinct trace pattern. If L is an event log, the set of variants is:
V(L) = \{\sigma : \sigma \in supp(L)\}
where supp(L) is the support of the multiset L.
The probability of a variant \sigma is:
p(\sigma) = \frac{count_L(\sigma)}{|L|}
A useful measure of process fragmentation is behavioral entropy:
Low entropy indicates that the process is concentrated around a small number of dominant variants. High entropy indicates behavioral dispersion. In enterprise processes, high entropy is not automatically bad. It may reflect product diversity, customer segmentation, legal-entity differences, localization, exception handling, or legitimate operational flexibility. However, high entropy without business explanation is a signal of weak standardization or uncontrolled exception handling.
A mathematically disciplined interpretation requires conditioning. Let Z be a set of contextual attributes, such as legal entity, business unit, product family, supplier type, customer segment, country, plant, warehouse, or channel. Then one should compare:
H(L)
with:
H(L \mid Z)
=
\sum_z \mathbb{P}(Z=z)H(L_z)
where L_z is the sublog restricted to cases or events with contextual condition Z=z. If entropy collapses after conditioning on Z, the variation is structurally explained. If entropy remains high within homogeneous partitions, the variation is likely operational rather than structural.
This distinction matters in ERP transformation. A multinational group may show hundreds of order-to-cash variants globally. Some are legitimate because fiscal, logistic, or customer-channel conditions differ. Others are pure organizational noise. Process mining becomes valuable when it separates these two cases.
Conformance checking
Discovery asks: what model can be inferred from the event log? Conformance checking asks a different question: given a normative model M and an event log L, how well does the observed behavior conform to the expected behavior?
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
M["Normative process model M"] --> LM["Allowed behavior<br/>𝓛(M)"]
LOBS["Observed event log<br/>L_obs"] --> ALIGN["Alignment computation"]
LM --> ALIGN
ALIGN --> FIT["Fitness<br/>Can the model replay the log?"]
ALIGN --> PREC["Precision<br/>Does the model allow too much?"]
ALIGN --> DEV["Deviation diagnostics<br/>skips, inserts, loops, wrong order"]
DEV --> ACT["Control remediation<br/>process, system, data, training"]
Figure 3: Conformance checking through alignment. The observed event log is compared with the behavior allowed by the normative process model. The alignment computation produces fitness, precision, deviation diagnostics, and remediation inputs for process, system, data, or training interventions.
Formally, conformance checking evaluates the relation between:
L_{obs}
and:
\mathcal{L}(M)
where \mathcal{L}(M) is the language of all traces allowed by model M.
The simplest view is language membership:
\sigma \in \mathcal{L}(M)
If \sigma is allowed by the model, it is conformant. If it is not, it deviates. In real processes, however, this binary view is too crude. A trace may deviate slightly or severely. It may skip one activity, execute activities in the wrong order, repeat a control step, or contain additional manual interventions.
A more useful formulation is alignment-based conformance. Given an observed trace \sigma and a model M, an alignment is a sequence of moves that synchronizes observed events with model transitions. A synchronous move means that the event and the model agree. A log move means that the event occurred but the model did not expect it. A model move means that the model expected an activity that was not observed.
The optimal alignment minimizes a cost function:
cost(\gamma) = \sum_{m \in \gamma} c(m)
where \gamma is an alignment and c(m) is the cost assigned to each move type. The deviation distance is then:
d(\sigma, M) = \min_{\gamma \in Align(\sigma,M)} cost(\gamma)
Fitness can be interpreted as the degree to which the model can replay the log:
Here, d_{max}(\sigma,M) denotes a normalizing maximum deviation cost for trace \sigma with respect to model M, so that the resulting fitness score can be interpreted on a bounded scale. If the denominator is zero, fitness must be defined by convention, because no deviation cost is available for normalization.
Precision measures the inverse problem: whether the model allows too much behavior that was never observed. A model with perfect fitness but poor precision may be so permissive that it accepts almost everything. Such a model is not analytically useful.
Generalization measures whether the model captures behavior likely to occur beyond the observed sample. Simplicity penalizes unnecessary structural complexity. Process discovery is therefore not a single-objective optimization problem. It is a trade-off among fitness, precision, generalization, and simplicity.
Performance mining
Process mining becomes operationally powerful when control-flow analysis is combined with temporal and economic measures. Let e_i and e_j be two events in the same trace such that t(e_i) < t(e_j). The elapsed time between them is:
\Delta t(e_i,e_j) = t(e_j) - t(e_i)
For two activities a and b, one can define the empirical waiting-time multiset:
where e_i \rightarrow e_j denotes the selected behavioral relation, usually direct succession or a domain-specific milestone relation. The mean waiting time is:
In practice, the distribution is often more informative than the mean. Enterprise waiting times are typically heavy-tailed. A small number of extreme cases may dominate the average. Median, quantiles, conditional distributions, and survival functions are therefore more robust.
For a process instance c, cycle time can be defined as:
CT(c) = t_{end}(c) - t_{start}(c)
Throughput is:
TH = \frac{N}{T}
where N is the number of completed cases in observation window T.
Work in progress can be estimated as:
WIP(t) = |\{c : t_{start}(c) \leq t < t_{end}(c)\}|
Under standard stability and flow-conservation assumptions, Little’s Law provides a fundamental consistency relation:5
\overline{WIP} = TH \cdot \overline{CT}
This relation is useful because it prevents superficial interpretations. If throughput is constant and WIP grows, then cycle time must grow. If the organization wants shorter cycle time without reducing input volume, it must either increase capacity, reduce rework, reduce queues, or change the flow structure.
Process mining gives empirical estimates of these quantities per process segment, resource, product family, legal entity, supplier class, plant, warehouse, or customer group.
Object-centric process mining
The classical event-log model assumes one dominant case identifier. This assumption is often false in enterprise systems.
Consider procure-to-pay. A single purchase requisition can generate multiple purchase orders. A purchase order can contain multiple lines. A line can be partially received. Several receipts can be matched to one invoice. One invoice can refer to several purchase orders. One payment can settle multiple invoices. The process is not a sequence over one object. It is a network of interacting objects. The same problem appears in order-to-cash, make-to-order, engineer-to-order, maintenance, logistics, warehouse management, project accounting, and intercompany flows.
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
E1(("Event<br/>Invoice posted"))
INV["Invoice<br/>INV-9981"] --- E1
PO["Purchase Order<br/>PO-450001"] --- E1
POL["Purchase Order Line<br/>PO-450001-10"] --- E1
SUP["Supplier<br/>SUP-210"] --- E1
LE["Legal Entity<br/>IT01"] --- E1
PO --- POL
PO --- SUP
POL --- INV
INV --- LE
Figure 4: Object-centric event structure. A single business event, such as invoice posting, can be related to several enterprise objects at the same time, including invoices, purchase orders, purchase order lines, suppliers, and legal entities.
The object-centric formulation replaces the case-centric trace with a typed object-event structure. Let:
O = \bigcup_{\tau \in \mathcal{T}} O_{\tau}
be the set of business objects partitioned by object type \tau, such as Sales Order, Sales Order Line, Delivery, Invoice, Payment, Purchase Order, Production Order, Batch, Shipment, Handling Unit, or Service Ticket.
An event is associated not with one case but with a set of objects:
rel(e) \subseteq O
The event log becomes a structure:
L_{OC} = (E, O, type, act, time, rel, attr)
where:
E is the set of events;
O is the set of objects;
type : O \rightarrow \mathcal{T} assigns each object to an object type;
act : E \rightarrow \mathcal{A} assigns an activity to each event;
time : E \rightarrow T assigns a timestamp;
rel \subseteq E \times O relates events to objects;
attr stores event and object attributes.
This structure is naturally a typed temporal hypergraph. Events are hyperedges connecting multiple business objects. Objects persist. Events occur. Relationships carry the semantics of operational interaction.
The analytical gain is significant. Instead of forcing the organization to choose whether the process is by order, by order line, by delivery, or by invoice, one can analyze several perspectives over the same object-centric model.
For example:
from the Sales Order perspective, one sees customer-commitment behavior;
from the Delivery perspective, one sees logistic execution;
from the Invoice perspective, one sees billing behavior;
from the Payment perspective, one sees cash-collection behavior;
from the Item perspective, one sees material-flow behavior.
Object-centric event logs are therefore more faithful to ERP reality. The OCEL 2.0 standard formalizes this kind of event data and supports richer relationships between events and objects, including object-to-object relationships and multiple exchange formats.6
Data architecture for process intelligence
A process-mining system is not an isolated analytical tool. It is a data product over operational systems.
A robust architecture contains at least seven layers.
Layer 1: source systems
The source layer includes ERP, CRM, MES, WMS, PLM, TMS, service-management systems, banking systems, supplier portals, customer portals, spreadsheets, workflow engines, API gateways, and sometimes desktop-interaction logs.
The essential question is not whether these systems contain data. They do. The essential question is whether they contain reconstructible event semantics.
A database table recording the current status of an order is insufficient unless historical status transitions are retained. Process mining requires temporal evidence, not only current state.
Layer 2: extraction layer
The extraction layer collects raw operational records. This may occur through database replication, APIs, change-data capture, flat-file exports, event streams, audit tables, message queues, or system-specific connectors.
The extraction design must preserve:
timestamp fidelity;
source-system identifiers;
transaction keys;
user and resource metadata;
status-transition history;
deletion and reversal semantics;
time-zone normalization;
legal-entity and organizational context.
Layer 3: semantic transformation layer
The semantic transformation layer maps raw records to event abstractions.
This layer defines the function:
\phi : D \rightarrow L_E
It decides that a row in a change-log table corresponds to an event such as Purchase Order Approved, Sales Order Blocked, Delivery Created, Invoice Posted, Goods Receipt Reversed, or Payment Cleared.
This layer is the most critical one. If it is wrong, all subsequent process analysis becomes formally valid but operationally false.
Layer 4: process data store
The process data store persists event logs, object tables, relationships, attributes, and derived metrics. In a case-centric model, this may be a set of event-log tables. In an object-centric model, this becomes a graph-like or relational structure connecting objects, events, and relationships.
The data store should support incremental refresh, historical reproducibility, lineage, versioning, and auditable transformation logic.
Layer 5: analytical layer
The analytical layer executes discovery, conformance checking, performance mining, variant analysis, root-cause analysis, predictive models, and simulation.
The output is not merely a graph. The output is a set of hypotheses about operational behavior, such as:
late deliveries are concentrated in specific product families;
invoice blocks correlate with missing purchase-order references;
maverick buying correlates with specific plants or buyers;
rework loops appear after manual price changes;
customer-credit blocks increase cycle time but reduce exposure;
intercompany flows create hidden waiting time between legal entities.
Layer 6: decision layer
The decision layer converts analytical signals into managerial or operational interventions. These may include alerts, exception queues, workflow tasks, control recommendations, automation triggers, policy changes, master-data remediation, or process redesign.
The decision layer must distinguish between correlation and intervention. A bottleneck signal is not automatically a prescription. It becomes a prescription only when the causal mechanism is understood well enough to justify action.
Layer 7: governance layer
The governance layer defines data ownership, process ownership, access control, semantic standards, metric definitions, auditability, and change management.
Without governance, process mining degenerates into visually persuasive analytics with unstable semantics. With governance, it becomes a computational representation of enterprise operations.
Potential applications
Order-to-cash
Order-to-cash is one of the most natural application areas because it combines commercial commitments, logistics, invoicing, credit management, and cash collection.
Relevant objects include:
customer;
quotation;
sales order;
sales order line;
delivery;
shipment;
invoice;
credit memo;
payment;
dispute.
Relevant events include:
quotation created;
order created;
order confirmed;
credit block applied;
block released;
delivery created;
goods issued;
invoice posted;
payment received;
dispute opened;
dispute closed.
Typical analyses include:
cycle time from order creation to delivery;
cycle time from delivery to invoice;
days sales outstanding;
frequency and duration of credit blocks;
rework caused by order changes;
delivery delays by warehouse, carrier, item, customer segment, or legal entity;
revenue leakage from billing errors;
exception paths that bypass standard approval.
In an ERP transformation, this analysis can validate whether the target operating model is actually being adopted after go-live.
Procure-to-pay
Procure-to-pay is structurally suitable for conformance checking because procurement processes usually contain explicit control expectations.
Relevant objects include:
purchase requisition;
purchase order;
purchase order line;
supplier;
goods receipt;
service entry sheet;
invoice;
payment;
contract.
Relevant events include:
requisition created;
requisition approved;
purchase order created;
purchase order approved;
goods received;
invoice received;
invoice blocked;
invoice released;
payment executed.
Typical analyses include:
maverick buying;
purchase orders created after invoice receipt;
missing approvals;
three-way match deviations;
invoice blocks by supplier or buyer;
payment-term deviations;
late payment risk;
contract leakage;
approval bottlenecks.
The mathematical value lies in comparing observed traces with control models. A deviation is not a subjective finding. It is a measurable distance between L_{obs} and \mathcal{L}(M).
Inventory and supply-chain planning
Inventory processes are not always modeled as clean workflows, but they generate rich event data. Object-centric process mining is especially relevant because inventory behavior emerges from interactions among items, warehouses, production orders, purchase orders, sales orders, transfer orders, forecasts, and replenishment policies.
Relevant analyses include:
stockout root-cause chains;
excess stock caused by forecast changes or minimum-order quantities;
lead-time variability by supplier and item;
replenishment-cycle deviations;
warehouse transfer delays;
blocked or quality-inspection stock;
planning nervousness;
mismatch between planning parameters and actual execution.
A process-mining layer can reveal whether the planning model is structurally coherent. If reorder points, safety stocks, lead times, and coverage groups are configured in one way but the actual replenishment process behaves differently, the difference becomes measurable.
Manufacturing and MES/ERP integration
Manufacturing processes combine ERP-level production orders with MES-level execution events and machine-level telemetry. The relevant process is not only administrative. It is cyber-physical.
Relevant objects include:
production order;
batch;
operation;
work center;
machine;
material lot;
quality inspection;
nonconformance;
maintenance order.
Relevant events include:
production order released;
material staged;
operation started;
operation completed;
machine stopped;
scrap recorded;
quality inspection completed;
rework initiated;
order technically completed.
Potential analyses include:
waiting time between release and execution;
queue time by work center;
rework loops;
scrap correlation with machine, shift, material lot, or operator;
divergence between planned and actual routing;
bottlenecks across production cells;
impact of maintenance events on order completion.
The key technical challenge is synchronization across time domains. ERP, MES, SCADA, and historian systems do not necessarily share the same event granularity or timestamp semantics.
Finance and working capital
Finance processes are attractive because their economic effect can be quantified directly.
Applications include:
invoice processing;
accounts payable;
accounts receivable;
dispute management;
cash application;
closing processes;
intercompany reconciliation.
Metrics include:
invoice cycle time;
blocked-invoice aging;
discount capture rate;
payment-term compliance;
overdue receivables;
dispute resolution time;
manual journal-entry frequency;
month-end closing bottlenecks.
The value is not only operational efficiency. It is liquidity, risk reduction, compliance, and working-capital optimization.
Compliance, internal control, and audit
Process mining can support internal controls by replacing sampling-based evidence with population-level behavioral analysis.
Examples include:
segregation-of-duties violations;
skipped approvals;
order changes after approval;
payments without proper invoice match;
manual price overrides;
goods receipt after invoice;
supplier-bank-account changes before payment;
emergency-user activity;
retrospective purchase-order creation.
The relevant mathematical concept is not discovery but conformance. The control model defines admissible behavior. The event log shows observed behavior. Deviations can be measured, ranked, and assigned to owners.
This does not eliminate audit judgment. It changes the empirical basis of audit judgment.
Digital transformation and ERP migration
In ERP programs, process mining can be used before, during, and after transformation.
Before transformation, it reconstructs the as-is process from actual data. This avoids designing the target model from workshop narratives alone.
During transformation, it supports fit-gap analysis. If the actual process contains many variants, the transformation team can distinguish necessary variants from historical noise.
After go-live, it measures adoption. The organization can test whether users follow the new process, whether legacy workarounds reappear, whether master-data issues create new bottlenecks, and whether local entities diverge from the template.
The most rigorous use is to treat process mining as a transformation-control system. The target operating model becomes a formal model M. The live ERP event log becomes L_t. Adoption is measured as a time-dependent conformance function:
A(t) = conformance(L_t, M)
where A(t) should increase after stabilization if the transformation is effective.
Limits and failure modes
Process mining is powerful, but its limits are structural:
It cannot see events that are not recorded. If a decision occurs in a phone call, spreadsheet, email, or informal meeting, the process model will only see its downstream trace.
It cannot infer semantics from identifiers alone. A timestamped status change does not explain why the status changed.
It can confuse correlation with causation. If late deliveries correlate with a certain warehouse, the warehouse may be the cause, or it may simply handle more complex orders.
Process mining can produce false managerial confidence. A graph generated from poor event abstraction may look objective while encoding wrong assumptions.
Excessive granularity can obscure process logic. Not every technical event should become a business event. The event model must be abstract enough to represent business semantics and concrete enough to preserve causal evidence.
Privacy and surveillance risks must be governed. The closer process mining moves toward user-level task mining or desktop interaction capture, the more it enters the domain of labor monitoring, privacy regulation, employee relations, and proportionality analysis.
Event logs may encode organizational bias. If a system records only formal approvals, only successful transactions, or only activities executed by certain roles, the resulting process model may overrepresent governed behavior and underrepresent informal recovery work, shadow processes, or exception handling. The observed log is therefore not the process itself; it is the projection of the process through the instrumentation layer of the enterprise.
Celonis as a commercial instantiation
Celonis can be understood as a commercial platform that industrializes the architecture described above. It is not merely a process-discovery tool. It packages process-data ingestion, process modeling, object-centric process analysis, dashboards, business applications, task mining, automation, and a process-intelligence semantic layer into a managed enterprise platform.
At the time of writing, Celonis presents its platform around the concept of a Process Intelligence Graph. This graph combines data from operational systems, applications, and devices with business context such as rules, KPIs, benchmarks, models, and enterprise architecture, with the objective of creating a system-agnostic digital twin of enterprise operations.7
From a technical perspective, the most important architectural point is the shift from isolated, case-centric process logs toward an object-centric data model. Celonis documentation describes the object-centric model as a unified structure of business objects, events, and relationships, avoiding the need to force complex enterprise processes into a single case notion.8
This direction is coherent with the mathematical limitations of classical process mining. Real ERP processes are not linear traces attached to one identifier. They are networks of interacting objects: orders, order lines, deliveries, invoices, payments, materials, suppliers, customers, plants, warehouses, and users. An object-centric architecture is therefore not only a product feature. It is a better computational approximation of enterprise reality.
Celonis also extends process mining toward task mining. In this layer, user interactions with applications and web pages can be captured and analyzed, subject to configuration and governance controls.9 This moves the analytical boundary from transactional system events to human-computer interaction traces. The gain is visibility into manual work. The risk is that the system moves closer to employee-monitoring infrastructure and therefore requires strict privacy, labor-law, and governance assessment.
Another relevant extension is the action layer. Celonis Action Flows are designed to create automations and combine them into processes.10 This changes the role of process mining from descriptive analytics to operational intervention. The architecture becomes a closed loop: observation feeds modeling, modeling supports diagnosis, diagnosis supports decision, decision triggers action, and the resulting execution generates new evidence for the next observation cycle.
The strategic implication is that Celonis should not be evaluated only as a visualization tool. It should be evaluated as a process-intelligence operating layer over enterprise systems. The hard questions are therefore architectural and organizational:
Which systems are authoritative for process events?
Which business objects define the object-centric model?
Which KPIs are governed and reusable?
Which deviations are merely descriptive and which trigger action?
Which actions can be automated without violating control principles?
Which process owners are accountable for model correctness?
Which parts of the organization are allowed to see user-level or resource-level data?
Which process improvements are economically material?
In this sense, Celonis is best interpreted as an enterprise process-intelligence platform rather than as a simple process-mining application. Its value depends less on the beauty of discovered process maps and more on the quality of the semantic layer, the correctness of event extraction, the maturity of process ownership, and the ability to convert evidence into controlled operational change.
Process mining in enterprise architecture and digital transformation
Process mining should not be interpreted as an isolated analytical technique. In a mature enterprise, it is more correctly understood as a computational layer of enterprise architecture: a mechanism that connects operating-model intent, information-system behavior, organizational accountability, and measurable execution evidence.
Enterprise architecture traditionally represents the enterprise through relatively stable artifacts: capability maps, process models, application landscapes, information models, integration views, organizational structures, and governance principles. These artifacts describe what the enterprise is supposed to be. They define the intentional architecture.
Process mining adds a complementary dimension. It reconstructs the behavioral architecture of the enterprise from event data. It shows how the enterprise actually executes, where control paths diverge from designed procedures, where systems introduce latency, where local variants emerge, and where organizational units use the same application landscape in materially different ways.
The relation can be expressed as follows:
EA_{intent} = (C, P, A, D, O, G)
where:
C is the capability architecture;
P is the process architecture;
A is the application architecture;
D is the data architecture;
O is the organizational architecture;
G is the governance architecture.
Process mining introduces an empirical behavioral layer:
EA_{observed} = f(L_E)
where E is the event structure extracted from operational systems.
The architectural problem is then not merely to discover a process model. The real problem is to compare intentional architecture with observed architecture:
\Delta EA
=
\operatorname{diff}(EA_{intent},EA_{observed})
This difference is one of the most important objects of digital transformation. It identifies where the designed enterprise and the executed enterprise diverge.
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
subgraph INTENT["Intentional Enterprise Architecture"]
C["Capability architecture"]
P["Process architecture"]
A["Application architecture"]
D["Data architecture"]
O["Organizational architecture"]
G["Governance architecture"]
end
subgraph OBS["Observed Behavioral Architecture"]
E["Event data"]
PM["Process mining model"]
K["KPIs, variants, deviations, bottlenecks"]
end
C --> DELTA["ΔEA<br/>Gap between designed and executed enterprise"]
P --> DELTA
A --> DELTA
D --> DELTA
O --> DELTA
G --> DELTA
E --> PM --> K --> DELTA
DELTA --> T["Transformation backlog"]
T --> R["Process redesign"]
T --> S["System configuration"]
T --> MD["Master-data remediation"]
T --> AU["Automation"]
T --> GOV["Governance intervention"]
Figure 5: Process mining as an enterprise-architecture feedback mechanism. Intentional architecture defines the designed enterprise, while observed behavioral architecture reconstructs execution from event data. The gap between the two feeds the transformation backlog across process redesign, system configuration, master-data remediation, automation, and governance intervention.
Capability architecture
At the capability level, process mining helps determine whether a business capability is only formally present or operationally mature.
For example, an organization may declare that it has a centralized procurement capability. However, event data may show that purchase orders are frequently created after invoice receipt, that approval paths differ by plant, that contracts are bypassed, or that suppliers are selected outside governed catalogues.
In architectural terms, the capability exists nominally but is not behaviorally instantiated in a controlled and repeatable way. Capability maturity can therefore be assessed through observable evidence: conformance to the intended process, behavioral stability, cycle time, exception rate, and automation rate. This is more rigorous than assigning maturity through interviews alone, because the assessment is partially grounded in observed execution.
Process architecture
At the process-architecture level, process mining validates whether documented processes correspond to real operational flows. The usual enterprise-architecture repository contains designed process models. These models are frequently normative, incomplete, outdated, or over-standardized. Process mining provides an empirical counter-model.
The designed process is:
P_{design}
The mined process is:
P_{observed}
The transformation-relevant object is the distance:
d(P_{design}, P_{observed})
This distance can represent skipped steps, additional activities, loops, local variants, timing deviations, control violations, or different routing patterns.
This matters because digital transformation often fails when the target process is designed as if the current process were already understood. Process mining reduces that epistemic risk. It does not eliminate judgment, but it constrains speculation by requiring evidence from the systems that execute the process.
Application architecture
At the application-architecture level, process mining reveals how systems actually participate in end-to-end execution.
Enterprise architecture diagrams often represent applications as boxes connected by interfaces. This is structurally useful but behaviorally incomplete. It says that two systems are integrated. It does not show whether the integration causes waiting time, rework, duplication, manual reconciliation, or inconsistent state propagation.
Process mining can expose application-level friction such as:
excessive waiting time between CRM quotation and ERP sales-order creation;
manual corrections after system-to-system transfer;
repeated status reversals after middleware failures;
invoice blocks caused by inconsistent master data;
production delays caused by ERP/MES synchronization gaps;
warehouse execution deviations caused by incomplete order attributes.
The application landscape can therefore be evaluated not only by technical ownership or interface count, but by behavioral contribution to process performance.
A useful architectural metric is the latency introduced by an application boundary:
Latency(A_i,A_j) = \mathbb{E}[t(e_j) - t(e_i)]
where e_i is the last relevant event in application A_i and e_j is the first corresponding event in application A_j.
This allows integration architecture to be evaluated empirically. A system boundary is not only a diagrammatic relation. It is a measurable delay, risk, and control point.
Data architecture and semantic governance
Process mining depends on the correctness of event semantics. For this reason, it is tightly connected to enterprise data architecture.
The same operational fact may be represented differently across ERP, CRM, MES, WMS, PLM, workflow systems, and data warehouses. A process-mining layer must decide which records become events, which timestamps are authoritative, which identifiers correlate objects, and which attributes define the analytical context.
This makes process mining a semantic-governance problem.
The event-construction function:
\phi : D \rightarrow L_E
must be governed as an enterprise artifact. It is not a technical detail. It defines the empirical reality that the organization will analyze.
If \phi is unstable, process metrics become unstable. If \phi is semantically wrong, dashboards become misleading. If \phi is locally customized without governance, cross-company or cross-country comparisons become invalid.
Therefore, a process-intelligence architecture requires:
governed event definitions;
canonical business-object identifiers;
lineage from source records to analytical events;
versioned transformation logic;
ownership of process metrics;
explicit treatment of time zones, reversals, cancellations, and status changes;
clear distinction between technical events and business events.
In digital transformation, this is critical. Without semantic governance, process mining becomes another reporting layer. With semantic governance, it becomes part of the enterprise operating model.
Operating model and organizational accountability
A process does not belong only to an application. It belongs to an operating model.
The same process may cross sales, finance, logistics, procurement, production, customer service, compliance, and external partners. Process mining exposes these crossings. It shows where ownership is fragmented, where handovers create delay, where exception handling is informal, and where local autonomy contradicts global standardization.
This has a direct consequence for transformation governance. Every relevant process metric should have an owner. Every relevant deviation class should have an accountable function. Every recurring exception should be classified as either:
a legitimate business variant;
a defect in the process design;
a defect in master data;
a defect in system configuration;
a training or adoption issue;
a control violation;
a necessary exception requiring explicit governance.
This classification is architectural. It determines whether the answer is process redesign, system change, master-data remediation, automation, organizational intervention, or policy enforcement.
ERP transformation and template governance
In ERP programs, process mining is especially valuable because it creates continuity between the as-is state, the target template, and post-go-live stabilization.
Before implementation, it supports empirical as-is discovery. This is useful because workshop-based process collection tends to overstate formal behavior and understate exceptions.
During design, it supports template rationalization. A global ERP template should not encode every local historical variant. However, it should not suppress legitimate legal, fiscal, logistic, or commercial differences. Process mining helps distinguish structural variation from accidental variation.
After go-live, it supports adoption control. The target template can be formalized as a reference model M_T. The live event log after deployment is L_t. Adoption can then be measured as:
Adoption(t) = conformance(L_t, M_T)
This allows the transformation office to observe whether the organization is converging toward the target operating model or recreating old behaviors inside the new system.
The same principle applies to phased rollouts. If different legal entities, plants, or countries adopt the same ERP template, process mining can compare behavioral convergence:
d(L_i, L_j)
where L_i and L_j are event logs from different organizational units.
Low distance suggests template convergence. High distance requires explanation. It may indicate legitimate localization, poor adoption, configuration divergence, different data quality, or process ownership gaps.
Automation and architectural control
Process mining often leads naturally to automation. If a repeated exception is detected, the organization may want to trigger a workflow, create a task, send a notification, update a field, release a block, or call an external service.
This must be treated carefully. Automation is not automatically transformation. Automating an incoherent process may only accelerate incoherence.
From an architectural perspective, automation should be introduced only when the following conditions hold:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
P["Observed pattern"] --> C["Diagnosed cause"]
C --> D["Governed decision"]
D --> A["Controlled action"]
Figure 6: Governed action chain for process-mining-driven automation. Observed patterns should first be diagnosed, then converted into governed decisions, and only then executed as controlled actions.
The action layer should therefore be governed by enterprise architecture principles:
clear ownership of automated decisions;
separation between recommendation and execution;
auditability of actions;
compatibility with internal controls;
rollback and exception handling;
security and access-control design;
avoidance of uncontrolled point-to-point automation;
alignment with the canonical process and data model.
This is especially relevant in ERP landscapes, where apparently simple automations can affect financial postings, inventory positions, customer commitments, supplier obligations, credit exposure, or compliance controls.
Process mining as a transformation control system
The strongest architectural interpretation is to treat process mining as a control system for digital transformation.
A transformation defines a desired future state:
S^*
The enterprise produces observed behavior over time:
S(t)
Process mining measures the distance:
d(S(t), S^*)
Transformation management then acts to reduce that distance, subject to constraints of cost, risk, compliance, organizational capacity, and strategic intent. The loop is:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
O1["Observe"] --> C["Compare"]
C --> D["Diagnose"]
D --> I["Intervene"]
I --> O2["Observe again"]
O2 -. feedback .-> C
Figure 7: Process mining as a transformation control loop. Observed execution is compared with the desired future state, diagnosed, corrected through intervention, and then observed again.
This is fundamentally different from static transformation governance. A steering committee that only checks milestones, budgets, and deliverables may know whether the project is progressing. It may not know whether the operating model is actually changing. Process mining supplies this missing empirical layer.
In this sense, process mining is not merely a tool for process improvement. It is an architectural instrument for making digital transformation observable, measurable, and governable.
It connects the formal architecture of the enterprise with its behavioral execution. It converts operational traces into evidence. It transforms process diagrams from static descriptions into hypotheses that can be tested against reality. And it allows digital transformation to be managed not only as system deployment, but as measurable change in the way the enterprise actually works.
Practical roadmap for introducing process mining
Introducing process mining in a corporation should not start from tool selection. It should start from the construction of a measurable process-intelligence capability. The tool is only one component. The decisive elements are event semantics, data access, process ownership, governance, and the ability to convert analytical evidence into operational change.
A practical roadmap can be structured as a staged progression:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
S["1. Scope<br/><b>What question matters?</b><br/>Process, owner, value hypothesis"]
D["2. Data<br/><b>What evidence exists?</b><br/>Systems, tables, timestamps, identifiers"]
E["3. Events<br/><b>What is an event?</b><br/>Case/object model, activities, attributes"]
M["4. Model<br/><b>What behavior is observed?</b><br/>Variants, flows, cycle times, conformance"]
X["5. Diagnose<br/><b>Why does it happen?</b><br/>Bottlenecks, deviations, root causes"]
G["6. Govern<br/><b>Who acts on it?</b><br/>Owners, controls, actions, accountability"]
C["7. Scale<br/><b>How does it become reusable?</b><br/>Standards, templates, cross-entity rollout"]
S --> D --> E --> M --> X --> G --> C
S -. output .-> S1["Process-mining charter"]
D -. output .-> D1["Data-availability matrix"]
E -. output .-> E1["Governed event model"]
M -. output .-> M1["Validated process model"]
X -. output .-> X1["Deviation and impact register"]
G -. output .-> G1["Action and ownership model"]
C -. output .-> C1["Reusable process-intelligence layer"]
Figure 8: Practical roadmap for introducing process mining. The roadmap starts from a bounded business question, verifies data availability, constructs governed event semantics, builds the first process model, diagnoses deviations and bottlenecks, institutionalizes ownership, and then scales the capability across processes and organizational entities.
Each stage reduces a specific uncertainty. The first stages answer whether the required evidence exists. The middle stages test whether the evidence can produce valid process knowledge. The final stages determine whether the organization can act on that knowledge.
Phase 1: define the process question
The first phase is not technical. It is architectural and managerial. The organization must select a process domain where three conditions hold:
the process is economically or operationally material;
the process leaves sufficient digital traces;
the process has an accountable owner able to act on the findings.
Good starting candidates are usually:
procure-to-pay;
order-to-cash;
invoice management;
service-ticket management;
production-order execution;
warehouse fulfillment;
ERP adoption monitoring after go-live.
The initial question should be narrow. For example:
Why are invoices blocked?
is better than:
Analyze procurement.
Similarly:
Which variants delay sales-order fulfillment?
is better than:
Optimize order-to-cash.
The correct first deliverable is therefore a process-mining charter:
Element
Description
Process scope
The process or subprocess to analyze
Business question
The specific operational or control question
Process owner
The accountable business function
Systems in scope
ERP, CRM, MES, WMS, workflow, ticketing, or other systems
Objects in scope
Orders, order lines, invoices, deliveries, payments, tickets, etc.
Expected value
Cost, cycle time, compliance, working capital, service level, adoption
Decision rights
Who can approve remediation actions
Constraints
Privacy, legal, security, system-access, and data-retention constraints
Without this charter, process mining risks becoming exploratory analytics without organizational consequence.
Phase 2: identify source systems and event evidence
The second phase determines whether the process can be reconstructed from available data. For each process, the organization must identify:
the authoritative transactional systems;
the relevant tables, APIs, logs, audit trails, or change documents;
the business objects and their identifiers;
the relevant timestamps;
the lifecycle states;
the users, roles, organizational units, and systems that create events;
the history-retention limits;
the quality of status-change records.
The key question is: can the process be reconstructed from recorded events? A simple data-availability matrix is useful:
Business event
Source system
Source object
Timestamp
Identifier
Available?
Notes
Sales order created
ERP
Sales order header
Creation datetime
Sales order ID
Yes
Header-level event
Delivery created
ERP/WMS
Delivery document
Creation datetime
Delivery ID
Yes
Link to sales order required
Goods issued
ERP/WMS
Delivery posting
Posting datetime
Delivery ID
Yes
May be batch-posted
Invoice posted
ERP
Invoice document
Posting datetime
Invoice ID
Yes
Link to delivery/order required
Payment received
ERP/Bank
Payment clearing
Clearing datetime
Payment ID
Partial
Bank reconciliation rules needed
This phase often reveals that the enterprise does not lack data. It lacks governed event semantics.
Phase 3: define the event model
The event model is the semantic core of process mining. It defines what counts as an event. For a case-centric analysis, the minimum model is:
e = (case, activity, timestamp, resource, attributes)
For an object-centric analysis, the model becomes:
e = (activity, timestamp, resource, attributes, rel(e))
where rel(e) is the set of business objects related to the event.
The organization must decide whether the process is naturally case-centric or object-centric. A case-centric model is suitable when the process has one stable case identifier: ticket, claim, workflow instance, service request, purchase requisition. An object-centric model is preferable when the process crosses many related objects: sales order, sales order line, delivery, shipment, invoice, payment, customer, material, and warehouse.
The event model should be documented as an enterprise artifact. For each event type, the documentation should specify:
Field
Meaning
Event name
Business-level name of the event
Source system
Authoritative system
Source table/API/log
Technical origin
Timestamp rule
Which timestamp is used and why
Object relationship
Which business objects the event relates to
Resource rule
How user, role, system, or agent is assigned
Reversal logic
How cancellations, reversals, and corrections are represented
Granularity
Header-level, line-level, operation-level, or object-level
Data-quality risks
Known limitations
This phase defines the transformation:
\phi : D \rightarrow L_E
where D is raw operational data and L_E is the constructed event-log structure.
Phase 4: build the first event log
The first event log should be small, controlled, and explainable. It should not attempt to cover the entire enterprise. A practical first build may include:
one process;
one legal entity;
one plant, country, or business unit;
three to six months of historical data;
ten to twenty event types;
a limited set of attributes.
The objective is not scale. The objective is semantic validation. The first event log should be tested against basic consistency checks:
Check
Purpose
Missing case identifiers
Detect events that cannot be correlated
Missing timestamps
Detect incomplete event evidence
Timestamp inversions
Detect impossible or suspicious ordering
Duplicate events
Detect repeated technical records
Orphan objects
Detect documents without upstream or downstream links
Extreme durations
Detect outliers, batch postings, or data-quality errors
Unmapped statuses
Detect lifecycle states not covered by the event model
Reversal patterns
Detect cancellations or corrections misread as normal events
Only after these checks does process mining become analytically meaningful.
Phase 5: perform exploratory discovery
The first analytical step is process discovery. The objective is to compare three distinct representations of the same process:
the documented process, namely the process described in procedures, BPMN diagrams, operating manuals, ERP design documents, or internal controls;
the expected process, namely what process owners, key users, and operational managers believe normally happens;
the observed process, namely what the event log reconstructs from system evidence.
The value of process mining is precisely in the tension among these three representations. If the documented process, the expected process, and the observed process coincide, the organization has a coherent operating model. If they diverge, the divergence must be explained: it may indicate an obsolete procedure, an unrealistic target process, local workarounds, system constraints, poor adoption, weak controls, or hidden operational complexity.
The discovery phase should produce:
a directly-follows graph;
the dominant variants;
the rare variants;
loop and rework patterns;
start and end activities;
cycle-time distributions;
waiting-time distributions;
segmentation by relevant attributes.
The critical discipline is not to interpret every discovered edge as meaningful. Some edges are artifacts of timestamp granularity, batch processing, incomplete event extraction, or over-detailed technical events. A discovered process model should be treated as an analytical hypothesis, not as an immediate representation of truth. It is the result of applying a discovery algorithm to a constructed event log; therefore, its validity depends on both the quality of the event model and the correctness of the extraction logic.
Before being used for decisions, the discovered model must be validated with process owners, source-system experts, and data owners. The validation should confirm that the observed paths, variants, loops, skips, and bottlenecks correspond to real operational behavior rather than to timestamp artifacts, incomplete extraction, duplicated records, or misunderstood system statuses.
Phase 6: introduce conformance checking
After discovery, the organization can introduce conformance checking. This requires a reference model: a formal or semi-formal representation of how the process is expected to behave. The reference model may come from:
internal procedures;
ERP template design;
workflow configuration;
control requirements;
compliance rules;
standard operating procedures;
target operating model definitions.
The observed event log is then compared with the behavior allowed by the reference model. In practical terms, this means checking whether real cases follow the expected sequence of activities, respect mandatory controls, avoid forbidden paths, and complete the required steps. The comparison should identify:
activities that occurred but were not expected;
activities that were expected but did not occur;
activities executed in the wrong order;
repeated activities or rework loops;
skipped approvals or controls;
exceptional paths that are legitimate but not yet documented;
deviations caused by incorrect event extraction rather than by real process behavior.
This phase is especially useful for:
skipped approvals;
retrospective purchase-order creation;
invoice before goods receipt;
delivery before credit release;
manual price override after approval;
order changes after confirmation;
blocked invoices released without required remediation;
segregation-of-duties violations.
The deliverable should not be only a deviation list. Each deviation type should be classified:
Deviation class
Interpretation
Typical action
Legitimate variant
Required by business, legal, fiscal, or logistic conditions
Formalize as accepted variant
Process defect
Designed process is incomplete or unrealistic
Redesign process
System defect
ERP/workflow configuration enables wrong behavior
Change configuration
Data defect
Master data or transactional data causes exception
Remediate data
Adoption defect
Users bypass the target process
Training or enforcement
Control violation
Required control is skipped or overridden
Escalate to control owner
Extraction artifact
Deviation caused by wrong event model
Fix event construction
This classification prevents process mining from becoming a purely diagnostic exercise.
Phase 7: quantify performance and economic impact
Once the process structure is understood, the organization should quantify performance. Relevant measures include:
cycle time;
waiting time;
throughput;
work in progress;
rework rate;
exception rate;
automation rate;
manual-touch frequency;
SLA breach probability;
cost of delay;
working-capital impact;
revenue leakage;
discount loss;
compliance exposure.
The key principle is that process-mining findings should be translated into economic or control significance.
For example:
Average invoice-block duration is 12.4 days
is descriptive.
A more useful statement is:
Invoice blocks on suppliers in category X delay payment execution by 12.4 days on average, causing loss of early-payment discounts and increasing manual workload in accounts payable.
Even better:
The top three invoice-block causes explain 67% of blocked-invoice waiting time and are linked to missing purchase-order references, incorrect tax codes, and goods-receipt quantity mismatches.
The analytical target is not process visualization. It is decision-grade evidence.
Phase 8: create process-owner dashboards
Dashboards should be introduced only after the event model and metrics have stabilized. A process-owner dashboard should not be a generic BI page. It should support operational governance. A minimal dashboard structure is:
Dashboard area
Content
Process overview
Volumes, variants, cycle time, throughput
Bottlenecks
Waiting-time distribution by activity, object, unit, resource
Deviations
Conformance violations by type and owner
Root causes
Segmentation by supplier, customer, item, plant, legal entity, channel
Economic impact
Working capital, delay cost, discount loss, revenue leakage
Action queue
Cases requiring remediation or owner decision
Trend view
Whether performance improves after interventions
The dashboard must distinguish between observed fact and recommended action. This distinction is essential for governance and auditability.
Phase 9: define the action model
Process mining becomes transformation-relevant only when the organization defines how insights lead to action. The action model should specify:
which deviations require human review;
which deviations create tasks;
which deviations trigger alerts;
which deviations require workflow changes;
which deviations can be automated;
which deviations are only monitored;
which deviations must be escalated to compliance or internal audit.
A controlled action pattern should make the transition from analytical signal to operational intervention explicit:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
S["Signal<br/>Observed deviation, bottleneck, or exception"]
T["Triage<br/>Classify cause and severity"]
O["Owner<br/>Assign accountable function or role"]
D["Decision<br/>Approve remediation or monitoring"]
A["Action<br/>Process, data, system, or control intervention"]
V["Verification<br/>Check whether the evidence improves"]
S --> T --> O --> D --> A --> V
V -. feedback .-> S
Figure 9: Controlled action pattern for process-mining findings. A process-mining signal is first triaged, then assigned to an accountable owner, converted into a governed decision, executed as an action, and finally verified against the event evidence.
For example:
Signal
Owner
Action
Verification
Invoice blocked for missing PO reference
Accounts Payable
Correct reference or reject invoice
Block removed and invoice posted
PO created after invoice
Procurement control owner
Review maverick buying case
Classified as exception or violation
Delivery delayed after credit block release
Sales operations
Investigate logistics handover
Delivery delay cause assigned
Repeated manual price override
Sales governance
Review pricing policy and approval rule
Override rate reduced
Production order rework loop
Manufacturing engineering
Analyze routing or quality cause
Rework loop frequency reduced
Automation should be introduced only after the causal mechanism is stable. Otherwise, the organization risks automating noise.
Phase 10: scale across processes and entities
Scaling process mining requires standardization. The organization should not build independent event models for every project. It should create a reusable process-intelligence architecture. Scaling requires:
canonical business-object definitions;
reusable event definitions;
common timestamp conventions;
standard quality checks;
shared metric definitions;
governed dashboards;
common lineage model;
access-control model;
data-retention model;
deployment pipeline.
A mature process-intelligence capability should support comparison across entities:
d(L_i, L_j)
where L_i and L_j are event logs from different plants, countries, legal entities, or business units. This allows the enterprise to distinguish:
legitimate local variation;
noncompliant process divergence;
template-adoption failure;
system-configuration drift;
master-data inconsistencies;
organizational performance differences.
Scaling without semantic standardization produces misleading benchmarks. Scaling with semantic standardization creates an empirical operating-model layer.
Phase 11: institutionalize governance
Process mining must eventually become part of enterprise governance. A sustainable governance model includes:
Role
Responsibility
Process owner
Owns process performance, deviations, and improvement actions
Data owner
Owns source data correctness and definitions
Event-model owner
Owns event semantics and transformation rules
Application owner
Owns source-system behavior and configuration constraints
Enterprise architect
Ensures alignment with capability, process, application, and data architecture
Security owner
Controls access, segregation, and technical risk
Privacy/legal owner
Assesses personal-data, labor, and retention implications
Internal control/audit
Defines control rules and reviews deviations
Data engineering team
Operates pipelines, quality checks, and data products
BI/product team
Maintains dashboards and user-facing analytical products
Only after the first use cases have clarified the enterprise’s real needs should the organization decide whether to continue with open source, adopt a commercial platform, or use a hybrid architecture.
The evaluation should be based on the following criteria:
Criterion
Open-source path
Commercial platform path
Hybrid path
Architectural control
High
Medium to low
High for data layer, medium for UX
Speed of rollout
Medium to low
High
Medium
Business-user experience
Depends on internal productization
Usually stronger
Strong if well integrated
Connectors
Custom or generic
Often packaged
Mixed
Event semantics
Fully owned internally
Often platform-mediated
Internally owned
Object-centric modeling
Possible, but engineering-intensive
Productized in advanced platforms
Internally governed, externally consumed
Task mining
Weak open-source maturity
Stronger commercial maturity
Commercial only where justified
License cost
Lower direct cost
Higher direct cost
Mixed
Engineering effort
Higher
Lower
Medium
Vendor lock-in
Lower at data layer
Higher
Reduced if data layer remains independent
Support model
Internal/community/consultancy
Vendor-backed
Mixed
The most robust corporate strategy is often hybrid: own the process-data and semantic layer, while buying or building analytical and user-facing capabilities selectively. This prevents the enterprise from losing control of its process semantics while still allowing commercial acceleration where it is economically justified.
Minimal implementation sequence
The first implementation should not try to cover the enterprise. It should prove one thing: that operational traces can be converted into governed evidence, and that governed evidence can drive measurable change.
The sequence is deliberately narrow:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
A["Select one high-value process<br/><b>Do not start enterprise-wide</b>"]
B["Define one precise question<br/><b>What decision should this evidence support?</b>"]
C["Identify source systems and timestamps<br/><b>Where is the process recorded?</b>"]
D["Define the case or object model<br/><b>What is being followed?</b>"]
E["Build the first event log<br/><b>Small, explainable, auditable</b>"]
F["Validate with process and system experts<br/><b>Remove semantic errors before analysis</b>"]
G["Discover variants and bottlenecks<br/><b>What actually happens?</b>"]
H["Compare with the reference model<br/><b>What should have happened?</b>"]
I["Classify deviations<br/><b>Cause, owner, severity</b>"]
J["Quantify impact<br/><b>Cost, time, risk, working capital, control exposure</b>"]
K["Build the process-owner dashboard<br/><b>Evidence for action, not decoration</b>"]
L["Define remediation actions<br/><b>Process, data, system, control, training</b>"]
M["Measure the effect<br/><b>Did the gap actually shrink?</b>"]
N["Standardize the event model<br/><b>Make it reusable</b>"]
O["Scale to adjacent processes or entities<br/><b>Only after semantic stability</b>"]
A --> B --> C --> D --> E --> F --> G --> H --> I --> J --> K --> L --> M --> N --> O
M -. "if no improvement" .-> I
F -. "if log is wrong" .-> D
Figure 10: Minimal implementation sequence for process mining. The first implementation starts from a high-value process and a precise business question, builds and validates the event model, discovers and explains deviations, converts findings into governed actions, and then standardizes the model for reuse.
The sequence is a control loop, not a reporting project. Each step must either increase the reliability of the evidence or increase the organization’s ability to act on it.
A weak implementation stops at a process map. A serious implementation continues until deviations are owned, causes are classified, actions are executed, and the next event log shows whether the gap has narrowed.
The practical test is simple:
Can the enterprise observe the gap between intended and executed behavior, explain why the gap exists, assign ownership, intervene, and verify that the intervention worked?
If the answer is yes, process mining has stopped being analytics. It has become part of the enterprise transformation system.
Conclusion
Process mining is the computational reconstruction of operational behavior from event data. Its foundations are elementary: events, time, ordering, correlation, and process semantics. Its implementation is difficult because enterprise reality is not a clean sequence of activities. It is a multi-object, multi-system, multi-agent, temporally distributed structure in which orders, deliveries, invoices, payments, materials, resources, systems, and organizational units interact continuously.
The technical core consists of event-log construction, process discovery, variant analysis, behavioral entropy, conformance checking, performance mining, object-centric modeling, and operational intervention. Each layer answers a different question. Discovery shows what happened. Variant analysis shows how fragmented the behavior is. Conformance checking shows where observed execution diverges from expected behavior. Performance mining shows where time, queues, rework, and throughput losses accumulate. Object-centric process mining extends the analysis from linear case traces to the object networks that characterize real ERP, supply-chain, manufacturing, finance, and service processes.
The central constraint is semantic correctness. Process mining does not extract truth directly from systems. It extracts models from constructed event logs. The decisive transformation is therefore the event-construction function:
D \xrightarrow{\phi} L_E
where D is raw operational data and L_E is the event log or object-centric event structure. If this transformation is wrong, all subsequent analysis may be formally valid and operationally false. This is why process mining is not only an algorithmic discipline. It is also a data-engineering, semantic-governance, and enterprise-architecture discipline.
The full inference chain can be expressed as:
D \xrightarrow{\phi} L_E \xrightarrow{mine} M \xrightarrow{evaluate} I \xrightarrow{govern} A
where:
D is raw operational data;
\phi is the semantic event-construction function;
L_E is the event log or object-centric event structure;
M is the discovered, reference, or normative process model;
I is the set of insights, deviations, bottlenecks, variants, risks, and predictions;
A is the set of governed actions.
Every arrow in this chain can fail. Raw data can be incomplete. Event construction can be semantically wrong. Models can overfit. Deviations can be misclassified. Bottlenecks can be correlated with the wrong cause. Dashboards can create visual confidence without decision quality. Actions can optimize local metrics while damaging the global system.
For this reason, process mining should be framed as a control system rather than as a reporting layer. Its practical value does not end with a process map. It emerges when the enterprise can observe the gap between intended and executed behavior, explain the causes of that gap, assign ownership, intervene through process, data, system, control, or organizational changes, and then verify from subsequent event evidence whether the gap has actually narrowed.
This interpretation makes process mining directly relevant to enterprise architecture and digital transformation. Enterprise architecture defines the intentional enterprise: capabilities, processes, applications, data, organization, and governance. Process mining reconstructs the observed behavioral enterprise from operational traces. The difference between the two is one of the most important objects of transformation. It shows where the designed operating model is real, where it is only nominal, where local variants are justified, where they are accidental, and where systems or organizational practices undermine the intended architecture.
The practical roadmap must therefore start narrow and become governed before it becomes large. The correct sequence is not to buy a tool and search for use cases. It is to select one material process, define one precise business question, identify the source systems and timestamps, define the case or object model, build a small and auditable event log, validate it with process and system experts, discover variants and bottlenecks, compare observed behavior with the reference model, classify deviations, quantify impact, create a process-owner dashboard, define remediation actions, measure their effect, and only then standardize and scale.
Commercial platforms such as Celonis industrialize several parts of this architecture: ingestion, object-centric modeling, process applications, task mining, dashboards, automation, and operationalization. Their value should therefore be evaluated not only as visualization products, but as process-intelligence operating layers. At the same time, the fundamental architectural question remains independent of any platform: which process semantics must the enterprise own, which analytical capabilities can be bought, and which actions can be automated without weakening governance or control?
Used superficially, process mining becomes another form of dashboarding. Used rigorously, it becomes a measurable, reproducible, and continuously refreshable representation of how the enterprise actually operates. Its strongest contribution is not the automatic discovery of process diagrams. It is the disciplined conversion of operational traces into governed evidence, and of governed evidence into accountable transformation.
Appendix — Dynamical allocation of resources to forecasted demand with process-mining feedback
This appendix formulates a toy continuous-time problem in which process mining is used to improve the dynamic allocation of resources to forecasted demand. The model is intentionally simplified, but it captures the essential structure of the problem:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
D["Forecasted demand<br/>lambda_hat(t), D_hat(t)"] --> A["Resource allocation<br/>U(t), x_star(t)"]
A --> E["Process execution<br/>dq/dt = lambda(t) - (I - P^T)y(t)"]
E --> L["Event log<br/>events, timestamps, resources, objects"]
L --> U["Parameter and structure update<br/>theta to theta_PM, G_norm to G_obs"]
U --> NA["New allocation<br/>U(t+1), x_star(t+1)"]
NA -. feedback .-> A
Figure 11: Process mining as a feedback loop for dynamic resource allocation. Forecasted demand drives resource allocation, resource allocation determines process execution, execution generates event logs, and event logs update both model parameters and model structure before the next allocation cycle.
The central idea is that process mining contributes in two mathematically distinct ways:
It improves the numerical parameters of the model: arrival rates, service rates, routing probabilities, rework probabilities, queue lengths, cycle times, and resource productivity.
It can change the equations themselves, because the discovered process may contain edges, loops, bypasses, or exception paths that were absent from the normative model.
The problem is therefore not only parameter estimation. It is also model-structure identification.
Process as a directed flow network
Let the process be represented as a directed graph:
G = (V,\mathcal{E})
where:
V = \{1,\ldots,n\} is the set of process activities, queues, or operational states;
\mathcal{E} \subseteq V \times V is the set of admissible transitions between activities.
Examples of nodes in an invoice-management process may be:
Node
Meaning
1
Invoice received
2
Formal validation
3
Three-way match
4
Exception handling
5
Approval
6
Posting
7
Payment scheduling
8
Completed
Let:
q_i(t) \geq 0
be the workload or backlog at node i at time t. The vector of process-state backlogs is:
This function has the correct qualitative behavior:
if no resources are allocated to activity i, then y_i(t)=0;
if no workload exists at activity i, then y_i(t)=0;
if workload is high, the outflow approaches the allocated processing capacity.
Routing matrix
Let:
P = [p_{i,k}]
be the routing matrix, where p_{i,k} is the probability that a case completed at node i moves next to node k. For transitions not present in \mathcal{E}, one has p_{i,k}=0.
The row sum may be less than one:
\sum_{k=1}^{n} p_{i,k} \leq 1
because some cases exit the process after node i. The exit probability is:
p_{i,\varnothing}
=
1 - \sum_{k=1}^{n} p_{i,k}
The matrix P is not merely a technical parameter. It is the mathematical representation of the discovered process structure.
In a normative model, P may contain only expected forward transitions. In an observed model, process mining may reveal:
rework edges;
exception paths;
skipped activities;
backflows;
manual bypasses;
alternative approval routes;
repeated loops.
These discovered transitions change P and therefore change the differential equations.
Forecasted demand as external inflow
Let:
\lambda_i(t)
be the external arrival rate into node i.
In many processes, external demand enters only at the first activity:
In more complex processes, demand may enter several nodes. For example, invoices may enter through standard invoice intake, exception intake, correction requests, supplier queries, or imported legacy items.
Process mining improves \lambda(t) by estimating empirical arrival rates from event logs, segmented by time, object type, legal entity, supplier, customer, plant, channel, or document class.
This is the core dynamical system. The control variable is the resource allocation U(t). The observed state is q(t). The forecasted input is \lambda(t). The structural parameter is P. The productivity parameters are \beta_{j,i} and K_i.
Toy three-node example
Consider a simplified invoice process with three operational states:
Node
Meaning
1
Invoice intake
2
Validation and matching
3
Exception handling
Cases exit the process after validation if no exception exists. Some validation cases move to exception handling. Some exception cases return to validation after remediation.
The observed process graph is:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
N1["1<br/>Invoice intake"] --> N2["2<br/>Validation and matching"]
N2 --> N3["3<br/>Exception handling"]
N3 --> N2
N2 --> X["Exit"]
N3 --> X
Figure 12: Toy three-node invoice process with exception rework. Invoices enter the intake node, move to validation and matching, may proceed to exception handling, and can either exit the process or return to validation after remediation.
Let:
q_1(t),\ q_2(t),\ q_3(t)
be the backlogs at intake, validation, and exception handling. Let the routing matrix be:
p_{23} is the probability that a validation case becomes an exception;
p_{32} is the probability that an exception case returns to validation;
1-p_{23} is the probability that a validation case exits successfully;
1-p_{32} is the probability that an exception case exits after remediation.
The dynamics are:
\dot{q}_1(t)
=
\lambda_1(t)
-
y_1(t)
\dot{q}_2(t)
=
y_1(t)
+
p_{32}y_3(t)
-
y_2(t)
\dot{q}_3(t)
=
p_{23}y_2(t)
-
y_3(t)
The service functions are:
y_1(t)
=
\frac{
\mu_1(t)q_1(t)
}{
K_1 + q_1(t)
}
y_2(t)
=
\frac{
\mu_2(t)q_2(t)
}{
K_2 + q_2(t)
}
y_3(t)
=
\frac{
\mu_3(t)q_3(t)
}{
K_3 + q_3(t)
}
where:
\mu_i(t)
=
\sum_{j=1}^{m}\beta_{j,i}u_{j,i}(t)
This system is small, but it captures a real operational mechanism: if too many validation cases become exceptions, and if too many exceptions return to validation, the process can generate self-reinforcing workload.
Rework amplification and stability
The expected number of validation visits generated by one case can increase when the process contains loops. In the three-node model, the loop is:
2 \rightarrow 3 \rightarrow 2
The loop gain is:
g = p_{23}p_{32}
If g is close to zero, rework is limited. If g approaches one, the process repeatedly circulates cases between validation and exception handling. A necessary condition for finite expected loop repetitions is:
p_{23}p_{32} < 1
The expected number of visits to validation caused by this loop is proportional to:
\frac{1}{1-p_{23}p_{32}}
Thus, even moderate increases in p_{23} or p_{32} can materially increase workload. This is precisely where process mining contributes. It estimates the actual loop probabilities from observed traces:
where N_{a \rightarrow b} is the number of observed directly-follows transitions from activity a to activity b.
If the normative model assumes p_{32}=0, but the event log shows \hat{p}_{32}>0, the equations must change. The term:
p_{32}y_3(t)
must be added to \dot{q}_2(t).
That is not parameter tuning. It is structural correction of the dynamical system.
Normative model versus process-mined model
Suppose the original normative model assumes no rework from exception handling back to validation. Then:
p_{32}^{norm}=0
The normative system is:
\dot{q}_1(t)
=
\lambda_1(t)
-
y_1(t)
\dot{q}_2(t)
=
y_1(t)
-
y_2(t)
\dot{q}_3(t)
=
p_{23}^{norm}y_2(t)
-
y_3(t)
This model says that exceptions are resolved independently and do not feed back into validation.
Now suppose process mining discovers that 60% of exception cases return to validation:
\hat{p}_{32}=0.60
Then the process-mined system is:
\dot{q}_1(t)
=
\lambda_1(t)
-
y_1(t)
\dot{q}_2(t)
=
y_1(t)
+
0.60y_3(t)
-
y_2(t)
\dot{q}_3(t)
=
\hat{p}_{23}y_2(t)
-
y_3(t)
The additional term:
0.60y_3(t)
changes the dynamics of validation. The validation queue is no longer driven only by new intake. It is also driven by remediated exceptions returning for revalidation. This is a mathematically explicit example of process mining changing the expression of the model.
Resource allocation as a control problem
The allocation problem is to choose U(t) so that the system remains stable and performance improves. A simple one-step objective is:
This is a continuous-time optimal-control problem.
In practical enterprise use, it would usually be solved in discretized form over daily, weekly, or shift-level intervals. The continuous-time formulation is still useful because it makes the causal structure explicit: backlog is a state variable, resource allocation is a control variable, process execution is the plant, and process mining is the empirical observation mechanism that updates both parameters and equations.
How process mining improves the input parameters
The model depends on the parameter vector:
\theta =
(P, \beta, K, \lambda)
where:
P is the routing matrix;
\beta is the resource-productivity matrix;
K contains the saturation constants;
\lambda(t) is the arrival-rate vector.
Process mining improves each of these quantities by estimating them from observed event data rather than from nominal process documentation, static master data, or managerial assumptions.
Routing probabilities
From event logs, process mining estimates transition frequencies:
N_{i \rightarrow k}
where N_{i \rightarrow k} is the number of observed transitions from node i to node k. Then:
where z may denote plant, supplier, customer, legal entity, product family, priority, channel, document type, or any other attribute that materially changes process behavior.
Resource productivity
Let C_i([t,t+\Delta t]) be the number of completions at node i in the interval [t,t+\Delta t] and u_{j,i}(\tau) be the observed allocation of resource pool j to node i at time \tau. The model:
and the productivity estimate becomes approximately:
\hat{\beta}_{j,i}
\approx
\frac{
\text{completed cases at node } i \text{ by resource pool } j
}{
\text{resource time allocated from pool } j \text{ to node } i
}
This estimate is not a theoretical capacity. It is an observed productivity coefficient derived from execution data.
Queue lengths and cycle times
Process mining also estimates the queue length at each node:
q_i(t)
=
\left|
\{c : c \text{ is active at node } i \text{ at time } t\}
\right|
and the empirical sojourn time of case c at node i:
S_i(c)
=
time_{out,i}(c) - time_{in,i}(c)
From this, one obtains the empirical mean sojourn time:
These estimates can be used to validate whether the state equation correctly represents the observed accumulation and depletion of work.
How process mining changes the expressions
The previous subsection describes parameter improvement. The deeper contribution is structural. Suppose the designed process model contains the edge set:
This changes the terms in each component equation. For example, if edge (3,2) is discovered, then \dot{q}_2(t) gains a new inflow term:
+p_{3,2}y_3(t)
If edge (1,3) is discovered, then \dot{q}_3(t) gains a new inflow term:
+p_{1,3}y_1(t)
If a skip edge (2,4) is discovered, then \dot{q}_3(t) may lose expected flow because not all completions from node 2 go to node 3. Thus process mining does not merely refine:
p_{i,k}
It may change whether p_{i,k} exists at all. This is model-structure learning. Process mining changes the mathematical object being optimized: not only the values inside the equations, but the equations themselves.
Attribute-dependent dynamics
In enterprise processes, routing is often not homogeneous. The probability of moving from activity i to activity k may depend on contextual attributes. Let z(t) be an attribute vector:
That change is essential for corporate use, because a single average process model may conceal the operational mechanisms that actually matter.
Exception-induced nonlinearities
Process mining may also reveal that exception probabilities increase with backlog or waiting time. This produces nonlinear dynamics. For example, suppose the probability that validation creates an exception is:
This expresses an operational fact often visible in process logs: when queues become large, errors, escalations, repeated touches, and clarification loops may increase.
Process mining detects this by showing that exception probabilities are not constant, but conditional on backlog, waiting time, resource pool, or case attributes. A linear normative model:
\dot{q}_3(t)
=
p_{23}y_2(t)
-
y_3(t)
is therefore replaced by a nonlinear observed model:
This is an uncontrolled positive feedback loop in the process itself. The goal of dynamic allocation is to impose a controlled feedback loop in the opposite direction:
or even priority allocation to exception handling:
u_{\cdot,3}(t) \uparrow
if the dominant cause of validation backlog is returning exception work. This is a concrete example where process mining changes the managerial conclusion by changing the dynamical equations.
However, structural changes require a different operation. If process mining discovers a statistically material edge (i,k) not present in the normative graph, then:
where \rho(\tau) is a vector of rework or exception intensities. For example:
\rho_i(\tau)
=
y_i(\tau)
\sum_{k: k \prec i} p_{i,k}(\tau)
where k \prec i denotes a backward or rework transition from node i to node k. This definition measures rework flow, not merely rework probability, because it weights the backward-routing probability by the actual outflow from node i.
The optimization penalizes:
backlog;
rework intensity;
unstable resource allocation.
Only the first control action is implemented. Then the process executes, new events are observed, process mining updates the model, and the optimization is solved again.
What process mining adds mathematically
Without process mining, the organization often uses a static model:
and where \hat{P}^{PM} may have a different sparsity pattern from P^{norm}.
The difference is not cosmetic. It changes:
the state equations;
the stability properties;
the bottleneck interpretation;
the optimal allocation;
the expected effect of interventions;
the governance discussion.
Compact numerical illustration
Assume the three-node system:
\dot{q}_1
=
\lambda
-
y_1
\dot{q}_2
=
y_1
+
p_{32}y_3
-
y_2
\dot{q}_3
=
p_{23}y_2
-
y_3
Let:
\lambda = 100
The normative model assumes:
p_{23}^{norm}=0.10,\quad p_{32}^{norm}=0
Process mining estimates:
\hat{p}_{23}=0.25,\quad \hat{p}_{32}=0.60
Assume high backlog, so that service rates approximate capacities:
y_i \approx \mu_i
Suppose the current allocation produces:
\mu_1=100,\quad \mu_2=100,\quad \mu_3=20
Under the normative model:
\dot{q}_1 = 100-100=0
\dot{q}_2 = 100-100=0
\dot{q}_3 = 0.10(100)-20=-10
The normative model predicts stability, or even a reduction of the exception backlog. Under the process-mined model:
\dot{q}_1 = 100-100=0
\dot{q}_2 = 100 + 0.60(20)-100=12
\dot{q}_3 = 0.25(100)-20=5
The observed model predicts that both validation and exception backlogs grow. The difference is caused by two process-mined corrections:
p_{23}: 0.10 \rightarrow 0.25
and:
p_{32}: 0 \rightarrow 0.60
The second correction changes the equation for \dot{q}_2 by adding:
+0.60y_3
The result is a different allocation decision. Increasing only \mu_2 may not solve the problem. The model indicates that \mu_3 must also increase to reduce the returning exception flow. For example, if the allocation changes to:
\mu_1=100,\quad \mu_2=120,\quad \mu_3=30
then:
\dot{q}_1 = 0
\dot{q}_2 = 100 + 0.60(30)-120=-2
\dot{q}_3 = 0.25(120)-30=0
The validation backlog starts decreasing, and the exception backlog stops growing. This is the basic mathematical role of process mining in dynamic allocation: it changes the inferred system from a falsely stable system into an accurately unstable one, and it changes the control decision accordingly.
and, more importantly, by identifying whether the graph G=(V,\mathcal{E}) itself is wrong. Therefore, process mining improves the dynamic allocation problem at two levels:
The first makes the numbers better. The second makes the equations truer. This is why process mining is not merely descriptive analytics. In a dynamic-resource-allocation setting, it becomes the empirical observation mechanism through which the enterprise identifies the real process, estimates its parameters, detects destabilizing feedback loops, and changes the allocation policy before backlog, rework, and cycle time amplify.
Appendix — From process mining to a mathematical S&OP decision model
This appendix reverses the usual interpretation of process mining. The conventional view is:
process mining → process discovery → process visualization → process improvement.
The stronger interpretation is:
process mining → empirical system identification → mathematical model → optimization → governed decision-making → S&OP control loop.
In this view, process mining is not the final analytical product. It is the observation mechanism through which the enterprise infers the real mathematical structure of its operating system.
The target is a full Sales & Operations Planning (S&OP) model in which demand, capacity, inventory, procurement, production, logistics, service levels, financial constraints, and process execution are not treated as disconnected managerial topics, but as one dynamic constrained optimization problem.
where N_{i \rightarrow j} is the number of observed transitions from node i to node j, and \varepsilon is a materiality threshold. The first correction is structural:
G^{norm} \rightarrow G^{obs}
This may add or remove equations. For example, if the normative model assumes:
This is the first point at which process mining changes the mathematical model. It does not merely improve parameters. It changes the topology of the system.
Calibrated dynamical model
The next step is to convert the observed process graph into a dynamical system. Let:
q_i(t)
be the workload, queue, or WIP at process node i.
Let:
y_i(t)
be the outflow from node i.
Let:
\lambda_i(t)
be the external inflow into node i. The process dynamics are:
This is a calibrated dynamical model of execution.
Local decision model: resource allocation
The first optimization problem is local resource allocation. Given the current state q(t), forecasted inflow \lambda(t), observed routing matrix P^{obs}(t), and resource productivity \beta(t), choose the allocation matrix:
U(t) = [u_{ri}(t)]
to reduce backlog, cycle time, and rework. A local control problem over horizon H is:
\sum_i u_{ri}(\tau) \leq R_r(\tau)
\quad \forall r
u_{ri}(\tau)\geq 0
\quad \forall r,i
where:
W weights backlog criticality;
V weights rework or exception intensity;
\eta penalizes excessive resource reallocations;
R_r(\tau) is available resource capacity.
This model is already useful, but it remains local. It optimizes execution capacity inside a process. S&OP requires a larger model: the enterprise must decide what to sell, produce, buy, move, stock, prioritize, delay, substitute, outsource, or escalate. The model must therefore evolve again:
M_3 \rightarrow M_4
Extension from process execution to S&OP state variables
A full S&OP model requires state variables beyond process queues.
Let:
i \in \mathcal{I} index products or product families;
l \in \mathcal{L} index locations, plants, warehouses, or markets;
s \in \mathcal{S} index suppliers;
r \in \mathcal{R} index resources or capacity pools;
t \in \{1,\ldots,T\} index planning periods.
The main state variables are:
I_{i,l,t}
inventory of product i at location l;
B_{i,l,t}
backlog or unmet demand;
WIP_{p,t}
work in progress in production or operational process p;
Q_{i,l,t}
quality-blocked or unavailable stock;
C_{r,l,t}
available capacity of resource r at location l in period t;
A_{i,l,t}
available-to-promise quantity;
D_{i,l,t}
demand for product i at location l in period t. The decision variables include:
x_{i,l,t}^{prod}
production quantity;
x_{i,s,l,t}^{buy}
procurement quantity from supplier s;
x_{i,l,l',t}^{trans}
transfer quantity from location l to location l';
x_{i,l,t}^{ship}
shipment to customer demand;
x_{r,p,t}^{alloc}
capacity allocated from resource r to process p;
x_{i,l,t}^{sub}
substitution quantity;
x_{i,l,t}^{lost}
lost sales or unserved demand. S&OP is therefore not one equation. It is a coupled system of material, capacity, demand, and process-execution equations.
Demand model with process-mined demand realization
The commercial forecast is:
\hat{D}_{i,l,t}
but observed demand realization differs from the forecast.
Let:
D_{i,l,t}
=
\hat{D}_{i,l,t}
+
\varepsilon_{i,l,t}
where \varepsilon_{i,l,t} is forecast error.
Process mining contributes by distinguishing demand events from process artifacts. For example, apparent demand may include:
duplicate orders;
cancelled orders;
changed orders;
backorder re-promising;
split deliveries;
intercompany demand;
emergency replenishment;
manual order corrections.
Therefore the process-mined demand signal is not merely sales-order volume. It is a cleaned event-derived signal:
\tilde{D}_{i,l,t}
=
\Psi_D(E_t)
where \Psi_D is the process-mining transformation that extracts true demand events from raw operational traces. The demand model becomes:
\hat{D}^{stat} is the statistical or commercial forecast;
\tilde{D} is the process-mined realized demand signal;
\alpha_D controls how strongly event evidence updates the forecast.
Inventory balance equations
For each product i, location l, and period t, let I_{i,l,t} denote physical inventory. Available inventory is derived later by subtracting quality-blocked, reserved, and otherwise unavailable quantities.
L_{s,i,l}^{buy} is procurement lead time from supplier s to location l for product i;
L_{l',l}^{trans} is transfer lead time from location l' to location l;
\operatorname{scrap}_{i,l,t} is scrapped or physically lost quantity.
Process mining improves the lead-time parameters:
L_{s,i,l}^{buy}
\rightarrow
\hat{L}_{s,i,l}^{PM}
L_{l',l}^{trans}
\rightarrow
\hat{L}_{l',l}^{PM}
by measuring actual elapsed times between operational events: purchase-order creation, supplier confirmation, shipment, receipt, quality release, warehouse availability, transfer creation, transfer shipment, transfer receipt, and stock availability.
Process mining may also change the inventory model itself when it reveals hidden inventory states. For example, if material is often physically received but then blocked in quality inspection, the simple assumption that receipt immediately implies availability is false. The model must distinguish physical inventory from available inventory.
\operatorname{reserved}_{i,l,t} is inventory reserved for existing demand or allocations;
\operatorname{blocked}_{i,l,t} is inventory unavailable for other administrative, compliance, or operational reasons.
This is a structural correction caused by process mining. The planning model no longer treats all physical stock as usable stock. It separates inventory existence from inventory availability, which is essential for S&OP, available-to-promise calculation, shortage analysis, and service-level planning.
Capacity equations
Production and operational capacity are constrained. Let:
a_{r,i,l}
be the capacity consumption of product i at location l on resource r. Then:
overtime and outsourcing are optional capacity-expansion decisions.
Process mining contributes by replacing nominal routing times with empirical routing times:
a_{r,i,l}^{norm}
\rightarrow
\hat{a}_{r,i,l}^{PM}
For example, if ERP routing says that an operation requires 0.20 hours per unit, but event logs from MES and ERP confirmations show 0.28 hours with high variance, the planning model must use the observed coefficient or at least model the discrepancy. The capacity model becomes:
a_{r,i,l,t}
=
\hat{a}_{r,i,l}^{PM}(z,t)
where z may include product variant, batch size, machine, shift, operator group, raw-material origin, quality grade, or plant.
This decomposition is not available from a standard planning model. It is inferred from event traces.
Rework, yield, and exception dynamics
S&OP models often assume that planned output becomes immediately available output. Process mining frequently shows that this is false. The difference may come from permanent losses, temporary unavailability, quality holds, rework loops, or exception-handling workload. These effects should not be collapsed into one generic yield coefficient.
Let:
Y_{i,l,t}
be the physical yield of production or fulfillment for product i at location l in period t. Physical yield should represent permanent output loss, such as scrap or irreversible rejection, not temporary unavailability.
A process-mined physical yield can be expressed as:
\operatorname{scrap}_{i,l,t} is permanently scrapped quantity;
\operatorname{rejected}_{i,l,t} is irreversibly rejected quantity;
x_{i,l,t}^{prod} is planned or executed production quantity.
However, physical yield is not sufficient to determine available output. Some quantity may be physically produced but not yet available for demand fulfillment because it is blocked, reserved, unreleased, under inspection, or pending administrative completion.
This expression assumes that the numerator categories are disjoint for the period considered; otherwise, the same quantity could be subtracted more than once.
where A^{out}_{i,l,t} is the quantity that can actually contribute to available supply in the S&OP model.
This distinction is important. Scrap and irreversible rejection reduce physical yield. Quality blocks and unreleased quantities reduce availability, but they may later become available after inspection, release, correction, or approval. Rework is different again: it may not directly reduce output, but it consumes capacity, increases lead time, and may generate additional process load.
For this reason, exception intensity should be indexed according to the mechanism it affects. Three separate quantities are useful:
\rho^{capacity}_{r,l,t}
for exceptions that consume or reduce resource capacity;
\rho^{demand}_{i,l,t}
for exceptions that generate additional demand-like workload;
\rho^{process}_{p,t}
for exceptions or rework loops measured at process level.
A generic process-mined exception-intensity function can be written as:
\rho_{p}^{0} is baseline exception intensity for process p;
WIP_{p,t} is work in progress in process p;
H_{p} is a saturation parameter;
z_{p,t} is a vector of contextual variables;
\alpha_{p} measures the sensitivity of exception intensity to WIP;
\delta_{p} measures the sensitivity of exception intensity to contextual attributes.
The effect of exception intensity depends on the operational mechanism. If exceptions primarily consume additional capacity, they reduce effective capacity:
where \rho^{lead}_{i,l,t} denotes the process-mined lead-time amplification factor for product i at location l in period t.
Process mining estimates these quantities from rework loops, repeated touches, reversals, cancellations, quality holds, release delays, correction cycles, and exception paths. The mathematical contribution is the separation of three effects that are often confused in planning models:
This separation makes the S&OP model more operationally faithful. It prevents the planning system from treating every deviation as lost output and allows different interventions: yield improvement for scrap, release acceleration for blocked stock, and capacity or process redesign for rework.
Integrated S&OP optimization problem
The full S&OP problem can now be written as a rolling-horizon stochastic or deterministic optimization model. A deterministic equivalent is:
This is the integrated S&OP mathematical model. Process mining enters the model through the superscript PM. It supplies empirically observed parameters:
In the final established state, process mining is no longer an occasional diagnostic exercise. It becomes part of the enterprise planning and control system. The mature S&OP state can be represented as:
The S&OP process is then no longer merely a monthly meeting sequence. It becomes a governed optimization loop:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
S["Sense"] --> M["Model"]
M --> O["Optimize"]
O --> D["Decide"]
D --> E["Execute"]
E --> L["Learn"]
L -. feedback .-> S
Figure 13: Governed S&OP optimization loop. Process mining supports the sensing layer, the mathematical model supports optimization, governance converts optimization into decisions, and execution produces new event evidence.
Meaning for S&OP governance
This formulation changes the meaning of S&OP:
A traditional S&OP process often reconciles demand and supply through meetings, spreadsheets, assumptions, and negotiated compromises.
A process-mining-enabled S&OP process reconciles demand and supply through an empirically calibrated model of enterprise execution.
The practical differences are substantial:
Demand is not only forecasted. It is corrected by observed order behavior.
Supply is not only planned. It is constrained by observed capacity, lead time, yield, rework, and exception behavior.
Inventory is not only counted. It is classified by availability, quality status, reservation, blockage, and process position.
Capacity is not only nominal. It is empirically measured through event traces.
Service level is not only reported. It is decomposed into causal failure modes.
The plan is not only approved. It is tested against the observed dynamics of the enterprise.
Conceptually, the mature S&OP process is an optimization problem over forecasts, constraints, observed process dynamics, and governance rules.
where \mathcal{X}^{PM} is the feasible set defined by material, capacity, financial, service, governance, and process-dynamic constraints inferred or corrected through process-mining evidence.
Conclusion
The evolution from process mining to S&OP can be summarized as follows:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
E["Event logs"] --> G["Observed process graph"]
G --> D["Dynamical execution model"]
D --> R["Local resource optimization"]
R --> S["Integrated supply-demand optimization"]
S --> C["Rolling S&OP control system"]
Figure 14: Evolution from process mining to a rolling S&OP control system. Event logs are transformed into an observed process graph, then into a dynamical execution model, then into local resource optimization, then into integrated supply-demand optimization, and finally into a rolling S&OP control system.
At the beginning, process mining explains what happened, but at the mature state, process mining helps decide what should happen next.
The strongest form of process mining is therefore not process visualization. It is empirical system identification for enterprise optimization. In a full S&OP setting, the value of process mining is not that it draws the real process. The value is that it makes the real process mathematically usable. It supplies the missing bridge between operational execution and decision science:
%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
R["Operational reality"] --> E["Event data"]
E --> M["Mathematical model"]
M --> O["Optimization"]
O --> A["Governed action"]
Figure 15: Process mining as the bridge between operational execution and decision science. Reality generates event data; event data feed a model; the model supports optimization; optimization produces governed action.
IEEE Task Force on Process Mining, (2012). Process Mining Manifesto. Webpage. From the manifesto: The idea of process mining is to discover, monitor and improve real processes (i.e., not assumed processes) by extracting knowledge from event logs readily available in today’s (information) systems. Process mining includes (automated) process discovery (i.e., extracting process models from an event log), conformance checking (i.e., monitoring deviations by comparing model and log), social network/organizational mining, automated construction of simulation models, model extension, model repair, case prediction, and history-based recommendations.↩︎
van der Aalst, W. (2016). Process mining: Data science in action (2nd ed.). Springer Berlin Heidelberg. DOI↩︎
XES, the eXtensible Event Stream standard, is a standard format for representing and exchanging event logs and event streams in process mining. The current IEEE version is IEEE 1849-2023, IEEE Standard for eXtensible Event Stream (XES) for Achieving Interoperability in Event Logs and Event Streams. See also the XES standardization initiative website.↩︎
A Petri net is a formal model for representing discrete-event systems, especially systems with concurrency, synchronization, conflict, and resource constraints. It is usually defined as a bipartite graph composed of places, transitions, and directed arcs. Places may contain tokens, and the distribution of tokens across places is called a marking, which represents the current state of the system. A transition is enabled when its input places contain the required tokens; when it fires, it consumes tokens from its input places and produces tokens in its output places. In process mining, Petri nets are often used because they provide precise execution semantics for process models, making it possible to reason formally about reachability, deadlocks, parallelism, loops, and conformance between an observed event log and a normative process model. See: Murata, T. (1989). Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4), 541–580. DOI↩︎
Little’s Law is a fundamental result of queueing theory. In its standard form, it states that the long-run average number of items in a stable system, usually denoted by L, is equal to the long-run average arrival rate, \lambda, multiplied by the average time an item spends in the system, W: L = \lambda W. In process mining and operations analysis, this relation is useful because it links work in progress, throughput, and cycle time. See: Little, J. D. C. (1961). A proof for the queuing formula: L = \lambda W. Operations Research, 9(3), 383–387. DOI↩︎
OCEL 2.0 is a standard format for representing object-centric event logs, where events may be related to multiple business objects rather than to a single case identifier. This makes it suitable for complex enterprise processes involving interacting objects such as orders, deliveries, invoices, payments, materials, and resources. See: Berti, A., Koren, I., Adams, J. N., Park, G., Knopp, B., Graves, N., Rafiei, M., Liß, L., Tacke Genannt Unterberg, L., Zhang, Y., Schwanen, C., Pegoraro, M., & van der Aalst, W. M. P. (2023). OCEL (Object-Centric Event Log) 2.0 specification (Version 2.0). Chair of Process and Data Science, RWTH Aachen University. PDF↩︎
