Process Analysis Using Machine Data: Understanding Workflows and Variants

Process analysis reconstructs actual production flows from event data. It shows which stages and activities a product has actually gone through, how long individual steps took, and where variations, backtracking, rework loops, or wait times occurred.

While traditional metrics summarize the outcome of a process, process analysis examines the path leading to that outcome. This reveals deviations that remain hidden in aggregated reports or a static target process.

What is process analysis in manufacturing?

A production process consists of activities and events: a part arrives at a station, a processing step begins, an inspection ends, or a rework process is triggered. If these events are stored with a timestamp and a common case ID, the actual sequence of events can be reconstructed chronologically.

A process analysis answers questions such as:

• Which process paths actually occur?
• Which option is the standard case, and which ones are exceptions?
• Where do waiting, transit, and layover times occur?
• Which stations are visited more than once?
• Which paths are particularly common in cases of scrap or rework?
• How do lines, products, and layers differ?
• Does the actual process deviate from the defined target process?

Production Analysis, Process Analysis, and Process Mining

Production Analysis

Production analysis examines output, quality, cycle times, machine status, and process parameters. It usually starts with a key performance indicator and narrows down an anomaly by time, workstation, or product.

Process Analysis

Process analysis focuses on the sequence and interrelationships of activities. It is particularly helpful when the same output is produced through different paths, repetitions, or waiting times.

Process Mining

Process mining refers to methods that automatically derive process models, variants, and deviations from event logs. It is a technical method within the broader field of process analysis. The business-oriented evaluation of the identified paths remains the responsibility of the process owners.

Value Stream Analysis

A traditional value stream analysis often describes material and information flows based on observations and workshops. Event-based process analysis supplements this idealized and sample-based picture with real-time data continuously captured from actual processes.

The Required Data Structure

The quality of a process analysis depends largely on the event log. Each entry must include at least:

Field	Meaning	Example
Case ID	Links events related to the same case	partId, batchId, orderId
Activity	Describes the step performed	Assembly, Inspection, Rework
Timestamp	Organizes events chronologically	Start or end time

Depending on the question, it may be helpful to include additional fields:

• Station, machine, or line;
• Event type, such as start, end, or status change;
• Product, variant, order, or recipe;
• Quality class and test results;
• Processing, waiting, or transit time;
• Process parameters and tool context;
• Shift, work group, or location.

A production log can provide information about parts and processes. Machine statuses and messages provide additional context when explaining interruptions or malfunctions.

From Raw Signals to the Event Log

Machines rarely provide a complete event log directly. Often, PLC signals, counters, state changes, or database entries must first be interpreted in a technical context.

Define Events

Specify how the start and end of an activity are detected. A signal change can mark the start of a process, and a test result can mark its completion.

Determine the case identifier

The job identifier is the most important link in the process. In discrete manufacturing, this is often a part ID. If no unique identifier exists, mapping rules must be carefully developed and any uncertainties documented.

Standardize time references

Timestamps from control systems, gateways, and IT systems must be comparable. Time zones, different clocks, transmission delays, and retroactive entries can distort the sequence.

Resume Normal Activities

Technical signal names should correspond to stable technical activities. Comparable machines should use the same activity terms whenever possible.

Add context

Product, order, quality class, and plant structure enable targeted comparisons of variants at a later stage.

Key Analyses and Key Figures

Process Variants

Variants group cases with the same or a similar sequence of activities. Frequency and outcome indicate which paths are normal, rare, or problematic.

Lead time

The turnaround time covers the period from the defined start to the end of a case. It includes processing, waiting, transport, and holding times.

Processing and Wait Times

Analyzing each component separately reveals whether a bottleneck is caused by slow processing or by the time between activities.

Loops and Repetitions

Repeated cycles of the same activity may indicate rework, repeat inspections, or unstable processes. Not every loop is undesirable; it depends on the intended process as defined by the subject matter experts.

Transitions and Bottlenecks

Frequent or particularly slow transitions between stations indicate transportation problems, missing buffers, or dependencies.

Conformity

Conformance checking compares actual sequences of events with a defined target process. Deviations can include skipped steps, incorrect sequences, or unexpected repetitions.

A Systematic Approach

1. Define the process boundary

Define the start, end, and technical unit of the analysis. A case can be a part, a batch, an order, or a fault event.

2. Clarify the question

Examples include: “Which processes most often result in rework?” or “Where does the additional lead time for product variant C occur?”

3. Validate the Event Log

Check case IDs, timestamps, activity names, missing events, and impossible sequences in specific cases.

4. Determine the main route and alternatives

Identify the most common workflow and compare rare or unusual variations in terms of time, quality, and output.

5. Identify bottlenecks and loops

Examine processing and wait times, as well as repetitive activities. Filter by product, line, shift, or result.

6. Add process context

Link notable incidents to machine statuses, messages, and process parameters to identify plausible causes.

7. Review the measure and process changes

Compare variants, lead times, and quality results before and after a change. Make sure that a loss hasn't simply been shifted to another area.

Example: Rework loop on an assembly line

Suppose the average lead time increases, even though the processing time at each station remains constant.

The process analysis shows:

1. The main workflow leads from assembly through testing directly to approval.
2. A growing proportion of parts are returning from inspection to the assembly line.
3. This loop occurs primarily in a specific product variant.
4. The affected parts previously exhibited an abnormal value for a process parameter.
5. Following a technical adjustment, the proportion of this variant will decrease and the turnaround time will return to normal.

Without case-specific events, only the longer overall duration would have been apparent. The actual drop and its product context are what explain the cause of the loss.

Real-time Analysis and Historical Analysis

Historical process analysis is useful for identifying and validating variations over extended periods of time. It supports root cause analysis, process design, and improvement projects.

A live view can detect known deviations during production, such as an unexpected setback or an unusually long wait time. To do this, rules, data quality, and the desired response must be clearly defined.

Both approaches should be based on the same event and context model. Otherwise, historical insights and operational monitoring will differ from a technical standpoint.

Common Data Quality Issues

• missing or duplicated case identifiers;
• Events with no clear connection to a facility or activity;
• Inconsistent clocks and timestamps;
• missing start or end events;
• technical names that differ from one machine to another;
• IT events posted retroactively that do not correspond to the actual time;
• Product changes or manual interventions without an explicit event.

Before performing an automated assessment, actual individual cases should be reconstructed in collaboration with those responsible for the process.

Requirements for Process Analysis Software

A suitable solution should:

• Generate or import event logs from machine and production data;
• Clearly display case IDs, activities, and timestamps;
• Visualize main routes, alternatives, loops, and transit times;
• filter by product, line, shift, time period, and quality;
• trace individual cases back to their original events;
• Integrate production metrics, reports, and process parameters in a complementary manner;
• Compare target processes with actual workflows;
• Document the results and actions taken for before-and-after analyses.

The Bytefabrik "Process Analysis" feature reconstructs actual production paths within Manufacturing Insights. For more information on the underlying methodology, see "Production Analysis Using Machine Data" and "Identifying Production Problems."