Solvency 2 – Lessons Learnt (Part 1)

I haven’t posted in a while; partly from a lack of inspiration but mostly from the fact that I’ve been eye-ball deep in Solvency 2 data related activity. However I thought it would be good to try and get back into the habit of posting as I find it helps my own thinking as well as being a useful vehicle to garner thoughts and comments from others. We’ll see how I get on.

There has been a lot of European debate around Solvency 2 and the timetables related to implementation of the directive and I don’t want to go into all the ins and outs but the simple fact is that it feels as though momentum has been lost somewhat. Especially given the fact of where we are in relation to the original implementation timescales. A lot of firms seem to be taking stock of where they find themselves and are using the time look back at where they’ve come from as well as reassessing where they are heading. I thought I’d do something similar and take a reflective look at some of the lessons (from a data management perspective) we can already take from the Solvency 2 journey that can be applied to any project. Part one looks at the ever important business case:-

Build a better business case

There is often too much reliance on the “we have to do this” argument when building business cases for data management activity relating to a regulatory initiative. Whilst this argument can often give things a good initial kick in the right direction it leaves your business case severely lacking should regulatory momentum be lost. A business case that is light on ‘real’ drivers and benefits will ultimately lead to a reduction in funding. In turn this forces a loss of key resource or a reduction in planned activity, leaving your data management programme dead in the water.

Solvency 2 has proven to be a useful driver for a lot of data management initiatives due to the explicit data requirements it contains. However focusing only on the regulatory imperatives means missing out on the “bigger picture” aspects of good data management. You are in danger of ending up with a short sighted and largely ineffective programme.

Rather than relying on the “have to”, try thinking about why you should “want to” do something. Regulations aren’t made up for the fun of it (I hope not anyway) so there will be sound reasoning why firms will be required to do something. Try to understand the reasoning and then identify what benefits you will realise as a result of doing it. Granted it is sometimes a struggle to identify the real benefits of regulatory requirements but when you establish what they are it will ensure that your business case holds water; even when the initial enthusiasm/panic associated with a new directive subsides.

It is also important to ensure you can illustrate an achievable vision that not only strikes a realistic balance between “need” and “want” but is engaging enough to secure buy-in as well as budget.  Over promising and under delivering is a common failing so make sure to be pragmatic with regards to what your business case proposes.

Another important consideration, but unlikely to be part of your business case, is your “Plan B”. Regardless of how good your business case is there is still the chance that it is rejected or you find your funding cut. You need to know what you plan to do and working out what your options are up front may save you stress later on.

Part 2 coming soon…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>