From production events to useful process evidence
A practical introduction to object-centric process mining: event data, traceability, conformance checks and responsible interpretation for engineering teams in Tanzania and beyond.
Start with a decision, not a dashboard
A useful process-mining study begins with a specific operational question. For example: where does an order wait between machining and inspection, or which rework paths occur before release? Define the decision, the observation period and the responsible process owner before extracting data. An attractive process map alone does not demonstrate a productivity improvement. A small, well-defined question makes it easier to check timestamps, compare like-for-like work and explain what a result can and cannot establish.
Discuss a research questionWhat makes an event log object-centric?
An event records an activity at a time and relates it to identifiable objects. In manufacturing, objects might include orders, parts and machines. OCEL 2.0 supports event-to-object and object-to-object relationships, including qualifiers and changing object attributes. This helps retain relationships that would be lost if every event had to fit one case identifier. The official OCEL specification defines the format; it does not guarantee that a particular source system records complete or correct data.
Read the OCEL 2.0 specificationAn illustrative workshop example
Consider an illustrative job with two parts: part A passes inspection while part B returns for another machining operation. Both belong to the same customer order, but their paths differ. Record the inspection result against the relevant part and link the part to its order. Keep the machine relationship where it is available. A single order-level row can conceal the rework path; duplicating every shared event across parts can inflate apparent activity counts. This example describes a modelling choice, not a measured result from a client project.
Explore the publication recordCheck the evidence before modelling
Agree on identifiers, event meanings, time zones and the treatment of cancellations. Check for duplicated records, missing completion events and timestamps captured long after the work happened. Document whether a duration means processing time or elapsed time that also includes a queue. Compare a sample of reconstructed traces with workshop records or the people responsible for the process. Retain the original data and transformation rules so another analyst can reproduce the result. An undocumented cleaning decision can otherwise change the conclusion.
Explore the research contextInterpret conformance with care
A conformance check compares recorded behaviour with an explicit model or rule. A deviation is a reason to investigate; it is not automatically evidence of poor performance or misconduct. The rule may omit a legitimate exception, or the event log may be incomplete. Evaluate findings with engineering and process knowledge. When testing a predictive model, separate training and evaluation data and report the conditions of the test. Avoid presenting a laboratory score as a guaranteed result for a different factory.
Read the related publication detailsA practical starting point in East Africa
A pilot can focus on one process and a limited set of records before attempting a broad system integration. Identify who can authorize access, remove personal fields that are unnecessary for the question, and agree on a data dictionary. Specify the expected output: for example, a validated trace sample, a documented bottleneck hypothesis or a reproducible conformance check. Cost, connectivity, instrumentation and staff time shape the feasible scope. The next step is to discuss those constraints, not to promise an improvement percentage before examining the evidence.
Plan a scoped collaboration