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

How to Reduce Costs when Complying with SOX 404

Section 404 contains the most onerous and most costly requirements you’ll ever encounter in the Sarbanes-Oxley Act (SOX). In this article, we?ll take a closer look at the salient points of this contentious piece of legislation as it relates to IT. We?ll also explain why companies are encountering difficulties in complying with it.

Then as soon as we’ve tackled the main issues of this section and identify the pitfalls of compliance, we can then proceed with a discussion of what successful CIOs have done to eliminate those difficulties and consequently bring down their organisation’s IT compliance costs. From this post, you can glean insights that can help you plan a cost-effective way of achieving IT compliance with SOX.

SOX 404 in a nutshell

Section 404 of the Sarbanes-Oxley Act, entitled Management Assessment of Internal Controls, requires public companies covered by the Act to submit an annual report featuring an assessment of their company?s internal controls.

This ?internal control report? should state management’s responsibility in establishing/maintaining an adequate structure and a set of procedures for internal control over your company?s financial reporting processes. It should also contain an assessment of the effectiveness of those controls as of the end of your most recent fiscal year.

Because SOX also requires the public accounting firm that conducts your audit reports to attest to and report on your assessments, you can’t just make baseless claims regarding the effectiveness of your internal controls. As a matter of fact, you are mandated by both SEC and PCAOB to follow widely accepted control frameworks like COSO and COBIT. This framework will serve as a uniform guide for the internal controls you set up, the assessments you arrive at, and the attestation your external auditor reports on.

Why compliance of Section 404 is costly

Regardless which of the widely acceptable control frameworks you end up using, you will always be asked to document and test your controls. These activities can consume a considerable amount of man-hours and bring about additional expenses. Even the mere act of studying the control framework and figuring out how to align your current practices with it can be very tricky and can consume precious time; time that can be used for more productive endeavours.

Of course, there are exceptions. An organisation with highly centralised operations can experience relative ease and low costs while implementing SOX 404. But if your organisation follows a largely decentralised operation model, e.g. if you still make extensive use of spreadsheets in all your offices, then you’ll surely encounter many obstacles.

According to one survey conducted by FEI (Financial Executives International), an organisation that carried out a series of SOX-compliance-related surveys since the first year of SOX adoption, respondents with centralised operations enjoyed lower costs of compliance compared to those with decentralised operations. For example, in 2007, those with decentralised operations spent 30.1 % more for compliance than those with centralised operations.

The main reason for this disparity lies in the disorganised and complicated nature of spreadsheet systems.

Read why spreadsheets post a burden when complying with SOX and other regulations.

Unfortunately, a large number of companies still rely heavily on spreadsheets. Even those with expensive BI (Business Intelligence) systems still use spreadsheets as an ad-hoc tool for data processing and reporting.

Because compliance with Section 404 involves a significant amount of fixed costs, smaller companies tend to feel the impact more. This has been highlighted in the ?Final Report of the Advisory Committee on Smaller Public Companies? published on April 23, 2006. In that report, which can be downloaded from the official website of the US Securities and Exchange Commission, it was shown that:

  • Companies with over $5 Billion revenues spent only about 0.06% of revenues on Section 404 implementation
  • Companies with revenues between $1B – $4.9B spent about 0.16%
  • Companies with revenues between $500M – $999M spent about 0.27%
  • Companies with revenues between $100M – $499M spent about 0.53%
  • Companies with revenues less than $100M spent a whopping 2.55% on Section 404

Therefore, not only can you discern a relationship between the size of a company and the amount that the company ends up spending for SOX 404 relative to its revenues, but you can also clearly see that the unfavourable impact of Section 404 spending is considerably more pronounced in the smallest companies. Hence, the smaller the company is, the more crucial it is for that company to find ways that can bring down the costs of Section 404 implementation.

How to alleviate costs of section 404

If you recall the FEI survey mentioned earlier, it was shown that organisations with decentralised operations usually ended up spending more for SOX 404 implementation than those that had a more centralized model. Then in the ?Final Report of the Advisory Committee on Smaller Public Companies?, it was also shown that public companies with the smallest revenues suffered a similar fate.

Can we draw a line connecting those two? Does it simply mean that large spending on SOX affects two sets of companies, i.e., those that have decentralised operations and those that are small? Or can there be an even deeper implication? Might it not be possible that these two sets are actually one and the same?

From our experience, small companies are less inclined to spend on server based solutions compared to the big ones. As a result, it is within this group of small companies where you can find a proliferation of spreadsheet systems. In other words, small companies are more likely to follow a decentralised model. Spreadsheets were not designed to implement strict control features, so if you want to apply a control framework on a spreadsheet-based system, it won’t be easy.

For example, how are you going to conduct testing on every single spreadsheet cell that plays a role in financial reporting when the spreadsheets involved in the financial reporting process are distributed across different workstations in different offices in an organisation with a countrywide operation?

