Skip to the lesson
CivOps AI Academy · M08Quality Management: Events, CAPA, Audits, Change, Risk and Supplier Quality on One Record Model
0%

Chapter 1 · Events, material review and holds

One record for every quality event

A quality system is only as good as its ability to connect things: the nonconforming lot, the customer complaint, the audit finding and the supplier that caused them. This chapter says what Quality management builds, the standards it is measured against, and the three ideas at its centre: one record model for every event, a signed material review decision, and holds that actually stop product.

25 min7 event types6 dispositions1 enforced hold rule

By the end of this chapter you can

  • Say what the module does, what it leaves to other modules, and what its capability tiers mean.
  • Explain why every kind of quality event lives in one supertype table with small detail tables.
  • Name the six material review dispositions and say what each does to the lot and its hold.
  • Explain the difference between an advisory flag and a hold that is enforced in the database.

What Quality management does

The module manages quality events end to end: nonconformances and material review, deviations, complaints, CAPA (corrective and preventive action) with root cause and effectiveness checks, audits, change control, risk in the form of FMEA (failure mode and effects analysis), and supplier quality. All of it sits on one record model, with holds that stop product. It replaces the electronic quality management system (eQMS) a business usually pays for: MasterControl, ETQ Reliance, Veeva Vault QMS, TrackWise, Intelex, Qualio, Greenlight Guru, QT9 or Ideagen Quality [5][6].

Its tables share the prefix qms_. Like every module on the platform it has no people list, site list, item list or file store of its own: it points at the shared spine (core_person, core_site, core_item, core_lot, core_equipment, core_party, core_attachment, core_e_signature and others), so a quality event about a lot is a row that points at the same lot every other module uses.

The edge of Quality managementInside: quality events, NCR and material review, quality holds, CAPA, audits, change control, FMEA and supplier quality. Outside, each with its owner: document lifecycle in M06, training records in M07, SPC charts and capability in M09, and engineering change of product definitions in M14, which links here. INSIDE QUALITY MANAGEMENT (M08)Quality eventsNCR and material reviewQuality holdsCAPAAuditsChange controlFMEASupplier qualityOUTSIDE, WITH ITS OWNERDocument lifecycleowned by M06Training recordsowned by M07SPC charts and capabilityowned by M09Product-definition changeM14 ECO; links to M08
The edge of Quality management. Inside: events, NCR and material review, holds, CAPA, audits, change control, FMEA and supplier quality. Outside, each with its owner: document lifecycle (M06), training records (M07), SPC charts and capability (M09) and the engineering change of product definitions (M14 ECO), which links here.
  • In: the quality event supertype with NCR, deviation, complaint, audit finding and supplier corrective action request (SCAR) subtypes; material review board (MRB) disposition and quality holds on lots, orders or equipment; CAPA with 8D, 5-Why, fishbone and A3; internal, supplier and regulatory audits; change control with impact assessment; FMEA with the AIAG-VDA action priority; approved supplier list, scorecards and PPAP status.
  • Out: the document lifecycle (M06), training records (M07), SPC charts and capability (M09), and the engineering change of product definitions (M14 ECO, which links to a change request here).

Eleven capabilities in three tiers

Each capability carries a tier. MVP must exist for a small or mid-size business to cancel the incumbent subscription with confidence. STD is parity with mainstream tools, what a buyer expects in a demo. BIC marks best-in-class differences, such as those made possible by AI.

CapabilityWhat it doesTier
Quality eventsUnified intake from forms, MES, SPC, LIMS, customers and suppliers; severity; triage; ownership; due dates; full status historyMVP
NCR and MRBQuantity affected, defect codes, containment, MRB disposition with approvals, cost of poor quality capturedMVP
Quality holdsHold lots, orders, equipment or suppliers; holds enforced in M04, M12 and M13; release with a signatureMVP
CAPAProblem statement, containment, root cause tools, actions by type, effectiveness criteria and verification, overdue escalationMVP
ComplaintsCustomer complaint intake, RMA link, investigation, reportability assessment, response lettersSTD
DeviationsPlanned and unplanned deviations with impact assessment and batch linkageSTD
AuditsAudit programme, schedule, checklists by standard clause, findings that become events and CAPA, audit reportsSTD
Change controlChange request, classification, impact assessment across documents, training, validation and regulatory, approvals, tasks, effectiveness reviewSTD
Risk and FMEADesign and process FMEA, severity, occurrence and detection, action priority, recommended actionsSTD
Supplier qualityApproved supplier list, qualification, SCARs, scorecards (ppm, on-time delivery, responsiveness), PPAP trackingSTD
Analytics and AICost of poor quality, trend detection, recurring-issue clustering, AI triage and CAPA draft suggestions with human approvalBIC

The standards, and what each is used for

StandardUsed in this module for
ISO 9001:2015, clauses 8.7, 10.2, 9.2 and 9.3 [1]Nonconforming outputs, corrective action, internal audit and management review
IATF 16949:2016 with the AIAG Core ToolsAPQP, PPAP, FMEA, MSA and SPC requirements for automotive
AIAG-VDA FMEA Handbook (2019)The seven-step FMEA and the action priority (H, M, L) that replaces ranking by RPN alone
ISO 13485:2016, FDA QMSR (21 CFR Part 820, effective 2 February 2026) and ISO 14971:2019 [2][3]Medical device quality systems, complaint handling and risk management
ICH Q9(R1) and ICH Q10Pharmaceutical quality risk management and the pharmaceutical quality system
21 CFR Part 11 and EU Annex 11 [4]Electronic records and electronic signatures
AS9100DAerospace quality systems: nonconformance and first-article linkage

