Disaster Recovery: Business Continuity Plans
Originally published: 11.01.13 by Dan Adams
DISASTER RECOVERY: BUSINESS CONTINUITY PLANS
RTO is how fast you intend to be back to business
We are just past the one year anniversary of Super storm Sandy. May storms the past few years have had very disastrous consequences but most of us do not take it serious. SBA statistics back up our lack of preparation showing that 2/3 (66%) of companies do not have a business continuity plan and of that, only 35% ever test them. So, based on the math, I know that it’s safe to say that the majority of you reading this article do not have a disaster plan. Why does it matter? Simple, because everything you have worked for is at risk without a plan.
Mother Nature is not the threat, we are.
We need to give a disaster a different definition as disaster is not limited to a hurricane, tornado or Godzilla’s foot smashing through your facility. A disaster is any time you are unable to transact business in the manner you, your staff, clientele, and vendors have come to expect and depend upon. Plain and simple, a disaster is when your businesses cannot operate.
Note, your gut feeling about the chances of getting hit by lightning are correct, but Mother Nature only causes about 5% of the outages, the rest are traced back to equipment, software and human failures. So as long as you have humans, equipment and software, the odds are not in your favor.
As time has rolled on, our dependency on systems and applications has increased. Our ability to take orders, manage inventory, schedule techs, invoice and run payments is tied to technology. Now consider that more and more companies are using technology based phone systems, and tying in smartphones, so, when these systems fail or are unavailable, business’ are at a dead stop.
But my “IT guy” would
tell me if I was at risk, wouldn’t he?
There is a basic misunderstanding between business and technology people. Let me walk you through this breakdown. Business leaders understand they are dependent on systems. They realize if something fails they need to be able to get their systems back up. Knowing this, they speak with IT and explain they need the ability to recover and get back up and running when the proverbial fan smells of manure.
Most technical people hear the word backup and think copy. A copy of the data is important but the real business goal is to be back to transacting business. That is different than having a copy of the files. A copy of the data does you no good unless you can run your business. It is a hard lesson to learn and it always comes at the most inconvenient times.
I thought backup and business continuity were
• Business continuity is the ability to continue transacting business. Backup is a copy.
• Business continuity needs to focus on how long it takes to return to the state of conducting business, where backup is a copy.
• Business continuity takes executive involvement, scope, planning, maintenance and testing, backup is just a copy.
• Business continuity tends to have multiple snapshots per hour where backup is generally just once a night.
• Most companies opt for backup mistaking it for business continuity.
I can personally confirm this problem is rampant. We have been in business for over 20 years, and multiple times every year I speak with a frustrated company owner or executive that mistakenly believed they had a process and a system in place to recover functionality quickly and accurately only to learn what they really had was a copy of their data. Most importantly, it will take many hours and often days to get the systems back to a functional state.
To solve the problem
We need to use a different approach to get a different result. The secret is using Recovery Time Objective (RTO) versus backup. RTO is how fast you intend to be back to business. With that in mind here are the steps you as a leader need to put in place.
1. Placing an RTO on each component of your business systems.
You need to know what each component does for your business and what the financial/operational impact is when each is down. Create a simple diagram of all of the components. Think big blocks like financial system, ERP, eMail, Internet, file and print services, security, etc.. (The Fishbone Diagram would be very useful - Publishers Page September 2006. Available online at wwwhvacrbusiness.com in the Down-load Center).
2. Convey the requirement to your technical staff and entire management team.
Document and share your time to recovery expectations. Specify in minutes/hours/days what you expect and hold them accountable to it with testing. They may complain or point to costs but they need to come back to you with proposals on how to meet your RTO objectives.
3. Understand your current solution costs
I see leaders strapped for funds unknowingly spending too much for subpar solutions. Knowledge is power. Add up in detail all of the costs associated with your current backup solution. Consider the backup devices, removable media, Internet storage fees, software, software installations and updates, time spent configuring and supporting, time spent checking, monitoring, restoring, media storage fees to (vaults like Iron Mountain, etc), labor of non IT people. Understanding the real cost will help you determine a plan moving forward.
4. Understanding the cost of business interruptions and downtime
Calculate your cost of down time. This is critical, and most companies do not take time to get the answer. How can you make a value based decision with only one number in front of you?
X – Y is an easy calculation however if one is unknown you cannot make an informed decision. Understanding your lost opportunity cost will also factor into your equation. For example, if you generate $60,000 in revenue a week and earn a profit of 10% how long would it take to make up for being out of business for an entire week, three days or even one?
A solution that meets your RTO and budget
Understanding your current costs, the cost for downtime and the proposed cost for a new solution that meets the RTO you’ve established, gives you the three variables to make an informed decision. From here, it’s much easier to make decisions, create plans, and most importantly put plans into action.
Most technical people seem to have an unrealistic idea on how fast they can get the world back up and functional. The truth is, unless systems are tested repeatedly you’ll end up with a less than favorable result. The first several times systems undergo testing, the end result typically does not go as planned. System testing should be conducted at least on an annual basis and whenever there are significant changes made.
In conclusion, having a plan, with objectives and details is not optional if you want to avert a serious business interruption. Recognize there are most likely serious gaps in your plan (assuming you have one) and if you don’t - get started. It’s not as difficult as it may appear. Make this a priority and over time you’ll be able to outline and implement a great plan that just may save your business. n