It’s really not a trivial problem.

Based on the FEI survey however, the big companies have already found a solution – employing a server-based system.

Typical server based systems, which of course espouse a centralised model, already come with built-in controls. If you need to modify or add more controls, then you can do so with relative ease because practically everything you need to do can be carried out in just one place.

For instance, if you need to implement high availability or perform backups, you can easily apply redundancy in a cost-effective way – e.g. through virtualisation – if you already have a server-based system. Aside from cost-savings in SOX 404 implementation, server-based systems also offer a host of other benefits. Click that link to learn more.

Not sure how to get started on a cost-effective IT compliance initiative for SOX? You might want to read our post How To Get Started With Your IT Compliance Efforts for SOX.?

8 Best Practices To Reduce Technical Debt

When past actions in software development return to haunt you…

Is your business being bogged down by technical debt? Let’s look at measures that you can take to reduce it and scale your operations without the weight pulling you back. 

 

Work with a flexible architecture.

Right from the word go, you want to use architecture whose design is malleable, especially with the rapid rate of software evolution witnessed today. Going with an architecture that keeps calling for too much refactoring, or whose design won’t accommodate future changes will leave you with costly technical debt. Use scalable architecture that allows you to modify or add new features in future releases. While on this, complex features required in the final product should be discussed at the planning stage, that way simplified solutions that will be easier to implement can be identified, as this will lead to less technical debt in the long run. 

 

The Deal with Refactoring 

This is basically cleaning up the code structure without changing its behaviour. With the updates, patches, and new functionalities that are added to the systems and applications, each change comes with the threat of more technical debt. Additionally, organisations are increasingly moving their IT infrastructure from on-premises facilities to colocation data centres and deploying them on the cloud. In such scenarios, some workarounds are often needed to enable the systems to function in the new environments, which they hadn’t been initially developed to accommodate. Here, you will need to take some time to refactor the existing system regularly, streamlining the code and optimizing its performance – and this will be key to pay down the tech debt. When working with a flexible architecture from the start, the amount of work that goes into this will be reduced, meaning there’ll be less tech debt involved. 

 

Run discovery tests

Discovery testing essentially takes place even before a line of code is written for the system or application. This takes place at the product definition stage, where human insight software is used to understand the needs of the customer and is particularly helpful in setting priorities for the development work that will be carried out. It gives your business the opportunity to minimize the technical debt by allowing customers to give you a roadmap of the most pertinent features desired from the product. 

 

Routine code review

Getting a fresh look at the product or application from different sets of eyes in the development team will improve the quality of the code, thus reducing technical debt. There’s a catch though – this should be planned in a convenient way that doesn’t end up becoming a burden for the developers. Here are suggestions:

● Break down pull requests

Instead of having complex pull requests where numerous changes in the code are introduced at a go, have this broken down into smaller manageable pull requests, each with a brief title and description about it. This will be easier for the code reviewer to analyse. 

● Define preferred coding practices

Documenting the preferred coding style will result in cleaner code, meaning the developers will focus their effort on reviewing the code itself, not losing time on code format debates.

 

Test automation

Relying only on scheduled manual testing opens you up to the risk of technical debt accruing rapidly, and not having sufficient resources to deal with the accumulated problems when they are identified. Automated testing on the other hand enables issues to be uncovered quicker, and with more precision. For instance, you can have automated unit tests that look at the functioning of the individual components of a system, or regression testing where the focus is on whether the code changes that have been implemented have affected related components of the system. However, establishing and maintaining automated testing will require quite some effort – making it more feasible for the long-term projects.

 

Keep a repository that tracks changes made

Do you have a record of changes made in the software? Keeping one in a repository that is accessible by the development team will make it easy to pin-point problems at their source. For instance, when software is being migrated to a new environment, or legacy software is in the process of being modernised, you will want to have an accurate record of changes that are being introduced, that way if there is an undesired impact on the system this it will be easier to zero-down on the cause.

 

Bring non-technical stakeholders on board

Does this conversation sound familiar?

Development Team: “We need to refactor the messy code quickly”

Product Team: “We have no idea what you are saying”

On one hand, you have the management or product team defining the product requirements, creating a project roadmap, and setting its milestones. On the other hand, there’s the software development/engineering that’s primarily focused on the product functionality, technical operations and clearing the backlog in code fixes. Poor communication between the two teams is actually a leading cause of technical debt.

For you to take concrete steps in managing your technical debt, the decision-makers in the organisation should understand its significance, and the necessity of reducing it. Explain to them how the debt occurred and why steps need to be taken to pay it down – but you can’t just bombard them with tech phrases and expect them to follow your thought process. 

