What’s BCM all about anyway?
By Saul Midler.
(This article featured in the Security Solutions magazine, Issue 39, January 2006.)
Y2K caused a significant level of interest, effort and expense in Business Continuity Planning (BCP). From a Planning perspective: documentation and capability were defined, costed, developed, tested and implemented. By virtue of the fact that 01/01/2000 resulted in negligible (if any) disruption, let alone disaster, it would be fair to say that the various BC Plans did their job.
But what has come of those plans? Is there a place for them in 2005?
You would have to agree that there is definitely a need for companies to have Business Continuity capabilities. The threat and the after-shock of terrorism in the US, Spain and the UK has certainly raised the profile of Business Continuity.
The reality, however, is that disruption to business operations will most likely arise from events less shocking and confrontational. In January 2005, a UK survey[1] of 440 managers across various industries sighted the causes of disruption to their organisation. The following table presents some of the findings.
TYPE OF DISRUPTION |
PERCENTAGE OF RESPONDENTS THAT SIGHTED THIS AS THE CAUSE OF THE DISRUPTION |
Loss of IT |
41 |
Loss of People |
28 |
Loss of Telecommunications |
25 |
Loss of Skills |
20 |
Employee Health and Safety Incidents |
19 |
Flood/High Winds |
18 |
Loss of Access to Site |
11 |
Fire |
5 |
Terrorist Damage |
2 |
It is disconcerting to think that many organisations are still relying on their Y2K plans (as developed in 1998 and 1999) as a means of proactively managing a disaster in 2005. For those organisations represented in the above survey, Y2K plans would only have addressed disruptions relating to IT and Telecommunications. Of course this assumes that the Y2K plans were kept up to date.
Unfortunately, the P in BCP does not evoke a feeling of keeping up to date. A Plan reflects the thoughts at a point in time. What’s missing is the need to ensure that the BC capability and documentation set is always current and echoes the structure, technology and operational requirements of the organisation.
Today, BCP has theoretically been replaced by Business Continuity Management (BCM) – i.e. project based planning has made way for ongoing, business as usual, management. However, from a practical standpoint, experience reveals that the business community hasn’t quite got there yet. They call it BCM but they do it like BCP.
The following simple check list (Linus’ Baker’s Dozen) can assist in identifying whether your organisation has a BCP or BCM culture:
OBSERVATION |
Y/N |
1. Is there a line management position for the Business Continuity Management function? (i.e. not a project management position) |
|
2. Is this position treated as a professional management discipline? |
|
3. Is there a line management position for the Disaster Recovery Management function (i.e. focus on IT systems and services)? |
|
4. Is status and issues regarding BC related initiatives reviewed by the Executive Management Team on a regular basis – like other management disciplines such as Risk Management, Audit and say compliance? |
|
5. Is the BC process based on a periodic cycle eg every 12 months? |
|
6. Are there defined trigger points that would initiate a BC review (eg. new business system, new functions, physical relocations to a new site, organisational restructures etc)? |
|
7. Is there a feed from the company’s strategic planning process to the BC process? |
|
8. Is there funding available to support the BC/DR management position (eg for training) and the associated activities of BCM (eg testing)? |
|
9. Is there a BC awareness program that may include the provision of BC related information as part of the staff induction process? |
|
10. Is there a program of testing activities throughout the year? |
|
11. Is there a corporate BC Policy? |
|
12. Is there a BC Maintenance program structured to ensure that the BC Capability and Documentation set remain current? |
|
13. Is a BC management software tool used (i.e. software excluding spreadsheets and tables in document)? |
|
Three or more NOs may strongly suggest that the organisation may still have a BCP mentality. The key tell tail signs centres on questions 11, 12 and 13.
- There must be a corporate policy that mandates the maintenance of the BC capability and documentation. Without the directive of a policy, there will be little or no focus on establishing a proactive perpetual management process which leads to a project approach based on a knee-jerk reaction to implement BC. This indicates a lack of clarity of the overall purpose of Business Continuity.
- Without a maintenance program, plans will become shelf-ware and capabilities will become ineffective. With the passage of time, the organisation’s exposure to disaster will increase exponentially
- The reluctance or ignorance to adopt a software tool may be a clear indication that the organisation is focused on short term objectives (eg tick in the box by a regulator). In some cases, the project manager may simply want to complete his / her project and hand over to someone else.
The Need for Software to Support the “M” in BCM.
It is fair to reflect that many organisations that head down the BC path for the first time do develop a BC Policy and seek to establish a BC Manager position. However, first timers don’t know what they don’t know! To get the ball rolling they set the BC process up as a project requiring a project manager to deliver BC.
As the organisation’s BC requirements are being captured during workshops and meetings, it is common practice to use simple tools such as word processors and spreadsheets as the repository for this information.
As more and more information is gathered, new columns or rows are inserted into the spreadsheet, or a new spreadsheet is created. To make sense of the amassed information, links and references are established across the document sets.
It is also common for external Consultants or internal Project Managers to be the gatherers and maintainers of BC data and essentially become most knowledgeable of the subtle intricacies and interdependencies of the various spreadsheets and files of data.
As the project progresses, the organisation quickly comes to the realisation that a significant amount of valuable and sensitive information about the organisation, together with its BC needs has been captured. As the project approaches its conclusion (i.e. implementation of tested BC capabilities), the issue of hand-over becomes critically important. As the Consultants leave or the Project Manager moves on to the next project, someone else within the organisation needs to take ownership of the BC process and understand and maintain the volumes of documents and the complexities of spreadsheets. This situation is exacerbated since user guides or supporting information are typically not developed as part of the hand over process to the incumbent.
Once the first iteration is near complete, the organisation realises some of the key learning – that BC is:
- Complex – since it needs to cover all business operations, all IT systems and stakeholders’ interests
- Dynamic – since over the life of the project the business has changed and IT has changed.
- Specialised – since it requires sophisticated processes and experienced staff
By not proactively responding to these BC aspects, the organisation is effectively adopting a BCP approach delivering a static point-in-time capability that will become inaccurate and out-dated.
For those organisations that have mandated a policy to deliver a BCM culture, the following BC attributes are recognised and resolved – that BC is:
- Cyclic – since it requires an on-going commitment and support beyond the 1st project
- Maintenance Hungry – since it requires real effort and time to maintain and report on BC information
The resolution of the above 5 points typically leads to the purchase of specialised BC software. The top 10 key attributes and features of software focuses on the capability to:
1. Echo the breadth of the organisation in terms of its structure and geographic spread of Business Functions & Resources
2. Scale-up the BC needs by expanding the BC scope to include additional areas of the business
3. Update key information such as:
- Business Functions, Locations, Resources
- Strategies and corresponding costs
- Team structures & contacts
- Procedures
4. Share concurrent update capability with a variety of staff across different business units / divisions
5. Analyses the data quickly to produce information and costing reports that:
- Removes time consuming analysis hack work (eg via word documents and spreadsheets)
- Builds business cases for expenditure approval
- Delivers procedures
- Provides a detailed holistic overview of the business eg for BPR, capacity planning, strategic planning
6. Quickly produces an action plan and updates all required procedures to manage the prioritised resurrection of the organisation after a disaster
Additionally, there are a number of software design features that should be evident. The software should:
7. Offer access control and audit functionality no different to the corporate Finance system or any other system that the organisation is significantly dependent upon.
8. Reflect a solid methodology that presents:
- Common industry terminology based on industry usage
- Clear step by step processes to maintain BC & develop a capability to respond to any type of disaster or unplanned incidents
9. NOT support the scenario planning since scenarios are infinite while resources are finite
10. Saves Time and Effort
To ensure that the organisation will remain appropriately protected by its BC capability, the combination of policy, line management responsibility and specialised software signifies the organisation’s commitment to the M in BCM.
Saul Midler MBCI is the Managing Partner of Linus Information Security Solutions Pty Ltd www.linus.com.au
[1] Business Continuity Management 2005 report by the Chartered Management Institute (UK) in conjunction with the Continuity Forum (UK) and VERITAS Software
|