One supertype for every event

Every quality event, whatever it is called on the floor, is a row in qms_quality_event: an NCR (nonconformance report), a deviation, a complaint, an audit finding, a SCAR, an observation or an out-of-specification (OOS) result. The row carries what every event needs: an event number, a type, a title, a severity, a status, an owner, a due date, and pointers to the site, item, lot, equipment, supplier and customer it concerns. Three kinds need extra fields, which live in small detail tables that point back at the event.

One supertype, three detail tablesThe qms_quality_event table holds every event, with event_type one of ncr, deviation, complaint, audit_finding, scar, observation or oos. Three detail tables, for NCR, complaint and deviation, each point at exactly one event. event_type is one of seven valuesncrdeviationcomplaintaudit_findingscarobservationoosqms_quality_eventevent_no, severity, status, owner,site, item, lot, equipment, supplierqms_ncr_detailquantity, defect code, MRB decisionqms_complaint_detailchannel, RMA, reportable, rationaleqms_deviation_detailplanned, impact, batches affectedEach detail row has a required, unique quality_event_id: at most one per event.audit_finding, scar, observation and oos use the event row alone.
One supertype, three detail tables. The seven event types share qms_quality_event. NCR, complaint and deviation each add one detail row, with a required, unique quality_event_id, so an event has at most one detail row of each kind and there is no table of NCRs that stands apart from the events.
event_typeWhat it is
ncrA nonconformance: product or process output that does not meet its requirement
deviationA planned or unplanned departure from an approved procedure or specification
complaintA customer complaint, with channel, RMA and a reportability decision
audit_findingThe result of an audit checklist item that was not conform
scarA supplier corrective action request
observationSomething noticed that is not (yet) a nonconformance
oosAn out-of-specification result, for example from a laboratory system

Severity is one of critical, major, minor or observation. Events arrive from forms that failed an item (frm.response.failed), SPC violations (spc.violation.detected), laboratory out-of-spec results (lims.result.oos), machine parameters out of spec (mes.parameter.out_of_spec), calibrations out of tolerance (cmms.calibration.out_of_tolerance) and customer service tickets (svc.ticket.complaint). Each carries source_type and source_id, and a retry from another module must create no second event.

Event statusesSix statuses in order: new, triage, investigation, disposition, capa_pending and closed. Cancelled is a way out, set by the approver; which statuses may move to it is your own rule in docs/qms-rules.md. A trigger refuses any other move. The allowed path of a quality eventnewreportedtriageset severityinvestigationfind the causedispositiondecide and signcapa_pendingCAPA openedclosedsignedcancelleda way out, set by the approverA trigger refuses any move not in the allowed list: new cannot jump to closed.
The path of an event. new, triage, investigation, disposition, capa_pending, closed, and cancelled as a way out, set by the approver. A database trigger refuses any other move, so an event cannot jump from new to closed.

Knowledge check

Why do NCRs, complaints and audit findings share one table, qms_quality_event?

Material review: a signed decision

An NCR adds a row in qms_ncr_detail: the quantity affected and its unit, the defect code (from the defect taxonomy in qms_defect_code), the containment taken, the cost of poor quality, and the disposition. The material review board decides the disposition, which is one of six values; until it is decided it is pending.

The six material review dispositionsThe approver signs one of six dispositions. Scrap and return to vendor reject the lot and convert the hold to scrap. Use as is, rework, repair and regrade keep the hold until the work is done, then it is released with a second signature. Dispositionsigned by the approverLOT REJECTED · HOLD CONVERTED TO SCRAPscraplot rejectedreturn_to_vendorlot rejected, goes backHOLD STAYS UNTIL THE WORK IS DONE, THEN RELEASEDuse_as_isaccepted as it isreworkredone to specificationrepairmade usableregradeused as a different gradeA disposition other than pending needs mrb_signature_id and mrb_decided_at.
Six dispositions. Scrap and return_to_vendor reject the lot and convert the hold to scrap. Use as is, rework, repair and regrade keep the hold until the work is done; then it is released with a second signature.

The decision needs an electronic signature: a core_e_signature row with its meaning, the signer, the time and a hash (a fingerprint) of what was signed. A disposition other than pending without a signature and a decision time is refused by the database. The signer is not the person who reported or owns the event, so nobody approves their own work. 21 CFR Part 11 sets out what such signatures must carry [4].

Cost of poor quality (COPQ) is captured on the same row: the module adds up scrap, rework, returns and concessions cost per period. It is the number that tells a manager what the problems cost, and it is only as good as the NCRs entered.

Holds that stop product

A hold in qms_hold blocks a lot, production order, equipment, supplier, item or location (the target_type), for a reason, placed by a person at a time, optionally linked to the event that caused it. Its status is active, released or converted_to_scrap. Releasing needs a signature.