So how do you go about it? Reframe the issues involved with the technical debt and explain the business value or impact of the code changes. Basically, the development team should approach it from a business point of view, and educate the management or production team about the cost of the technical debt. This can include aspects such as expenses in changing the code, salaries for the software engineers especially when the development team will need to be increased due to the workload piling up, as well as the revenue that is lost when the technical debt is allowed to spiral. 

The goal here is to show the management or production team how issues like failing to properly define the product requirements will slow down future software development, or how rushing the code will affect the next releases. That way, there will be better collaboration between the teams involved in the project. 

 

Allocate time and resources specifically for reducing technical debt

With management understanding that working with low-quality code is just like incurring financial debt and it will slow down product development, insist on setting time to deal with the debt. 

For instance, when it comes to the timing of application releases, meetings can be conducted to review short- and longer-term priorities. These meetings – where the development team and product team or management are brought together, the developers point out the software issues that should be resolved as a priority as they may create more technical debt. Management then ensures that budgets and plans are put in place to explicitly deal with those ongoing maintenance costs.

 

Retire old platforms

While most of the resources are going into developing new applications and improving the systems being used, the organisation should also focus on retiring the old applications, libraries, platforms, and the code modules. It’s recommended that you factor this into the application release plans, complete with the dates, processes and costs for the systems involved. 

 

Total overhaul

When the cost and effort of dealing with the technical debt far outweighs the benefits, then you may have to replace the entire system. At this tipping point, you’re not getting value from the technical debt, and it has become a painful issue that’s causing your organisation lots of difficulties. For instance, you may be dealing with legacy software where fixing it to support future developments has simply become too complicated. The patches available may only resolve specific issues with the system, and still leave you with lots of technical debt. Here, the best way out is to replace the system in its entirety. 

 

Final thoughts

Every software company has some level of tech debt. Just like financial debt, it is useful when properly managed, and a problem when ignored or allowed to spiral out of control. It’s a tradeoff between design/development actions and business goals. By taking measures to pay down your organization’s debt and address its interest as it accrues, you will avoid situations where short term solutions undermine your long-term goals. This is also key to enable your business to transition to using complex IT solutions easier, and even make the migration between data centres much smoother. These 8 measures will enable you to manage your technical debt better to prevent it from being the bottleneck that stifles your growth.

Implementing Large-Scale Complex Business Change

Sometimes, driving your people to work harder is not enough for your organisation to withstand the pressures laying siege to it. With uncertain economic conditions, unpredictable fresh competition, and looming threats from the environment or even pandemic-grade diseases, empowering your people to not only ‘think’ but also to ‘step’ out of the box is currently the name of the game.

However, such initiatives typically require sweeping changes throughout your entire organisation … and to think even the slightest change is often met with hard resistance.

Whether you’re about to undergo an M&A, relocate due to a major catastrophe, scale down to a skeletal workforce, or implement a brand-new company-wide strategy, our systematic approach to large-scale complex business change can help you make the transition as seamless as possible.

We understand the importance of the human aspect in change management. That is why we’ll focus on making your people appreciate the benefits of having to learn new skills, perform new tasks, employ modern technologies, and go through new processes in order to tone down the resistance level.

Our entire process spans from top to bottom, wherein we’ll start with your sponsors, down to your managers, and then to other stakeholders in making them appreciative of the needed changes and in order to achieve alignment with your organisation’s goals. Our top to bottom approach is also aimed at casting a positive “shadow of the leader” on people down the line, enabling them with an optimistic view despite the gruelling tasks before them.

We invite you to have a look at the steps we take in implementing large-scale complex business change to win over a strong and lasting commitment to it.

Evaluating the Required Change

Large-scale complex business change initiatives can be implemented expeditiously and economically if you’ve clearly defined the scope of the change as well as the forces that shape your organisation. You’ll want to know which areas yield easily and which are hard to change to determine where and how you’re going to focus more of your efforts on.

To arrive at a sound and systematic plan, we first gather as much information as needed and analyse them. We determine whether your departments have the required capabilities and how we can arrive at a clear organisational alignment. That way, we don’t waste time, effort and resources when the moment comes to carry out the plan.

These are some of the diagnostic procedures we perform in evaluating the required change.

  • Change complexity analysis. We’ll assess the contribution of people and task factors to the overall complexity of the change project. This will help us determine how to approach the problem efficiently.
  • Causal analysis. By establishing cause and effect relationships, we can identify root or circular causes. This will allow us to pinpoint problem areas and prevent a repetition of past mistakes.
  • Structural analysis. Any company is propped up by a number of structures: organisational, process, motivational, social, and physical, among others. Understanding the structures that drive, motivate, hamper, connect, and influence your people’s behaviours can provide insights as to how or where structural change can best be executed.
  • Context analysis. We’ll look into market forces as well as political, economic, social, technological, legal, and environmental factors enveloping your business. We’ll also analyse your driving objectives, organisational alignment, and organizational capabilities. By analysing the internal and external environment in which your business currently operates, we can formulate a customised strategic and effective plan of action.

