Institute of Risk ManagementSolvency II Special Interest Group

Avoiding the pitfalls in ERM IT Solution Selection

Susan YoungHead of Risk ManagementR&Q Managing Agency Limited

10th July 2012Private & Confidential www.rqih.com

Agenda

• Background and Context

• Criteria pointing to automation

• Approach to selection and selection criteria

• Implementation - what went well

• Implementation - what lessons did we learn

• The Vendor’s perspective

• Was it worth it?

• Some parting thoughts

• Questions

Background and Context

• I Joined R&Q in August 2010 as Head of Risk Management

• The initial priority was the Lloyd’s Managing Agency, launching a new “Live” syndicate anddeveloping a Solvency II compliant ERM framework

• These, however, were not the only drivers………

• R&Q is a complex group engaged in many areas of activity which has grown largely byacquisition. The holding company is AIM listed and there are other regulated entities withinthe Group including overseas activity, some of which is governed by local regulators

There was a group-wide demand for Risk Management

Criteria pointing to automation

• The Risk Management Framework needed to be;

– Scaleable

– Customisable

– Interactive

– Easy to use

– Have comprehensive reporting functionality

– Solvency II Internal Model friendly - will it give the modellers what they want in theformat they want it?

Existing capability (MS Office Tools) alone would not cut the mustard

Approach to selection and selection criteria

• Personal research

• Exhibitors at IRM (and other) conferences

• Word of mouth

• Shortlisted 3 to give initial demonstrations to key stakeholders

• Made initial selection based on– Ease of use– Reporting Functionality– Vendor’s knowledge of industry and client base– Scenario analysis – Solvency II Use test in mind

• Proposal to Risk Committee and to the BoardWe did our homework as best we could!

Implementation - what went well

• We had existing Risk Registers in place which could simply be uploaded – once therequisite analysis and configuration had been done

• We also had a developing Risk Management Framework which was alreadyembedding – most users therefore understood this was a means to an end

• Buy in from senior management had already been obtained

• User training – engagement before roll out

• Vendor was very accessible, hands on and patient!

That was the good bit….

Implementation - what lessons did we learn?

• Plenty!

• Scope the implementation our as a project - that’s what it is

• Get to know the software and what it can do before you begin

• Decide what you want it to do for you early on and avoid scope creep

• This is a change management project - it is an integral element of embedding an risk culture– treat it that way!

• Leave yourself plenty of time – don’t try and do the implementation on top of the day job (orconcurrent with other initiatives – like Solvency II – unless it is explicitly within scope of thisproject

Wait there’s more….

Implementation - what lessons did we learn(continued)?

• Don’t set artificial deadlines – be realistic

• Don’t rush it – it may mean more time spent in rework later on

• Appreciate that any automated Risk Management solution is an enabler – it supplementsyour Risk Management Framework and it a means to an end only

• From the point above, have your Risk Management Framework broadly in place first

• Test the system fully before it goes live, with users. Get their feedback on what works andwhat doesn’t – and then……

• Pilot the live system with a few users before rolling out – get more feedback

• Phase it properly – don’t get too excited by all the things it can do initially

There were probably others but these were the main ones…..

The Vendor’s Perspective

• Help the vendor to help you – give them the full context and background

• Define the key people – who may not necessarily be who you think – and ensure the vendorhas sufficient time/access to the during the implementation – get the right balance

• Prioritise your requirements, keep it simple and to those priorities leaving bells and whistlesto later phases

• Listen to the vendor’s advice/suggestions, they will have experience of implementing thesoftware at hundreds of organisations so are aware of what works and the potential pitfalls

• Provide your users with risk methodology training before the software training so that theycan focus on learning the tool

• Do not change your mind too many times !

No coincidence there is overlap with the preceding slides…..

Was it worth it?

• Empowerment - for Risk/Control Owners

• Consistency – all Risk Registers are on a common platform in common format

• Reporting and MI at the touch of a button – we have used in our ORSAs

• Audit Trail – we can track down the culprits more easily

• Control for the Risk Management Function – its all in one place!

• Trend analysis and roll forward functionality facilitate monitoring over time

• Efficiencies? Undoubtedly – but we are still on our journey and have much to do

Yes it was!

Some parting thoughts

• Establish the business case first - Risk Management is a business process

• Take the business with you – don’t impose it on them

• Automation is not for everyone

• It can only help you do your job better – it won’t do it for you

• “Rubbish in, Rubbish out” – output quality matches that of input – to a degree

• Remember the six “P”s

Common sense but points worth making

And Finally………..

Thank you for listening!

Questions?

susan.young@rqih.comwww.rqih.com

Thank you for listening!

Questions?

susan.young@rqih.comwww.rqih.com