The question “Should we purchase automated planning software?” is often asked.
The answer is definitely “It depends.”
In the early days of the DR/BC industry, +/? 30 years ago depending on who’s counting, automated planning tools were very popular and very necessary. It was predominantly a mainframe world and office automation of the time, let alone DR/BC automation, was in its relative infancy. The spreadsheet of choice was a green-screen version of Lotus 123. MS Windows existed, but few had ever seen it in practice, and even fewer had ever used it. Most documentation, lists and inventories were maintained on the mainframe in TSO. The industry was in its infancy in all regards and guidance and direction of any kind, (or quality, for that matter,) was needed for the early adopters to have a chance of successfully implementing their nascent recovery capabilities. Clearly, a consistent toolset was needed and the methodologies, templates and repositories of the first automated recovery planning packages were invaluable to getting early DR/BC initiatives off the ground.
Now roll the clock forward 25 or 30 years and ask the question again: “Should we purchase automated planning software?”
We believe that except for all but a very few special exceptions, the answer is no…or at least, not without keeping your eyes fully open.
Most companies want automated planning software for one of the following reasons: to simplify their plan development efforts (i.e. templates), to speed their plan development efforts, to simplify and consolidate their maintenance efforts, or to distribute their maintenance efforts to the end-user business proponents. Each of these reasons at first seems sound. However, actual experience across a large number of different planning packages and a large number of different companies of different types and sizes reveals a disturbing trend of repeating problems. Let’s look at each objective in more detail.
How can the first objective of simplifying plan development be a bad thing? The answer is ‘by appearing to simplify plan development while actually creating a false sense of security’. Almost by definition, a DR/BC manager looking to an automated planning system for best practice planning templates is doing so because he/she does not already have their own model plans. In the same vein, they often do not know exactly what to look for in a best practice plan (see NextGen™ Plans backgrounder). But this situation changes very quickly and before long, it becomes clear to the diligent manager that the templates in most automated planning tools do not reflect best practice. Unfortunately, they often do not even represent the primary focus of the developer who (too frequently) puts the disproportionate bulk of their efforts into the automation side of their tool at the expense of the template side. Virtually all users of automated planning tools progress through a predictable cycle from the excitement of wanting, to the malaise of having, to the burden of replacing the system’s templates with their own in-house developed procedures, and finally to the regret of terminating their license. By the end of this too-common cycle, the user has experienced the worst of both worlds—paying for the software and paying to redevelop their initial plans.
The second objective also seems logical at first: speed-up plan development. But consider: how can the plan-development timeline be shortened with so much additional overhead? It is hard enough to get an hour or so for a departmental team member to provide a list of updated phone numbers or to attend a tabletop exercise. How much harder is it to 1) Communicate to them a plan architecture that is “virtualized” inside of a database planning tool; 2) Train them on how to use the tool; 3) Convince them to convert all of their existing procedures into the new tool; 4) Make sure that, when the next maintenance update is due, they still remember how to use the tool; 5) Work around the incompatibilities with the “old way” that the tool does not yet support, etc., etc., etc.? Clearly, implementing an entirely new method of creating and maintaining documents for a very singular purpose should not be undertaken lightly.
The third objective should be even harder to argue against…consolidate documentation and simplify maintenance. The thought here is obvious, that an “automated” tool will consolidate plans and “automate” maintenance. Unfortunately, this perceived benefit also often becomes another “grail search”. Let’s consider the concept of consolidation. What is there to consolidate in the first place? Well, in very large organizations, there may be hundreds or even thousands of plans and related documents to “consolidate”. And as we said earlier, for a very few organizations, an automated tool may be necessary. If you have thousands of plans, you may be one of those organizations. (On the other hand, WTG intentionally does not consolidate plans…we keep distinct plans distinct for a reason. Automated tools are simply a repository for plan documents and often conflict with your existing repositories (i.e. SharePoint, document management systems, web sites, Exchange public folders, etc.)) However, for those with only a few hundred plans (or less), there is usually a better approach. After all, how many thousands of disparate documents, emails and attachments, etc. do you currently manage and track day-to-day without any specialized tools other than a Windows folder-sub-folder structure? WTG’s long-standing planning Axiom #1 states…’whenever possible, keep your DR/BC information in its original format and in the hands of the original data owner’. The logic here should be obvious—one copy of data is better than two or more and if someone owns the data, they should own it for all purposes (i.e. contact information in an HR system and a DR system).
One source, one owner. Anything else leads to duplicate maintenance and data integrity errors. But this axiom contradicts the planning tool’s basic premise—to provide a separate and distinct repository for your plan documentation. Seldom will the original data owner shut-down their repository or discontinue using their tool of choice. The result is duplication of data and maintenance and the predictable resulting errors. By properly designing your plans and supporting documentation in the first place, a simple windows file structure is usually all that is needed to simply and intuitively organize all your planning documents. Even better, more and more companies are using general-purpose collaboration tools (i.e. Sharepoint) or document management systems (i.e. Documentum or Stellent). These tools provide a multi-purpose repository and add robust functionality for archiving, work flow management, automated follow-ups, etc.; all in a package that will become a standardized tool across the whole organization.
Now let’s move on to maintenance. While the basic concept of an “automated planning tool” seems to infer some kind of automation (e.g. reducing maintenance?), most tools only automate report generation and document association (i.e. which documents pertain to which plan/department). Few if any really do anything to reduce maintenance out of the box without custom scripting. In fact, many packages actually increase the amount of maintenance required. Consider, for example, Call List maintenance. All organizations have an HR system with contact information even if it is not 100% accurate = copy 1. And for practical purposes, all planning tools have a section in their database for contact information = copy 2. Further, many organizations today use a notification system = copy 3 (if it is not integrated with the planning software). Most DR/BC managers also maintain many Outlook group mail lists to communicate with their recovery team and members = copy 4. Add a wallet card, still popular even when automated notification systems are used = copy 5. And who knows how many more copies…
The final objective is to redistribute maintenance responsibilities to end users in order to distribute the workload and to involve the actual data owners (once again Axiom #1). The problem here is that while involving the actual data owners protects the first half of Axiom #1, the second half is being violated. The data owners cannot use their normal toolset. Instead, they are required to use the automated planning tool. This requires training (and in many cases extensive training) on a tool that will see very little actual day-to-day usage. In fact, by the time the next round of updates occurs, many departmental designates will need to be retrained just to get the updates done. By the third round of maintenance, a large number of the departmental designates have changed jobs or left the company and a new designate will need to be trained. The cycle continues until the DR/BC manager job morphs into a full-time software training manager. But, there is another, even more dangerous side to distributed maintenance. There is very little that end users should be allowed to maintain or change. Their “raw data” is theirs to maintain, but typically not in a separate DR/BC system. As previously stated, names and contact information should be maintained in the HR system. Similarly, hardware inventories should be maintained in the hardware database, assets in the asset management database, etc. End users should not be allowed to change their core plans because once they do, there is no guarantee that they will coordinate effectively with any other department’s plans. As you systematically step through your plan documents, you find that the only elements you actually want your end users to maintain directly are their bridging procedures (manual workarounds), lost data reentry procedures and the catch-up procedures…and these are almost always Word documents.
So, if dedicated planning software is not the answer, what is the best way to accomplish the afore-mentioned objectives?
WTG’s NextGen™ approach starts with protecting Axiom #1 by using the ubiquitous MS Office to develop and maintain all planning documents…specialized training is instantly eliminated and everyone is ready to participate day one. Secondly, we use Adobe Acrobat to publish the final plans so that there is one, single, bullet-proof document (for each plan) that will always look the same on any computer. We also use built-in features of Acrobat and MS Office to give us “free automation”.
Acrobat supports automatic compilation of master plans from component sub-documents, as efficiently as the dedicated tools. Simply tell Acrobat which files make-up the master plan and where they reside and press the button…the master plan is generated in a few moments, even if it contains hundreds of individual sub-documents. If one of those documents changes tomorrow, press the button again and the new plan is ready and waiting (so much for automated planning tool objective three…consolidate documents and reduce maintenance). Acrobat also offers another very powerful feature for your DR/BC plans. Most multi-document PDFs are assembled by attaching “printed PDF” versions of the component documents. This is fine if what you want is a static document (i.e. the call list is “printed to PDF” alphabetically and attached to the master PDF). But what if at time of disaster you need to sort the list by location? Sure, you can go find the original Excel spreadsheet, resort it and reprint it. Or, if you also attached the .xls file into the PDF, you can simply double click the contact list from the PDF and the live Excel spreadsheet will open from inside the PDF and you can dynamically sort and resort to your heart’s content. We also extend the concept of “free automation” by using what Microsoft refers to as Smart Documents. By developing macros and Visual Basic code inside the MS Word or Excel documents, we can enhance the time of disaster functionality of the document with more “free automation”. Let’s take that same Excel call list that we attached to the published plan PDF. What if we needed to do more than simply re-sort the list? Let’s say that we want to use the call list as the base for all of our disaster communications, and that to do so we need to be able to easily send a lot of different emails to a lot of different interest groups ad hoc at time of disaster. Well, some relatively simple Visual Basic code gives us the ability to dynamically select an ad hoc group, automatically assemble them into an email list, and send the message from inside the Excel Call List (which is inside the plan PDF). The same technology allows us to actually eliminate much of the ongoing maintenance process. Let’s stick with the Call List example. We build the initial call list in MS Excel (a current, known tool – aka Axiom #1) by taking an export directly from the HR system (a single data source – aka Axiom #1). Thereafter, on whatever schedule is desired, an updated export is compared against the existing call list to automatically identify team members who are no longer with the company or are in a different role. An automatically generated email is sent to the team leader asking them to name the new replacement team member. If no response is received within a specified timeframe, another automatic email will be sent for follow-up. At the same time, automatically generated emails are sent to all members for whom contact information is missing—i.e. no cell phone number or home phones. The push of another “button” automatically generates the wallet card with current information and no manual intervention. Another “button” automatically generates a blank email form addressed to all alternate team members, of all technical teams, in the Pacific Rim (to invent an ad hoc group) all without the need to maintain a separate Outlook email list. In all, we estimate that 70 – 80% of the actual manual effort of contact maintenance can be completely eliminated through the use of embedded Excel macros and Visual Basic for Applications—all without license fees, training curves, software maintenance, etc. “Free Automation” from a proven platform that is already used for all of your documentation needs.
Following are some of the NextGen plan components that have been automated via Smart Documents:
- Call List generation and Maintenance
- Automatic Ad Hoc Outlook Distribution List Creation
- IBPD (BIA) Departmental Needs Assessment and Automatic Solutioning
- DR/BC Program Assessment
- DR/BC Standards Benchmarking
- Data Center Assessment
- Facility Assessment
- Exposure Assessment
- Departmental Recovery Procedure Matrix
From here, the only remaining question is where to store the plan.
And again, Axiom #1 points us to an existing tool that is perfectly suited for anytime-anywhere access…a simple offsite Web site. The website inherently provides all of the organization, compartmentalization, security and accessibility needed for both pre-disaster and time of disaster plan storage and maintenance and can be implemented literally overnight, with existing resources, for pennies on the dollar.
Is the Smart Document approach the only alternative to automated planning software?
No. But it clearly illustrates that many companies can get much of the same functionality, and in certain cases even more functionality, without incurring the cost and overhead of dedicated, single-purpose planning tools.