Is your DR/BC Implementation Functional?

Is your DR/BC Implementation Functional?

Do you consider the actual functionality of your business continuity and disaster recovery plans?

I have been thinking quite a bit about things in my life being usable and functional vs. being “pretty” and just “there.” It’s not that I don’t like or want nice clothes or that I don’t enjoy the colors in the backyard, but what is in my life that is taking up time and effort that really does not push me to be a better person and world citizen? This blog is not about how to improve our lives, but rather, what is in our BC program that is “pretty” or “there” and is not really making our business more resilient or functional?

Here is a DR example. The IT team says they have a DR strategy in place and are able to recover servers. Everything has been tested. But after looking a little closer, it is clear that only the test environment for an application was included, and that not all of the necessary production servers are being replicated to the DR site. The basic functionality will be available, but not the middleware servers or external facing (public) servers. If this were an order entry system, the only way to get information or make changes on self-service would be to call or physically go to the support center. Also, passing information to suppliers would not occur. Orders can be processed, but the actual functionality is severely limited.

The technology has been tested and the strategy works, but both are far from functional. In today’s environments, the technology itself is often the least concern. More important is ensuring that all the necessary dependencies are in place to guarantee equal (or at least sufficient) functionality is in place. This is much more than verifying that “the servers are up.”

How about a BC example? The company has a work from home strategy and IT has put in place the capability to access systems remotely via web access or VPN. It is assumed and verified that everyone has a company issued laptop. The BC analyst stays late one night and notices that at least half of the laptops are still on the docking stations after the office is vacated for the night. Corporate policy and security do not allow non-corporate devices through VPN. In the event of relocation, how many people would actually be able to work? Again, strategies are in place and verified, but in actuality those strategies are not functional.

We encourage you to look closely at your program and identify areas that may look good, but actually have significant functionality gaps. They may be easily fixed, or they may be more complicated. At least you will know and can then put together a plan.

Let’s start looking at how functional we are and not just what boxes are checked.

Richard Long is one of MHA’s practice team leaders for Technology and Disaster Recovery related engagements. He has been responsible for the successful execution of MHA business continuity and disaster recovery engagements in industries such as Energy & Utilities, Government Services, Healthcare, Insurance, Risk Management, Travel & Entertainment, Consumer Products, and Education. Prior to joining MHA, Richard held Senior IT Director positions at PetSmart (NASDAQ: PETM) and Avnet, Inc. (NYSE: AVT) and has been a senior leader across all disciplines of IT. He has successfully led international and domestic disaster recovery, technology assessment, crisis management and risk mitigation engagements.

Business continuity consulting for today’s leading companies.

Follow Us

© 2024 · MHA Consulting. All Rights Reserved.

Learn from the Best

Get insights from almost 30 years of BCM experience straight to your inbox.

We won’t spam or give your email away.

  • Who We Are
  • What We Do
  • Blog