In Part 1 of this series we noted that Risk Management went much beyond Supplier Risk, and the primitive Supplier “Risk” Management application that is bundled in many S2P suites (which is really more of a Supplier “Uncertainty” Management module). Then, in Part 2 of this series, we noted that there are risks in every supply chain entity; with the people and materials used; and with the locales they operate in. Then in Part 3 of this series we discussed inwardly focussed Corporate Risk Management, which some companies offer partial solutions to in the form of GRC (Governance, Risk, and Compliance) solutions.
Then, yesterday in Part 4A, we began our discussion of third party risks and outlined some of the specific baseline capabilities that such a solution should possess. Today we complete our discussion of third party risk and outline the remainder of baseline capabilities that we believe such a solution should possess.
| Sustainability | An organization needs to be sustainable, which it can only be if the suppliers it uses are sustainable as well. As such, a TPRM solution needs to monitor the sustainability of its suppliers. Their carbon footprint, or at least the footprint of the products/services they provide, associated GHG emissions, and (fresh)water utilization, especially if significant or beyond the norm (and reducable).
This part of the application should integrate with third party data feeds and assessments on sustainability as well as the integrated assessment module. |
| Commodity Markets | Sudden, unexpected, price increases represent a great risk to the organization, no matter where they occur in the chain. Since it’s usually the supplier (or the supplier’s supplier) who buys the raw materials from the commodity markets, the organization often doesn’t know about the price increase until it’s too late. Thus, it’s critical that an organization monitor the commodity markets for any raw materials it needs in considerable quantity that can have a significant impact on its financials.
Thus, a good TPRM system will integrate with commodity market feeds and track the raw materials used in the relevant Bill of Materials of the organization. As such, the system should also integrate with the ERP and be able to pull in the raw materials the organization’s suppliers need to acquire in large quantities on a regular basis. |
| Location Considerations | There’s a lot of risk associated with a location. Geopolitical, economic, natural disaster, and so on. The system should track all of the locations associated with each third party, the risks associated with the location, the likelihood, and, if possible, the potential impact.
This part of the solution should tie into the event monitoring, sentiment monitoring, third party feeds, and any other indicators that could indicate a location-based risk. When one is detected, all of the (potentially) impacted suppliers should be identified, and the potential severity of the event also identified. |
| Certificates | The solution must track all appropriate certificates / certifications for third parties that the organization needs to verify that the organizations are compliant with regulations, have the appropriate insurance, and so on.
A good solution will also integrate with third parties that can verify the existence/issuance of the certificate, the dates of validity, and other key meta-data. |
| Industrial Accidents | It’s important to keep track of any industrial accidents in the third parties you do business with, whether they have been cleaned up, what the impacts were, and whether or not the third parties have taken steps to prevent similar accidents from happening again. A supplier that could be shut down at any time due to an accident which has more than a negligible chance of occurring is not a reliable supplier. Plus, this can also impact reputation / brand.
Thus, the application needs to tap into organizational filings and disclosures to identify past accidents, event monitoring to identify accidents as they happen, assessments to get updates from suppliers as they clean up / recover, action plans that capture what the supplier/third party plans to do, and monitoring. |
| Recalls | Just like its important to keep track of industrial accidents, it’s also important to keep track of recalls. For what, how often, and how severe. A supplier that has to regularly do recalls has quality (management) issues and is not a supplier you want to be relying on.
It’s important that the application track recalls, track any updates on those recalls, and track any news stories that led to those recalls. You also want to know how often a supplier has had to do a recall in the past. |
| Related Parties | We’ve more-or-less stated this in many of the sections above, but it’s critical that you track the parties related with a supplier/third-party of interest. Those that supply, service, or invest in the third parties you rely on should also be tracked. In addition to tracking these, it’s critical to maintain the relevant relationships between the parties and keep this up to date.
The system should integrate with third party corporate registries that track ownership and relationship information and update the relationships in the TPRM as necessary. |
| Action Plans / Development Goals | As we hinted at in our discussion of Industrial Accidents, it’s not enough to just track the risks, the likelihood, and indicators they are materializing / have materialized, an organization has to work with suppliers to minimize the likelihood and, should they materialize, minimize the recovery time and the impact on the organization.
The application must support the definition of a multi-stage plan, with multiple tasks per stage, collaborative development of the plan, approval workflows, and when the plan is instantiated, execution and tracking of the progress made by the third party. Basically, it’s customizable development program management for a third party. |
| Maturity Model | The platform should support the definition of maturity models by third party (supplier) organization type, the mapping of third parties to these models, default action plans that can be instantiated to help a third party progress up the maturity model, and associated metrics to measure the aptitude of a third party at each level.
In other words, it’s not just point-based program management for the development of select capabilities in a third party, it’s integrated multi-faceted organizational management of a third party with monitoring, management, and reporting over time. |
Moreover, a Third Party Risk Management (TPRM) will also contain a host of generic analytics/planning/monitoring capabilities, but since many of these are common, and since stand alone risk-focussed analytics applications are also part of the plethora of offerings out there, instead of discussing these generic features in this and every other article, as we noted in our coverage of Corporate Risk, we will instead discuss these capabilities in an article dedicated to Risk Analytics and Monitoring.