Using SpiraPlan for Supplier Qualification

Supplier Qualification Overview

Supplier qualification is the process by which a company will choose the correct supplier/third-party vendor for components/raw materials/services based on its requirements and regulatory protocols.

Supplier qualification means that a company needs to thoroughly evaluate candidate suppliers and third-party vendors as per their requirements, and then choose the best supplier or third-party vendor. These are usually regulatory requirements.

Why is Supplier Qualification Important?

Companies such as life sciences and biotech firms that research, develop, manufacture and sell products that directly affect humans, will have to maintain the highest industry and regulatory standards at each step of the life cycle of their products. This helps ensure that they will choose the right supplier after a thorough supplier evaluation and qualification process.

Hence, supplier qualification is important to ensure business continuity, reduce risk and consistently ensure that manufactured products are of the highest standard. So although the concept may be most important in the development of medical devices and pharmaceuticals, it is important for any company that manufactures mission-critical or safety-critical systems (e.g. aerospace, automotive, and general manufacturing)

According to Good Manufacturing Practice (GMP) regulations, supplier qualification is a crucial part of the validation process before choosing the right supplier for a company. It means that supplier qualification is not just a recommended protocol, but also a regulatory requirement.

Configuring SpiraPlan for Supplier Qualification

In general when using SpiraPlan for the supplier qualification process, we will use the following key artifacts:

• Requirements will be used to track the individual suppliers themselves
• Releases will be used to track the key milestones for supplier qualification and supplier updates
• Incidents will be used to manage the two key processes that relate to qualifying and managing suppliers:
  • Supplier initial qualification
  • Supplier annual update
• Documents will be used to store any related supplier information, such as:
  • Tax forms
  • Banking / financial information
  • Quality forms

We shall describe how each of these should be configured in turn. However the first thing will be to create a new dedicated SpiraPlan project that has its own template dedicated to supplier qualification:

Once that's done, we can now configure the various artifacts in the template.

Requirements Configuration

For requirements, we need to configure the components, types, custom properties and associated workflows.

Components

The first thing will be to create the various components that will be used to categorize the different types of supplier. We recommend using Components for the primary type of categorization for the suppliers. More granular sub-classifications can then be done via. custom properties. In the example below, we have created components for suppliers involved with Hardware, Other, Services and Software.

Requirement Types

For the requirement types, you can either just create a single requirement type for Supplier (called Supplier) and use a single workflow, as illustrated below:

However if you intend to have different custom properties for different types of supplier and/or have different workflows, you might want to duplicate the categories as requirement types (as well as components) so that you can have different workflows and custom properties associated with each type of supplier. However most of the business processes around supplier management will be done later in with the incident workflows, so you may not need to have a complex workflow for the suppliers themselves, just a status for the key statuses:

• Requested = New Suppliers
• Accepted = Approved Suppliers
• Obsolete = Obsolete Suppliers

Custom Properties

The choice of custom properties will depend a lot on your business, but typically you will want to have custom properties defined for the key supplier fields such as address, website, regions and other contractual and technical information:

Since this example is taken from a life sciences company, the suppliers will need to have a contracts point of contact, quality point of contact and a boolean Yes/No flag denoting if the supplier is GxP validated.

Releases Configuration

For the case of supplier management, our recommendation is to use the Releases module relatively sparingly, simply create major releases for each calendar year so that you can track all the supplier actions in a given year. This is useful if you have an annual supplier re-validation process.

If you want additional granularity, you could add phases under each release for each calendar quarter (Q1, Q2, Q3, Q4, etc.).

Incidents Configuration

The requirements are used to represent the actual suppliers themselves, whereas we will use the incident artifact to represent the different business processes that are associated with supplier management:

• New Suppliers
• Supplier Updates
• Supplier Deactivation

In addition, you may have other processes, such as annual supplier recertifications, etc. that require their own process. The incidents module makes this easy and straightforward.

Incident Types

We recommend that you create a separate incident type for each type of business process associated with suppliers:

The incident types can all have their own unique workflow, or they can share a common workflow if the steps are the same (for example a supplier update might be the same process as a supplier annual certification).

Incident Workflows

As we described above, each unique supplier process should have its own workflow. Processes that are similar, can generally share a workflow:

