Process Mining in Manufacturing with Purchased Components and Variable Lead Times

Manufacturing delays are rarely caused by a single isolated bottleneck. They emerge from the interaction of procurement, supplier lead times, quality release, warehouse availability, material reservations, production execution, testing, rework, and shipment. This article explains how process mining can reconstruct that operational reality from ERP, MES, WMS, QMS, procurement, supplier, and logistics events. Using the example of a smart dosing pump assembled from purchased components and internal operations, it develops an object-centric model that links sales orders, production orders, purchase order lines, receipts, quality lots, reservations, operations, test records, and shipments. The article shows how governed event construction, timestamp control, object linking, and semantic validation are prerequisites for reliable analysis. It then uses the reconstructed event structure to estimate empirical supplier lead times, distinguish physical stock from available stock, compute full-kit readiness, identify the critical missing component, detect conformance deviations, expose rework loops, and correct planning assumptions. The central argument is that process mining becomes valuable when it is treated not as process visualization, but as an IT-enabled evidence pipeline: raw operational data are transformed into governed event structures, interpreted through process semantics, and converted into accountable actions for planning, procurement, quality, warehouse, manufacturing engineering, and S&OP.

Why manufacturing is a natural process-mining use case

Manufacturing processes are often described as if they were deterministic chains:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD
  PLAN["Plan"] --> PROC["Procure"]
  PROC --> REC["Receive"]
  REC --> PROD["Produce"]
  PROD --> INSP["Inspect"]
  INSP --> SHIP["Ship"]

Figure 1: Simplified normative manufacturing chain. The sequence represents the intended high-level flow from planning to procurement, receipt, production, inspection, and shipment.

This representation is useful as a normative process description, but it is not sufficient to explain what actually happens inside a manufacturing system. A finished item depends on purchased components, internally processed parts, supplier lead times, quality inspections, warehouse availability, production capacity, engineering changes, material substitutions, inventory reservations, and customer priorities.

A production order may be ready from a routing perspective but blocked by a missing component. A purchased part may be physically received but unavailable because it is still under quality inspection. A work center may be available, but the order may wait because the complete kit is not ready. A production order may start, stop, wait, be reworked, and then return to testing.

Process mining is useful precisely because it does not start from the nominal routing, the standard lead time, or the planning parameter. It starts from event evidence: what happened, when it happened, to which production order, purchase order, item, batch, supplier, resource, warehouse, and quality lot it happened.

The process-mining pipeline can be summarized as a conceptual transformation chain:¹

D \xrightarrow{\phi} L_E \xrightarrow{\operatorname{mine}} M \xrightarrow{\operatorname{evaluate}} I \xrightarrow{\operatorname{govern}} A

where:

• D is raw operational data;
• \phi is the_ 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.

In the manufacturing example, this means that ERP, MES, WMS, QMS, procurement, and shipment records are first converted into governed event evidence, then mined into process models, evaluated for delays and deviations, and finally translated into accountable operational actions.

Example setting: a smart dosing pump

Consider a manufacturer that produces a configurable smart dosing pump used in industrial plants. The product is not extremely complex, but it is complex enough to expose the main manufacturing problem: a finished item is assembled from purchased components, internally processed components, subassemblies, quality-controlled parts, and final test operations.

The simplified bill of materials is:

Level	Component	Type	Source	Quantity
0	Smart dosing pump	Finished item	Manufactured	1
1	Pump head assembly	Subassembly	Internal assembly	1
2	Pump head casting	Component	Purchased, then machined	1
2	Seal kit	Component	Purchased	1
1	Motor module	Subassembly	Internal assembly	1
2	Electric motor	Component	Purchased	1
2	Coupling	Component	Purchased	1
1	Control module	Subassembly	Internal assembly	1
2	Controller PCB	Component	Purchased	1
2	Pressure sensor	Component	Purchased	1
2	Wiring harness	Component	Purchased	1
1	Final housing	Component	Purchased	1

The nominal process is:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD
  SO["Sales order"]
  POCR["Production order creation"]
  PR["Purchase requisitions"]
  PO["Purchase orders"]
  REC["Component receipt"]
  QC["Quality inspection"]
  AV["Component availability"]
  MACH["Machining"]
  SUB["Subassembly"]
  ASM["Final assembly"]
  TEST["Functional test"]
  PACK["Packing"]
  SHIP["Shipment"]

  SO --> POCR
  POCR --> PR
  PR --> PO
  PO --> REC
  REC --> QC
  QC --> AV
  AV --> MACH
  MACH --> SUB
  SUB --> ASM
  ASM --> TEST
  TEST --> PACK
  PACK --> SHIP

Figure 2: Nominal manufacturing process for a finished item assembled from purchased components and internal operations. The sequence runs from sales order to production order creation, procurement, receipt, quality inspection, component availability, internal processing, final assembly, testing, packing, and shipment.

The business question is deliberately narrow:

Why do some production orders miss the committed shipment date even when final assembly capacity appears sufficient?

This is a good process-mining question because the answer may be hidden across several systems. The delay may not be visible in final assembly alone. It may originate in procurement, supplier lead-time variability, quality release, warehouse availability, material reservation, or testing rework.

Event model

The primitive object is the event:²

e = (i,a,t,r,x)

where:

• i is the case identifier or, in a more general formulation, a set of related business objects;
• a is the activity or state transition observed;
• t is the timestamp;
• r is the resource, system, supplier, machine, organizational unit, or agent responsible for the event;
• x is a vector of attributes describing the event context.

For a manufacturing process, one case identifier is usually not enough. A finished item is related to a sales order, a production order, several purchase orders, component items, warehouse receipts, quality lots, inventory reservations, operations, work centers, test records, and shipment documents.

A case-centric analysis by production order is useful, but it hides part of the causal structure. If a production order is late because one purchased component was released from quality inspection too late, the production-order trace alone is not enough. The event must be connected to the purchase order line, item, supplier, receipt, quality lot, warehouse, and production order.

The more faithful formulation is therefore object-centric:

L_{OC} = (E,O,type,act,time,rel,attr)

where:

• E is the set of events;
• O is the set of business objects;
• type : O \rightarrow \mathcal{T} assigns each object to an object type;
• act : E \rightarrow \mathcal{A} assigns each event to an activity;
• time : E \rightarrow T assigns each event to a timestamp;
• rel \subseteq E \times O relates events to objects;
• attr stores event and object attributes.

For example, the event Controller PCB received may be related to:

Object type	Example
Purchase order	PO-450091
Purchase order line	PO-450091-10
Supplier	PCB-SUP-02
Item	PCB-CTRL-24V
Production order	PRD-71025
Sales order	SO-8841
Warehouse receipt	REC-33018
Quality lot	QL-9812

