Disaster recovery and business continuity planning: Know the risks

More on disaster recovery DR: Use simple plan to classify apps DR plan: Finding the best solution for the money Virtualization the center of county's 'disaster avoidance' plan

In my voluminous spare time, I am responsible for implementing process improvements across all of our business functions (manufacturing, engineering, finance and IT, among others). As I teach our employees the principles of process improvement, one of the foundation principles I attempt to explain is that not all products, customers and processes are created equal. Quality product management is based on inequality among products. For example, the product line at one of our businesses includes more than 2,000 distinct products. Of these 2,000 products, only 10% (the A products) account for 80% of the sales revenue. When looking at ways to improve marketing, sales, production planning and distribution, we treat this 10% differently from how we treat the other 90% of the products. We make sure that we never run out of these products because they are in high demand. We make sure that these products have priority in our catalogs and sales presentations.

Of the rest of the 2,000 products, 30% account for the next 15% of sales. These are the B products. We need them, but if we have some hiccups in their sales, marketing or production, it does not hurt us too badly. The other 50% of the products account for the bottom 5% of sales. We treat these C products as custom-order items. We quote longer lead times when a customer orders a C product because we don't want to build C products, put them in our warehouses and pray that someone orders them.

I have found that by applying this same A, B, C stratification to our IT systems, we make better DR/BC plans and decisions. (See, I told you there would be a connection between product management and DR/BC!)

The A systems are those that can be down for only a short period of time before the business is at risk. The A systems are our real-time systems. The B systems are those that can be down for a longer period -- anywhere from hours to days -- before the business is at risk. The C systems are those that can be down for a long time before anyone outside IT even notices.

I have found that by applying this same A, B, C stratification to our IT systems, we make better DR/BC plans and decisions.

Once we have categorized our systems into the appropriate A, B or C status, we match our disaster recovery and business continuity plans to the system status. For example, our DR/BC efforts focus on protecting and recovering the A systems. Only our A systems qualify for hot or warm backup sites. We invest in redundancy of A systems. We look for and eliminate single points of failure in our A, and possibly B, systems but tolerate them for our C systems.

We factor our A, B, C categories into our help desk and response decisions. If an A or B system goes down, we immediately reallocate our resources, even those assigned to priority projects, to get the A and B systems back up. Not so for C systems -- they can wait until we have finished our priority projects.

As you might expect, segregating systems into A, B and C categories is not a process IT does by itself. This classification requires collaboration with our business customers. I typically approach system stratification as part of DR/BC planning. Together with a risk management committee, we define the criteria we will use to identify the A, B and C systems. With the criteria in place, we complete our sort. After we have completed the initial stratification, we schedule regular reviews to make sure we capture any changes, particularly A systems that have moved to B or C status.

I have found that taking this product management approach is the best way for me to focus IT's DR/BC efforts where they belong -- on the systems that matter most.