1. Institute of Risk Management
Solvency II Special Interest Group
Avoiding the pitfalls in ERM IT Solution Selection
Susan Young
Head of Risk Management
R&Q Managing Agency Limited
10th July 2012
Private & Confidential www.rqih.com

2. 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

3. 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 and
developing 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 by
acquisition. The holding company is AIM listed and there are other regulated entities within
the Group including overseas activity, some of which is governed by local regulators
There was a group-wide demand for Risk Management

4. 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 the
format they want it?
Existing capability (MS Office Tools) alone would not cut the mustard

5. 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 Board
We did our homework as best we could!

6. Implementation - what went well
• We had existing Risk Registers in place which could simply be uploaded – once the
requisite analysis and configuration had been done
• We also had a developing Risk Management Framework which was already
embedding – 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….

7. 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 (or
concurrent with other initiatives – like Solvency II – unless it is explicitly within scope of this
project
Wait there’s more….

8. 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 supplements
your 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 and
what 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…..

9. 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 vendor
has 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 whistles
to later phases
• Listen to the vendor’s advice/suggestions, they will have experience of implementing the
software 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 they
can focus on learning the tool
• Do not change your mind too many times !
No coincidence there is overlap with the preceding slides…..

10. 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!

11. 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

12. And Finally………..
Thank you for listening!
Questions?
susan.young@rqih.com
www.rqih.com
Thank you for listening!
Questions?
susan.young@rqih.com
www.rqih.com