Quality data separated from production data is quality data nobody uses.<\/strong><\/p>\n If inspections live in a spreadsheet and production lives in your ERP, connecting a defect to a batch, a supplier, an operator or a work order is a manual exercise. So it does not happen<\/strong>, and the patterns that would tell you something stay invisible.<\/p>\n In the same system, the connections are already there.<\/strong> A failed inspection knows which lot it belongs to, which supplier the material came from, and which work order produced it.<\/p>\n That is the argument for doing it in Odoo<\/strong> rather than alongside it.<\/p>\n Quality control points.<\/strong> Where an inspection happens \u2014 at receipt, during manufacturing, before delivery \u2014 defined per product or per operation.<\/p>\n Quality checks.<\/strong> The inspection itself. Pass or fail, a measurement within a range, or an instruction to follow.<\/p>\n Quality alerts.<\/strong> Raised when something fails. A record of the problem, who is handling it, and what stage it is at.<\/p>\n Teams and stages.<\/strong> Alerts routed to the right people, moving through stages you define.<\/p>\n Root cause and action fields.<\/strong> So an alert records why, not just what.<\/p>\n FIGURE 1: THE FOUR PIECES<\/p>\n Control points<\/p>\n Quality checks<\/p>\n Quality alerts<\/p>\n Teams and stages<\/p>\n Three natural places<\/strong>, and most businesses need at least two.<\/p>\n On receipt.<\/strong> Inspecting incoming material. Catches supplier problems before they enter production<\/strong>, which is by far the cheapest place to catch them.<\/p>\n During manufacturing.<\/strong> At a specific operation. Checks a characteristic while the work is in progress, rather than at the end.<\/p>\n Before delivery.<\/strong> Final inspection. The last chance before the customer.<\/p>\n The principle from risk-based thinking applies:<\/strong> put the checks where failure is likely and costly. Inspecting everything equally is expensive and still misses things.<\/strong><\/p>\n Pass \/ fail.<\/strong> Simple, and the right choice for a visual or a yes-or-no condition.<\/p>\n Measure.<\/strong> A value with a tolerance. Use this wherever the characteristic is numeric<\/strong> \u2014 it produces data you can analyse, and pass\/fail throws that away.<\/p>\n Instructions.<\/strong> A procedure the operator follows and confirms.<\/p>\n A worthwhile habit:<\/strong> if a characteristic can be measured, record the measurement rather than a pass. A run of measurements drifting towards the tolerance limit tells you something a run of passes never will.<\/strong><\/p>\n A failed check raises an alert.<\/strong> What happens next is what makes this useful or decorative.<\/p>\n A useful alert records:<\/strong><\/p>\n What failed<\/strong>, linked to the product, lot and operation.<\/p>\n Root cause.<\/strong> Not “operator error” \u2014 why the process allowed it.<\/p>\n Corrective action.<\/strong> What changed.<\/p>\n Verification.<\/strong> Did it work.<\/p>\n Odoo has fields for these.<\/strong> Whether they get filled in is a discipline question, not a software one.<\/p>\n Without root cause and verification, an alert log is a record of problems that recurred<\/strong> \u2014 which is exactly the pattern most quality systems fall into.<\/p>\n FIGURE 2: ALERTS THAT WORK AND ALERTS THAT DO NOT<\/p>\n Working<\/p>\n Just a log<\/p>\n The advantage that only exists in an integrated system.<\/strong><\/p>\n Lots and serial numbers, tracked through receipt, production and delivery.<\/strong><\/p>\n What that gives you:<\/strong><\/p>\n Backwards.<\/strong> A customer reports a defect. Which lot? Which materials went into it? Which other customers received material from the same batch?<\/p>\n Forwards.<\/strong> A supplier reports a problem with a batch they shipped you. Where did it go? What did we make with it? What is still in stock?<\/p>\n That second one is the containment question<\/strong>, and answering it in minutes rather than days is the difference between a contained problem and a recall.<\/p>\n It requires lot or serial tracking to be switched on and used consistently<\/strong> \u2014 which is a decision to make early, because retrofitting it is difficult.<\/p>\n Because purchasing and quality share a database, supplier performance becomes visible without assembling it.<\/strong><\/p>\n Which suppliers generate the most quality alerts.<\/strong> By volume, and as a proportion of what they ship.<\/p>\n Which ones deliver late.<\/strong><\/p>\n Which ones cause the most rework.<\/strong><\/p>\n Why this matters:<\/strong> supplier decisions usually get made on price, because price is the number everyone has. Quality cost is real and invisible<\/strong> unless something is tracking it.<\/p>\n A supplier who is five percent cheaper and generates three times the rework is not cheaper.<\/strong><\/p>\n Odoo’s quality alerts handle the record.<\/strong> The CAPA discipline is yours.<\/p>\n Four habits that make the difference:<\/strong><\/p>\n Record small things too.<\/strong> Three minor issues with the same underlying cause is a bigger finding than any of them alone \u2014 and you cannot see that pattern if you only log the significant ones.<\/p>\n Root-cause the recurring ones.<\/strong> Start with whatever happens most.<\/p>\n Verify.<\/strong> Come back and check the problem stopped.<\/p>\n Review the log periodically.<\/strong> Not just before an audit.<\/p>\n FIGURE 3: FROM CHECK TO CLOSURE<\/p>\n Check fails<\/p>\n Alert raised<\/p>\n Root cause found<\/p>\n Action verified<\/p>\n 1. Decide where inspection actually matters.<\/strong> Not everywhere. Where failure is likely or costly.<\/p>\n 2. Turn on lot or serial tracking<\/strong> for anything where traceability matters. Do this early<\/strong> \u2014 it is difficult to add later.<\/p>\n 3. Start with receipt inspection<\/strong> on your problem suppliers. Cheapest place to catch problems, and it produces supplier data quickly.<\/p>\n 4. Use measurements rather than pass\/fail<\/strong> wherever the characteristic is numeric.<\/p>\n 5. Define your alert stages and teams<\/strong>, so failures reach somebody.<\/p>\n 6. Make root cause a required habit<\/strong>, not an optional field.<\/p>\n 7. Review the alert log monthly.<\/strong> The patterns are the point.<\/p>\n A weak process.<\/strong> Recording defects faster does not reduce them.<\/p>\n Containment culture.<\/strong> If alerts are closed by fixing the instance, moving them into Odoo changes nothing.<\/p>\n Unclear standards.<\/strong> If nobody agrees what acceptable looks like, no system settles it.<\/p>\n The software provides the structure. The discipline is separate<\/strong>, and it is the part that determines whether any of it works.<\/p>\n Quality data belongs in the same system as production data<\/strong>, because the connections \u2014 lot, supplier, operation, customer \u2014 are what make it useful.<\/p>\n Put control points where failure is likely and costly<\/strong>, not everywhere.<\/p>\n Record measurements rather than pass\/fail<\/strong> wherever you can. A drift towards the limit is a warning; a pass is not.<\/p>\n And turn on lot tracking early.<\/strong> The ability to answer “where did that batch go” in minutes is worth more than everything else on this page.<\/p>\n Quality records in spreadsheets, separate from production?<\/p>\n Get in touch. We set up quality control in Odoo so defects connect to lots, suppliers and work orders \u2014 which is where the useful patterns are.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" Why it belongs in your ERP Quality data separated from production data is quality data nobody uses. If inspections live in a spreadsheet and production lives in your ERP, connecting a defect to a batch, a supplier, an operator or a work order is a manual exercise. So it does not happen, and the patterns […]<\/p>\n","protected":false},"author":3,"featured_media":9477,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25,29],"tags":[],"class_list":["post-9476","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo","category-quality_management"],"yoast_head":"\nWhat Odoo provides<\/h2>\n
\n
\n
\n
\n
Where to put control points<\/h2>\n
Choosing the check type<\/h2>\n
Alerts, and what they need<\/h2>\n
\n
\n
Traceability<\/h2>\n
Supplier quality<\/h2>\n
Connecting it to nonconformities<\/h2>\n
\n
\n
\n
\n
Setting it up sensibly<\/h2>\n
What it does not solve<\/h2>\n
The short version<\/h2>\n