A part was wrong, so you replaced it.<\/strong><\/p>\n That is containment.<\/strong> Necessary, immediate, and not the job finished.<\/p>\n Corrective action asks why the wrong part got through<\/strong> \u2014 and changes something so it does not happen again.<\/p>\n Most companies stop at containment.<\/strong> Which is why the same problems recur for years, each time treated as a fresh event.<\/p>\n The test:<\/strong> if the same situation arose tomorrow, would the outcome be different?<\/p>\n If not, you fixed the instance. Nothing has been corrected.<\/p>\n Correction.<\/strong> Fixing the immediate problem. Replace the part, redo the work, refund the customer.<\/p>\n Corrective action.<\/strong> Removing the cause of something that happened.<\/p>\n Preventive action.<\/strong> Removing the cause of something that has not happened yet, but could.<\/p>\n CAPA<\/strong> covers the last two, and it is the process most standards require you to have.<\/p>\n FIGURE 1: THREE DIFFERENT THINGS<\/p>\n Correction<\/p>\n Corrective action<\/p>\n Seven steps. Skipping any of them is where CAPA becomes paperwork.<\/p>\n 1. Describe the problem.<\/strong> Specifically. Not “quality issue” \u2014 what happened, when, to what, how many.<\/p>\n 2. Contain it.<\/strong> Stop it getting worse. Quarantine the stock, halt the process, notify the customer.<\/p>\n 3. Find the root cause.<\/strong> The methods below.<\/p>\n 4. Decide the action.<\/strong> What will change so this cannot happen the same way again.<\/p>\n 5. Do it.<\/strong><\/p>\n 6. Verify it worked.<\/strong> The step most often skipped.<\/strong> Come back later and check the problem has actually stopped.<\/p>\n 7. Close it.<\/strong> With evidence.<\/p>\n Step 6 is what separates a working CAPA system from a log of good intentions.<\/strong> Auditors look for it specifically.<\/p>\n Three methods, in order of complexity.<\/p>\n Ask why, repeatedly, until you reach something worth changing.<\/strong><\/p>\n The part was wrong. Why?<\/em> The operator used the wrong setting. Why?<\/em> The setting sheet was out of date. Why?<\/em> Setting sheets are updated by hand and nobody was assigned to it. Why?<\/em> The process for updating them was never defined.<\/p>\n Now you have something to fix<\/strong> \u2014 and it is not “retrain the operator”.<\/p>\n Two cautions:<\/strong><\/p>\n Five is not a rule.<\/strong> Stop when you reach something you can change.<\/p>\n Do not stop at human error.<\/strong> “The operator made a mistake” is where weak investigations end. Ask why the process allowed the mistake to matter.<\/strong><\/p>\n A structured way to consider causes across categories<\/strong> \u2014 people, method, machine, material, measurement, environment.<\/p>\n Useful when the cause is not obvious<\/strong>, and useful in a group, because it stops everyone anchoring on the first theory.<\/p>\n A more formal eight-discipline process<\/strong>, common in automotive and in customer-facing corrective action.<\/p>\n Team, describe, contain, root cause, choose the fix, implement, prevent recurrence, close and recognise.<\/p>\n Heavier than 5 Whys.<\/strong> Appropriate for significant problems, customer complaints, and anywhere a formal report is expected.<\/p>\n Often required by automotive and aerospace customers<\/strong> as the format for responding to a complaint.<\/p>\n FIGURE 2: PICKING A METHOD<\/p>\n 5 Whys<\/p>\n Fishbone<\/p>\n 8D<\/p>\n All three<\/p>\n Four patterns.<\/p>\n Stopping at human error.<\/strong> “The operator made a mistake” is a description, not a cause. Why did the process let a mistake become a defect?<\/strong> Design the process so mistakes are caught, not so people never make them.<\/p>\n Stopping at the first plausible answer.<\/strong> The first theory is often right and often incomplete. Ask why once more than feels necessary.<\/p>\n Blame.<\/strong> An investigation people are afraid of gets incomplete information. The people closest to the problem know most about it<\/strong>, and they will not say so if the outcome is disciplinary.<\/p>\n No time.<\/strong> Root cause takes an hour or two. Skipping it means doing the whole thing again next quarter.<\/p>\n A good corrective action changes something structural.<\/strong><\/p>\n Weak:<\/strong> retrain the operator. Remind the team. Add a check to the procedure.<\/p>\n Why weak:<\/strong> they depend on people remembering, and the next new starter has not been reminded.<\/p>\n Stronger:<\/strong> change the process so the error is not possible. Make the wrong setting physically unavailable. Automate the update. Add a system validation that blocks it.<\/p>\n A useful ranking:<\/strong><\/p>\n Eliminate<\/strong> \u2014 make the failure impossible.<\/p>\n Control<\/strong> \u2014 make it automatically caught.<\/p>\n Warn<\/strong> \u2014 make it visible.<\/p>\n Train<\/strong> \u2014 make people aware.<\/p>\n Work down the list<\/strong>, and only settle for training when the ones above are genuinely not practical.<\/p>\n FIGURE 3: WEAK AND STRONG ACTIONS<\/p>\n Weak<\/p>\n Strong<\/p>\n Come back and check.<\/strong><\/p>\n When:<\/strong> after enough time or enough volume that recurrence would have shown.<\/p>\n What to check:<\/strong> has the problem happened again? Is the new process actually being followed? Did it create a different problem?<\/p>\n That last question matters.<\/strong> A control added in one place sometimes causes a delay or a workaround somewhere else.<\/p>\n Without verification, CAPA is a log of intentions.<\/strong> With it, you can say the problem is fixed and show why you believe that.<\/p>\n Record everything, including small things.<\/strong> You cannot see patterns in problems you never wrote down.<\/p>\n Look at the log periodically.<\/strong> Three separate small issues with the same underlying cause is a bigger finding than any of them alone.<\/p>\n Keep it proportionate.<\/strong> A full 8D for a minor issue means nobody raises minor issues. Match the effort to the significance.<\/p>\n Close things.<\/strong> An open CAPA list that only grows tells you the process is not working.<\/p>\n And make raising problems safe.<\/strong> A system where reporting leads to blame produces a system where nothing is reported.<\/p>\n Correction fixes the instance. Corrective action removes the cause.<\/strong> Most companies do the first and call it the second.<\/p>\n 5 Whys for straightforward problems, fishbone when the cause is unclear, 8D when it is significant or a customer is waiting.<\/strong><\/p>\n Do not stop at human error.<\/strong> Ask why the process let a mistake become a defect.<\/p>\n And verify.<\/strong> Without coming back to check, CAPA is a record of what you meant to do.<\/p>\n The same problems coming back every few months?<\/p>\n Get in touch. That is almost always containment without root cause \u2014 and the fix is a process, not more effort.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The distinction everything depends on A part was wrong, so you replaced it. That is containment. Necessary, immediate, and not the job finished. Corrective action asks why the wrong part got through \u2014 and changes something so it does not happen again. Most companies stop at containment. Which is why the same problems recur for […]<\/p>\n","protected":false},"author":3,"featured_media":9465,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29],"tags":[],"class_list":["post-9464","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-quality_management"],"yoast_head":"\nThe three terms<\/h2>\n
\n
\n
The CAPA process<\/h2>\n
Finding root cause<\/h2>\n
5 Whys<\/h3>\n
Fishbone<\/h3>\n
8D<\/h3>\n
\n
\n
\n
\n
Why investigations fail<\/h2>\n
Choosing the action<\/h2>\n
\n
\n
Verification<\/h2>\n
Making it work<\/h2>\n
The short version<\/h2>\n