Process Analysis in Manufacturing: Methods, Data & Tools

What is process analysis?

Process analysis is the systematic examination of manufacturing processes to understand how they actually behave — as opposed to how they are assumed to behave. It combines data from the shopfloor with structured analytical methods to identify bottlenecks, variance sources, loss patterns and optimisation potential. Synonyms in common use: process investigation, production analysis, Prozessanalyse.

The shortest honest definition: process analysis is the discipline of replacing opinion with evidence in production decisions. That sounds obvious — but in my experience building the data platform for 15,000+ connected machines, almost every plant begins process analysis with an opinion about what the problem is, and the first week of real data proves the opinion wrong about 60–70% of the time. That is not a criticism; it is a property of complex systems that nobody can observe in full without instrumentation.

What types of process analysis are there?

The useful taxonomy — each answering a different question:

Most plants skip from descriptive directly to prescriptive — observe a symptom, prescribe a solution. The diagnostic step in the middle is where the work lives, and it is the step that requires data infrastructure that most plants do not have until they deploy an MES. Without correlation data, every diagnosis is a guess, and every prescription is an expensive bet.

What methods are used in process analysis?

The classics work because they are orthogonal — each exposes a different kind of problem:

• Pareto analysis — ranks defect reasons or stop causes by frequency or cost impact. Always the first analysis to run. In every plant I've seen, three reasons cover 60–70% of the problem.
• Value-stream mapping — exposes waste in the flow between processes, not just inside them. Catches queue times, transport waste and information delays that in-process analyses miss.
• Fishbone (Ishikawa) diagrams — structures root-cause investigation across man, machine, material, method, measurement, environment. Only useful after enough data exists to populate it.
• 5-Why — iterative questioning to move from symptom to root cause. Simple, but surprisingly effective when the first "why" answer is usually wrong.
• SPC charts — statistical control charts (Xbar-R, I-MR, p-charts) that separate common-cause from special-cause variation. Essential for stability analysis; requires time-series data with enough resolution.
• FMEA — failure mode and effects analysis for prospective process design. Less about running analysis, more about anticipating where variance will emerge.
• Correlation/regression — statistical linking of process parameters to quality outcomes. The highest-value analysis in most discrete manufacturing settings, and the one that depends most heavily on data infrastructure.

What data does process analysis actually need?

This is where most process-analysis initiatives fail before they begin. The methods are well-documented; the data to feed them usually isn't there. The minimum viable data set for serious process analysis:

1. Machine state time series — running, stopped, blocked, starved, setup. Timestamped at source, sampled at least every few seconds. This is the backbone of availability analysis.
2. Cycle-time data per part — not per shift, not per order. Per-part resolution is what makes performance analysis meaningful.
3. Stop events with reason codes — captured at source, classified close to the event in time. Reason codes logged hours later are essentially fiction.
4. Quality events linked to process parameters — a defect event without the process parameters at the moment of defect is half a data point.
5. Contextual data — order, product, material batch, operator, shift. Without this, segmentation is impossible and all analysis becomes averaged noise.

The single most common failure mode I see: a plant invests in analytics software while its underlying data is aggregated hourly, reason codes are free-text, and quality events live in a separate system that can't be joined to machine data. The software then produces graphs that everyone agrees are beautiful and nobody trusts enough to act on. The fix is not better analytics — it's better data capture.

How does process analysis fit with MES?

Process analysis and MES are complementary in a specific way: the MES produces the data; the analysis interprets it. A cloud-native MES with per-part cycle-time capture, reason-coded stops and parameter logging essentially pre-builds the data layer that every process-analysis initiative needs. From my perspective designing the platform, the hardest part of process analysis is almost always the data plumbing — protocol handling, time-stamp synchronisation, context joins, retention policies. When that infrastructure is in place, the analytical work gets dramatically easier, and the time from "we have a hypothesis" to "we have evidence" drops from weeks to minutes.