The event-object relation is:

rel(e) \subseteq O

This is why object-centric process mining is important in manufacturing. The production order alone does not explain the delay. The delay may originate in a purchase order, a supplier, a quality lot, a warehouse receipt, or an inventory reservation.

Process structure

A simplified object-centric view is:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD
  SO["Sales order"] --> PRD["Production order"]
  PRD --> BOM["BOM components"]
  BOM --> PO["Purchase orders"]
  PO --> REC["Component receipts"]
  REC --> QC["Quality inspection"]
  QC --> AV["Available stock"]
  PRD --> MACH["Machining"]
  AV --> KIT["Full kit ready"]
  MACH --> KIT
  KIT --> ASM["Final assembly"]
  ASM --> TEST["Functional test"]
  TEST --> PACK["Packing"]
  PACK --> SHIP["Shipment"]

Figure 3: Object-centric manufacturing structure. A finished product is linked to a sales order, production order, purchased components, purchase orders, receipts, quality lots, internal operations, testing, and shipment.

This diagram should not be read as a simple linear process. Some events occur in parallel. Purchase orders may be released before or after production order creation, depending on the planning policy. Some components may already be available in stock. Some components may be substituted. Some receipts may arrive in partial quantities. Some operations may start before the complete kit is formally ready, if the organization allows partial release.

The diagram is therefore a projection of an object-centric event structure, not a claim that manufacturing execution is a single sequential trace.

Event construction from source systems

The event log is not found ready-made in the enterprise system. It must be constructed.

The event-construction function is:

\phi : D \rightarrow L_E

where D is raw operational data and L_E is the constructed event-log or object-centric event structure.

This function should not be understood as a simple data extraction query. It is a governed transformation from heterogeneous operational records into business events. The transformation has three distinct responsibilities:

1. it must extract the relevant technical records from source systems;
2. it must interpret those records as meaningful business events;
3. it must preserve the object relations needed to explain the manufacturing process.

In other words, the event-construction problem is not only technical. It is semantic and architectural. The same database record may be read as a status update, a posting, a confirmation, a reversal, a correction, or a physical event depending on the process context. If that interpretation is wrong, the process-mining model will be precise in form but false in substance.

For the smart dosing pump example, relevant source systems may include:

Source system	Typical source objects	Example events
ERP	sales orders, production orders, purchase orders, inventory transactions	sales order confirmed, production order created, PO released, goods receipt posted
MES	operations, work centers, confirmations, machine events	assembly started, assembly completed, test started, test failed, rework completed
WMS	receipts, put-away, reservations, picking, issue to production	component received, component available, component reserved, component issued
QMS	inspection lots, nonconformities, releases	quality inspection started, quality released, quality blocked, rejected
Supplier portal	confirmations, ASN, shipment notices	supplier confirmed date, supplier shipment created, delay notification
Logistics system	packing, transport, shipment	packing completed, shipment posted, carrier pickup

The semantic problem is to map technical records into business events. For example:

Business event	Possible source	Semantic risk
PO released	ERP purchase order approval or release flag	release date may differ from creation date
Supplier confirmed date	supplier portal, procurement confirmation, EDI/message log	latest confirmation may overwrite earlier commitments
Component received	ERP goods receipt or WMS receipt	physical receipt may precede ERP posting
Put-away completed	WMS warehouse movement	put-away may be posted in batch after physical execution
Quality inspection started	QMS inspection-lot creation or first inspection record	lot creation may not mean inspection actually started
Quality released	QMS inspection usage decision or stock-status change	release may be partial, reversed, or conditional
Component available	WMS availability plus stock status plus reservation status	physical stock is not equal to usable stock
Component reserved	ERP/WMS reservation or pegging record	reservation may be soft, hard, automatic, or manually overridden
Component issued to production	ERP material issue or WMS picking confirmation	issue may be backflushed after physical consumption
Full kit ready	computed event from all component availability events	requires pegging, reservation, substitution, and allocation logic
Assembly started	MES operation start or ERP confirmation	batch posting may distort timestamp
Functional test failed	MES/QMS test result	failed tests may be overwritten by final pass status
Functional test passed	MES/QMS test result	retests and partial tests must be modeled
Rework completed	MES rework operation or quality disposition	rework may be recorded as a separate order, operation, or nonconformity
Packing completed	WMS packing event	packing may not imply shipment availability
Shipment posted	ERP delivery posting or WMS shipment	posting time may differ from physical pickup

The correctness of \phi determines whether the analysis is meaningful. If component received is treated as equivalent to component available, the model will ignore quality holds. If production-order release is treated as material readiness, the model will hide missing-component delays. If failed tests are overwritten by final pass status, rework disappears from the event log.

Event construction as an IT architecture problem

From an IT architecture perspective, \phi is a controlled data product. It should be designed with explicit source ownership, extraction rules, transformation logic, lineage, access control, and validation procedures.

A minimal architecture contains four layers:

Layer	Purpose	Typical artefacts
Source layer	Preserve the operational records in their original systems	ERP tables, MES records, WMS movements, QMS lots, supplier messages, shipment records
Extraction layer	Retrieve source records without changing their operational meaning	extraction specification, incremental-load rule, source timestamp, extraction timestamp
Semantic transformation layer	Convert technical records into business events	event catalogue, transformation rules, object-linking logic, timestamp hierarchy
Analytical event layer	Expose validated events for process mining and performance diagnosis	object-centric event log, lineage table, validation report, analytical views

The source layer remains the system of record. The process-mining layer should not become a parallel operational system. Its role is to reconstruct process evidence from governed data, not to replace ERP, MES, WMS, or QMS execution logic.

This distinction matters because a process-mining model is only as trustworthy as its lineage. Each generated event should remain traceable to the source record or records that produced it:

lineage(e) = \{d_1,d_2,\ldots,d_n\}

where e is the constructed event and d_1,\ldots,d_n are the source records used to derive it.

For example, the event Component available may require several source facts:

component\ available = receipt + quality\ release + putaway - quality\ block - reservation\ conflict

This event is therefore not a primitive source-system event. It is a computed event. Its reliability depends on whether the underlying receipt, inspection, stock-status, put-away, and reservation records are correctly interpreted.

Object linking and identifier reconciliation

Manufacturing event construction requires stable object relations. The following objects must be connected:

