This article develops a practical manufacturing example of process mining applied to a production environment with purchased components, variable supplier lead times, quality release, warehouse availability, material reservations, internal operations, testing, rework, and shipment commitments. Its central thesis is that manufacturing delay is rarely explained by a single visible bottleneck. What appears as a production-capacity issue may in fact originate in procurement timing, supplier variability, quality-blocked inventory, reservation conflicts, late full-kit readiness, test failures, rework loops, or shipment execution. Process mining becomes valuable when it reconstructs this causal chain from event evidence rather than relying on nominal routings, static lead times, or generic explanations such as supplier delay, quality issue, planning error, or shop-floor congestion.
The article uses the example of a configurable smart dosing pump assembled from purchased components and internal operations. The product is deliberately simple enough to be understandable, but complex enough to expose the structural problem of modern manufacturing: one finished item is not the result of a single linear process. It depends on a sales order, a production order, a bill of materials, purchase order lines, supplier confirmations, warehouse receipts, quality lots, reservations, internal machining, subassembly, final assembly, functional testing, rework, packing, and shipment. A case-centric view based only on the production order is therefore insufficient. The production order may show that assembly started late, but it may not explain whether the delay came from a controller PCB, a pump head casting, a pressure sensor, a quality hold, an unavailable reservation, or a late purchase order.
The article therefore introduces an object-centric event model. Instead of treating the process as a single trace, it models events as observations linked to multiple business objects: sales orders, production orders, purchase orders, purchase order lines, suppliers, items, warehouse receipts, quality lots, inventory reservations, operations, work centers, test records, and shipments. This object-centric structure is necessary because manufacturing causality is distributed across objects. The same delay may be visible only when a production order is linked to a component, the component to a purchase order line, the purchase order line to a supplier, the receipt to a quality lot, and the quality lot to the stock-status transition that finally makes the material usable.
A major part of the article is devoted to event construction. The event log is not assumed to exist ready-made inside the ERP or MES. It must be built through a governed transformation from heterogeneous operational records into meaningful business events. This transformation is formalized as an event-construction function that turns raw data into an event log or object-centric event structure. The article stresses that this is not a mere extraction query. It is an IT architecture and semantic-governance problem. The same technical record may represent a status change, a physical event, an approval, a posting, a reversal, a correction, a partial receipt, or a computed availability transition depending on process context. If this interpretation is wrong, the resulting process-mining analysis may be mathematically precise but operationally false.
The article identifies the source systems required for a credible manufacturing process-mining pilot: ERP for sales orders, production orders, purchase orders and inventory transactions; MES for operations, confirmations and test execution; WMS for receipts, put-away, reservations, picking and stock movements; QMS for inspection lots, nonconformities, releases and rejections; supplier portals or EDI logs for confirmations and shipment notices; and logistics systems for packing, transport and shipment events. These systems must be connected through explicit event definitions, object-linking rules, timestamp rules, lineage, access control and validation procedures. The process-mining layer must remain an analytical evidence layer, not an uncontrolled shadow execution system.
The article gives particular importance to timestamp governance. Manufacturing timestamps are not neutral. A timestamp may represent physical execution, operator confirmation, system posting, message receipt, batch update, integration time or extraction time. Since most process-mining metrics are time differences, using the wrong timestamp converts operational diagnosis into numerical artefact. For example, a WMS scan may better represent physical receipt than the ERP posting time; a QMS usage decision may better represent quality release than a later inventory-status update; and a carrier pickup may be more meaningful for shipment completion than a financial posting. The article therefore requires an event catalogue with preferred timestamps, fallback timestamps and known distortions for each event type.
The article also explains why reversals, corrections, partial receipts, partial releases, substitutions and rework orders must be preserved rather than cleaned away. These are not data noise by default; they are often the evidence of the real process. A purchase order line may be received in partial quantities. A quality release may be reversed. A failed test may be overwritten by a final pass status. A production order may be split or recreated. If the event log keeps only the first receipt, the last receipt, or the final state, it may hide the true waiting time, the temporary state that influenced planning, or the exception loop that consumed capacity. For this reason, the article proposes a minimal data contract including event identifiers, event types, timestamps, source systems, source records, object references, resources, quantities, status before and after, reversal flags and confidence levels.
The analytical core of the article is the distinction between physical stock, available stock and quality-blocked stock. Manufacturing planning often fails when it treats inventory as a single quantity. A component may be physically present in the warehouse but unavailable for production because it is under quality inspection, blocked, not yet put away, reserved for another order, or otherwise unusable. The article formalizes available inventory as physical inventory minus quality-blocked, reserved and otherwise unavailable quantities. This distinction changes the interpretation of delay. Without it, the organization may incorrectly attribute waiting time to production, while the true constraint lies in quality release, warehouse execution or allocation logic.
The article then introduces full-kit readiness as the operational point at which a production order has all required components available under the relevant reservation and allocation rules. For each production order, the availability time of each required component can be estimated from receipt, quality release, put-away, reservation, pegging and issue events. Full-kit readiness is the maximum of those component availability times. The critical missing component is the component that becomes available last. This formulation is central because it shows that the manufacturing order is constrained not by the average component, but by the last required component to become usable. A controller PCB that arrives late, or a casting that is physically received but blocked in quality inspection, may dominate the entire order cycle.
Using the smart dosing pump event log, the article reconstructs a concrete delayed order. The event chain shows that the controller PCB becomes available late, full-kit readiness is delayed, assembly starts late, functional testing fails, rework is required, and shipment occurs after the committed date. This is the difference between a planning assumption and process evidence. The planning system may have expected procurement and internal operations to meet the shipment date, but the event log exposes the actual causal chain that made the order late.
The article then uses standard process-mining techniques to move from individual diagnosis to aggregate process intelligence. A directly-follows view projects the event log into adjacent activity relations. Variant analysis identifies recurring patterns such as normal flow, late PCB availability, quality hold on castings, test-fail-rework-test-pass loops, and production-order release before material readiness. Behavioral entropy is used cautiously: high variation is not automatically bad, because it may reflect legitimate product variants, configurations, customer-specific options or plant differences. The disciplined question is whether variation remains high after conditioning on product family, supplier, plant, order type, customer segment or configuration class. If it does, the variation is more likely to indicate operational instability.
Conformance checking is used to compare observed behavior with admissible process rules. The article gives examples of relevant rules: production orders should not be released before material availability is confirmed; final assembly should not start before full-kit readiness; shipment should occur only after functional test has passed. Deviations are not treated as anecdotes. They become measurable events with frequency, duration, affected objects, attributes and owners. A production order released before components are available points to planning or MRP-parameter issues. Assembly before quality release indicates a control violation or incorrect stock status. Multiple test-fail-rework cycles suggest product, routing, supplier-quality, calibration or work-center problems.
The performance-diagnosis section decomposes total cycle time into procurement waiting, quality waiting, full-kit waiting, assembly time, test and rework time, and shipment waiting. This decomposition is not only descriptive. It tells the organization where intervention is possible. If the dominant component is availability lead time rather than receipt lead time, the issue is not only supplier delivery but also quality release and warehouse availability. If test and rework time is significant, nominal capacity is overstated because part of it is consumed by exception handling. If full-kit waiting time dominates, the planning system is releasing or committing orders without correctly accounting for component readiness.
The article then connects process mining to planning-parameter correction. The planning system may contain a nominal lead time for a component, but process mining estimates empirical receipt lead times and, more importantly, empirical availability lead times. The mean may look acceptable while the 90th percentile is operationally dangerous. The receipt lead time may appear stable while the availability lead time reveals quality or warehouse delay. Therefore, planning should not replace one static number with another static number; it should use empirical lead-time distributions. The relevant question becomes which percentile of observed availability lead time should be used for the service level required by the product family.
The same logic applies to capacity. Rework reduces effective capacity. If a specific product variant, supplier batch, sensor type or work center has a high probability of test failure and rework, the delay should not be attributed only to insufficient assembly capacity. It may originate in calibration, supplier quality, design tolerance, assembly procedure or test specification. Process mining estimates the rework probability and translates it into a correction of effective capacity. In this sense, process mining bridges observed execution and S&OP. The S&OP model should incorporate empirical demand realization, empirical lead-time distributions, empirical capacity consumption, effective capacity, exception intensity and availability-adjusted output.
The article’s practical implementation section argues that the first release should not attempt to mine the entire factory. It should be a narrow IT-enabled diagnostic loop: one plant, one product family, one shipment-delay question and a limited set of source systems. 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 implementation requires a business sponsor, process owner, plant manager, planning and supply-chain owners, procurement, quality, warehouse, manufacturing engineering, IT application owners, data engineering, enterprise architecture and IT security or data governance.
The proposed implementation is organized around governance gates. The first gate validates scope: the pilot must be narrow enough and economically meaningful. The second gate validates semantics: sampled traces must be reviewed by planning, warehouse, quality, production and procurement owners to confirm that the event log represents operational reality. The third gate validates actionability: findings must be converted into an action register with owners, target metrics, baselines and a verification period. A successful first release proves that the same production order can be connected to its sales order, purchase orders, receipts, quality lots, reservations, operations, test events and shipment; that the organization can distinguish physical receipt, quality release, available stock, full-kit readiness, assembly start, test pass and shipment; that at least one dominant delay mechanism can be quantified and assigned; and that the next event log can verify whether the corrective action changed the process.
The article is careful about limits. Process mining does not prove causality by itself. It identifies behavioral evidence, temporal relations, deviations, bottlenecks and patterns. Causal interpretation still requires process-owner validation, source-system knowledge and operational judgment. Directly-follows graphs can also be misleading when parallel component flows are projected into a single sequence. Object-centric modeling mitigates this risk by preserving relationships between events and multiple business objects, but it does not eliminate the need for semantic discipline. Timestamp distortion, unstable identifiers, order splits, substitutions, quality-status errors, reservation ambiguity and weak lineage can all undermine the analysis.
The conclusion is that 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, but its real value is not the process map. The value is governed evidence: evidence that identifies the real critical path, separates apparent bottlenecks from causal constraints, assigns findings to accountable owners, corrects planning assumptions and verifies improvement in the next event log. In manufacturing environments with purchased components and variable lead times, process mining becomes a disciplined mechanism for turning operational traces into accountable manufacturing intelligence.
process mining, manufacturing, object-centric process mining, event log, event construction, ERP, MES, WMS, QMS, procurement, supplier lead time, variable lead time, purchased components, production order, sales order, purchase order line, quality lot, warehouse receipt, inventory reservation, full-kit readiness, available stock, physical stock, quality-blocked stock, material availability, critical component, critical path, conformance checking, process variants, directly-follows graph, rework loop, manufacturing execution, S&OP, planning parameters, empirical lead time, data lineage, timestamp governance, semantic validation, enterprise architecture, digital transformation, process intelligence
A practical manufacturing process-mining case showing how object-centric event logs can expose supplier lead-time variability, quality-blocked stock, full-kit delays, rework loops, and planning-parameter errors.
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"]
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:1
D \xrightarrow{\phi} L_E \xrightarrow{\operatorname{mine}} M \xrightarrow{\operatorname{evaluate}} I \xrightarrow{\operatorname{govern}} A
where:
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.
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
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.
The primitive object is the event:2
e = (i,a,t,r,x)
where:
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:
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.
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"]
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
This is the difference between a planning assumption and process evidence.
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.3
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
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.
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.4
The reference model may contain explicit admissibility rules. For example:
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.
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:
This changes the managerial conclusion. Adding assembly operators would not solve the dominant cause.
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.
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.
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
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.
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
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.
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:
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"]
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.
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:
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.
The analysis depends on the quality of the event model. Several risks must be controlled:
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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 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.↩︎
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.↩︎
The directly-follows relation follows the process-discovery section of Process Mining as Computational Process Intelligence.↩︎
See the variants and behavioral-entropy section in Process Mining as Computational Process Intelligence.↩︎
@online{montano2022,
author = {Montano, Antonio},
title = {Process {Mining} in {Manufacturing} with {Purchased}
{Components} and {Variable} {Lead} {Times}},
date = {2022-12-13},
url = {https://antomon.github.io/longforms/process-mining-in-manufacturing-with-purchased-components-and-variable-lead-times/},
langid = {en},
abstract = {This article develops a practical manufacturing example of
process mining applied to a production environment with purchased
components, variable supplier lead times, quality release, warehouse
availability, material reservations, internal operations, testing,
rework, and shipment commitments. Its central thesis is that
manufacturing delay is rarely explained by a single visible
bottleneck. What appears as a production-capacity issue may in fact
originate in procurement timing, supplier variability,
quality-blocked inventory, reservation conflicts, late full-kit
readiness, test failures, rework loops, or shipment execution.
Process mining becomes valuable when it reconstructs this causal
chain from event evidence rather than relying on nominal routings,
static lead times, or generic explanations such as supplier delay,
quality issue, planning error, or shop-floor congestion. The article
uses the example of a configurable smart dosing pump assembled from
purchased components and internal operations. The product is
deliberately simple enough to be understandable, but complex enough
to expose the structural problem of modern manufacturing: one
finished item is not the result of a single linear process. It
depends on a sales order, a production order, a bill of materials,
purchase order lines, supplier confirmations, warehouse receipts,
quality lots, reservations, internal machining, subassembly, final
assembly, functional testing, rework, packing, and shipment. A
case-centric view based only on the production order is therefore
insufficient. The production order may show that assembly started
late, but it may not explain whether the delay came from a
controller PCB, a pump head casting, a pressure sensor, a quality
hold, an unavailable reservation, or a late purchase order. The
article therefore introduces an object-centric event model. Instead
of treating the process as a single trace, it models events as
observations linked to multiple business objects: sales orders,
production orders, purchase orders, purchase order lines, suppliers,
items, warehouse receipts, quality lots, inventory reservations,
operations, work centers, test records, and shipments. This
object-centric structure is necessary because manufacturing
causality is distributed across objects. The same delay may be
visible only when a production order is linked to a component, the
component to a purchase order line, the purchase order line to a
supplier, the receipt to a quality lot, and the quality lot to the
stock-status transition that finally makes the material usable. A
major part of the article is devoted to event construction. The
event log is not assumed to exist ready-made inside the ERP or MES.
It must be built through a governed transformation from
heterogeneous operational records into meaningful business events.
This transformation is formalized as an event-construction function
that turns raw data into an event log or object-centric event
structure. The article stresses that this is not a mere extraction
query. It is an IT architecture and semantic-governance problem. The
same technical record may represent a status change, a physical
event, an approval, a posting, a reversal, a correction, a partial
receipt, or a computed availability transition depending on process
context. If this interpretation is wrong, the resulting
process-mining analysis may be mathematically precise but
operationally false. The article identifies the source systems
required for a credible manufacturing process-mining pilot: ERP for
sales orders, production orders, purchase orders and inventory
transactions; MES for operations, confirmations and test execution;
WMS for receipts, put-away, reservations, picking and stock
movements; QMS for inspection lots, nonconformities, releases and
rejections; supplier portals or EDI logs for confirmations and
shipment notices; and logistics systems for packing, transport and
shipment events. These systems must be connected through explicit
event definitions, object-linking rules, timestamp rules, lineage,
access control and validation procedures. The process-mining layer
must remain an analytical evidence layer, not an uncontrolled shadow
execution system. The article gives particular importance to
timestamp governance. Manufacturing timestamps are not neutral. A
timestamp may represent physical execution, operator confirmation,
system posting, message receipt, batch update, integration time or
extraction time. Since most process-mining metrics are time
differences, using the wrong timestamp converts operational
diagnosis into numerical artefact. For example, a WMS scan may
better represent physical receipt than the ERP posting time; a QMS
usage decision may better represent quality release than a later
inventory-status update; and a carrier pickup may be more meaningful
for shipment completion than a financial posting. The article
therefore requires an event catalogue with preferred timestamps,
fallback timestamps and known distortions for each event type. The
article also explains why reversals, corrections, partial receipts,
partial releases, substitutions and rework orders must be preserved
rather than cleaned away. These are not data noise by default; they
are often the evidence of the real process. A purchase order line
may be received in partial quantities. A quality release may be
reversed. A failed test may be overwritten by a final pass status. A
production order may be split or recreated. If the event log keeps
only the first receipt, the last receipt, or the final state, it may
hide the true waiting time, the temporary state that influenced
planning, or the exception loop that consumed capacity. For this
reason, the article proposes a minimal data contract including event
identifiers, event types, timestamps, source systems, source
records, object references, resources, quantities, status before and
after, reversal flags and confidence levels. The analytical core of
the article is the distinction between physical stock, available
stock and quality-blocked stock. Manufacturing planning often fails
when it treats inventory as a single quantity. A component may be
physically present in the warehouse but unavailable for production
because it is under quality inspection, blocked, not yet put away,
reserved for another order, or otherwise unusable. The article
formalizes available inventory as physical inventory minus
quality-blocked, reserved and otherwise unavailable quantities. This
distinction changes the interpretation of delay. Without it, the
organization may incorrectly attribute waiting time to production,
while the true constraint lies in quality release, warehouse
execution or allocation logic. The article then introduces full-kit
readiness as the operational point at which a production order has
all required components available under the relevant reservation and
allocation rules. For each production order, the availability time
of each required component can be estimated from receipt, quality
release, put-away, reservation, pegging and issue events. Full-kit
readiness is the maximum of those component availability times. The
critical missing component is the component that becomes available
last. This formulation is central because it shows that the
manufacturing order is constrained not by the average component, but
by the last required component to become usable. A controller PCB
that arrives late, or a casting that is physically received but
blocked in quality inspection, may dominate the entire order cycle.
Using the smart dosing pump event log, the article reconstructs a
concrete delayed order. The event chain shows that the controller
PCB becomes available late, full-kit readiness is delayed, assembly
starts late, functional testing fails, rework is required, and
shipment occurs after the committed date. This is the difference
between a planning assumption and process evidence. The planning
system may have expected procurement and internal operations to meet
the shipment date, but the event log exposes the actual causal chain
that made the order late. The article then uses standard
process-mining techniques to move from individual diagnosis to
aggregate process intelligence. A directly-follows view projects the
event log into adjacent activity relations. Variant analysis
identifies recurring patterns such as normal flow, late PCB
availability, quality hold on castings, test-fail-rework-test-pass
loops, and production-order release before material readiness.
Behavioral entropy is used cautiously: high variation is not
automatically bad, because it may reflect legitimate product
variants, configurations, customer-specific options or plant
differences. The disciplined question is whether variation remains
high after conditioning on product family, supplier, plant, order
type, customer segment or configuration class. If it does, the
variation is more likely to indicate operational instability.
Conformance checking is used to compare observed behavior with
admissible process rules. The article gives examples of relevant
rules: production orders should not be released before material
availability is confirmed; final assembly should not start before
full-kit readiness; shipment should occur only after functional test
has passed. Deviations are not treated as anecdotes. They become
measurable events with frequency, duration, affected objects,
attributes and owners. A production order released before components
are available points to planning or MRP-parameter issues. Assembly
before quality release indicates a control violation or incorrect
stock status. Multiple test-fail-rework cycles suggest product,
routing, supplier-quality, calibration or work-center problems. The
performance-diagnosis section decomposes total cycle time into
procurement waiting, quality waiting, full-kit waiting, assembly
time, test and rework time, and shipment waiting. This decomposition
is not only descriptive. It tells the organization where
intervention is possible. If the dominant component is availability
lead time rather than receipt lead time, the issue is not only
supplier delivery but also quality release and warehouse
availability. If test and rework time is significant, nominal
capacity is overstated because part of it is consumed by exception
handling. If full-kit waiting time dominates, the planning system is
releasing or committing orders without correctly accounting for
component readiness. The article then connects process mining to
planning-parameter correction. The planning system may contain a
nominal lead time for a component, but process mining estimates
empirical receipt lead times and, more importantly, empirical
availability lead times. The mean may look acceptable while the 90th
percentile is operationally dangerous. The receipt lead time may
appear stable while the availability lead time reveals quality or
warehouse delay. Therefore, planning should not replace one static
number with another static number; it should use empirical lead-time
distributions. The relevant question becomes which percentile of
observed availability lead time should be used for the service level
required by the product family. The same logic applies to capacity.
Rework reduces effective capacity. If a specific product variant,
supplier batch, sensor type or work center has a high probability of
test failure and rework, the delay should not be attributed only to
insufficient assembly capacity. It may originate in calibration,
supplier quality, design tolerance, assembly procedure or test
specification. Process mining estimates the rework probability and
translates it into a correction of effective capacity. In this
sense, process mining bridges observed execution and S\&OP. The
S\&OP model should incorporate empirical demand realization,
empirical lead-time distributions, empirical capacity consumption,
effective capacity, exception intensity and availability-adjusted
output. The article’s practical implementation section argues that
the first release should not attempt to mine the entire factory. It
should be a narrow IT-enabled diagnostic loop: one plant, one
product family, one shipment-delay question and a limited set of
source systems. 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
implementation requires a business sponsor, process owner, plant
manager, planning and supply-chain owners, procurement, quality,
warehouse, manufacturing engineering, IT application owners, data
engineering, enterprise architecture and IT security or data
governance. The proposed implementation is organized around
governance gates. The first gate validates scope: the pilot must be
narrow enough and economically meaningful. The second gate validates
semantics: sampled traces must be reviewed by planning, warehouse,
quality, production and procurement owners to confirm that the event
log represents operational reality. The third gate validates
actionability: findings must be converted into an action register
with owners, target metrics, baselines and a verification period. A
successful first release proves that the same production order can
be connected to its sales order, purchase orders, receipts, quality
lots, reservations, operations, test events and shipment; that the
organization can distinguish physical receipt, quality release,
available stock, full-kit readiness, assembly start, test pass and
shipment; that at least one dominant delay mechanism can be
quantified and assigned; and that the next event log can verify
whether the corrective action changed the process. The article is
careful about limits. Process mining does not prove causality by
itself. It identifies behavioral evidence, temporal relations,
deviations, bottlenecks and patterns. Causal interpretation still
requires process-owner validation, source-system knowledge and
operational judgment. Directly-follows graphs can also be misleading
when parallel component flows are projected into a single sequence.
Object-centric modeling mitigates this risk by preserving
relationships between events and multiple business objects, but it
does not eliminate the need for semantic discipline. Timestamp
distortion, unstable identifiers, order splits, substitutions,
quality-status errors, reservation ambiguity and weak lineage can
all undermine the analysis. The conclusion is that 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, but its real value is not the process map. The value is
governed evidence: evidence that identifies the real critical path,
separates apparent bottlenecks from causal constraints, assigns
findings to accountable owners, corrects planning assumptions and
verifies improvement in the next event log. In manufacturing
environments with purchased components and variable lead times,
process mining becomes a disciplined mechanism for turning
operational traces into accountable manufacturing intelligence.}
}