Quality Issues Rarely Start Where You Think They Do
Why Engineers Must Play Detective
Manufacturing issues rarely originate where they first appear. Often, they stem from a long and overlooked chain of events.
It starts in Stamping. A flat sheet of metal is passed through a series of dies to press, pierce, and trim it into a door panel. But the draw die was set slightly out of balance, causing the shape of this batch of panels to differ slightly.
This subtle deviation has a cascade of downstream effects.
Now the panel has reached Body Shop. It sits differently in the hemming fixture, altering the form further, affecting the fit to the vehicle.
Before the vehicle moves to paint, the changed fit condition makes it difficult for the production associate to apply the jig that holds the door in position through the multiple dips and ovens of the paint process.
The door warps further as it is baked.
Now it’s in General Assembly. The door no longer sits flush with the fender. A fitter, under pressure to keep the line moving, improvises a fix by adjusting the fender, and in turn the hood.
At the next station, the hood doesn’t cinch properly. The latch is adjusted. Now the gap between the hood and headlight grows. The issue is flagged at final audit.
A quality concern is raised, for an issue that began days earlier in stamping.
🔍 Now begins root cause analysis
My example of how a quality issue manifests itself might be slightly exaggerated, but I am sure there are some of you out there that lives this on a regular occurrence.
For everyone else, bear with me as I extend the chain of events, to how the problem resolution process plays out.
Now, Quality and Process Engineers are likely to be trained in root cause analysis processes, fishbone diagrams, 8D, A3s and alike. But these days, the process usually begins by raising a JIRA ticket and assigning an owner.
Now that owner is under pressure to show some progress, with the first step being containment.
Correctly, they go to investigate the fit process. After some discussions with the fitters, they find a few tweaks that reduce the issue. It gets the begrudging approval of the quality auditor and vehicles can keep shipping. But the underlying condition still needs resolution.
Then the night shift comes in.
There’s no pass-down. The issue flares up again. At 2 a.m., the quality engineer gets a call, multiple cars have hit rework. They make their way in, and present the containment to the night shift, and production begins flowing again.
Stressful, right? And we haven’t even started to investigate root cause.
Fast forward a few days. The containment mostly holds, despite occasional escapes. The quality engineer finally gets what they think are the most likely parts measured, the hood and fender. Both are within spec.
While waiting for the hood and fender results to return from metrology, they search around and find some continuous data collection of gap and flush measurements between the body panels in Body Shop, prior to being shipped to paint.
Aha, they see a shift in the trend of the flush measurement between the front door and fender the previous week, but it has since returned to normal.
They speak to associates and hear anecdotal reports:
“Yeah, last week’s doors felt different.”
However, without traceability, there’s no way to isolate the door assemblies. Instead, they grab a random sample from the line for measurement and request inspection of the hemming fixture.
They update the JIRA ticket - waiting on measurements - enough progress to get them through this week’s quality review.
But then there are reports of cars in general assembly failing containment, first the occasional black car, then a steady stream of white and blue ones.
The quality engineer, now armed with partial data and a bit more confidence, proposes a test, remove the containment for ten vehicles, check fit, and review.
Eight out of ten cars pass, and it is agreed to remove the containment and send anything failing to rework.
A few more days pass. No major incidents, fewer and fewer cars are routed for rework, except a batch of yellow cars which mysteriously showed up all at once with the old issue. But that passes too.
Surprisingly, the issue seems resolved.
Eventually, the remaining measurements come back, Nothing conclusive. The only real insight remains that shift in the door fit chart from Body Shop.
The engineer uploads the chart to JIRA, along with a note:
"There was a process change in Body Shop that affected door fit. Recommend reaction plan if metrics go out of control again."
The ticket is closed, without the investigation ever progressing to Stamping.
And the quality engineer sleeps peacefully, until the next time the die isn’t balanced correctly.
⚙️ How can this chain of events be improved?
Industry 4.0 and AI hold promise, but being able to leverage these tools is an end result. Less is discussed about the process of getting there.
While this article focuses on data, there is a whole skills and attitude aspect as well. No quality process or data insight will offset the skill of logically and mechanically thinking through a problem and getting hands on trying to tangibly see how a process behaves.
But the reality is that while there are forward thinking manufacturers that have live dashboards showing manufacturing health, and human-in-the-loop feedback alerting engineers of process deviations that can be dealt with before it becomes a quality concern.
Over 90% of the manufacturing sector are Small and Medium Enterprises (SMEs) and the vision of Industry 4.0, is far out of reach.
What does exist is a scattered mess of proprietary software, spreadsheets, PDFs, and whiteboards. Measurement data lives in Excel. Maintenance logs are scribbled in notebooks. Quality escapes are buried in a poorly organized JIRA system.
Process engineers are stuck cutting and pasting across tabs, trying to link information that was never designed to be connected.
Like your product design, production system and Manufacturing Execution System (MES), your quality and process data system should be designed from the outset.
Where should measurements be collected? What process parameters are critical? Where should sensors be placed within the production line? These are all questions that should be asked, along with the specification of data formats, traceability, database architecture and quality reports.
Now with Large Language Models (LLM) there is a place to centralize informal communication, slack messages, maintenance logs, meeting transcriptions. All this can be analyzed along with quantitative data to remind the team of that shim move that was made two weeks ago, or the robot that had to be reprogrammed following a fault.
All of which would add context for the poor engineer in our example. The maintenance team in Stamping may have recorded an anomaly when they loaded the door die. This could then be tied to the batch of doors that caused the quality concern.
But there are barriers. Propriety software wrapped in layers of permissions, tiers, guardrails, and configuration steps. I remember being sent a quote for $5k just to be able to get a poorly formatted excel from a gear measurement machine.
Then there are SaaS tools tailored for data scientists, tools that overlook the needs of quality and process engineers, and end up pushing teams back to tried-and-trusted Excel.
These are problems which can be overcome with discipline. If the right data is captured early, engineers don’t have to start from scratch every time an issue shows up. Instead, they can look across connected datasets, spot patterns, and apply lessons learned.
🧩 Start Where Engineers Start
The goal isn’t just automation. It’s not AI for AI’s sake. It’s building systems that meet engineers where they are, on the floor, in the problem, figuring things out.
That means tools that surface the right data at the right time, preserve context across shifts, and make it easier to solve problems.
We need systems designed to support the messy, human-centered work of engineering problem solving, helping people connect the dots, remember what happened last time, and fix things properly.
Because the future isn’t just AI-driven. It’s engineer-enabled.
📚Thanks for Reading
If you enjoyed the article please consider sharing or subscribing. If you are not yet convinced please check out some of my other articles:
Also, please feel free to connect with me on LinkedIn.
Reading this brought back some fun memories of my days in automotive.