Object	Why it matters
Sales order	identifies customer commitment and requested or confirmed shipment date
Production order	identifies the manufacturing execution object
Finished item	identifies product family, configuration, and BOM
BOM component	identifies required materials and quantities
Purchase order line	links purchased components to suppliers and promised dates
Warehouse receipt	identifies physical inbound material movement
Quality lot	identifies inspection, hold, release, rejection, and nonconformity
Inventory reservation	identifies whether stock is usable for the production order
Operation	identifies routing execution and work-center activity
Test record	identifies pass, fail, retest, and rework behavior
Shipment	identifies customer-facing completion

The object-linking function can be written as:

rel(e) = \{o \in O : link(e,o)=true\}

The difficult part is not the formula. The difficult part is the practical rule behind link(e,o). In a real system, links may be direct, derived, or inferred.

Link type	Example	Risk
Direct link	production order number stored on a MES operation	usually robust, but may fail after order split or rework order creation
Derived link	PO line linked to production order through pegging or MRP trace	may change after replanning
Inferred link	component receipt associated with delayed order by item, batch, date, and reservation	useful but weaker; requires explicit confidence rule

For this reason, the event model should distinguish hard relations from soft relations. A hard relation is supported by an explicit source-system identifier. A soft relation is reconstructed through business logic. Soft relations are often necessary, but they should be marked as such, because they affect the strength of the diagnosis.

A minimal object-linking table may look like this:

Relation	Preferred key	Fallback key	Confidence
Sales order → production order	make-to-order reference	item, customer, requested date, production batch	high if explicit, medium if inferred
Production order → BOM component	production order BOM line	item and effective BOM version	high
BOM component → PO line	pegging record or requirement reference	item, supplier, due date, quantity	high if pegged, medium if inferred
Receipt → PO line	PO line reference	supplier, item, receipt date, quantity	high
Receipt → quality lot	inspection lot reference	item, batch, receipt date	high to medium
Quality lot → available stock	stock-status transition	item, batch, warehouse, quality decision	medium
Available stock → production order	hard reservation or issue transaction	item, batch, production order, issue date	high if reserved, medium if inferred
Test record → production order	production order operation reference	serial number, batch, work center, date	high to medium

This is where object-centric process mining becomes operationally necessary. Without object linking, the analysis collapses into disconnected fragments: procurement lead time, warehouse movement, quality release, production execution, and shipment. With object linking, the same delayed shipment can be reconstructed as a chain of related events.

Timestamp governance

Timestamps are not neutral. A timestamp may represent physical occurrence, system posting, approval, confirmation, message receipt, or batch update. Therefore, each event type should have a timestamp rule.

A minimal timestamp hierarchy is:

Priority	Timestamp type	Meaning
1	physical execution timestamp	when the physical event actually occurred
2	operational confirmation timestamp	when the operator, machine, scanner, or workflow confirmed it
3	system posting timestamp	when the transaction was posted in the source system
4	integration timestamp	when the record was transferred to another system
5	extraction timestamp	when the analytical pipeline extracted the record

For process mining, the preferred timestamp is the one that best represents the business event being analyzed. For goods receipt, a WMS scan may be closer to physical reality than the ERP posting time. For quality release, the QMS decision timestamp may be more relevant than the subsequent inventory-status update. For shipment, carrier pickup may be more operationally meaningful than invoice or delivery posting.

The event catalogue should therefore define, for each event:

Event	Preferred timestamp	Fallback timestamp	Known distortion
PO released	approval/release timestamp	PO status-change timestamp	approval workflow may be bypassed
Component received	WMS receipt scan	ERP goods receipt posting	ERP posting may occur later
Quality released	QMS usage decision	inventory-status change	release may be partial or reversed
Component available	computed timestamp from stock-status and reservation state	latest timestamp among required availability conditions	depends on allocation logic
Assembly started	MES start timestamp	ERP operation confirmation	ERP confirmation may be entered after execution
Test failed	test execution timestamp	QMS/MES result posting	failed tests may be overwritten
Shipment completed	carrier pickup or WMS shipment confirmation	ERP delivery posting	posting may differ from physical dispatch

This control is essential because most process-mining metrics are time differences. If timestamps are semantically inconsistent, lead times and waiting times become numerical artefacts rather than operational evidence.

Reversals, corrections, and partial events

Manufacturing systems often contain reversals, corrections, partial receipts, partial releases, substitutions, and rework orders. These events should not be silently removed because they are often the evidence of the real process.

For example, a purchase order line may be partially received:

receipt(j) = \{(q_1,t_1),(q_2,t_2),\ldots,(q_n,t_n)\}

where q_i is the quantity received at time t_i.

The availability of a component for a production order depends not on the first receipt but on the first time at which usable quantity satisfies the requirement:

T_{m,k}^{avail} = \inf \{t : A_{m,k}(t) \geq b_{p,k}\}

This means that partial events must be preserved. If the model keeps only the first receipt, it may underestimate delay. If it keeps only the last receipt, it may overestimate delay. The correct interpretation depends on the required quantity, the accepted quantity, the quality status, and the reservation rule.

The same applies to reversals. If a quality release is reversed, the event log should not contain only the final state. It should contain both the release and the reversal, because the temporary release may have influenced reservation, picking, or production scheduling.

Semantic validation

The constructed event log should be validated before it is mined. Validation is not a formal courtesy; it is a control against false precision.

A practical validation cycle uses sampled traces:

Validation object	Reviewer	Question
one delayed production order	production planner	does the reconstructed sequence match the planning history?
one late purchased component	procurement owner	does the PO release, confirmation, receipt, and delay history match supplier communication?
one quality-blocked receipt	quality owner	does the inspection and release sequence match the lot history?
one reservation conflict	warehouse/inventory owner	does the availability calculation match actual stock usability?
one rework loop	manufacturing engineering	does the test-fail-rework-retest sequence match technical execution?
one late shipment	logistics owner	does shipment completion match physical dispatch?

The validation should produce a correction log:

Issue found	Example	Correction
wrong timestamp	ERP posting used instead of WMS receipt scan	change timestamp rule
missing relation	quality lot not linked to receipt	add lot-receipt relation
false availability	stock counted despite quality block	include stock-status filter
overwritten failure	test failures hidden by final pass	model all test attempts
duplicated event	ERP and WMS both generate receipt event	define source priority
missing reversal	quality release reversal ignored	model reversal as event

Only after this validation does it make sense to discover variants, measure lead times, compute full-kit readiness, or perform conformance checking.

Minimum data contract

A minimal process-mining pilot should define a data contract for each event type. The contract does not need to be complex, but it should be explicit.

