The problem is not that you don't have a system.
The problem is that you think you do.
"We already have procedures."
"Everything is documented."
"We're IATF certified."
"It's all in the ERP."
All true, on the surface. You have documents. You have software. You trained people. You spent time and money getting everything "ready."
And yet something still feels wrong. Repeat complaints still come. The same audit findings still return. The line still works the old way when nobody is watching.
Having a system is not the same as using one.
The documentation trap
Somewhere along the way, building a system turned into a to-do list. Write the steps. Draw the flowcharts. Get certified. Configure the software. Done.
The more documents you have, the more "systematic" it feels.
But a written process is not a working system.
The work instruction says "check every batch." What does "check" mean at the machine? Look at it? Measure it? With which gauge? Who decides if it passes? Where is the result written? Does anyone notice if the step is skipped?
It's like printing a gym routine, pinning it on the wall, and wondering why nobody gets fit.
A real system makes the right action the easy action, by design, not by supervision.
Why systems die, even when everything is written down
Systems rarely fail loudly. They die quietly, in the gap between what's planned and what actually happens. Five gaps show up again and again.
1. No shared purpose. If a procedure exists only to pass the audit, the first time production pressure comes, it gets dropped. People follow what they understand the reason for.
2. No ownership. People rarely protect what they didn't help build. A system written in the quality office and handed to the floor becomes a poster on the wall.
3. No visibility. Can your system raise its hand when something goes wrong? If problems only show up in the monthly review, that's not a system. That's a silence machine.
4. No feedback loop. Every process breaks sometimes. What matters is what happens next. Do people report it, or quietly patch it and move on? No loop, no learning.
5. No adaptability. If a procedure hasn't changed in a year despite new parts, new customers, new people and new machines, it isn't adapting. What doesn't adapt eventually cracks.
Dead system or living system?
Use this as a quick check on one of your processes.
| Area | Question to ask | Dead system | Living system |
|---|---|---|---|
| Purpose | Why does this process exist? What problem does it solve every day? | "We made it for IATF." "The customer asked for it." | "It stops this defect reaching the customer." "It prevents rework." |
| Ownership | Who improves it when problems come up? | "Only quality reviews it." "The consultant wrote it." | "The team updates it based on real issues." "Operators suggest changes." |
| Visibility | How quickly do we know when something goes wrong? | "We see it in the monthly report." | "We see it the same shift, at the line." |
| Feedback | What happens when someone spots a problem? | "Nobody talks unless it's a big failure." | "Small issues are raised and recorded. Ideas flow up." |
| Adaptability | When did this last change? | "Years ago. If it's not broken…" | "Last month, after the process change." |
Count your answers in the "dead" column. Zero or one: the system is breathing. Two or three: warning signs. Four or five: it's on paper only. The good news is that every one of these can be fixed.
The beliefs that keep building dead systems
Nobody sets out to build a system people will ignore. It happens because of a few beliefs that sound logical and quietly break everything.
"If it's clearly written, they'll follow it." Clarity on paper is not clarity at the machine. People follow what helps them hit today's target when they're tired and under pressure.
"Once built, it will run." The world changes: a new customer, a new part, a shift added, the team doubles. The system stays frozen, and what once worked slowly stops working.
"More detail means more control." One more column, one more signature, one more checklist. Instead of control, you get overload. People stop reading, start skipping, and guess.
"Copy what works elsewhere." You see a great board at another plant and copy it exactly. In your plant it becomes decoration, because it solved their problem, not yours. Copy the thinking, not the tool.
"Software will fix it." Software speeds up your current process. If the process is broken, software makes it break faster. Fix the process first, then digitise it.
"Our experts will handle it." Every plant has its heroes: the one engineer who knows every customer requirement, the senior operator who fixes every setup. Heroes are valuable, but they hide a broken system. When they're on leave, chaos returns. When they leave, the knowledge leaves with them.
Everything connects
Most improvement efforts fail for one more reason: they fix one part and ignore the rest.
Think of a mechanic who services your vehicle without a diagnostic routine. He's experienced, so he starts changing parts based on instinct. He fixes one problem and creates three new ones. With a troubleshooting routine, he'd find the real cause and change only what needs changing.
Plants do the same. Quality is fixed separately from delivery. Production separately from maintenance. Training separately from the procedures it's meant to support. Before you change anything, ask: if I change this, what else changes?
How to build a system your team actually uses
1. Start with one costly, recurring problem. Not the whole QMS. One thing: a repeat customer complaint, a dispatch delay whenever one person is absent, rework that keeps piling up on one part family. Small, visible wins build belief.
2. Watch what actually happens, not what's written. Put the procedure down and go to the floor. Who's involved? What happens first, next, last? Where does it get stuck? Who decides when something unexpected happens? If the paper says "inspect every batch" and the floor says "inspect when there's time," your starting point is the floor.
3. Build it with the people who do the work. Sit with them and ask: "What would make this faster, clearer and harder to get wrong?" They know more than any manual. When people help build a system, they protect it.
4. Make it visible where the work happens. If the process lives only in a file, people fall back on memory, and memory fails under pressure. Put the flow above the dispatch table. Photos of good and bad parts at the inspection station. Reorder levels marked on the rack.
5. Test, learn and keep improving. Your first version is a prototype. Run it for a week or two, then ask: what worked, what still confused people, where did mistakes still happen? Adjust. And revisit it every few months, because a living system grows with the plant.
What this looks like in practice
Take inspection on a critical part family. One inspector knows exactly which defects matter, what the customer accepts, and how to handle borderline parts. When he's absent, parts pile up, production waits, and people guess.
- Start connected: focus on inspection, but map how delays there affect production flow, delivery and the customer.
- Watch reality: follow the inspector for two days. Note what he actually checks, not what the instruction says.
- Build together: sit with him and an operator. Agree what anyone needs to know to catch the real problems.
- Make it visible: a short checklist at the station, photos of acceptable and rejectable parts, clear pass/fail criteria.
- Test it: let someone else run inspection for a week. See what breaks. Add what's missing, remove what confuses.
The next time he's on leave, inspection carries on without delays or wrong decisions. That's a system.
Three questions to end with
- When did you last improve a process because the floor needed it, not because an audit was coming?
- Do people rely on the system to get work done, or work around it?
- Is your system helping the plant improve, or just helping it survive the next audit?
If those questions sting a little, good. Now you can see what needs fixing, and where to start.