Spring World 2018

Conference & Exhibit

Attend The #1 BC/DR Event!

Fall Journal

Volume 30, Issue 3

Full Contents Now Available!

Introduction

Computers and networks have become an integral part of daily operations for business, education and government organizations alike. For those increasingly dependent on computers and networks for routine operations, downtime or data loss can be devastating, impacting earnings and even market valuation. This paper explores the costs and causes of downtime as well as ways to minimize such costs through downtime prevention, early problem detection and effective recovery capabilities.

The Cost of Computer / Network Downtime

The impact of downtime on an organization ranges from a minor inconvenience to an inability to perform necessary business tasks with resulting loss of productivity, revenue, and even customers and market share. One survey on downtime reported industry average numbers of $80,000 per hour, four hours average downtime and nine occurrences per year for a loss of nearly $3 million per organization per year. Another survey reported annual losses of $350 thousand to $11 million per organization with an average annual loss of $5 million.

These surveys covered a variety of organizations with different sizes, in different industries and with different problems, but are useful to demonstrate how significant downtime costs have become. An organization trying to reduce its downtime costs needs to focus not on such averages but on its own particular cost structure.

Estimating downtime costs deserves some care. Lost sales opportunities mean the loss of not just the profit on those sales, but of the entire gross margin which also helped pay marketing, administrative and development costs. The direct labor and benefit costs for idled workers will add to the cost unless that work can be deferred during the downtime and caught up afterwards without any overtime or extra cost. The loss of customers and market share has implications for the future as well.

Where Do We Go from Here?

We are presently in the midst of the greatest threat to business continuity since the ideas of disaster recovery were founded. I am not here to dwell on "the Y2K bug" as the popular media wants to call it, but to note that it is spotlighting the need for continuity planning now and in the future. We are seeing more companies wake from their "I’m safe" slumber to put disaster or continuity planners on new projects as well as the present states of business. The future looks brighter.

So, what is the future of Continuity Planning? We have seen our profession change in many ways over the last twenty years. We have gone from disaster recovery to continuity planning to resumption planning to continuity planning.

With disaster recovery we were involved in plans for the data center. We reported to the Data Processing Manager and were concerned with backup plans and hardware. Once some business entities entered into the picture we became aware of contingency planning. We needed to help a department to plan for contingencies when something happened in Data Processing that would cause them problems. This assignment was still part of Data Processing with some matrixed help from the department.

January 1, 2000–as the countdown rapidly draws closer, businesses and governments are becoming increasingly nervous about what might happen as this millennium rolls over into that special year. Will computers stop working? Will power grids fail? Will networks that support worldwide businesses do strange things? Across the globe people dedicated to preparing for not only a century change but also a new millennium are working diligently to fix all the known glitches. Programmers are attempting to correct all computer code that relies solely on 2-digit dates in order for business process programs to continue to run even as the clock ticks its way into the new year.

Initially, the Y2K struggle was geared to focusing energy on computer programs and system dates contained in old code—usually mainframe-based – in an effort to update and correct the manner these dates are represented within programs. Beyond the code correction struggle, follow-on energies are being devoted to preparing contingency plans in case these and the millions of embedded chips that exist in almost every advanced piece of equipment do not work properly after midnight on December 31, 1999. However, throughout all of this preparation, there is very little talk about our telecommunications equipment. Recent experience shows even less attention to the telephony end of telecommunications is its current situation.

 

The focus of preparation for the arrival of the Millenium Bug has been on technology. It is, after all, a technology problem. COBOL programmers have been called out of retirement, hardware and software have been replaced or upgraded, suppliers have been pushed to guarantee their products and services, and panic has emerged at the thought of embedded chips in critical systems being overlooked. As the millennium "hot dates" approach, however, the realization has dawned that technological fixes will not be enough to handle the crisis. Once again, we must depend upon people to ensure that the fabric of our economy is not torn apart by the possibility of widespread failure of business and government organizations.

For it is people that must perform the non-automated procedures that will keep an organization going in the event of system failure. These people will be performing under significant stress. Will they have the skills to work effectively with others under stress? Will they be able to focus and communicate in order to ensure the kind of collaboration necessary to be successful? There is a lot at stake and we must be ready. Here are some ideas about how to be prepared.

All organizations confront a challenge in effectively building and maintaining business continuity programs. However, those organizations creating a corporate-wide business continuity program are faced with a whole new level of complexities: not only are there multiple sites, functions and systems to contend with, but also multiple people with varying degrees of continuity expertise located throughout the organization must be involved in the program on an ongoing basis.

Bringing together all the disparate sites, functions and people is the first, and often most difficult, challenge the individual or group charged with an organization’s business continuity program faces. Using software tools that establish a consistent format, process and outcome across the enterprise can assist tremendously as the continuity group builds an enterprise-wide program.