Advisory flag or enforced blockLeft, the pitfall: a hold flag on a lot only warns, and the lot moves anyway. Right, the rule: every route that moves material calls qms_assert_not_held first, which reads active holds and either allows the move or refuses it with the hold number. ADVISORY FLAG · THE PITFALLHold flag on the lota column someone must checkScreen shows a warninga person may click past itLot moves anywayconsumed or shippedENFORCED BLOCK · THE RULEConsume or ship routeM04, M12 or M13 ask firstqms_assert_not_heldreads the active qms_hold rowsAllowedno active holdRefusedhold_no in the message
Advisory flag or enforced block. Left, the pitfall: a flag that only warns lets the lot move anyway. Right, the rule: every route that moves material calls qms_assert_not_held first, which reads the active holds and either allows the move or refuses it with the hold number.
Exercise · Sort ten real quality records20 minutes

You need: Read access to your eQMS or quality log, a text file, and the quality manager for five minutes

Use the records your business has today. Do not copy customer, patient or employee names: record only the type, severity and status.

Outcome: A ten-line table of event type, severity, status and hold, and a count of how many records are split across lists today.

Knowledge check

What makes a hold different from an advisory flag?

References

  1. ISO 9001:2015, Quality management systems: requirements. https://www.iso.org/standard/62085.html
  2. ISO 13485:2016, Medical devices: quality management systems. https://www.iso.org/standard/59752.html
  3. 21 CFR Part 820, Quality System Regulation and QMSR (eCFR). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
  4. 21 CFR Part 11, Electronic records and electronic signatures (eCFR). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
  5. Prezent: eQMS platforms for life sciences. https://www.prezent.ai/blog/qms-for-life-sciences
  6. SoftwareConnect: Veeva Vault QMS. https://softwareconnect.com/go/veeva-vault-qms-29564

Chapter 2 · Finding the cause and proving the fix

Corrective action, audits and change control

Containing a problem is not the same as solving it. CAPA finds the cause, changes something so it does not return, and then checks that the change worked. Audits find problems before customers do, and change control makes sure a fix does not create a new problem somewhere else.

25 min7 CAPA statuses3 gates8 change types

By the end of this chapter you can

  • Walk a CAPA through its statuses and say what each of the three gates refuses.
  • Choose a root cause tool (5-Why, fishbone, is/is-not, fault tree, Pareto, timeline) and say where its content is stored.
  • Explain how an audit result becomes a finding and then a CAPA, and why auditors must be impartial.
  • Describe the change control path and what must be true before a change is implemented and closed.

CAPA: cause, action, proof

A CAPA record (qms_capa) starts from a problem, often an event, and keeps one story from the problem statement to the signed closure. It holds the origin event, the problem statement, the method (eight_d, five_why, a3, dmaic or other), the containment, the root cause and its category, the owner, the due date, the effectiveness criteria and the effectiveness result. ISO 9001:2015 clause 10.2 asks for exactly this chain on a nonconformity: react to it, find out whether similar ones exist or could occur, review and determine the cause, implement the action needed, review its effectiveness and update risks if necessary [1].

CAPA statuses and the three gatesSix steps in order: open, investigation, action_plan, implementation, effectiveness_check and closed; a seventh status, cancelled, ends a CAPA that is withdrawn. Gate 1 leaves investigation only with a root cause and category. Gate 2 enters the effectiveness check only when no action is open or unverified. Gate 3 closes only with an effectiveness result that is not pending, and a signature. openinvestigationaction_planimplementationeffectiveness_checkclosedGate 1root_cause androot_cause_categorymust be filled inGate 2no action openor unverifiedGate 3result is not pendingclosure is signedCourse rule, not a standard: a not_effective result needs a follow-up CAPA number to close.
A CAPA and its three gates. A database trigger refuses to leave investigation without a root cause and category, refuses an effectiveness check while any action is open or unverified, and refuses closure without an effectiveness result that is not pending, signed.

Root cause tools

Each tool is a row in qms_rca_artifact, with its content kept as JSON because the shape of a fishbone differs from a timeline: five_why, fishbone, is_is_not, fault_tree, pareto or timeline. The quality engineer or the CAPA owner builds them. The conclusion goes into the CAPA itself, as a root cause and a root cause category: man, machine, method, material, measurement, environment, design, supplier or unknown [2].

A 5-Why chainA problem, an incoming lot with a gap in the seal, followed by five answers to why: the gasket was cut too short, the cutter used an old setting, the set-up sheet was not updated, the change had no update task, and a change may close with no tasks. The last answer is a cause you can act on. ProblemGap in seal onan incoming lotWhy 1Gasket cuttoo shortWhy 2Cutter usedan old settingWhy 3Set-up sheetwas not updatedWhy 4The change hadno update taskWhy 5Change may closewith no tasksA cause you can act onRequire a task before a change can closeStop when the answer is a cause you can change. Five is a guide, not a rule.
A 5-Why chain. Keep asking why until the answer is a cause you can act on. This example is invented to show the shape: the last answer is about the process, not a person.
A fishbone diagramA fishbone with the effect, a gap in the seal, at the head. Six branches, grouped as man, machine, method, material, measurement and environment, each with one possible cause written beside it. Effectgap in sealmanSetter not toldmachineCutter not lockedmethodSheet not revisedmaterialNew roll, new lotmeasurementLength not checkedenvironmentNight set-up rush
A fishbone (cause and effect) diagram. The effect is at the head; causes are grouped under headings so a team can look in every direction, not only the first one that comes to mind [3][4].

