Supply Chain & Production
Analytics System
ETL-powered production analytics with real-time event monitoring, SKU-level demand forecasting, and Agile workflow intelligence for a North American automotive parts manufacturer (General Motors supply chain).
The Challenge
A complex manufacturing operation struggled with massive data volumes from production lines, supply chain feeds, and ERP systems — but no meaningful way to analyze it. ETL processes were slow and brittle. Forecasting was done manually at aggregate level, missing SKU-level demand signals. Unplanned downtime was a persistent cost driver with no early warning system.
Our Solution
We re-engineered the entire ETL infrastructure using PySpark, dramatically reducing processing times. We built real-time event monitoring using PyWin32 socket connections that continuously tracked production line states, deployed SKU-level forecasting models using historical demand patterns, and designed production analytics dashboards that gave operations and plant managers real-time production visibility.
The Impact
ETL processing time dropped by 85%, enabling near-real-time data availability. Unplanned production downtime fell 28% through event monitoring and early warning. Forecast errors reduced by 14% at SKU level, improving supply chain planning accuracy. Agile workflow improvements, informed by analytics, reduced team coordination overhead significantly.
Dashboard View 01
Production Line
Real-Time Monitor
Key Results
Measurable Manufacturing
Intelligence Impact
Dashboard View 02
Supply Chain &
SKU Forecast Analytics
Technical Stack
Technologies Deployed
In Context
What the Numbers
Actually Mean
Headline percentages travel badly between organisations. Here is what each figure measured, and what it depended on.
Supply chain ETL runtime, reduced by restructuring transformations to execute in parallel across partitions rather than sequentially. No hardware change was involved, which is why the improvement was available at all — the constraint was the shape of the work, not the capacity underneath it.
Unplanned production downtime, reduced through improved workflow visibility rather than through any change to the machines. Attributing stoppages to real causes is what redirects maintenance effort; the equipment did not become more reliable, the decisions about it became better informed.
Demand forecast accuracy at SKU level. The gain came from discovering that error concentrated in a minority of items rather than being spread evenly — which made it addressable. Aggregate forecast accuracy would have hidden this entirely.
Architecture
How It Was
Actually Built
Supply chain ETL was the bottleneck, not the reporting. Overnight batch processing meant production questions asked in the morning were answered against data that had stopped being current the previous evening — and when a run failed, the answer simply was not available that day at all.
The pipelines were re-engineered in PySpark, with the transformations that had been running sequentially restructured to execute in parallel across partitions. That is the source of the 85% processing reduction: not different hardware, but work shaped to the framework instead of ported into it. Event monitoring was added so a failure surfaces immediately rather than being discovered when a report is empty.
SKU-level demand forecasting sits on top of the rebuilt pipeline, which is the order that matters — forecasting against unreliable or stale inputs produces confident numbers that are wrong. With the data layer stable, forecast-versus-actual tracking at SKU level showed where error concentrated, which is what made the 14% accuracy improvement actionable rather than merely observed.
Delivery
How an Engagement
Like This Runs
Retrospective
What We Would
Do Differently
Every engagement teaches something. These are the decisions we would change if we started this one again.
Event monitoring should have been part of the first release rather than added later. For several weeks the pipeline was faster but no more observable, and a silent partial failure is more damaging than a slow run that visibly completes.
We would also agree the downtime taxonomy before building the analysis. Reason codes were being interpreted differently between shifts, and reconciling that afterwards cost more than defining it up front would have.