Field	Purpose
event id	uniquely identifies the constructed event
event type	defines the business activity or state transition
event timestamp	defines when the event occurred according to the selected timestamp rule
source system	identifies where the source record comes from
source record id	preserves lineage to the operational record
object references	links the event to sales order, production order, PO line, item, lot, reservation, operation, or shipment
resource	identifies supplier, work center, operator role, system, or organizational unit
quantity	preserves partial receipts, issues, releases, and consumption
status before / status after	captures state transitions rather than final state only
reversal flag	identifies cancellation, reversal, or correction events
confidence level	distinguishes direct evidence from inferred linkage

This data contract is the practical expression of \phi. It makes the event log auditable, repeatable, and governable.

The resulting object-centric event structure is therefore not just a table of activities and timestamps. It is a reconstructed operational graph:

G_{event} = (E,O,rel,time,act,attr,lineage)

where events, objects, relations, timestamps, attributes, and lineage are all required to preserve the meaning of the manufacturing process.

This is the architectural foundation for the rest of the analysis. Component lead times, available stock, full-kit readiness, critical-path diagnosis, conformance checking, and S&OP correction are all downstream of this construction step. If event construction is weak, the later analysis only gives the appearance of precision. If event construction is governed, process mining becomes a disciplined way to transform operational traces into accountable manufacturing intelligence.

Component lead times

The planning system contains nominal lead times. Process mining estimates empirical lead times from events.

For a purchased component k supplied by supplier s, the planned lead time is:

L_{k,s}^{plan}

However, several empirical lead times matter. The receipt lead time for purchase order line j is:

L_{j}^{receipt} = time(\operatorname{receipt}_j) - time(\operatorname{purchase\ order\ release}_j)

The availability lead time is:

L_{j}^{avail} = time(\operatorname{available}_j) - time(\operatorname{purchase\ order\ release}_j)

The difference is important. A component can be physically received but not yet usable. If the item is blocked for quality inspection, missing documentation, or warehouse put-away, then:

L_{j}^{avail} > L_{j}^{receipt}

Aggregating over historical purchase order lines gives empirical supplier-item lead-time distributions:

\hat{L}_{k,s}^{receipt,PM} = \{L_j^{receipt} : item(j)=k,\ supplier(j)=s\}

and:

\hat{L}_{k,s}^{avail,PM} = \{L_j^{avail} : item(j)=k,\ supplier(j)=s\}

This is more informative than a single planning parameter. The mean may be acceptable while the 90th percentile is operationally dangerous. Also, the receipt lead time may look acceptable while the availability lead time reveals the true constraint.

A simplified empirical table may look like this:

Component	Supplier	Planned LT	Median availability LT	90th percentile availability LT	Typical issue
Pump head casting	Foundry A	15 days	18 days	27 days	quality inspection delay
Electric motor	MotorCo	20 days	19 days	24 days	stable
Controller PCB	Electronics B	30 days	34 days	48 days	supplier variability
Pressure sensor	SensorLab	12 days	13 days	21 days	intermittent shortage
Seal kit	SealsCo	7 days	6 days	10 days	stable
Wiring harness	HarnessPro	10 days	9 days	14 days	stable
Final housing	Plastics C	14 days	15 days	22 days	transport delay

The immediate finding is that average lead time is not enough. The controller PCB and pump head casting dominate the high-percentile risk. This is precisely the kind of empirical correction that process mining can provide to planning and S&OP models.

Physical stock, available stock, and quality-blocked stock

Manufacturing planning often fails when it treats inventory as a single quantity. In reality, physical stock and available stock are not the same thing.

For component k at location l and time t, physical inventory can be written as:

I_{k,l,t}^{physical}

Quality-blocked inventory is:

Q_{k,l,t}

Reserved inventory is:

R_{k,l,t}^{reserved}

Other unavailable inventory is:

U_{k,l,t}^{unavailable}

Available inventory is therefore:

I_{k,l,t}^{available} = I_{k,l,t}^{physical} - Q_{k,l,t} - R_{k,l,t}^{reserved} - U_{k,l,t}^{unavailable}

Process mining estimates the transitions between these states from receipt, inspection, release, reservation, issue, reversal, and adjustment events.

This distinction is essential for the manufacturing example. A component can be visible in physical stock but still unavailable for the production order. If the event log does not distinguish these states, the analysis will attribute the delay to production when the real cause is quality release or inventory reservation.

Full-kit readiness

The production order cannot proceed to final assembly under a strict full-kit policy until all required components are available. For a finished item p, let:

B_p

be the set of required components, and let:

b_{p,k}

be the required quantity of component k in the bill of materials.

For production order m, define:

A_{m,k}(t)

as the available quantity of component k that is usable for production order m at time t, after quality release, reservation constraints, and allocation rules.

The component availability time is:

T_{m,k}^{avail} = \inf \{t : A_{m,k}(t) \geq b_{p,k}\}

The full-kit readiness time is:

T_m^{kit} = \max_{k \in B_p} T_{m,k}^{avail}

The critical missing component is:

k^*(m) = \arg\max_{k \in B_p} T_{m,k}^{avail}

This is a compact but powerful formulation. It shows that the manufacturing order is constrained not by the average component, but by the last required component to become available.

If the controller PCB arrives last, then the controller PCB is the critical component. If the casting is physically received early but blocked in quality inspection, then the casting may be the critical component even though it is already inside the warehouse.

Process mining estimates T_{m,k}^{avail} from receipt, quality release, inventory reservation, pegging, allocation, and component issue events.

Example event log

A simplified event log for one production order may be:

Object	Event	Timestamp	Resource/System	Attribute
SO-8841	Sales order confirmed	2026-02-01 09:12	ERP	committed date = 2026-03-22
PRD-71025	Production order created	2026-02-02 08:40	ERP	item = SDP-100
PO-450091	PO released for controller PCB	2026-02-03 10:00	ERP	supplier = Electronics B
PO-450092	PO released for motor	2026-02-03 10:15	ERP	supplier = MotorCo
PO-450093	PO released for casting	2026-02-03 10:20	ERP	supplier = Foundry A
REC-33011	Motor received	2026-02-22 11:10	WMS	item = motor
REC-33019	Pump head casting received	2026-02-24 15:20	WMS	item = casting
QL-9810	Casting quality released	2026-03-04 10:45	QMS	result = pass
REC-33018	Controller PCB received	2026-03-17 14:30	WMS	item = PCB
QL-9812	PCB quality released	2026-03-18 09:30	QMS	result = pass
PRD-71025	Full kit ready	2026-03-18 10:00	ERP/WMS	critical part = PCB
PRD-71025	Assembly started	2026-03-19 08:00	MES	line = A2
PRD-71025	Assembly completed	2026-03-21 16:00	MES	line = A2
PRD-71025	Functional test failed	2026-03-22 10:00	MES/QMS	reason = sensor calibration
PRD-71025	Rework completed	2026-03-23 14:00	MES	station = rework
PRD-71025	Functional test passed	2026-03-24 09:00	MES/QMS	result = pass
SHP-6022	Shipment posted	2026-03-25 16:30	ERP/WMS	carrier = C1