Actions, and the proof that they worked

The work of a CAPA is a list of rows in qms_capa_action, each with a type, an owner and a due date. The six types are different jobs:

action_typeWhat it is for
containmentStop the problem spreading now: hold the lot, sort the stock
correctionFix the nonconformity that already exists
correctiveRemove the cause so it does not return
preventiveStop the same kind of problem happening somewhere else
trainingTeach people the change; writes qms.capa_action.training_required for the training module (M07)
document_changeChange a controlled document, linked to a change request

An owner completes an action and attaches the evidence; a different person, never the owner, verifies it. Before the CAPA reaches implementation it has effectiveness criteria and an effectiveness due date: what will be true, measured how, by when, if the fix worked. After that date the quality engineer records effective or not_effective against the criteria. This is the Check in Plan-Do-Check-Act [5], and it is what separates a CAPA from a to-do list.

Knowledge check

Which of these does the database refuse?

Audits: finding problems first

An audit (qms_audit) is an internal, supplier, customer, regulatory, certification, process, product or layered audit, with a standard reference, a scope, a lead auditor, an auditee and planned dates. Its checklist (qms_audit_item) has one row per question, with the clause reference, a result and the evidence. The results are conform, minor_nc, major_nc, ofi (opportunity for improvement), not_applicable and not_audited.

From audit to finding to CAPAAn audit has checklist items. Each item has a result: conform, ofi, minor_nc, major_nc, not_applicable or not_audited. A minor or major nonconformance result creates a finding event, which can start a CAPA. Auditqms_auditChecklist itemqms_audit_itemFinding eventevent_type audit_findingCAPAorigin_event_idresult on each checklist itemconformofiminor_ncmajor_ncnot_applicablenot_auditedA minor_nc or major_nc result creates an audit_finding event.An audit cannot close while any item has no result.
From audit to finding to CAPA. A minor or major nonconformance result creates an audit_finding event and sets finding_event_id on the item. The event then follows the same path as any other and can start a CAPA.

ISO 9001:2015 clause 9.2 asks that audits are run so that the auditors are objective and impartial [1]. In the module that becomes a rule: an auditor's home site (core_person.home_site_id) must differ from the audit's site_id, and an audit with no site_id, such as a supplier audit, is open to any assigned auditor. An audit cannot close while any checklist item has no result.

Change control: changing safely

A change request (qms_change_control) records what is changing and why: the type (process, equipment, material, supplier, document, software, facility or product), a classification (minor, major or critical), a risk level and an impact assessment kept as JSON, across documents, training, validation and regulatory filings. The work to carry it out is a list of rows in qms_change_task: document, training, validation, regulatory, equipment, supplier, it or other.

Change control statusesA change request moves from draft to assessment to approval, and can be rejected there. After a signed approval it moves to implementation, effectiveness review and closed. It cannot reach implementation without a signature, and cannot close until every task is complete. draftowner, type, reasonassessmentimpact and riskapprovalsigned approvalrejectedstops hereimplementationqms_change_task rowseffectiveness_reviewdid the change workclosedall tasks completeNo implementation without approved_signature_id.No close until every qms_change_task is complete.
The change path. Draft, assessment, approval (or rejection), implementation, effectiveness review and closed. Approval needs an e-signature; closing needs every task complete.

The signature is an approver's, with the meaning approved [6]; approving writes qms.change_control.approved for other modules to act on. A change request can also come from a CAPA, when an action of type document_change links to it. The engineering change of a product definition itself belongs to M14; the request here links to it.

Exercise · Walk a real CAPA through the three gates25 minutes

You need: Read access to one closed CAPA in your eQMS, a text file, and the quality manager

Choose a CAPA that is closed, preferably about a repeat problem. Look only at its fields; do not copy any names.

Outcome: A one-page gate review of a real CAPA that names the weakest gate, ready to turn into a test in Session 4.

Knowledge check

An audit checklist item is marked major_nc. What happens next in the module?

References

  1. ISO 9001:2015, Quality management systems: requirements. https://www.iso.org/standard/62085.html
  2. ASQ: What is root cause analysis?. https://asq.org/quality-resources/root-cause-analysis
  3. ASQ: Fishbone (cause and effect) diagram. https://asq.org/quality-resources/fishbone
  4. ASQ: Five whys and five whys analysis. https://asq.org/quality-resources/five-whys
  5. ASQ: The Plan-Do-Check-Act (PDCA) cycle. https://asq.org/quality-resources/pdca-cycle
  6. 21 CFR Part 11, Electronic records and electronic signatures (eCFR). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11

Chapter 3 · Ranking risk and managing suppliers

Risk, FMEA and supplier quality

FMEA asks what could go wrong before it does. Supplier quality asks who sends you the things that could go wrong. This chapter covers how a failure mode is rated, why the product of three numbers is no longer enough, and how the approved supplier list, the scorecard and PPAP keep suppliers under control.

20 minRatings 1 to 101,000 combinations5 supplier statuses

By the end of this chapter you can

  • Describe an FMEA line and the three ratings that drive its action priority.
  • Explain why an RPN alone hides risk, and what the AIAG-VDA action priority does instead.
  • Describe the approved supplier list statuses, the scorecard and what PPAP tracks.