What does a good process-analysis workflow look like?

The sequence that actually delivers results, in the order that matters:

• Define the question precisely. "Why is OEE low" is not a question — it's a complaint. "Why does Line 3 produce 18% scrap on Product X but not on Product Y" is a question. The precision of the question determines the precision of the answer.
• Check the data exists. Before running any analysis, verify the required data is actually available at the required resolution. Half the analyses I've seen fail because the data the method requires isn't there in usable form.
• Run descriptive first. Pareto, histograms, run charts. Understand what is before asking why.
• Segment before correlating. A correlation across all products, all shifts and all operators is usually a statistical illusion. Segment the data into homogeneous populations before looking for causes.
• Validate the hypothesis with an experiment. Correlation in historical data is not causation. Run a controlled change on one line and measure the effect.
• Standardise the result. An improvement that isn't documented in standard work disappears with the next shift change.

FAQ

What's the difference between process analysis and process mining?
Process mining is a specific subset of process analysis that focuses on extracting process flow patterns from event logs — typically in administrative and business processes. Manufacturing process analysis is broader: it includes physical process parameters, machine states and quality data, not just event sequences. The methods overlap; the data sources and questions do not.

Do you need statistical expertise for process analysis?
For SPC and regression work, yes. For Pareto, 5-Why and value-stream mapping, no — they require discipline, not statistics. Start with the structured methods; add statistics when the questions demand it. Most plants over-estimate the statistical sophistication required and under-estimate the data-discipline required.

How is process analysis related to Six Sigma?
Six Sigma is a framework that uses process analysis as one of its core activities — especially in the Measure and Analyze phases of DMAIC. Process analysis exists independently of Six Sigma as a general discipline, but most serious process-analysis practitioners use Six Sigma tools because they are battle-tested.

Can process analysis be automated?
Partially. Descriptive and diagnostic analyses can be automated when the data is structured — live dashboards, automatic Pareto generation, correlation alerts. Prescriptive analysis — deciding what to do about the findings — remains a human judgement problem, at least for now. AI assistants are good at surfacing patterns; they are not yet reliable at choosing the right corrective action.

How long does a typical process-analysis cycle take?
With automatic data capture in place, from question to validated answer in 2–4 weeks is realistic for a focused problem. Without that infrastructure — when the data has to be gathered manually — 3–6 months is typical, and the analysis usually arrives after the process has changed for other reasons. That delay is the single biggest argument for investing in data infrastructure before analytical sophistication.

What's the most common mistake in manufacturing process analysis?
Analysing averages instead of distributions. An OEE average of 78% can hide a line that runs at 90% on some shifts and 60% on others — which is a completely different problem than a line that runs at 78% every shift. Averages destroy the information that matters most. Always look at the distribution before drawing conclusions from the mean.

How does SYMESTIC support process analysis?
SYMESTIC is built on the premise that the analysis is only as good as the data feeding it. The platform captures machine states, cycle times and stop events automatically via OPC UA, MQTT and digital-I/O gateways — with timestamp precision and contextual joining to orders, products, operators and shifts. Production Metrics and Process Data modules make Pareto, run-chart and correlation views available in real time, without exporting to a separate analytics tool. The platform doesn't replace the analyst; it removes the data plumbing that used to consume 80% of the analyst's time.

Related: OEE · MES · Statistical Process Control · Six Sigma · Production Stability · Value-Stream Mapping · Root-Cause Analysis · Machine Data Collection · Production Metrics · Process Data.

About the author

Mark Kobbert

CTO of SYMESTIC GmbH. Responsible for the Cloud-MES architecture since 2014. Built the platform from scratch as cloud-native on Microsoft Azure — microservices, OPC UA and MQTT gateway connectivity, real-time processing of 15,000+ connected machines in 18 countries. B.Sc. Business Informatics (SRH Heidelberg). · LinkedIn