ISO Certification Consultants Editorial Team · 8 min read · 9 chapters
The operational problem
A rejected shipment is easy to record and hard to follow through on. An inspector finds a bracket out of tolerance, a note goes into a log, and the parts sit on a shelf. Meanwhile, the supplier still shows as approved, the buyer places the next order, and the corrective action request sits half-written in someone's email. Nothing here is unusual. It happens because three activities—qualifying suppliers, checking what arrives, and resolving what went wrong—are owned by different people who keep their records in different places.
This guide is for Canadian quality and operations teams who want to close those gaps and are considering supplier quality software to help. It treats software as a means to an end. The end is a workflow in which every supplier has a documented basis for approval, every receipt is checked against the order and the specification, every rejection reaches the supplier record, and every corrective action is verified before it closes. Software can support that workflow, but it cannot create it. A team that has not decided who may approve a supplier, who may grant a concession, or who may reinstate a suspended source will carry the same ambiguity into the new system.
The ISO 9001 Auditing Practices Group, a joint effort of ISO/TC 176 and the International Accreditation Forum, offers a helpful frame in its paper on external providers. It says an auditor may find it sufficient to check that an up-to-date list of approved providers exists, that orders were placed with providers meeting the criteria, that outsourced-process providers are monitored, and that the activities needed to meet requirements were carried out. It then cautions that this may not be enough, and that a review of the wider procurement, outsourcing, and supply chain processes may be preferable. In other words, a list is a record, not a control. The guide follows that distinction throughout.
Treat the paper with care. It is auditor guidance, it was written for ISO 9001:2015, and it carries a disclaimer that it has not been endorsed by ISO, ISO/TC 176, or IAF. It shows what a reasonable review looks at, and it does not set requirements for any edition. Confirm which edition and which customer requirements apply to your organization with your certification body before you design controls around any single document.
Key Consideration: Write your own operational problem in one or two sentences before reading further. Every chapter that follows is easier to use when you can compare it with a problem you have named.
Illustrative example: An unnamed Canadian manufacturer of fabricated assemblies receives welded frames from a regional shop. Twice in one quarter, the frames arrive with a hole pattern that does not match the current drawing. Each time, receiving sets the lot aside and sends an email. No one links the two events, the shop stays on the approved list, and a third order ships. The team describes its problem as rejections that never change a supplier's standing, which means the same cause can return without anyone noticing. That statement becomes the test for each step in the guide.
How to use this guide
The guide has nine chapters and this introduction. They follow the life of a supplier relationship and the project to bring software into it, and they are written to be read in order. Each chapter can also be used alone when a team is at that stage, provided the reader has first written a short problem statement and a list of owners.
The first two chapters prepare the decision. The chapter on mapping the current workflow asks you to define the problem, trace the records and handoffs behind a real order, assign decision rights, and set risk-based acceptance criteria. The chapter on evaluating software capabilities then turns those results into a functional matrix, a test of decision gates and human review, a check of audit trails and permissions, and a comparison of licensing and support.
The next four chapters follow a supplier through the workflow you have designed. Qualifying and approving suppliers covers risk tiers, qualification evidence, approval gates, and conditional approvals. Connecting receiving inspection records links purchase orders and engineering revisions to inspection, sampling, quarantine, concessions, and traceability. Following supplier corrective actions covers raising a request from a nonconformance, reviewing the supplier's cause analysis and containment, approving the proposed action, and verifying that the problem stayed away. Reviewing supplier performance covers scorecards, compliance gaps, status changes such as probation, and the evidence you retain for customer and registrar audits.
The last three chapters cover the move to the new system. Planning migration and configuration deals with inventory, cleaning and mapping of existing records, a pilot import, and the cutover. Training teams and rolling out the system covers role-based learning, sandbox simulations, staged deployment, and the measurement of adoption. Maintaining the system and choosing next steps covers periodic audits of how the software is used, a disciplined view of cost and benefit, answers to common questions, and a script for vendor demonstrations.
Each chapter uses a similar pattern for every topic. It names the role that normally leads the work, the inputs that role needs, the decision it makes, the record it produces, and the exception that can disrupt the usual path. It then lists the criteria you can use to test software against that topic.
The guide uses hypothetical scenarios to make decisions concrete. Each begins with the words Illustrative example and describes an unnamed business.
A note about product claims. ISO Certification Consultants publishes a Supplier Quality module page that describes topics such as approval gates, scorecards, supplier corrective action requests, and a supplier portal. This guide treats those descriptions as questions to confirm in a demonstration, not as verified promises, because the company's internal capability register still lists the supplier portal as pending. The same standard is recommended for every vendor you evaluate: a feature counts when you have seen it work on your own sample records.
Planning evaluation and implementation
A software project for supplier quality has two phases, and teams that merge them tend to buy before they understand what they need. The first phase is understanding and deciding. The second is configuring, migrating, and living with the system. This section outlines how the guide supports both, and what to prepare before the first vendor call.
Start with people. Name a project lead from quality, a representative from purchasing, someone from receiving, someone from engineering, and a person responsible for information technology. Supplier quality software touches all of them, and a project owned by only one function usually fails at the handoffs it was meant to fix.
Next, collect the material that the early chapters ask for. A useful starter pack has six items.
- A problem statement. One or two sentences naming the gap you want to close, with an example of when it last cost you something.
- A workflow map. The path from specification to purchase order, receipt, nonconformance, and corrective action, with the records each step produces.
- A decision table. Who may approve, suspend, and reinstate suppliers, and who may grant concessions, at each risk level.
- A risk classification. Which parts and processes are critical, and what inspection and documents each level needs.
- A sample data set. A masked selection of real orders, drawings, certificates, rejections, and corrective actions for use in demonstrations.
- A baseline. A few measures taken before the project, such as how long a rejection takes to reach the supplier record, so that later claims can be checked.
With that material, the evaluation becomes a test of fit and not a tour of features. You write the script, supply the data, and score what you saw. Features a vendor describes but cannot show go into the matrix as pending.
Several principles recur across the guide, and they are worth stating up front.
- Automated suggestions are drafts. Where software proposes a cause, a summary, or a status, a named person must review and accept it before it becomes a record, and the log should show who did.
- Controls beat lists. A status that does not change what buyers, inspectors, and engineers can do is only a label.
- History must survive. Approvals, evidence, decisions, and corrections should stay retrievable, with the original and the change both visible.
- Claims need evidence. Benefits are reported from records you can show, and estimates are labeled as estimates.
- Edition and customer requirements come first. Check which version of the standard and which customer clauses apply before encoding them in software.
Plan the rollout early, even though it comes late in the guide. Data migration, training, and staged deployment take longer than most teams expect, and they depend on decisions made during evaluation, such as whether suppliers will use a portal or have staff enter data on their behalf. Raise those questions in the first demonstrations.
When your matrix is complete and your demonstration scripts are ready, the final chapter explains how to run the vendor sessions and score them. To see how the ICC module performs against your script, you can request a software demonstration through the contact page and bring your sample records with you.