FMEA: finding failures on paper

Failure mode and effects analysis lists, step by step, how a design or a process could fail, what that would cause, and what is done about it [2]. In the module an FMEA has a header (qms_fmea: number, type design, process or machinery, the item or process it covers, a revision, the team, and a status of draft, active or superseded) and many lines (qms_fmea_line). The AIAG-VDA FMEA Handbook (2019) describes a seven-step method: planning and preparation, structure analysis, function analysis, failure analysis, risk analysis, optimization, and results documentation [6].

Each line names a step or function, a failure mode, its effect, the cause, the prevention controls and the detection controls. Three ratings, each a whole number from 1 to 10, score it: severity of the effect, occurrence of the cause, and detection of the failure before it reaches the customer. The line may mark a special characteristic: none, cc (critical) or sc (significant), which the control plan (M09) follows. A recommended action gets an owner and a due date, and after it is done the line records the revised severity, occurrence and detection.

Action priority, not RPN alone

For many years lines were ranked by the risk priority number (RPN), the product severity × occurrence × detection. Two very different lines can have the same product.

Two lines with the same RPNTwo FMEA lines drawn to scale on a 1 to 10 rating scale. Line A has severity 10, occurrence 2 and detection 5. Line B has severity 2, occurrence 10 and detection 5. Both multiply to an RPN of 100, but the risk is very different. Line A: 10 × 2 × 5 = 10010Severity2Occurrence5DetectionLine B: 2 × 10 × 5 = 1002Severity10Occurrence5DetectionSame RPN, 100. Severity 10 is the worst effect on the scale; severity 2 is minor.Action priority reads the combination of ratings, not their product.
Two lines, one RPN. Drawn to scale on the 1 to 10 scale. Line A has the worst possible severity with rare occurrence; line B has a minor effect that happens all the time. Both multiply to 100.

The AIAG-VDA handbook replaces ranking by RPN alone with an action priority of high, medium or low, read from a table of the three ratings [6]. In the module a function, qms_action_priority(s, o, d), holds that table, and a trigger on qms_fmea_line always sets action_priority from it, so a typed value is never trusted.

From ratings to action prioritySeverity, occurrence and detection, each from 1 to 10, go into the qms_action_priority function. A trigger sets the action priority as high, medium or low, and the next action is an owner, a date and revised ratings. Severity 1–10Occurrence 1–10Detection 1–10qms_action_prioritya trigger sets action_priority;a typed value is never trustedHighMediumLowNext actionowner, date,revised ratingsThe table is in the AIAG-VDA handbook: 1,000 combinations, each priority H, M or L.Lines of an active FMEA are frozen; a change is a new revision.
From ratings to action priority. The three ratings go into the function; the result is high, medium or low; a line with a recommended action gets an owner and a due date. Lines of an active FMEA are frozen: a change is a new revision.

Risk methods differ by industry. ISO 14971:2019 covers risk management for medical devices [3], and ICH Q9(R1) quality risk management applies to pharmaceuticals [4]. The module's tables keep the names qms_fmea and qms_fmea_line, because the CivOps automated process FMEA and control plan generation build on them.

Exercise · Rate three failure modes20 minutes

You need: One process step from your own plant, a text file, and the person who runs that step

Pick one step that has caused a problem in the last year. You will not need the handbook's table for this exercise; the aim is the ratings and the RPN comparison.

Outcome: Three rated FMEA lines with ratings agreed by the person who runs the step, and a note on whether RPN alone would have ranked them correctly.

Knowledge check

Why is ranking FMEA lines by RPN alone a pitfall?

Supplier quality

Suppliers are managed on the approved supplier list (qms_approved_supplier): a supplier, the item class it is approved for, and a status of pending, approved, conditional, probation or disqualified, with the approval date, the date requalification is due, its certifications and a risk rating of low, medium or high. A supplier is always a row in core_party, the shared list of suppliers and customers.

Approved supplier list and scorecardThe approved supplier list status moves through pending, approved, conditional, probation and disqualified. Each period a scorecard holds ppm, on-time percentage, scar count, responsiveness and a grade of a to d. The scar count is counted by the route. pendingqualification openapprovedrequalify_due setconditionalapproved with limitsprobationunder watchdisqualifiedremoved from the listqms_supplier_scorecard · ONE PER PERIODppmtyped from receivingon_time_pcttyped from receivingscar_countcounted by the routeresponsivenesstyped with its sourcegradea, b, c or dscar_count comes from the supplier's scar events in the period, never typed.
Approved supplier list and scorecard. The status is set by people; the scorecard is one row per supplier per period. The scar_count is counted from the supplier's scar events in that period, never typed.

A scorecard (qms_supplier_scorecard) holds the period, ppm (defective parts per million), on-time percentage, the SCAR count, responsiveness, a score and a grade of a, b, c or d. The numbers typed in, ppm and on-time percentage, come from the business's receiving records, with the source noted. A SCAR is a quality event of type scar with the supplier_party_id set, so it appears in every event count as well as on the scorecard.

For automotive suppliers, IATF 16949 with the AIAG Core Tools asks for APQP, PPAP, FMEA, MSA and SPC [1][5]. The production part approval process (PPAP) is tracked in qms_ppap_submission: the supplier, the part, the PPAP level (a whole number), the elements as JSON (the module does not fix their list), and a status of requested, submitted, approved, interim or rejected, with the dates submitted and decided.

