Written by Bill Bedsole   

 

Should You Buy Automated Planning Software?

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.

Simplifying Plan Development

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.

Here are some suggested components of a best practice plan:

  • 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

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.

Speed-up Plan Development

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.

Consolidate Maintenance

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, we really don’t consolidate plans. In fact, we intentionally do not consolidate…we keep our 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? My 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, 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…

Redistribute Maintenance Responsibilities

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?

One 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, Adobe Acrobat can be used 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. The built-in features of Acrobat and MS Office give “free automation”.

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.


About the Author

Bill Bedsole is a Speaker, Author and Consultant. Founder and President of the William Travis Group and author of the NextGen 360° Advanced BC methodology, he has more than 25 years working in the Disaster Recovery and Business Continuity industry. He can be reached at Tel: 847-303-0055, Fax: 847-303-0378.