Tags: SQL, Statistical Process Control, Data Analysis
Domain: Manufacturing
PostgreSQL
To support process stability and quality assurance in a manufacturing setting using SQL to apply Statistical Process Control (SPC) techniques — identifying deviations, flagging anomalies, and surfacing operational risks through data.
This case study demonstrates how SQL can be used as a lightweight alternative to external SPC software. The objective was to move beyond basic metrics and build layered logic that tracks rolling averages, detects control limit violations, highlights recurring problem areas, and identify potential quality risks — all from within the database.
In manufacturing, even small deviations can lead to costly downstream issues — whether it’s defective parts, increased rework, or delays. SPC provides a framework to distinguish between random variation and actual process shifts, helping teams avoid unnecessary corrections while still reacting quickly when needed.
In this simulation, we applied SPC logic using SQL directly on production data, replicating how such monitoring could work live on a factory floor. The dataset comes from the manufacturing_parts table and includes the following fields:
item_no: unique part identifier.
length, width, height: measured dimensions of each part.
operator: the machine or individual responsible for that batch.
Each query built upon the last, progressively layering in more targeted insights:
Control Limit Alert.
📌 Purpose: Flag any product whose height falls outside rolling control limits.
🧠 Why it matters: SPC depends on real-time detection of anomalies, so these flags are the foundation for more advanced monitoring.
💡 Business value: Enables immediate detection of faulty outputs and supports consistent quality across production runs.
Rolling Mean Deviation.
📌 Purpose: Compare each rolling 5-part average to the overall average per operator..
🧠 Why it matters: Subtle shifts in measurements can indicate an emerging issue.
💡 Business value: Enables real-time quality monitoring and early detection and rejection of faulty outputs.
Control Limit Violations Count.
📌 Purpose: Count how many violations occurred per operator.
🧠 Why it matters: Quantifies instability across the process.
💡 Business value: Enables targeted investigation into batches or shifts.
First Violation Detection.
📌 Purpose: Identify the first part in the production line that violates control limits.
🧠 Why it matters: Early detection helps avoid widespread downstream issues.
💡 Business value: Supports root-cause analysis and early intervention.
Operator Stability Check.
📌 Purpose: Flag operators who produce consecutive violations.
🧠 Why it matters: Consecutive failures can signal deeper issues with calibration, training, or equipment.
💡 Business value: Informs retraining needs and resource allocation.
This project shows that SPC practices can be implemented directly within a SQL environment, without requiring new tools or platforms. With just historical production data and core SQL features, teams can begin to monitor process health, flag anomalies, and uncover deeper operational trends — paving the way for more robust quality assurance at scale. This opens the door to faster quality feedback, better operator accountability, and scalable QC processes without introducing new software tools.
To see the code, please visit my GitHub.