Knowledge check

How is scar_count on a supplier scorecard set?

References

  1. AIAG: Quality Core Tools (APQP, CP, PPAP, FMEA, MSA, SPC). https://www.aiag.org/expertise-areas/quality/quality-core-tools
  2. ASQ: Failure mode and effects analysis (FMEA). https://asq.org/quality-resources/fmea
  3. ISO 14971:2019, Medical devices: application of risk management. https://www.iso.org/standard/72704.html
  4. ICH quality guidelines, including Q9(R1) and Q10. https://www.ich.org/page/quality-guidelines
  5. IATF Global Oversight: IATF 16949. https://www.iatfglobaloversight.org/
  6. AIAG: AIAG & VDA FMEA Handbook (product FMEAAV-1). https://www.aiag.org/training-and-resources/manuals/details/FMEAAV-1

Chapter 4 · Building it and replacing the old tool

Tables, roles, KPIs and cutover

Everything so far becomes eighteen tables, five roles, a short list of screens and six numbers. This chapter is the reference you build from in Session 2: every table and column, who does what, how the numbers are counted, the three checks that define done, and how the old history comes in.

30 min18 tables5 roles6 KPIs

By the end of this chapter you can

  • Name the eighteen qms_ tables and read their columns, types and required flags.
  • Say what the five roles and four machine accounts do, and why the rights must cover the whole module.
  • Define each KPI and hand-count the seeded data to check a dashboard.
  • State the three checks that define done and the rule for importing history from the old tool.

Eighteen tables on the shared spine

Every table starts with the standard columns every platform table has: id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. Foreign keys point only at core_ tables and at each other. The table below lists every column the module adds. It is what your agent builds from in Session 2.

Types are as in the specification: text, int, num (a decimal number), bool, ts (a timestamp with time zone), date, uuid, json (jsonb in Postgres), qty (a quantity) and money. An arrow means a foreign key to that table. req means required (not null), and a list after a colon is the set of allowed values, enforced by a check constraint.

TableHoldsColumns: type, req = required
qms_quality_eventSupertype record for all quality eventsevent_no text req, unique per tenant; event_type text req: ncr, deviation, complaint, audit_finding, scar, observation, oos; title text req; description text; severity text req: critical, major, minor, observation; status text req: new, triage, investigation, disposition, capa_pending, closed, cancelled; site_id → core_site; occurred_at ts; reported_by → core_person; owner_id → core_person; item_id → core_item; lot_id → core_lot; equipment_id → core_equipment; supplier_party_id → core_party; customer_party_id → core_party; source_type text; source_id uuid; due_at ts; closed_at ts; closure_signature_id → core_e_signature
qms_defect_codeDefect taxonomycode text req, unique per tenant; name text req; category text; parent_id → qms_defect_code
qms_ncr_detailNonconformance detail and MRB dispositionquality_event_id → qms_quality_event req, unique; qty_affected qty; uom_id → core_uom; defect_code_id → qms_defect_code; containment text; disposition text req: pending, use_as_is, rework, repair, scrap, return_to_vendor, regrade; mrb_decided_at ts; mrb_signature_id → core_e_signature; copq_cost money
qms_complaint_detailComplaint-specific dataquality_event_id → qms_quality_event req, unique; channel text req: email, phone, portal, sales, field_service, regulator; contact_ref uuid; rma_no text; product_returned bool; reportable bool; reportability_rationale text; response_due_at ts; responded_at ts
qms_deviation_detailDeviation-specific dataquality_event_id → qms_quality_event req, unique; planned bool req; impact_assessment text; batches_affected json; product_impact text: none, potential, confirmed
qms_holdQuality hold on a lot, order, equipment or supplierhold_no text req, unique per tenant; target_type text req: lot, production_order, equipment, supplier, item, location; target_id uuid req; reason text req; quality_event_id → qms_quality_event; placed_by → core_person req; placed_at ts req; released_by → core_person; released_at ts; release_signature_id → core_e_signature; status text req: active, released, converted_to_scrap
qms_capaCorrective and preventive action recordcapa_no text req, unique per tenant; origin_event_id → qms_quality_event; title text req; problem_statement text req; method text req: eight_d, five_why, a3, dmaic, other; containment text; root_cause text; root_cause_category text: man, machine, method, material, measurement, environment, design, supplier, unknown; status text req: open, investigation, action_plan, implementation, effectiveness_check, closed, cancelled; owner_id → core_person req; due_at ts; effectiveness_criteria text; effectiveness_due_at ts; effectiveness_result text: pending, effective, not_effective; closed_at ts; closure_signature_id → core_e_signature
qms_capa_actionAction within a CAPAcapa_id → qms_capa req; action_type text req: containment, correction, corrective, preventive, training, document_change; description text req; owner_id → core_person; due_at ts; completed_at ts; verified_by → core_person; verified_at ts; linked_type text; linked_id uuid
qms_rca_artifactRoot-cause tool content (fishbone, 5-Why, is/is-not, fault tree)capa_id → qms_capa req; tool text req: fishbone, five_why, is_is_not, fault_tree, pareto, timeline; content json req; author_id → core_person
qms_auditAudit instanceaudit_no text req, unique per tenant; audit_type text req: internal, supplier, customer, regulatory, certification, process, product, layered; standard_ref text; scope text; lead_auditor_id → core_person; auditee_party_id → core_party; site_id → core_site; planned_start date; planned_end date; status text req: planned, in_progress, reporting, closed, cancelled; report_attachment_id → core_attachment
qms_audit_itemChecklist item and resultaudit_id → qms_audit req; clause_ref text; question text req; result text: conform, minor_nc, major_nc, ofi, not_applicable, not_audited; evidence text; finding_event_id → qms_quality_event
qms_change_controlChange request with impact assessmentcc_no text req, unique per tenant; title text req; change_type text req: process, equipment, material, supplier, document, software, facility, product; classification text req: minor, major, critical; reason text req; impact_assessment json; risk_level text: low, medium, high; status text req: draft, assessment, approval, implementation, effectiveness_review, closed, rejected; owner_id → core_person req; implementation_due date; approved_signature_id → core_e_signature
qms_change_taskImplementation task of a changechange_control_id → qms_change_control req; task_type text req: document, training, validation, regulatory, equipment, supplier, it, other; description text req; owner_id → core_person; due_at ts; completed_at ts
qms_fmeaFMEA header (design or process)fmea_no text req, unique per tenant; fmea_type text req: design, process, machinery; item_id → core_item; process_ref text; revision text req; team json; status text req: draft, active, superseded
qms_fmea_lineFailure mode line with S/O/D and AIAG-VDA action priorityfmea_id → qms_fmea req; step_function text req; failure_mode text req; failure_effect text; severity int req; failure_cause text; occurrence int req; prevention_controls text; detection_controls text; detection int req; action_priority text req: high, medium, low; special_characteristic text: none, cc, sc; recommended_action text; owner_id → core_person; due_at ts; revised_severity int; revised_occurrence int; revised_detection int
qms_approved_supplierApproved supplier list entry by commoditysupplier_party_id → core_party req; item_class_id → core_item_class; status text req: pending, approved, conditional, probation, disqualified; approved_at date; requalify_due date; certifications json; risk_rating text: low, medium, high
qms_supplier_scorecardPeriodic supplier performancesupplier_party_id → core_party req; period_start date req; period_end date req; ppm num; on_time_pct num; scar_count int; responsiveness num; score num; grade text: a, b, c, d
qms_ppap_submissionPPAP status per part and suppliersupplier_party_id → core_party req; item_id → core_item req; level int req; elements json req; status text req: requested, submitted, approved, interim, rejected; submitted_at date; decided_at date

