Deck: "Be prepared" isn't just a motto for Boy Scouts.

A disaster can strike at any time without warning, whether it's a tornado, fire, earthquake, power outage or failed disk in your computer. No matter what the disaster, it can suddenly leave your company without any means of processing important data such as accounts payable, payroll and other essential applications.

However, through the development of a disaster recovery plan, your company can minimize the impact of an unforeseen emergency and get back to business-as- usual, as quickly and efficiently as possible. In this article, you will be provided with the knowledge, tools and techniques needed to formulate such a plan.

If you are undecided as to whether your company really needs a disaster recovery plan, read the accompanying sidebar, "Quantifying the Risks." This simple worksheet will help you estimate any losses that could result should a disaster occur at your company without adequate planning.

Learn To Walk Before You Run

While there is no single way to put together a disaster recovery plan, your goal is to find the best approach for your company. It's important that your final plan be flexible in order to continue to be of value as your business and computer systems change over time.

In order to put together a plan that encompasses these challenges, it is essential to understand the special needs and procedures of disaster recovery. Without such understanding, your plan may not be a complete success. And when it comes to recovery planning, a bad plan is worse than no plan at all. Why? With a bad plan, you won't really know where you stand during a disaster, which could result in a variety of unwanted surprises during the recovery process. In order to prevent such problems, proper education and regular plan testing are essential to success. (Testing will be discussed later in the article.)

The following are five ways to learn the specifics of disaster recovery:

 1. Study tested disaster recovery plans. Review your company's plans, if any exist Review other companies' plans 2. Take advantage of professional organizations. Association of Contingency Planners The Contingency Planning Exchange Disaster Recovery Information Exchange Mid-Atlantic Disaster Recovery Association Data Processing User Groups 3. Review trade publications such as this one. 4. Attend topic specific seminars and conferences. Vendor disaster recovery workshops Regional trade shows 5. Select a knowledgeable and reputable vendor. 

The Right Vendor Provides Additional Resources

Once you know you need to put a plan in place, it is time to select a disaster recovery vendor. In most cases, companies do not have the resources or money to go it alone, so an experienced and knowledgeable vendor can be a valuable partner in the planning, testing and execution of a plan.

While some companies turn to other companies (instead of a disaster recovery vendor) as an alternate site in the event of a disaster, there are several issues to be considered before selecting this avenue. First, look at your computing requirements; the reciprocal company site you select must have a configuration similar to yours in hardware, software, storage and telecommunications. Additionally, you would need assurances that machine time and support services would always be available for testing as well as during an actual emergency recovery. Even if such details could be arranged, if the reciprocal site is near yours and a common disaster occurs, neither company could help the other.

Through vendor support, companies can be assured of facilities, equipment and technical support staff around-the-clock. An experienced vendor staff can help troubleshoot system problems as well as any other recovery problems that may arise during disaster situations. Depending on your situation, it is important to have immediate access to recovery facilities located throughout the country, which are fully equipped with systems, communications and on-site technical support.

The different types of recovery sites available to you include hot sites, which are centers completely equipped with hardware, software, communications and on-site technical support; warm sites, which are facilities where printers and displays are configured to process remotely to a hot site; and cold sites, which are facilities wired and configured to operate a system supplied by you or your vendor.

Identify Plan Parameters

The first step towards developing a disaster recovery plan is to create a mission statement. This strategic statement helps set company expectations, parameters of what the recovery plan will encompass and to what length the company is willing to go to keep the computer operations up and running.

The following is a sample mission statement: "The mission of this recovery plan is to provide reasonable assurance that critical business applications will not be inoperable due to lack of computer processing capabilities for more than a 48-hour period. This plan will include all computer applications utilizing the AS/400 and the personal computers in the sales department. Applications on other personal computers in various departments are not covered by this plan."

Once the mission statement has been written and accepted by the company, a plan format must be selected to create direction for the planning process. Look at the different types of design formats available; seek a format that is flexible and also meets your standards. Whether you select a consultant to write the plan, use a PC-based guide or a written manual, the format should prompt you to consider all of your company's needs and requirements necessary for a workable plan.

Initially, you should form two different committees: a disaster recovery management committee, which consists of key management staff and a steering committee consisting of upper management. The management committee will help manage the day-to-day planning of your recovery operation. The steering committee, which should meet once or twice a month, will approve a budget and the management committee's recommendations, and review project progress.

Once you've selected the design format, a project overview, containing both a budget and time estimates, should be developed. The project overview will drive your disaster recovery kick-off meeting, which all those involved in the process--including the members of both committees--should attend to receive their marching orders.

This meeting should also give your employees a feel for how important disaster recovery planning is and a sense of what would happen if a disaster occurred without a plan in place. For example, your billing department may not be able to invoice customers, orders may not be processed, inventory cannot be replenished, thus the manufacturing process cannot take place, and customer orders cannot be filled.

Critical Application Selection Is a Vital Process

Now that your mission has been identified and company-wide support has been gained, it is time to design the plan. In order to do this, critical applications must be identified. Through a review process, you can identify which applications are critical and which are not.

First, you should create a list of applications which includes the key users affiliated with each application. This application list should provide as much information as possible, from run frequency to inter-system dependency about the applications. Next, write a list of questions to determine the importance of the applications.

Once developed, begin interviewing users for information essential to the decision process. Also identify if any manual procedures could be used in place of computer applications during the disaster, if they have been tested and how effective they will be under different disaster scenarios.