Managing Stakeholders

Change initiatives won’t prosper without total commitment from all stakeholders. Stakeholders refer to people in your organisation who either have interests in the change project or can be affected by it.

We deal with your stakeholders starting from the top because if we can’t gain full commitment from those already in the best position to spur the diverse entities in your company into active cooperation, striving to secure commitment from other areas will be futile.

That is, if you don’t have the full support of your key and principal sponsors, i.e. the people who have the biggest say and have greatest control over resources in your organisation, you can’t hope to sustain the change endeavour, let alone provide the much needed spark to get it started.

Here’s how we carry out our stakeholder management actions.

  • Conduct research to identify all stakeholders: the sponsors, your internal and external partners, the main targets of the change, and all interested parties. That way you can “switch on” implementors of each change action in the proper sequence.
  • Not everyone will offer resistance to your change endeavours. We’ll help you identify those stakeholders and sponsors who are willing to offer support, evaluate the level of support they are willing to give, harness all available supports and utilise them extensively to benefit the change.
  • Gain a deeper understanding as to why certain stakeholders are willing to lend support. In doing so, we can implement the right strategies that will encourage them to continue supporting you.
  • Assemble a leadership team that will champion your change initiatives. We’ll facilitate effective collaboration among its team members, transforming them into a cohesive force designed to carry out plans and motivate everyone else down the line.
  • Upon realisation of the change project, we’ll see to it that all stakeholders get a taste of the carrot at the end of the stick. This will encourage them to continue active cooperation in future change initiatives.

Planning for the Change

Anyone who has experienced having their car stuck in the mud knows that stepping on the accelerator will only get the vehicle trapped even deeper. Without the aid of a towing truck, getting the car out will require careful planning since different combinations of pulling, pushing, lifting, rocking to-and-fro, and stepping on the accelerator may be needed.

Of course, some combinations are just better than others. The same principle holds when effecting change.

Our approach to change management typically varies depending upon the information we obtain from the different analyses performed earlier. For instance, since not all organisations are suitable for a collaborative approach, we will employ either collaborative, consultative, directive, or coercive change management strategies wherever applicable.

A well-planned change will result in a smoother, less costly, and less disruptive transition. Here’s how we’ll help you plan your change initiatives.

  • When put in a predicament similar to the car-in-the-mud, the basic strategy entails identifying the current resisting forces and predicting what other resisting forces may be encountered along the way. After researching and pointing out your organisation’s resistance forces, we’ll lay out the most appropriate facilitation, education, and negotiation techniques.
  • To bring down wastage to the lowest possible levels, we’ll engineer a change delivery plan that involves the most cost-effective sequence of driver, process, technology, organisational, and people alignment.
  • To win and maintain a high level of trust, confidence and commitment from all sponsors and stakeholders, we’ll present a clear road map of the change process as well as landmarks that will prove how far we will have gone. These landmarks will then be brought to each sponsor’s and stakeholder’s attention each time they are arrived at in order to build up assurance and continued commitment.
  • We’ll design measurement tools and schedule reporting deadlines so that you’ll know what to look forward to and when to expect them.

Managing the Change

Your company will hold a better chance of maintaining a sizeable lead over the rest of the pack if you constantly establish a rally point and instil in your stakeholders the drive to rally to that point from the get-go. To make this happen, your company must undertake the unfreezing, transition, and refreezing phases of change skilfully in order to bring all stakeholders into the right mindset.

Our specialists’ systematic and efficient methods for each of these phases are designed to simplify the management of each phase as well as provide a seamless shift from one phase to the next. This is what we’ll do:

  • Set up a change project management office to ensure that everything associated with the change initiative is given the needed attention and resources even while all the other usual processes in your organisation run concurrently.
  • To unfreeze your people and get them started on the road of change, we’ll employ unfreezing techniques wherever they are most appropriate. We’ll resort to different kinds of methods ranging from presenting persuasive evidence justifying the need for change to showing a motivational vision for inspiring your people to embark on the change process.
  • Since it is during the transition phase when your people can find themselves groping in the dark, we’ll offer executive coaches for your senior managers; facilitators to provide guidance during team meetings and other change activities; coaches to educate and inspire them to meet the change with the right attitude; trainers to teach new systems, procedures, and technologies; as well as employ a variety of other techniques in order to make the transition phase as seamless as possible.
  • Although your people should always be ready to undertake the next major change after a previous one, there should be points in between where they can taste the spirit of success, establish a temporary base to rejuvenate, and immediately gain a deeper understanding of the nearby terrain so as to envision the next rally point. We’ll see to it that this vital phase of change is carried out completely.

Ready to work with Denizon?

Contact Us Today