Look at the rules that follow from the list. event_no, hold_no, capa_no, audit_no, cc_no and fmea_no are each unique per tenant, issued from the spine's number sequences and never counted by hand. The ratings on qms_fmea_line and the three revised ratings are whole numbers from 1 to 10. A detail table's quality_event_id is required and unique. Money and quantities are typed columns, and JSON is used only where the shape varies: root cause artifacts, impact assessments, teams, certifications, PPAP elements.

Five roles, four machine accounts

Roles are jobs, not names, and each maps to a row in the spine's core_job_role. The Role and Exposure Matrix of Session 3 gives each one the rights its job needs and nothing else. Nobody gets delete: a correction is a new row or a cancelled status.

Roles and machine accountsFive roles: reporter, quality engineer, CAPA owner, auditor and approver. Four machine accounts: intake, importer, escalation job and number issuer. Nobody signs a record they reported, own or investigated, and nobody gets delete. FIVE ROLESReporterraises events at their own siteQuality engineertriages, holds, runs CAPA, auditsCAPA ownerowns a CAPA and its actionsAuditorruns audits, raises findingsApproversigns decisions and closuresFOUR MACHINE ACCOUNTSIntakeevents from forms and modulesImporterloads the old historyEscalation jobdaily overdue checkNumber issuerthe only writer of numbersNobody signs a record they reported, own or investigated. Nobody gets delete.
Five roles and four machine accounts. The reporter raises events; the quality engineer triages, holds and runs CAPA, audits, FMEA and suppliers; the CAPA owner owns a CAPA and its actions; the auditor runs assigned audits; the approver signs. The intake, importer, escalation and number issuer accounts do the automatic work.
SurfaceScreensWho opens them
Operator, on the phone/quality/report, /quality/my-actionsReporter and quality engineer; CAPA owner
Supervisor/quality/events, /quality/events/[id], /quality/capa, /quality/capa/[id], /quality/audits/[id], /quality/fmea, /quality/changes, /quality/suppliersQuality engineer; CAPA owner for CAPA; auditor for audits
Manager/quality/approvals, /quality/kpisApprover; the quality engineer may open the KPIs

Other modules talk to this one through events. It publishes qms.event.created, qms.hold.placed, qms.hold.released, qms.capa.closed, qms.change_control.approved and qms.capa_action.training_required. It consumes frm.response.failed, spc.violation.detected, lims.result.oos, mes.parameter.out_of_spec, cmms.calibration.out_of_tolerance and svc.ticket.complaint.

Knowledge check

Why must the rights of Sessions 4 to 6 be checked against the matrix in Session 3?

Six numbers

