Many financial services companies today are facing increasing regulation,not just around mortgage approval processes, but also on their supply chain. The focus of this has been in the area of supply risk governance, and strengthening processes for supplier risk escalation and quality assurance. This has been especially focused on preventative remediation, and a way to coordinate and assess risk in a decentralized environment. The organizational governance issue is one that you can’t assume will go one way or another – and most financial services will continue to operate in a decentralized environment where there isn’t a lot of centralized coordination over supplier activities. Today, that means lots of spreadsheets. So what should managers do?
One of the things that is great about being an academic is the ability to take a sabbatical and work on stuff you’ve never had a chance to work on during the year, read material you don’t have a chance to read normally, and speak with individuals on subjects you haven’t had a lot of time to think about in the past. So I’m on sabbatical this semester, and I’ve been working on over the last two weeks I’ve had the chance to think a lot more about global risk and intelligence in supply markets. I’ve been doing interviews – most recently with senior sourcing executives at major banks, people in military intelligence and in the Marine Corps, and other folks from various backgrounds – on how you go about collecting intelligence and assessing risk. One of the standard tools that seems to be common to many of these groups is a data collection report that provides room for leading indicators that are standard – but also individual observations that can be linked to latent indicators of risk. The focus is on then building a format for data collection that filters into a centralized analytics team. The framework has suppliers linked to a consequence algorithm – which filters into the team and controlled by a risk working group.
The process would look like this
- Anyone submits a potential risk event and enters a description.
- Each risk is evaluated by a risk manager for a quality check, and submitted to the risk management Center of Excellence
- The COE confirms risk levels, determines handling approach, and approves a mitigation risk.
- The risk is approved (recognized) and linked into a database where it is tracked.
- The risk status is monitored and a mitigation plan identified.
- The risk is closed through mitigation, acceptance, or overcome by events.
This is the idea – but is anyone doing this particularly well? Not sure….but stay tuned for more as I work on it….
Sandeep Srinivasan
September 7, 2011 @ 4:28 pmNice article, esp the process. From my experience in IT, I can tell (and you many know) there is a structured mechanism typically to handle risks in a project. Coordinated mainly by the Project Manager, there is a frequently updated RAID log (Risks, Assumptions, Issues, Dependencies). Typically anyone can suggest a risk along with a risk rating (H/M/L). The mitigating action for each risk is then developed based on discussions within the larger group. One practice I have observed intermittently that can be standardized across business functions is identifying triggers (different from indicators, in that trigger is simply a 1/0 event). Following the trigger, the mitigating action must be deployed which helps save time. Once the trigger fires, the risk should be treated like an issue in the RAID log. The log must be updated on a weekly basis. I think this fits into your suggested process.