Why Spreadsheets can send the Pillars of Solvency II Crashing Down


Solvency II is now fast approaching and while it may provide added protection to policy holders, its impact on the insurance industry is not all a bed of roses. Expect insurance companies to restructure, increase manpower, and raise spending on actuarial operations and risk management initiatives. Those that cannot, will have to go. But what have spreadsheets got to do with all these?

Well, spreadsheets aren’t really the main casts in this blockbuster of a regulatory exercise but they certainly have a significant supporting role to play. Pillar I of Solvency II, which calls for improved supervision on internal control, risk management, and corporate governance, and Pillar II, which tackles supervisory reporting and public disclosure of financial and other relevant information, both affect systems that have high-reliance on spreadsheets.

A little background about spreadsheets might help.

Who needs an IT solution when you can have spreadsheets?

Everyone in any organisation just love spreadsheets; from the office clerk to the CEO. Because they’re so easy to use (not to mention they’re a staple in office computers), people employ them for processing numbers and as an all-around tool for planning, forecasting, reporting, complex modelling, market data analysis, and so on. They make such tasks faster and easier. Really?

You probably haven’t heard of spreadsheet hell

Unfortunately, spreadsheets do have certain shortcomings. Due to their inherent structure and lack of controls, it is so easy to commit simple errors like an accidental copy paste, an omission of a negative sign, an incorrect data input, or an unintentional deletion. Such shortcomings may seem harmless until your shareholders discover a multi-million discrepancy in your financial report.

And because spreadsheet errors can go undetected for a long time, they are constant targets of fraudsters. In other words, spreadsheets are high risk applications.

Solvency II Impact on Spreadsheet-based Financial and IT Systems

Regulations like Solvency II, are aimed at reducing risks to manageable levels. Basically, Solvency II is a risk-based system wherein a company?s capital requirements will depend on its measured riskiness. If companies want to avoid facing onerous capital requirements, they have to comply.

The three pillars of Solvency II have to be in place. Now, since spreadsheets (also known as User Developed Applications or UDAs) are high-risk applications with weak control features and prone to produce inaccurate reports, companies will have a lot of work to do to establish Pillars II and III.

There are at least 8 articles that impact spreadsheets in the directive. Article 82, for example, which requires firms to ensure a high level of data quality and accuracy, strikes at the very core of spreadsheets? weakness.

A whitepaper by Raymond Panko entitled ?Spreadsheets and Sarbanes-Oxley: Regulations, Risks, and Control Frameworks? mentioned that 94% of audited real world operational spreadsheets that were included in his study were found to have errors and that an average of 5.2% of all cells in the audited spreadsheets had errors.

Furthermore, many articles in the directive call for the enforcement of better documentation. This is one thing that’s very tedious and almost unrealistic to do with spreadsheets because just about anyone uses them. Besides, with different ‘versions? of the same data existing in different workstations throughout the organisation, it would be extremely difficult to keep track of them all.

Because of spreadsheets you now need an IT solution

It is clear that, with the growing number of regulations and the mounting complexity of tasks needed for compliance, spreadsheets no longer belong in this era. What you need is a server-based solution that allows for seamless collaboration, data reliability, data consistency, increased security, automatic consolidation, and all the other features that make regulation compliance more doable.

One important ingredient for achieving Solvency II compliance is sound data risk management. Sad to say, the ubiquitous spreadsheet will only expose your data to more risks.

More Spreadsheet Blogs


Spreadsheet Risks in Banks


Top 10 Disadvantages of Spreadsheets


Disadvantages of Spreadsheets – obstacles to compliance in the Healthcare Industry


How Internal Auditors can win the War against Spreadsheet Fraud


Spreadsheet Reporting – No Room in your company in an age of Business Intelligence


Still looking for a Way to Consolidate Excel Spreadsheets?


Disadvantages of Spreadsheets


Spreadsheet woes – ill equipped for an Agile Business Environment


Spreadsheet Fraud


Spreadsheet Woes – Limited features for easy adoption of a control framework


Spreadsheet woes – Burden in SOX Compliance and other Regulations


Spreadsheet Risk Issues


Server Application Solutions – Don’t let Spreadsheets hold your Business back


Why Spreadsheets can send the pillars of Solvency II crashing down

Advert-Book-UK

amazon.co.uk

Advert-Book-USA

amazon.com

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK

Check our similar posts

Failure Mode and Effects Analysis

 

Any business in the manufacturing industry would know that anything can happen in the development stages of the product. And while you can certainly learn from each of these failures and improve the process the next time around, doing so would entail a lot of time and money.
A widely-used procedure in operations management utilised to identify and analyse potential reliability problems while still in the early stages of production is the Failure Mode and Effects Analysis (FMEA).

FMEAs help us focus on and understand the impact of possible process or product risks.