KPIDefinition
CAPA on-time closureCAPAs closed by the due date ÷ CAPAs due
CAPA effectiveness rateEffective ÷ verified CAPAs
Cost of poor qualityScrap + rework + returns + concessions cost per period
Internal and customer ppmDefective parts per million
Repeat event rateEvents matching a previously closed root cause ÷ events
Supplier ppm and on-time deliveryFrom the supplier scorecards

Management review under ISO 9001:2015 clause 9.3 is where numbers like these are looked at [4], and a dashboard is only trusted when it matches a count made by hand. Session 2 seeds a small, invented quarter: eight events, six CAPAs, two holds and one audit. In Session 4 you count it by hand, then build the dashboard on queries over the typed tables, and it must match exactly. If it does not, fix the query, not the count.

A hand count on the seedCost of poor quality is a bar of 600 made-up units: scrap 400, use as is 50, rework 150. CAPA on-time closure is 3 of 5 and CAPA effectiveness rate is 3 of 4. Cost of poor quality on the seed, to scale (1 px = 1 made-up unit)scrap 400use_as_is 50rework 150= 600CAPA on-time closureCAPA effectiveness rate3 ÷ 5 = 60%3 ÷ 4 = 75%green: closed by the due date · rose: closed late, or open past duegreen: effective · rose: not_effectiveA synthetic seed made up for the lab, not a measurement of any business.
The hand count of the seed, to scale. Cost of poor quality is 600 made-up units: scrap 400, use as is 50, rework 150. Of five CAPAs due, three closed by the due date. Of four verified, three were effective.

Three checks that define done

  • A held lot cannot be consumed in MES or shipped in WMS (a cross-module test).
  • A CAPA cannot close without an effectiveness result.
  • The action priority computed from severity, occurrence and detection matches the AIAG-VDA table on test vectors read independently from the handbook.

Three compliance rules sit beside them. Holds are enforced at the database and API level in every module that can move or consume material. Closure and MRB disposition require electronic signatures [1]. A complaint's reportability decision must record its rationale. Analytics and AI suggestions, such as triage or CAPA drafts, are drafts only: a person approves each one.

Cutover: the old history comes in

Export the open and closed events, CAPAs and audits with their attachments from the old eQMS. Open work and active holds come in live; closed records come in as read-only history, with the original signatures kept as attached evidence, not as new signatures.

How the old history comes inThe export from the old eQMS splits in two. Open events, CAPAs and active holds are imported live with status, due dates and owners kept. Closed events, CAPAs and audits are imported archived and never editable, with original signatures kept as attached evidence. Export from the old eQMSevents, CAPAs, audits,attachmentsOpen events, CAPAs and active holdsImported live: status, due dates and owners kept.An active hold keeps its lot on_hold.Closed events, CAPAs and auditsImported archived: archived_at set, never editable.Original signatures kept as attached evidence.Old numbers are kept in ext.legacy_no; imported numbers get the prefix L-.A second run of the import adds no rows.
How the old history comes in. Open events, CAPAs and active holds are live, with status, due dates and owners kept, and an active hold keeps its lot on hold. Closed records are archived and never editable. A second run adds no rows.

The old tool's bill is a figure from its invoice, never an estimate. Read the vendor's cancellation terms from your own account page (notice period, renewal date, export window) and take the full export before the last day. Further reading on what buyers weigh when choosing or replacing a QMS tool is in [2] and [3].

Exercise · Hand-count your own export25 minutes

You need: A report or export from your eQMS (counts only), a spreadsheet, and the quality manager

Use counts, not records: no names, no customers, no free text. This is the count your dashboard will have to match.

Outcome: A confirmed hand count of one quarter, with the report named, which a new dashboard must match exactly.

Knowledge check

Which is the definition of CAPA on-time closure?

References

  1. 21 CFR Part 11, Electronic records and electronic signatures (eCFR). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
  2. Rajesh Kumar: top 10 QMS buyer criteria. https://www.rajeshkumar.xyz/blog/quality-management-systems-qms/
  3. SoftwareConnect: TrackWise eQMS. https://softwareconnect.com/reviews/trackwise/
  4. ISO 9001:2015, Quality management systems: requirements. https://www.iso.org/standard/62085.html

Chapter 5 · 13 questions · 80% passes

Final assessment

Thirteen questions across the element. Score 80% (11 of 13) to pass. Your LMS records your score and each answer; you can review the chapters and try again.

15 min13 questions≈ 15 minutesRetake allowed

Choose one answer for each question, then submit. You will see the right answer and why for every question.

1. What is the main reason every quality event lives in one supertype table with small detail tables?
2. What makes a quality hold different from an advisory flag on a lot?
3. Who chooses the disposition on a nonconformance, and what does it need?
4. An NCR is dispositioned scrap. What happens to the lot and its hold?
5. A CAPA has an effectiveness result of pending. What does the module do when someone tries to close it?
6. Who verifies a CAPA action once its owner has completed it?
7. What does a fishbone diagram do in a root cause investigation?
8. An audit checklist item is marked minor_nc. What does the module do?
9. Why does the AIAG-VDA handbook replace ranking by RPN alone with an action priority?
10. How many combinations of severity, occurrence and detection, each from 1 to 10, must the action priority function cover?
11. How does a closed event from the old eQMS come into the new module?
12. How is scar_count on a supplier scorecard set?
13. How is CAPA on-time closure defined?