How To Overcome A Just-Good-Enough BC/DR Plan
More businesses understand today that they need to have a plan to ensure continuity in the face of disaster and disruption. That’s good news, and if you’re one of those businesses, that’s great. It means you’ve embraced the process of conducting a business impact analysis, identifying the elements of your operation that might be affected by a catastrophe, and building a plan to recover from it.
As good as that news is, however, it may not be enough. In fact, Mick Jagger’s line that too much is never enough may be more to the point. Because no matter how good your business continuity/disaster recovery (BC/DR) plan is, you really need it to be a resilient plan.
Confronting Shortfalls
Anything can be improved. In the case of an organizational BC/DR plan, that might start with its origin. Quite often organizations have implemented BC/DR at the bidding of a technology officer or even from the c-suite. Though a plan may have been built, oftentimes in the corporate world programs created from someone else’s idea often fall short of complete buy-in. Those programs frequently have gaps or reflect incomplete thinking — but they got checked off on the corporate “to-do” list.
In short, it’s just good enough.
Some examples you might concern yourself about:
- Silo-itis. Departments may have focused their BIAs and planning on their own department, but did not interact with the entire enterprise. Sometimes this is the result of tunnel vision. Often it reflects the organization’s incomplete acceptance, as not every division participates, and there’s a lack of collaboration across departments.
- Old School-itis. Planning is conducted in an analog fashion. Notebooks are kept in each department, with updates printed from word processing documents, then delivered and replaced in binders manually, and often without coordination. Sometimes the BIAs and planning documents are kept in a spreadsheet to the same result.
- Errors of Inaccuracy or Timeliness. It may be that only department heads have administrative rights to make updates to the word processing or spreadsheet documents. Or the most recent version may be on a key manager’s local hard drive, but not yet revised on the main server or the golden document in the cloud.
- Inner-Focus-Only Failures. Sometimes planning is done well for internal systems. However, every business relies on vendors and customers. Too often, companies fail to plan how to overcome the effects disasters have on vendors — these can be everything from delivery problems to monetary problems. Similarly, a business can do everything right to ensure it continues to operate during a disruption, only to forget to enable customers to conduct transactions. If no plan exists for customers to reach a store or a sales website or exchange funds for goods, the plan is only semi-resilient.
- Meeting Regulatory Minimums. In some industries, disaster planning is required by governmental regulations or trade groups. Businesses often plan to meet specific directives, but overlook preparing for problems not specified.
- Underestimation Errors. Sometimes programs are based on incorrect assumptions. For instance, the time to recover from a malfunction could have been pegged in a user manual as requiring two hours. If that recovery time is based on an average, that means your servers could be down from 30 minutes to three and a half hours. The task could be more complex, because, in addition to servers being down, power could be out, and the server room could be flooded. Resolving that problem would certainly exceed average recovery time. Or a plan could have been based on the wind speed of the average hurricane in the region when a more severe storm strikes.
Then there are those black-swan events that even the best prognosticators can’t predict, much less plan for. A black hole opens up on your factory floor. An earthquake in North Dakota (last one? 1952). All metal on earth converting to bacon.
But often, some hints that are too small to be noticed or deemed relevant can become large problems. The famous Apollo 13 disaster turned out to be the result of an oxygen-tank thermostat that welded shut well ahead of the mission launch. An entire production run could halt if someone accidentally kicked an ethernet cable loose.
Keeping Small Things Small
Infinite Blue has acted to supplement the ability of humans to plan — and rely on their intuition — by putting machine learning models to work. By detecting minute or obscure connections people might miss, our new enterprise resilience solution, Cenari, enables better planning, response, and recovery. By learning from what it encounters, Cenari can correlate events and signals that would commonly be missed by a person.
When an incident is detected, Cenari’s virtual event command center tracks disruptions, contacts response teams, and keeps them — and the c-suite — informed in real-time. This allows timely, coordinated response and streamlined recovery. This means assessing the impact of an incident sooner than ever… and returning to business sooner than ever. And it means responding to a small problem, not the bigger one it would otherwise become. Remember Apollo 13 — a great movie, but a true near-tragedy? How much simpler it would have been to identify the thermostat flaw on the ground weeks ahead of launch. Instead, it led to an oxygen tank explosion and NASA had to bend every resource to solve the problem. Caught early, Apollo 13’s three astronauts would not have been imperiled, and the mission of landing on the moon could have continued.
Because Cenari is predictive and proactive, companies putting it to work reduce their exposure to risk from just-good-enough BC/DR by enhancing their resilience. The platform automatically coordinates response across departments, facilities, and other business systems. And the more resilient an organization is, the better able it is to complete its mission and separate itself from its competitors.
