BCBS 239 Transformation – how?
In my recent article, ‘Beyond the Hype: BCBS 239 & Getting it Right’, in the context of BCBS 239, I posed the question ‘How do we go about all of this?’ I also teased that the answer is actually straightforward.
With this in mind, I have written this article to help illustrate what I believe is a practical and straightforward set of steps to deliver a transformation, indeed one that can be integrated across risk, finance and treasury too, that ultimately delivers BCBS 239 compliance as a by-product of implementing good business practice. I hope you will agree with my sentiment that this is not complicated or challenging. The approach is very straightforward and to some might be seen as ‘stating the obvious’. However, I am not seeing a methodology of any kind come out of the traditional consulting organisations (or at least one that delivers), and therefore I present this here to assist those organisations that are struggling to deliver their transformational goals in the hope they find this useful.
I would like to issue my normal health warning here, this article is based on my personal views and my perspective. It’s a perspective based on many years’ experience of dealing with financial service organisations, and risk, finance and treasury agendas themselves. As such, I hope you read the article in the spirit in which it is intended and that it helps to formulate ideas and plans to get more from otherwise stalled risk enabled transformation activities.
Transformation failure
Let’s start with a statement of fact: Financial institutions and large consultancies are struggling to deal with finance and risk transformation. This is clearly evident to us as we observe transformations are failing with many such organisations on a daily basis. Again, there is a mass of online content out there that talks about whytransformations fail. I will not attempt to reiterate the various research articles that list the ‘top 10 reasons why transformations fail’. For the most part, they follow a common theme – a lack of vision or sponsorship, poor communication etc., however where they all fail to deliver is compelling methodology for the transformation – howdo you do it effectively and successfully? In addition, there is a distinct lack of guidance for boards requiring substantive answers to the following questions:
- How do we identify and define what actually needs to be transformed and what our outcome goals are?
- What risk capabilities, processes, data and IT infrastructure do we need to support the (BCBS 239) transformation requirement and where are the capabilities and processes best located?
- What methodologies are available for transformation?
- How should we manage software vendors when the technology may not yet be fit for purpose?
- If we embark on an expensive transformation then how can improve our chances of success?
OK, so how do you do it?
Process Centric Design Approach
The diagram below outlines an appropriate Risk, Finance and Treasury Transformation Design Methodology – a key component in addressing BCBS 239 and Risk and Finance (including Treasury) transformation strategy.
A top down process design approach to transformation will ensure that the senior leadership’s vision is the driver for all transformational change. Strategic objectives should be aligned to the vision. In essence, target capabilities should be identified and mapped to appropriate ‘measures of success’ that allow for measurable success to be tracked and referenced throughout the transformational change.
There are seven Levels in our business process driven approach to transformation. Deep Risk, Finance and Treasury subject matter expertise is key to the approach that underpins the end state vision. In my experience, this is also where most organisations fail, and the simple reason is lack of genuine and deep subject matter expertise in this critical topic.
I have written in previous article that one outcome of good business practice or ‘getting it right’ is a satisfied regulatory agenda. The principle here is ‘business first and the regulatory agenda second’.
Target capabilities
A clear starting point is required for target capabilities. These should be identified up front – high-level capabilities that would need to be in place to underpin the end state vision. As an example, an outline Level 1 capability model that could be used across Risk, Finance and Treasury is shown below. Note, this model has been drawn out with a specific vision in mind, and is shown here for illustrative purposes only.
This integrated model should be established across Risk, Finance and Treasury, from level 1 through to level 7. Note, that this is no mean feat – the model that I developed for risk vision to achieve an AA grade rating identified over 350 key risk processes defined at level 3 only. At level 5 there were approximately 5000 processes for Risk alone. However, this is straightforward work, if you harness the right level of expertise across all risk types and ensure adequate integration with Finance and Treasury.
Drilling into Level 2 this model, for Risk could be drawn as below:
An example of level 3 Risk processes are shown below:
As successive layers of the process model are worked through, then the touch points between Risk, Finance and Treasury should be identified. These touch points are points of dependency, or points where processes can be shared or are common between functions e.g. defining legal entity capital ownership structure is a level 3 process that is usually common to Risk, Finance and Treasury functions. The process can reside in one common area, supplied with a single common data source, if definition and ownership of the process is approached in a top down manner.
Link all architectures
The successively more granular processes should be worked through and overlaid through the relevant levels within the organisation, data, application and infrastructure architectures.
Driving out the TOM
Overlaying the successively more granular process levels into an organisation design draws out the Target Operating Model (TOM) that is designed to support the vision.
Technology gap analysis
It is no secret that the bulk of vendor solutions in the ERM / ERP space often fail to meet organisational and commercial requirements. A robust technology gap analysis using the respective level of detail in the process models should then be performed against the chosen ERM / ERP solution e.g. OFSAA, SAP etc.
Critically, the business should then understand what requirements will be delivered by the vendor solution and more importantly, what requirements will not be delivered by the vendor solution. Gaps in vendor data models will also be known and alternative solutions / bespoke development can then be arranged and prioritised as appropriate.
Building the roadmap
Business issues, across Finance, Treasury and Risk should be mapped against the respective process levels. The technical resolution for these issues is provided by the vendor software gap analysis.
Achieving the vision
The roadmap manages software delivery, alternative solutions and bespoke delivery. By continually linking back up to the vision, tracking delivery throughprocess you can ensure that the Board vision has a more robust prospect of being realised.
OK, so what are the benefits?
If adopted, the above methodology will enhance the prospects of delivering your transformation successfully. In my experience, the benefits of the methodology are clear:
- Ultimately, it ensures the board vision is actually achieved.
- The methodology is efficient, minimises duplication and throwaway cost: “Get it right first time and every time”.
- Allows stakeholders expectations to be managed properly.The business will clearly understand what they are going to get and, more importantly, what they are not going to get. At any point in time, the board can reference exactly how much of their vision has been achieved i.e. from a perspective they understand – the business process.
- The methodology allows the business to understand the functional order of delivery. This is critical, the business are not interested in the technical delivery but merely the business outcomes which impact them
- This approach clearly enables the production of a business agreed roadmap based on the issues to be addressed.
- This helps keep the business engaged at all times – the approach ensures that we actually deliver what the business want and when they want it.
- The approach is a key enabler to establishing the Target Operating Model (TOM), a politically sensitive area.
- Ensures global / enterprise process owners are engaged at the right time and on the right process, leading to process harmonisation across the organisation.
- Allows for more effective management of external software vendors.
- Allows for more efficient planning across the internal IT organisation.
Conclusion
The route to success is actually very straightforward. Transformational activities are failing for many organisations, often because they lack an approach for handling the scale of change needed to be delivered. My advice is to adopt a transformation design methodology that provides you with genuine transformational outcomes. This must be process centric and should be delivered through a granular, integrated process model across Finance, Risk and Treasury.
If you have any queries regarding this article then please feel free to contact me here.