Operational Risk Management is a growing sector because the development of business processes in the last 30 years has made them more vulnerable to disruption. The reasons include:

• Reliance on Information and Communications Technology: businesses which relied on manual systems had fewer single points of failure since the processes were effectively distributed amongst a number of independent processors (staff). Now the failure of a single computer system can effectively bring a business to its knees.

• Performance and Productivity Improvement: partly due to the introduction of IT, businesses work faster and have to maintain this performance to satisfy their clients. Just-in-time supply chains are but one example. With lower inventories, business interruption has a severe impact on profitability, where before it was cushioned. Equally, improvement in productivity has been achieved by reducing overhead operations to a minimum to remain competitive. With slimmer organisations the potential for disruption is increased, and with centralisation of resources the effect of disruption is felt throughout the organisation, rather than being confined to a single division.

It is also clear that smaller disruptions can have a more dramatic effect than in the past. So businesses have to "fight fires" more frequently and management are diverted from the development of the business just to maintain the status quo.

The risks of disruption to business have come to the attention of shareholders and Government. New legislation following the Turnbull Report now requires public companies to report on their risk management systems. However, all too often companies see this as a chore to be completed with the minimum of effort rather than an opportunity to reduce the risk of disruption to operations and to free up management to concentrate on strategic issues.

One reason for this reluctance to tackle the job thoroughly is that it may seem a daunting task. Businesses are more complex than they used to be. They rely on an array of complex technologies, on more complex internal communications structures and on more sophisticated relationships with external suppliers, outsourced service providers and strategic partners. There is no one person in the organisation who understands all of this and the change from hierarchical organisations to "neural" networks of divisions and functions makes it difficult to delegate the task.

The common solution is to contract an external agency to produce a report which will satisfy the auditors. Although this may meet the business’s legal obligations it will do little to improve the actual management of its operational risks. That would require the process to involve fully those responsible for the operations, to allow all levels of management to understand the process and for the result to be a working model which can be used continually and to adapt to changes as they occur.

The usual approach is to anticipate events which could result in disruption to the business, and to devise procedures to minimise their impact. However the costs to the business of implementing these reactions is high. For example, diverting to disaster recovery sites takes time, during which business and customers are lost.

It’s evident that preventative measures should be taken to minimise the chances that Disaster Recovery or Incident Management procedures need to be invoked. This is what we at CCM call Operational Risk Management, and it requires the following steps:

1. Understand the dependencies of the business and the impact of their failure

2. List the risks of failure to each dependency

3. Determine and implement effective countermeasures to those risks

4. Continuously review the dependency model, the risks and the adequacy and quality of the countermeasures

Most managers take a responsible attitude to their jobs, and instinctively put in place procedures to mitigate business disruption. In other words it is usual to find that countermeasures are in place anticipating most risks. What is unusual is to find a structured approach which covers all identifiable risks. It is also unlikely to find risk management systems in place which are accessible to all parts of the organisation and all levels of management.

In our work we frequently find that countermeasures taken by one part of an organisation providing services to internal customers are not known by their customers and do not meet the requirements of the end user. Therefore it is important that the process should allow simple communication of risk assessments within and between different parts of the organisation.

Example: In one organisation the FM department had installed a UPS for critical systems which would provide 4 hours back-up in the event of mains power failure. The business managers thought this meant they could work for 4 hours before their computer systems failed. However the IT department needed 2 hours to perform a graceful shut-down of their systems. Moreover although the central systems were fully backed up only a handful of desktop units were connected to the UPS. This meant that the business could keep going for only 2 hours and only a few staff would be able to continue operating. Effectively it meant that the business shut down as soon as the mains power failed. In this way a mains outage became a critical risk to the business, whereas before our intervention the management thought they had an effective countermeasure.

To put operational risk management into context, the business should have a clear view of what it is trying to achieve, and what level of performance is needed to achieve those objectives. With this in mind, all aspects of operations can be submitted to the following scrutiny:

1. Upon what do you depend (e.g. processes, systems, facilities, third parties) to achieve your declared performance levels?

2. What could jeopardise the operation of these dependencies?

3. What countermeasures do you have in place to mitigate these risks?

Conducting this scrutiny in a structured way – so as to anticipate nearly all the risks the business’s operations face – is the true challenge of risk management. It is also a process that requires continuous review, since businesses are normally involved in some change process and the environment in which they operate is also in a constant state of flux. And yet if the solution is as complex as it seems it needs to be, the organisation will find it difficult to implement and maintain.

Indeed there are currently many risk modelling methods and systems which are so complex that they fail to achieve the objective of giving management an effective tool to minimise the possibility of damage to their operations. They are tools of analysis not of management.

An effective method will exhibit the following characteristics:

CCM’s method is centred on a dependency modelling tool called Visual Risk Analyser. This generates a graphical description of the businesses dependencies, and shows where risks are being managed and where they are not, using a "traffic light" system.

The benefits of an Visual Risk Analyser diagram are:

• It is simple to generate and maintain the model

• It provides a clear description of the business dependencies which can be used by all levels of management throughout the organisation

• It gives an immediate report on where risks are not being properly managed

• It provides the necessary framework for an audit trail

In other words, it gives management the means to know that it is taking all reasonable steps to ensure the continuity of business operations.

Associated with the dependency model is risk schedule which describes the risks of non-performance and the countermeasures that are in place (or not, as the case may be!) to mitigate those risks. This allows managers to plan and undertake risk reduction measures to cover those areas where material risks to the business are unmanaged or inadequately managed.

How are these models and risk schedules prepared? We start the process by looking at the high level dependencies of the business and determining an effective way of grouping dependencies so that specialist teams can be formed to address them. Every business will be different, but dependencies could be defined at a high level in the following diagram:

From the high-level dependency model we hold workshops of the specialist teams for each of the first level dependencies and determine in detail what their parts of the business depend upon to perform to target.

By combining the dependency models derived from the workshops, a complete model of the business is formed. But it is not over-complicated: the tree structure of the model allows us to break it down into manageable sections so that you need only go down to the level of detail you require.

After the modelling workshops the teams review the diagrams and make the necessary changes before proceeding to the countermeasures workshops. Again these are organised into specialist groups where we identify threats to the operations and determine whether there are adequate countermeasures in place. The whole process can be completed surprisingly quickly.