The intended process would have predicted that procurement and internal operations could meet the committed shipment date. The event log shows a more precise causal chain:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD
  PCB["Controller PCB available late"]
  KIT["Full kit delayed"]
  ASM["Assembly starts late"]
  TEST["Functional test fails"]
  REWORK["Rework is required"]
  SHIP["Shipment misses committed date"]

  PCB --> KIT
  KIT --> ASM
  ASM --> TEST
  TEST --> REWORK
  REWORK --> SHIP

Figure 4: Process-mined causal chain for a delayed manufacturing order. The delay originates from late controller PCB availability, propagates to full-kit readiness and assembly start, is amplified by functional-test failure and rework, and finally causes shipment after the committed date.

This is the difference between a planning assumption and process evidence.

Directly-follows view

A directly-follows view is a projection of the event log into adjacent activity relations. The directly-follows relation is:

a >_L b

if activity a is immediately followed by activity b in at least one trace of the log L.³

The frequency of the edge (a,b) is:

freq_L(a,b) = \sum_{\sigma \in supp(L)} count_L(\sigma) \cdot |\{k : \sigma_k = a \land \sigma_{k+1}=b\}|

At the production-order level, the directly-follows graph may look like this:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD
  A["Production order created"] --> B["Purchase orders released"]
  B --> C["Components received"]
  C --> D["Quality released"]
  D --> E["Full kit ready"]
  E --> F["Assembly started"]
  F --> G["Assembly completed"]
  G --> H["Functional test"]
  H --> I["Packing"]
  I --> J["Shipment"]
  H --> R["Rework"]
  R --> H

Figure 5: Simplified directly-follows graph for the manufacturing example. The production order depends on purchase orders, receipts, quality release, full-kit readiness, assembly, testing, possible rework, and shipment.

The rework edge:

Functional\ Test \rightarrow Rework \rightarrow Functional\ Test

is especially important. It means that even if component availability is solved, shipment may still be delayed by quality or testing loops.

The directly-follows graph is useful, but it must be interpreted carefully. Manufacturing contains parallel flows. Many component purchase orders progress at the same time. A directly-follows graph may therefore overstate causality if it is built from an artificial projection. In this example, the graph is a diagnostic view, not the complete process semantics.

Variants

A manufacturing process is rarely one path. A small set of variants may explain most outcomes.

Variant	Trace pattern	Share	Interpretation
1	Full kit ready → assembly → test passed → shipment	52%	Normal flow
2	PCB available late → full kit delayed → assembly → test passed → shipment	21%	Supplier lead-time issue
3	Casting received → quality hold → full kit delayed → assembly → shipment	12%	Quality-release issue
4	Full kit ready → assembly → test failed → rework → test passed → shipment	9%	Internal quality or rework issue
5	Production order released before components available → waiting → assembly	6%	Planning or release-policy issue

The process variant set is:

V(L)=\{\sigma:\sigma\in supp(L)\}

The probability of a variant is:

p(\sigma) = \frac{count_L(\sigma)}{|L|}

Behavioral entropy measures how fragmented the manufacturing execution process is:

H(L) = - \sum_{\sigma \in V(L)} p(\sigma)\log p(\sigma)

A high entropy value is not automatically bad. It may reflect legitimate product variants, engineering configurations, customer-specific options, or legal-entity differences. The disciplined interpretation is conditional:

H(L \mid Z) = \sum_z \mathbb{P}(Z=z)H(L_z)

where Z may include product family, supplier, plant, order type, customer segment, or configuration class. If entropy collapses after conditioning on Z, variation is structurally explained. If entropy remains high inside homogeneous partitions, it is more likely to represent operational instability.⁴

Conformance checking

The reference model may contain explicit admissibility rules. For example:

• Material readiness rule: a production order should be released only when material availability is confirmed.
• Full-kit rule: final assembly should start only after full-kit readiness.
• Quality-gate rule: shipment should occur only after functional test has passed.

Conformance checking compares the observed event log:

L_{obs}

with the allowed behavior of the reference model:

\mathcal{L}(M)

where \mathcal{L}(M) is the language of traces allowed by model M.

Typical deviations include:

Deviation	Interpretation	Possible owner
Production order released before critical components are available	Planning policy or MRP parameter issue	Production planning
Assembly started before full-kit readiness	Release-policy violation or operational workaround	Production / Planning
Assembly started before quality release	Control violation or incorrect stock status	Production / Quality
Component received but not available	Quality or warehouse release delay	Quality / Warehouse
Test failed and reworked multiple times	Product, routing, calibration, or supplier quality issue	Manufacturing engineering
Purchase order created too late	Planning lead-time parameter too short	Procurement / Planning
Shipment before complete documentation	Compliance or process-control issue	Logistics / Quality

A simple binary check asks whether:

\sigma \in \mathcal{L}(M)

A more informative conformance model computes an alignment distance:

d(\sigma,M) = \min_{\gamma \in Align(\sigma,M)} cost(\gamma)

where \gamma is an alignment between the observed trace and the model. This allows deviations to be ranked by severity rather than treated as identical exceptions.

The value is that deviations are not anecdotal. They are measurable cases, with frequency, duration, affected objects, attributes, and owners.

Performance diagnosis

The manufacturing delay can be decomposed into intervals:

Interval	Formula	Meaning
Receipt lead time	\operatorname{time}(receipt)-\operatorname{time}(PO\ release)	Supplier and inbound performance
Availability lead time	\operatorname{time}(available)-\operatorname{time}(PO\ release)	Supplier plus quality and warehouse release
Quality release time	\operatorname{time}(QC\ release)-\operatorname{time}(receipt)	Quality and inspection delay
Full-kit waiting time	T_m^{kit}-\operatorname{time}(production\ order\ creation)	Material readiness delay
Assembly time	\operatorname{time}(assembly\ complete)-\operatorname{time}(assembly\ start)	Production execution
Test and rework time	\operatorname{time}(test\ passed)-\operatorname{time}(first\ test)	Quality and rework burden
Order-to-ship time	\operatorname{time}(shipment)-\operatorname{time}(sales\ order\ confirmation)	Customer-facing cycle time

The total manufacturing cycle time for order m can be written as:

CT(m) = T_m^{ship} - T_m^{order}

A useful decomposition is:

CT(m) = W_m^{procurement} + W_m^{quality} + W_m^{kit} + T_m^{assembly} + T_m^{test} + W_m^{shipment}

where each term represents a waiting or processing component of the total cycle time. This decomposition is not merely descriptive. It tells the organization where to intervene.

In the example, the delay is not primarily caused by final assembly capacity. The event evidence points to a compound delay mechanism:

• supplier lead-time variability, which delays component availability;
• quality release delay, which keeps physically received components unavailable;
• test rework, which consumes additional time after assembly.

This changes the managerial conclusion. Adding assembly operators would not solve the dominant cause.

Critical-path diagnosis

For each production order m, the critical component is:

k^*(m) = \arg\max_{k \in B_p} T_{m,k}^{avail}

Aggregating k^*(m) across production orders gives a powerful diagnostic:

Critical component	Share of delayed orders	Main cause
Controller PCB	44%	supplier lead-time variability
Pump head casting	27%	quality-release delay
Pressure sensor	13%	intermittent shortage
Electric motor	6%	rare supplier delay
Other	10%	mixed causes

This result separates the apparent bottleneck from the real bottleneck. The apparent bottleneck may be final assembly because orders wait before assembly. The real bottleneck may be the controller PCB because it determines full-kit readiness.

This is also why process mining is useful for manufacturing management. It converts a generic operational statement such as production is late into an evidence-based diagnosis: 44% of delayed orders are constrained by controller PCB availability, and the dominant mechanism is supplier lead-time variability.

The first statement identifies a symptom. The second identifies a measurable constraint, its frequency, and its dominant causal mechanism.

Correcting planning parameters

The planning system may currently use:

L_{PCB}^{plan}=30\ days

but process mining estimates:

median(\hat{L}_{PCB}^{avail,PM})=34\ days

and:

P90(\hat{L}_{PCB}^{avail,PM})=48\ days

The planning question is therefore not only:

What is the average lead time?

It is:

Which lead-time percentile should be used for the service level required by this product family?

For example:

Planning policy	Lead-time parameter	Consequence
Aggressive	median observed availability lead time	lower inventory, higher lateness risk
Balanced	75th percentile observed availability lead time	moderate buffer
Service-oriented	90th percentile observed availability lead time	higher inventory, lower lateness risk

The process-mined correction is:

L_{k,s}^{plan} \rightarrow \hat{L}_{k,s}^{avail,PM}

where \hat{L}_{k,s}^{avail,PM} should be treated as a distribution, not as a single number.

This is a first bridge between process mining and S&OP. The planning model becomes more empirical because it is calibrated on observed execution rather than on master-data assumptions alone.

Rework and exception loops

The example also contains a rework loop:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD
  FAIL["Functional test failed"] --> REWORK["Rework completed"]
  REWORK --> RETEST["Functional test repeated"]
  RETEST --> PASS["Functional test passed"]
  RETEST -. "if still not conforming" .-> REWORK

Figure 6: Rework loop after functional test failure. A failed functional test sends the production order to rework; after rework completion, the order returns to functional testing.

Let:

p_{test,rework}

be the probability that a production order enters rework after functional test. Process mining estimates:

\hat{p}_{test,rework} = \frac{ N_{test \rightarrow rework} }{ N_{test \rightarrow rework} + N_{test \rightarrow pass} }

where N_{a \rightarrow b} is the number of observed directly-follows transitions from activity a to activity b.

If the rework probability is high for a specific product variant, supplier batch, pressure sensor type, or work center, the delay should not be attributed only to capacity. The real cause may be calibration, supplier quality, design tolerance, assembly procedure, or test specification.

Rework also changes the effective capacity model. If \rho_{p,t}^{PM} is the process-mined exception or rework intensity for process p in period t, then the effective capacity may be lower than nominal capacity:

C_{r,t}^{effective} = C_{r,t}^{nominal}(1-\rho_{p,t}^{PM})

This expresses a simple operational fact: a work center may have nominal capacity, but part of that capacity is consumed by rework and exception handling.

From process mining to action

A practical action register may be:

Finding	Evidence	Owner	Action	Verification
PCB is critical in 44% of delayed orders	k^*(m)=PCB frequently	Procurement	renegotiate lead time, qualify second supplier, increase buffer	PCB criticality share decreases
Castings often blocked after receipt	high W_m^{quality}	Quality	risk-based inspection, supplier quality plan	QC release time decreases
Production orders released before full kit	conformance deviation	Planning	change release rule	early-release deviations decrease
Test failures create rework loop	repeated test → rework → test	Manufacturing engineering	root-cause analysis on sensor calibration	rework rate decreases
Lead-time master data too optimistic	L^{plan}<P75(\hat{L}^{avail,PM})	Supply planning	update planning parameters	schedule adherence improves
Physical stock differs from available stock	high Q_{k,l,t} or reservation conflicts	Warehouse / Quality	improve release and reservation logic	available-stock mismatch decreases

The action must be verified with a subsequent event log. Otherwise, process mining remains reporting rather than control.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD
  E["Event evidence"] --> B["Bottleneck and variant diagnosis"]
  B --> C["Cause classification"]
  C --> O["Owner assignment"]
  O --> A["Action"]
  A --> V["Verification in next event log"]
  V -. feedback .-> E

Figure 7: Manufacturing process-mining action loop. Evidence identifies the bottleneck, the cause is assigned to an owner, an intervention is executed, and the next event log verifies whether the process improved.

This is the same governance principle used in the broader process-mining framework: evidence must become accountable action, and action must be checked against subsequent evidence.

Implications for S&OP

This example also shows why process mining matters for S&OP. The S&OP model should not rely only on master-data lead times, nominal routings, and assumed capacity. It should incorporate observed execution.

Process mining can feed the planning model with:

\hat{D}^{PM},\quad \hat{L}^{PM},\quad \hat{a}^{PM},\quad \hat{C}^{PM},\quad \hat{\rho}^{PM},\quad \hat{\phi}^{PM}

where:

• \hat{D}^{PM} is process-mined demand realization;
• \hat{L}^{PM} is the empirical lead-time distribution;
• \hat{a}^{PM} is empirical capacity consumption;
• \hat{C}^{PM} is effective capacity;
• \hat{\rho}^{PM} is exception or rework intensity;
• \hat{\phi}^{PM} is the availability-adjusted output factor.

For the smart dosing pump, the S&OP implication is clear: the limiting factor is not only final assembly capacity. It is the joint behavior of supplier lead time, quality release, component availability, reservations, and rework.