After you've obtained all of the vital information, priorities must be set to decide which applications are critical and which are not. Questionnaires should be reviewed and the information prioritized accordingly. It is important for you to keep in mind that applications which can be processed manually may only be effective for a specific period of time before accuracy begins to deteriorate or a particular disaster scenario may render it ineffective. Thus, all applications should be prioritized by a worst-case scenario.

Address Risks to Prevent Potential Problems

It is important that your plan encompass more than just recovery from natural disasters such as weather, security or fire risks; it also should provide for recovery from disk crashes, computer failures and potential sabotage.

By watching controllable security measures, you may be able to prevent a potential disaster due to sabotage. You should review your company's security measures, know who has passwords to specific data and programs, keep track of keys, and inspect fire extinguishers, smoke alarms and sprinkler systems often.

Additional safety precautions include storing back-up files and libraries in secure off-site locations. This can assure you of access to data destroyed in a disaster. Information such as back-up frequency and retention duration of the back-up data should be documented with the disaster plan. Additionally, a reserve of any special forms needed for specific applications should be stored there.

While this article primarily focuses on the recovery of your data processing department's capabilities, it is extremely important that plans created in other departments be in harmony with your data processing recovery plan. In most cases, user departments have no disaster recovery plan. However, if they are developed, the user plans should be documented and consistent with your data processing plan.

Once all of this is planned, it is time to talk with your vendor to make sure the alternative site service provided will meet your computing requirements.

Team Development Key to Plan Support

Now it's time to build the teams needed to perform the recovery tasks. Team sizes depend on the amount of tasks and time allocated. Below is a sample of a company team. Remember, it is important to have an alternate for each team member. However, if staff is limited, you may want to cross-train to cover absent team members.

Management Team--Establishes a command center, notifies hot site, approves expenses for travel and reviews insurance requirements.

Recovery Center Team--Restores and tests systems, creates processing schedules, runs applications and arranges for any technical assistance.

Transportation Team--Picks-up and delivers back-ups, provides transportation to and from the hot site and distributes reports.

Replacement Facilities Team--Establishes security, recovers unusable equipment and works with building contractors.

Communications Team--Establishes voice and data communications.

Application Team--Determines file accuracy and coordinates the manual processes.

It also is a good idea to create a schematic displaying each team's tasks in the order they will be performed. Such a big picture display will eliminate any misunderstandings regarding responsibilities and provide management with the information needed to manage the plan.

Testing Goals Ensures Plan Success

With the disaster recovery plan written and the recovery team in place, it is time to test the plan according to pre-determined goals. If your plan has never been tested, it's a good idea to try to accomplish only the major goals during the first test and worry about minor issues during the second test.

For example, your first test goals may be to simply load specific critical applications and data without a timeframe. A second test might be to have the applications and data loaded and running within a set timeframe. While testing, you should document all information regarding test results, duration and encountered problems. This new information can be used to make any needed changes to the plan.

Return-to-Normal Is Often Forgotten

Planning for a disaster is essential, but so is planning for a return-to- normal business. Yet, this is the one part of a disaster recovery plan that is often forgotten. In order to actually begin business-as-usual again, return-to-normal plans must be formulated, including two essential parts: physical repairs and disaster in reverse.

If your data processing facility is significantly damaged or even destroyed, you should begin repairing the facility as soon as possible. In order to be prepared, it is a good idea to gather information from building contractors and restoration companies before a disaster happens.

After repairs are made to the facility, it is time to return-to-normal. System cut-over schedules should be created; choose either a phased cut-over process or a straight all-at-once process, whichever best facilitates the restore of your back-ups. Luckily, in a disaster recovery in reverse situation, the timing can be controlled. All return-to-normal planning should be included within your recovery plans, before a disaster occurs.

Don't Wait Until It's Too Late

A disaster can strike at any time without warning, leaving your company without any means of processing business-critical data, and in the process devastating your business through unfilled sales orders, union charges for late paychecks, late accounts payable, and disgruntled customers, vendors and personnel. However, through disaster recovery preplanning, your company can be prepared to combat such unforeseen emergencies and guide your company back to business-as-usual as quickly and orderly as possible.

Greg Holdburg is manager, Midrange Recovery Services, for XL/Datacomp, Inc. He has over 16 years of data processing experience in programming, data processing management and system design.

Quantifying the Risks

1. Identify your organizations' key business functions (order entry, payroll and inventory) and the computer systems that support them.

2. Assume you are no longer able to use the systems due to an unplanned event, fire, earthquake or power outage.

3. Estimate the financial impact this loss would have on your business based on how long the systems would be out.

4. Use the table below to estimate the losses incurred for each key business function if no plan was in place during the disaster.

Name of Business Function (e.g., Order Entry, Payroll or Inventory)

 Activity Day 1 Day 2 Day 7 Day 15 Lost Sales $_____ $_____ $_____ $_____ Lost Revenues $_____ $_____ $_____ $_____ (Fees, Collections) Loss of Customers/ Future Business $_____ $_____ $_____ $_____ Increased Expenses $_____ $_____ $_____ $_____ (Temporary Employees, overtime, and lost discounts) Fines & Penalties $_____ $_____ $_____ $_____ (Regulator, agencies, unions and vendor contract obligations) Adverse Publicity $_____ $_____ $_____ $_____ (Legal ramifications, liability, customers and stockholders) Total $_____ $_____ $_____ $_____ 

Also Read

Practical Middleware: Architecting for the Future

Practical Middleware: Starting the Journey

IBM i 7.2: The Carrot Versus the Stick