The FMEA method for quality is based largely on the traditional practice of achieving product reliability through comprehensive testing and using techniques such as probabilistic reliability modelling. To give us a better understanding of the process, let’s break it down to its two basic components ? the failure mode and the effects analysis.

Failure mode is defined as the means by which something may fail. It essentially answers the question “What could go wrong?” Failure modes are the potential flaws in a process or product that could have an impact on the end user – the customer.

Effects analysis, on the other hand, is the process by which the consequences of these failures are studied.

With the two aspects taken together, the FMEA can help:

  • Discover the possible risks that can come with a product or process;
  • Plan out courses of action to counter these risks, particularly, those with the highest potential impact; and
  • Monitor the action plan results, with emphasis on how risk was reduced.

Find out more about our Quality Assurance services in the following pages:

Implementing Matrix Management

Matrix management is a culture change. More than the hierarchical structures, lines of responsibilities, modes of communication and channels of decision-making, it is a concept that needs to be planned ahead and managed appropriately over time.

Implementing matrix management to any organization can be confusing. It is essential to ensure that it fits right to your business strategies, skills and competencies. With this, realizing matrix management should not be taken lightly. Careful stages should be considered, instead.

Here are the steps to proper implementation of matrix management:

Consider Your Business Context

You need to evaluate your organisation to analyse what are your development needs with regards to skills, products, services and market environment. This will help you decide on what type of matrix structure you will apply in your organisation. Consider the following questions in building up your context:

  • What is our strategy?
  • Where are the demands in our business?
  • What are the structures that our competitors currently employ?
  • What are the talents that my people possess?
  • What are other business organizations doing?

Set Your Implementation Scope

Next, you need to define the parameter and set the scope of your implementation. What area in your business do you think matrix management will successfully work? There are several things that you need to consider in setting your scope. You have to make sure that it works well with your overall business strategies, that it can be excellently communicated and easily understood. Also, you must ensure that you acquire the necessary talents and skills in the business to deliver the new system of responsibilities.

Implement the New Structure

When you have already decided what structure type you will implement, you are ready to give it a go. You will need to establish new communication channels so you can monitor the progress and receive feedback effectively.

Here?s how to apply the matrix structure:

  • Highlight your development needs
  • Define roles based on outputs and not inputs
  • Line up procedures and systems to support the structure and the behaviour that comes with it.
  • Invest in training and development
  • Support the key people in the structure by coaching them to better adapt in changes
  • Communicate regularly
  • Monitor progress and make necessary adjustments

Review the Matrix Structure, Roles and Responsibilities

Organisations that successfully implement matrix management adapt to the changes in their environment. With this, they do regular evaluations to highlight the need for changes and revisions. The review can either focus on the structure only or to the entire process as a whole. The results can alter the structure, the roles involved and the responsibilities taken.

The process of implementing matrix management follows a step-by step method. Each stage is equally important with the rest. Hence, if you plan to exploit it in your organisation, you have to recognise the purpose of each step and follow it appropriately. Balance is the key. And when you achieve stability in matrix management, amidst the complex changes in the world of business, then your organisational success is just around the corner.

Can you do away with the Project Initiation Meeting?

Project initiation meetings are often skipped to fast-track projects. Once a sponsor is found, organisations go straight to project planning and execution. But based on our own experience, holding a project initiation meeting can actually eliminate many issues that may crop up in the future and hence may speed things up instead in the long run.

It is in the project initiation meeting where your project objectives and scope are clarified and all stakeholders are brought to the same page. Project sponsors and stakeholders will have to know in a nutshell what is needed from them, what the possible risks are, what different resources are required, and so on. So that, when it’s time to proceed to the next phase, everyone is already in-sync.

So what are taken up in such a meeting? Perhaps an actual example can help. Sometime in the past, we set out to work on an eCommerce website project. After conducting the project initiation meeting, these were some of the things we were able to accomplish:

  • Identified deliverables e.g. site design, interface to payment system, etc.
  • Come up with the project phases
  • Agreed what should be in and out of scope
  • Defined the acceptance test criteria
  • Identified possible risks
  • Identified the possible training and documentation work needed
  • Established whether any analysis was required, e.g. as with regards to payment interfaces
  • Formulated disaster recovery plans
  • Defined roles and responsibilities
  • Drafted timelines and due dates

Aren’t these covered in project planning? If the project is a big one, the answer is no. In a large project, project planning is a much more exhaustive activity. In a project initiation meeting, only the basic framework is defined.

Some questions may still remain unanswered after a project initiation meeting, but at least you already know what answers you need to look for. In the example we gave earlier, we left the meeting knowing that we needed:

  • a list of all necessary hardware to estimate the costs
  • to identify possible dependencies we might have with third parties
  • to identify what software had to be bought and what skills we needed to hire

When it was time to proceed to project planning, everyone involved already knew what direction we were taking. In effect, by not skipping the project initiation meeting, we were able to avoid many potential obstacles.

Ready to work with Denizon?