A better planning model distinguishes the states that are often collapsed too quickly:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD
  REC["Physical receipt"] --> QC["Quality release"]
  QC --> AV["Available stock"]
  AV --> KIT["Full-kit readiness"]
  KIT --> ASM["Assembly start"]
  ASM --> TEST["Test pass"]

Figure 8: Planning-relevant manufacturing states distinguished by process mining. Physical receipt, quality release, available stock, full-kit readiness, assembly start, and test pass are distinct states with different operational meanings.

The important point is that these states are not equivalent. A component can be received but not quality-released; quality-released but not available because it is reserved elsewhere; available in stock but insufficient to complete the full kit; assembled but not yet accepted because functional testing has failed. That distinction is exactly what process mining makes measurable.

A simplified inventory-availability correction is:

I_{k,l,t}^{available} = I_{k,l,t}^{physical} - Q_{k,l,t} - R_{k,l,t}^{reserved} - U_{k,l,t}^{unavailable}

A simplified capacity correction is:

C_{r,t}^{effective} = C_{r,t}^{nominal}(1-\rho_{p,t}^{PM})

A simplified lead-time correction is:

L_{k,s}^{plan} \rightarrow \hat{L}_{k,s}^{avail,PM}

Together, these corrections change planning from a nominal model to an empirically calibrated model.

Minimal implementation

A practical implementation should be treated as a small IT and process-transformation project, not as a reporting exercise. The first release should remain deliberately narrow: one plant, one product family, one shipment-delay question, and a limited set of source systems. The objective is not to mine the entire factory. The objective is to prove that operational events can be extracted, semantically reconstructed, validated by process owners, and converted into governed improvement actions.

The minimal project can be organized as a staged roadmap.

Phase	Main question	Lead actors	Supporting actors	Tools and artefacts	Exit criterion
1	What business problem is being solved?	Business sponsor, plant manager, supply-chain/process owner	Production planning, procurement, quality, warehouse, manufacturing engineering	Project charter, scope statement, KPI baseline, delay taxonomy	One precise business question is approved, for example: why do confirmed orders miss shipment date?
2	Which process objects must be connected?	Process owner, enterprise architect, business analyst	ERP key user, MES/WMS/QMS key users, data owner	Object model, process-context map, source-system inventory	Sales order, production order, purchase order line, item, receipt, quality lot, reservation, operation, test, and shipment are formally defined
3	Which events are reliable enough to use?	Data analyst, data engineer, source-system owners	Process owners, IT application owners	Event catalogue, timestamp assessment, data-quality profile, extraction specification	Each event has a source table/API/file, timestamp logic, business meaning, owner, and known limitation
4	How will the event structure be built?	Data engineer, solution architect	IT operations, cybersecurity, data governance	Data pipeline, staging area, transformation rules, object-linking logic, access-control model	A reproducible object-centric event structure is generated from source systems
5	Is the reconstructed process semantically correct?	Process owner, production planner, quality owner, warehouse owner	Data analyst, enterprise architect	Validation workshops, sample trace review, exception list, semantic correction log	Business users confirm that reconstructed traces correspond to operational reality
6	What does the process evidence show?	Data analyst, process-mining analyst	Process owners, business analyst	Variant analysis, conformance checks, lead-time analysis, full-kit readiness calculation, critical-component diagnosis	The pilot identifies measurable delay patterns, bottlenecks, deviations, and responsible process domains
7	Which actions will be governed?	Business sponsor, process owner, plant manager	Procurement, quality, warehouse, manufacturing engineering, planning	Action register, owner matrix, benefit hypothesis, control metric	Each finding is translated into an assigned action with expected operational effect
8	Did the intervention work?	Process owner, data analyst, business sponsor	IT, process owners, plant functions	Next-period event log, before/after comparison, KPI dashboard, lessons learned	Improvement is verified against subsequent event evidence rather than anecdotal feedback

The tooling does not need to be large at the beginning. A minimal technical stack contains five capabilities:

Capability	Purpose
Data extraction and integration	Retrieve relevant records from ERP, MES, WMS, QMS, procurement, supplier collaboration, and logistics systems
Data staging and transformation	Normalize timestamps, identifiers, quantities, statuses, reversals, partial receipts, and object relations
Event catalogue and semantic mapping	Document how technical records become business events
Process-mining and analytical workspace	Discover variants, compute lead times, check conformance, identify bottlenecks, and calculate full-kit readiness
Action and governance workspace	Register findings, assign owners, track decisions, verify interventions, and preserve auditability

The key architectural point is that the process-mining layer should not become an uncontrolled shadow system. It should consume governed data, preserve lineage to source records, document transformation logic, and expose results through controlled analytical views. The project therefore needs both business ownership and IT ownership.

A minimal responsibility model is:

Responsibility	Accountable actor
Business question and expected benefit	Business sponsor
Process interpretation and operational validation	Process owner
Plant-level feasibility and action execution	Plant manager
Planning assumptions and lead-time parameters	Production planning / supply planning
Supplier lead-time interpretation	Procurement
Quality-release interpretation	Quality
Stock, reservation, and availability interpretation	Warehouse / inventory management
Rework and test-loop interpretation	Manufacturing engineering
Source-system access and extraction	IT application owners
Data model, pipelines, and lineage	Data engineering
Cross-system process structure	Enterprise architecture
Access control, segregation, and data protection	IT security / data governance

The pilot should be managed through a controlled backlog. The first backlog items should not be generic dashboards. They should be traceable analytical questions:

Backlog item	Required evidence	Decision enabled
Calculate actual availability lead time by component and supplier	PO release, receipt, quality release, available-stock transition	Whether planning lead times are too optimistic
Identify the critical missing component per delayed order	BOM, reservations, quality release, stock availability, production order	Which component family drives full-kit delay
Detect release before material readiness	Production-order release, material availability, reservation status	Whether release policy is being violated
Measure quality-blocked waiting time	Receipt, inspection start, quality decision, stock-status transition	Whether quality release is a relevant constraint
Measure test and rework loops	Test start, test fail, rework start, rework complete, retest, test pass	Whether effective capacity is reduced by exception handling
Compare shipment lateness by variant	Sales order, production order, full-kit readiness, assembly, test, shipment	Which delay pattern dominates customer-facing lateness

The implementation should pass through three governance gates.

Gate	Question	Minimum evidence
Gate 1 — Scope validation	Is the pilot narrow enough and economically meaningful?	Approved product family, plant, KPI, process owner, and delay question
Gate 2 — Semantic validation	Does the event log represent operational reality?	Sample traces validated by planning, warehouse, quality, production, and procurement
Gate 3 — Action validation	Can findings be converted into accountable operational changes?	Action register with owners, target metric, baseline value, and verification period

