As noted in Part 1, if you’re going to be merging all areas of the two companies and the acquired will be engulfed or swallowed up by the acquiring company, then BCM/DR has a very large workload ahead of itself. In some regards, it’ll be like starting over but you’ll know half the BCM need already. If you work for the acquiring company you will have – or better have – your Business Impact Analysis (BIA) results, which would have been used to build the rest of your program; however, if you’re in need of the same information from the acquired company, you may not have that information available. If you do – hurray! but if you don’t, well, now you’ve got to get that half of the acquisition on par with what you already have.
It’s not as easy as saying that you’d replace one system with another (e.g. one finance department changes to the other finance departments operations). Your BIA needs to identify all the new applications, systems, people, processes and all the interdependencies – internal and external. Then you have to compare the results of the two companies; identifying duplication and stand-alone items. Not an easy thing because you may find that some processes can’t be merged easily with other processes due to system configuration, regulatory requirements (especially if the company you’re purchasing is a foreign business) and user application.
Finding like-for-like systems and applications isn’t easy and will take time. In fact, you may end up with multiple projects being implemented before you can actually do any DR/BCM work at all. Still, you’re able to merge the Crisis Teams and the Communications strategies, as I noted in part II, but specific roles and responsibilities may need to be amended depending whether new individuals are placed on the team or if other areas are replaced by new teams.
If there are existing materials by way of BCP or ERP plans, then they may need to be revisited also for formatting etc to ensure they match other plans. There is no point in having different versions of documents with differing formats; that’ll just create confusion and in the end if you’re audited, it’ll make you look slopping, as though you haven’t conformed anything. The problem there is that if you don’t conform documents and processes, you may have inconsistencies as well as information that contradicts information in another plan. So make sure you set a particular format to follow and use that for all new plans; existing ones and those being brought on board.
Finally, don ‘t forget about the 3rd party vendors that come into play. You may now have two sets of companies that clean carpets and an even bigger headache, two different DR vendors providing DR services. At some point you’ll need to review these contracts and bring them together under one over-arching vendor contract, which can take time and allot of effort to accomplish.
It can be confusing if you’ve got two contracts with the same vendor that need to be merged but it’ll be harder if you’ve got differing IT DR vendors. They will both compete for the business but you first have to know what he new strategy will be. Will you have a separate contract and strategy for both or will both companies now fall under the same DR strategy? If they fall under the same strategy, again, projects mat be initiated to bring them into line and then deal with the contract matter. It depends on what decisions are made and then when those are known, it will be easier to determine what steps to take.
No matter what, be sure to review every aspect of the DR/BCM programs of both companies and look for the best strategy in each; the best parts to leverage, the components to merge and the components that may no longer be required. It’s allot of work to do and in the end, you will have reviewed and re-strategized the entire organization and brought everyone together… Did I mention you’ll need to test all this new stuff too? 😉
© StoneRoad 2015
A.Alex Fullick has over 18 years’ experience working in Business Continuity and is the author of numerous books, including “Heads in the Sand” and “BIA: Building the Foundation for a Strong Business Continuity Program.”