The following is an example supplier workflow. Noe that for simplicity we have taken the built-in defect workflow and just simplified it:

However for a more realistic workflow, we might want to complete change all the incident statuses/steps as well as the transitions between the steps. For example, here's a sample supplier qualification workflow you might want to use:

1. Question – define requirements and develop questions
2. Understand – compile candidates and assess capabilities
3. Evaluate – evaluate candidates and identify the best one
4. Site audit – perform a comprehensive site audit
5. Track – re-qualify suppliers on a routine basis

Custom Properties

The custom properties defined on the incident artifact should include all the information needed to qualify the supplier as well as support the other processes (management, annual recertification, deactivation, etc.). Each workflow will then show or hide the appropriate custom properties as needed.

In the example above, we have added custom properties to track:

• General notes about the supplier (rich text)
• The regions the supplier operates in (list)
• Whether or not the supplier needs to be GxP validated

Now that we have setup the template and project correctly, the next step is to illustrate the end user flow as they enter a new supplier. For brevity, we have not disabled all of the standard incident fields (such as Verified Release, Fixed Build, etc.) that you will most likely want to hide in a real process.

New Supplier Qualification

When you click on the New Incident button, the system will let you start the 'New Supplier Request' process. Simply enter in the name and description of the request (in this example, we're adding "Microsoft" as a new supplier"). Choose the region, component (supplier type), priority and whether it is a GxP supplier or not. We also use the Detected Release field to indicate that it is a 2022 supplier.

Once the request is submitted, it will follow the defined workflow for this type of incident. At some point, the supplier is approved, with appropriate comments and audit trail. You can now use the special Create Requirement From This Incident to turn the supplier request (incidents module) into an actual supplier in the supplier registry (requirements module).

When you use this button, the key information from the new supplier request is transferred over to the new supplier requirement record:

Any additional information that was not part of the new supplier request can also be directed added to the requirement.

Supplier Management

Now that the supplier has been added to the system, we can use the Requirements Board View to view and organize the suppliers. In this example view, we are viewing all of the suppliers by type (component) and the color coding indicates their priority (Critical - Low)

The boards allow inline editing so that it's easy to make changes to a supplier entry. You can also use the board drag and drop features to adjust the priority, component or other fields.

Generally simple changes can be made directly on the requirement artifact for the supplier, but other standard processes may require using the new incident form (e.g. annual recertification, deactivation, etc.). We shall look at each of these.

Supplier Annual Update

The annual supplier recertification and update process uses a similar process to the 'new supplier request' form, except that when you change the incident type from 'New Supplier Request' to 'Supplier Update', the list of required and available fields will change (see below) and only the information pertinent to the update process of suppliers will be defined.

One key difference is that you will use the Associations tab to explicitly link the supplier update request to the requirements record for the supplier itself (in this case Microsoft). That ensures that all activities related to the supplier will be visible from the supplier record.

Similarly to deactivate a supplier, you use the separate "Supplier Deactivation" incident type and follow that workflow to process the deactivation request for the supplier.

Once the deactivation request is completed (by following the workflow), the status of the actual supplier record will be changed to the obsolete status.

By using these two artifacts together (requirements and incidents), we can see in a single-view, all the details of the supplier (requirement), together with all the related business processes (incidents):

Document Storage

The final aspect of managing suppliers, is the need to store and manage the associated documentation that goes with the supplier requests and maintenance activities. For example, you may need to store:

• Supplier quality information
• Supplier financial/banking information
• Supplier tax forms
• etc.

Using the SpiraPlan document management functionality, you can create folders for each of the different types of documentation you need to store for suppliers. Then when you upload the documents associated with the supplier requests, you can simply specify the appropriate folder at the time of upload:

You can of course always move the documents around after the fact, just using drag-and-drop.

In addition, the SpiraPlan document management repository supports versioning of the documents and the workflow support electronic signatures, review and approval, and locking the final version to prevent unauthorized changes.

That way you have a complete audit trail of all documentation changes associated with the supplier. Furthermore, you can click on the Attachment tab for a Supplier and see all of the associated documentation in one place:

Summary

In this article, we have seen how we can use the requirements, releases, incidents and documents modules of SpiraPlan to manage the entire lifecycle of a supplier, from initial request, through annual recertification, all the way to eventual deactivation.