Dedication to regulation

Regulationis a fact of life and business. The signs are that its impact will be felt more strongly and constantly than ever as time wears on. Of course, the extent of the impact depends on which industry your business operates in. However, it is hard to think of one that does not require any standards to be maintained at any level. The way in which IT responds to the challenge of helping the business address its regulatory obligations is not set in stone or standardised in any particular way. On one hand, the nature of the industry and the regulations in play dictate the requirements the business must comply to. On the other hand, the way an organisation treats, approaches, procures and manages IT can dictate how those business requirements are translated into imperatives, programs and projects by or for the CIO and its team. Where the former is consistent across an individual sector or country, the latter is certainly not. From the research we have done this pattern is familiar to us, and will no doubt be to any CIO with experience of running IT in more than one organisation during their career. There are always several ways to approach a task where IT is concerned. Note the word approach. I do not mean which products or services to use. That’s a different (but related) part of the discussion. Regardless of the problem or topic in question, when analysing studies we have frequently been able to identify different types of organisations through the way they approach problems with IT. The ‘progressive’ IT organisations that we have identified will not take a brief, directive or requirement from the business at face value only. They will tend towards carrying out (for want of a better expression) due diligence on the requirement by finding the answers to a series of questions such as: • How have we tackled such a request in the past? • What can we improve or avoid this time? • What choices – technically, operationally and people-centric do we have? • Where can we extend the benefits of addressing the requirement? In other words, such IT organisations take a holistic approach and look for opportunities to make broad improvements using the principles of repeatability and ‘extensible by design’. Not only do the choices they make stand a good chance of fulfilling the brief, but the business is protected should the same or similar requests be made in the future. IT is ready to help again because its ability to do so was built in from the start.

Less progressive IT organisations, either by virtue of their own make up, or (more likely) because they have no choice, are likely to take a silo or ‘start-stop’ approach to the same brief. There may be little or no due diligence done in terms of building links between previous or future projects. Methodologies may not be repeatable or extensible by design. Next time a similar question is asked, IT will go through the same motions and building on or extending on value created previously will be much harder to achieve. There is no reason why an IT organisation cannot apply those same ideas to how it addresses regulatory change now and in the future. In fact, if we believe that quickly evolving industry regulation may soon necessitate an almost constant ‘change program’ approach, then IT organisations that do already take a more holistic view are going to be in far better shape to cope than those that do not. The financial services industry is gearing up for yet another set of impending legislation. This time it’s the turn of the insurance industry. Solvency II is ‘their’ equivalent of the banking sector’s Basel II. There are lessons that can be learned from banks’ more recent experiences, some of which decided that it would suffice to create fancy algorithms to calculate certain requirements and this would suit the regulator. By not addressing underlying assumptions, models, processes and broader information management issues, many banks had to in effect, ‘go back and start again’. This was classic silo thinking: Short-term action which addressed the symptoms but not the causes and did not create any real or sustainable value for the business. For Solvency II, the smarter insurance companies will seek to extend the progress they have made at an individual, internal level. When addressing existing regulation around capital requirements (which Solvency II seeks to standardise and harmonise) they will have retained some knowledge of what they actually did in the first place, and not have to re-pay an army of contractors to repeat the work all over again. Less progressive insurers risk continuing piecemeal digestion of whatever the regulator throws at them. While their balance sheets may not reflect the costs associated with a broader improvement program, their risk management capabilities will be weaker, and their capital requirements may be higher than necessary. Solvency II is only relevant to the insurance industry, but hopefully it can serve as a reminder to other organisations that change on the horizon usually signals an opportunity to demonstrate the value and validity of technology investment when used wisely and with the broadest benefit to the business in mind.