The first release is successful only if it proves four things:

1. the same production order can be connected to its sales order, purchase orders, component receipts, quality lots, reservations, operations, test events, and shipment;
2. the organization can distinguish physical receipt, quality release, available stock, full-kit readiness, assembly start, test pass, and shipment;
3. at least one dominant delay mechanism can be quantified and assigned to an accountable owner;
4. the next event log can verify whether the corrective action changed the process.

This is the minimum viable implementation. It is not a full factory-wide process-mining program. It is a controlled IT-enabled diagnostic loop: extract events, reconstruct the object-centric process, validate semantics, measure deviations, assign actions, and verify improvement.

Limits and semantic risks

The analysis depends on the quality of the event model. Several risks must be controlled:

1. Timestamps may not represent physical reality. A component may be physically received before the ERP goods receipt is posted. A MES confirmation may be entered at the end of the shift. A quality release may be backdated.

2. Identifiers may not be stable. A production order may be split, merged, rescheduled, or technically closed and recreated. A purchase order may be substituted by another supplier. A material may be replaced by an equivalent component.

3. Physical stock is not available stock. If quality status, reservation, put-away, and allocation logic are not modeled, the analysis may falsely conclude that production waited despite available inventory.

4. A directly-follows graph can be misleading when parallel component flows are projected into a single sequence. Object-centric modeling reduces this problem because it preserves relationships between events and multiple business objects.

5. Process mining does not by itself prove causality. It identifies behavioral evidence, temporal relations, deviations, and bottlenecks. Causal interpretation still requires process-owner validation, source-system knowledge, and operational judgment.

Conclusion

Manufacturing delays are often explained too generically: supplier delay, capacity issue, quality problem, planning error. Process mining makes these explanations precise.

In the smart dosing pump example, the relevant question is not simply whether the product was late. The question is which event chain made it late:

• Was the purchase order released too late?
• Was the component receipt delayed?
• Was the component received but blocked in quality inspection?
• Was the component available but reserved for another order?
• Was the full kit incomplete?
• Was final assembly capacity actually constrained?
• Did functional testing generate rework?
• Did packing or shipment introduce the final delay?

By reconstructing the process from event data, the enterprise can identify the real critical path for each production order and the dominant causes across many orders.

The key result is architectural. Manufacturing performance is not only a property of the shop floor. It is an emergent property of procurement, supplier reliability, quality release, inventory availability, reservation logic, planning parameters, production execution, testing, rework, and shipment. Process mining gives the enterprise a quantitative way to observe that system.

The value is not the process map. The value is the governed evidence that tells the organization what to change.

Further reading

This manufacturing example is deliberately narrow: one product family, purchased components, variable supplier lead times, quality release, full-kit readiness, assembly, test, rework, and shipment. The following articles expand the same problem from three complementary angles: enterprise modeling, process intelligence, and enterprise-architecture capability building.

ArchiMate 4 and the Cartography of Complexity

This article is useful if the manufacturing example raises a modeling question: how should the enterprise represent dependencies among products, processes, applications, data, technology, suppliers, and governance structures?

The process-mining example shows that manufacturing performance is not caused by one isolated activity. It emerges from the interaction of procurement, inventory, quality, production, warehouse execution, and shipment. The ArchiMate article explains why enterprise architecture needs a disciplined modeling language to describe those dependencies without confusing operational detail with architectural intent. It is the natural companion for readers who want to understand how process evidence can be connected to architecture models, capability maps, application landscapes, and governance views.

Process Mining as Computational Process Intelligence

This is the theoretical foundation behind the present example. The manufacturing case applies only a subset of the full framework: event construction, object-centric process modeling, directly-follows analysis, variants, conformance checking, performance diagnosis, and governed action.

The longform develops the complete argument from first principles. It explains why process mining is not process visualization, but a computational method for reconstructing operational behavior from event data. It also extends the topic toward object-centric process mining, enterprise architecture, data architecture, Celonis, implementation roadmaps, dynamic resource allocation, and S&OP decision models. Readers who want to move from the manufacturing example to the full mathematical and architectural theory should read that article next.

Introducing Enterprise Architecture in a Multinational Company: A Roadmap for Building the Discipline from Scratch

This article is useful if the manufacturing example raises an organizational question: who should own the structural knowledge required to act on process-mining evidence?

Process mining can identify that supplier lead-time variability, quality-blocked inventory, reservation conflicts, or rework loops are damaging manufacturing performance. But turning that evidence into durable change requires enterprise architecture, governance, ownership, and a roadmap for institutionalizing architectural reasoning. The EA roadmap article explains how to build that capability in a multinational environment: from architectural discovery and governance to knowledge-base creation, strategic planning, delivery integration, and the management of transformation trade-offs.

Together, these three articles complete the picture. The present article shows a concrete manufacturing use case. The process-mining longform provides the formal theory. The ArchiMate article explains how to represent enterprise complexity. The enterprise-architecture roadmap explains how to make this knowledge operational inside a large organization.

See also longforms

ArchiMate 4 and the Cartography of Complexity

How ArchiMate 4 simplifies enterprise modeling while enterprise systems grow more complex, shifting the real challenge from notation to semantic governance and operational evidence

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

Introducing Enterprise Architecture in a Multinational Company: A Roadmap for Building the Discipline from Scratch

Building an architectural capability to guide technological evolution, manage structural complexity, and evaluate transformation trade-offs in large multinational enterprises

From S&OP to Continuous Orchestration: Envisioning the Hybrid Enterprise of Humans and AI Agents

From calendar-driven cycles to signal-driven enterprise adaptation

From Planning to Orchestration: Reimagining the Enterprise Beyond S&OP

Designing the continuously orchestrated enterprise

Comprehensive Guide to Sales & Operations Planning, Sales & Operations Execution and Master Production Scheduling

From planning cycles to organisational capability: how integrated planning evolves through execution, feedback and learning

See also posts

Process Mining: From Theory to Execution

Why quantitative process intelligence is becoming essential for enterprise architecture and digital transformation

Architecting Change

How I blend enterprise architecture, technology, and interim leadership to transform organizations

Footnotes

1. See the general inference chain in Process Mining as Computational Process Intelligence, where process mining is framed as a governed pipeline from raw operational data to accountable action.

2. See the event definition in Process Mining as Computational Process Intelligence, where an event is represented as an observed state transition with case or object, activity, timestamp, resource, and attributes.

3. The directly-follows relation follows the process-discovery section of Process Mining as Computational Process Intelligence.

4. See the variants and behavioral-entropy section in Process Mining as Computational Process Intelligence.