Be prepared for the little things as well

The term business continuity often conjures up visions of rows of empty desks hooked up to idle telecoms and IT equipment, just waiting for a disaster to happen and for a homeless workforce to move in.

For some, disaster recovery arrangements such as this are essential, but they represent the extreme end of measures to ensure that the business keeps running regardless of anything that happens within or around it.

While being mindful of how you would cope with a flood, fire or terrorist attack is important, most businesses are much more likely to be interrupted by an IT failure of some kind. Indeed, in a recent Freeform Dynamics research study, when more than 1,200 IT professionals were asked about the frequency with which IT systems failures affected their businesses, more than half (57 per cent) alluded to disruptions occurring on average at least once a month.

In most cases, of course, these disruptions do not mean the business as a whole stops completely; it might just be one department, function or workgroup being hit for a while because a critical application has gone down. At an aggregate level, however, such incidents can translate to a significant amount of process interruption, and whichever way you look at it, this is a business continuity issue.

A separate study, this time involving 700 organisations from across Europe and the Middle East, showed “downtime of key IT systems” was ranked second on a list of 14 risk factors. This was way above any perceived threats from terrorism or natural disaster.

Top of the risk list, however, was “loss of business-critical information”. One possibility here is loss arising from the destruction or compromise of paper records, but in most organisations today, we are likely to be talking about electronic data stored in computer systems.

In an extreme situation such as the loss of an entire customer database, a company could easily be brought to its knees. But what if the loss related to the past two days, or even two hours of transaction data in a core system? Even if the process of delivering goods or following up on support calls were only interrupted for a subset of customers, this would again constitute a business continuity issue.

Thinking in this way prompts a redefinition of what many people regard as the meaning of business continuity. Given the fundamental objective of avoiding business interruption wherever possible and recovering quickly from it when it occurs, it is important to look beyond the exceptional disaster scenarios and consider the everyday interruptions that occur so frequently.

It is also necessary to appreciate that from an IT perspective, it is as much about minimising the degree to which IT itself actually causes interruptions, as it is about getting the workforce back online quickly when the business is disrupted by some other cause.

There are certain practical constraints that we cannot escape, not least that it would be prohibitively expensive to make all systems and applications 100 per cent resilient in most IT environments.

It is therefore necessary to prioritise based on the likelihood of a failure occurring, or its anticipated frequency, coupled with the impact of that failure if or when it actually occurs. Judgements can then be made on a system-by-system basis, with the aim being to achieve the best compromise between cost and the level of risk mitigation achieved.

Those who understand systems-level risk – quite often from having to pick up the pieces and deal with the fallout from business managers when systems go down – frequently complain that it is difficult to get business stakeholders to take the risks seriously and, more importantly, to approve the funding necessary to minimise the exposure.

Apart from working on the systems aspect of disaster recovery plans, one of the most productive exercises any IT department can do in terms of business co ntinuity is to help business sponsors understand the dependencies between systems availability and the continued operation of key business processes.

Whether this is achieved through service mapping within an ITIL best practice framework, use of your favourite portfolio management system, or simply sitting down with a whiteboard and just talking through systems, processes, risks and implications, does not really matter. The bottom line is that many businesses will remain unnecessarily exposed until proper understanding and alignment is reached and business stakeholders become accountable.