Expert Systems: Extra Power For Business Recovery Planning
- Published on October 29, 2007
The rule-based inference engine forms the heart of the expert system.
It is through this inference engine that the expert’s knowledge is constantly and consistently available.
This allows you to rely on expert knowledge, not “next guy” knowledge.
WHY USE AN EXPERT SYSTEM?
The intent of software systems designed for contingency planning is twofold.
First, these systems must assist with the implementation and maintenance of a plan.
Second, the system must produce a powerful and manageable plan.
Most commercially available systems, whether word processing or database oriented, assist the planner in some form.
The expert system, however, allows the planner to reach his goals faster and more easily than ever before.
WHAT MAKES AN EXPERT SYSTEM MORE EFFICIENT?
A true expert system for contingency planning offers two major benefits over conventional word processor/database systems. First, because it has built in “intelligence,” it allows the user to develop a working plan more quickly. Once a prototype plan has been developed, it can be refined through a reiterating process.
Second, the true expert system provides a control system that lets the user get at information using plain English (natural language), not complex query languages.
RAPID PLAN DEVELOPMENT
Advanced expert systems for contingency planning speed plan development by helping the planner to determine quickly which business functions or applications are essential to continued operation following a major disaster. These systems ask department heads and application users a series of questions about a business function or application. The system’s inference engine will analyze the answers in conjunction with senior management’s evaluation criteria (also known as rules of thumb or heuristics) to determine if a function or application is critical, necessary, or optional.
The expert system will even explain how it arrived at its decision. This information is maintained in a relational database table that provides a series of predefined reports, as well as the natural language interface.
The natural language interface allows the user to report/retrieve information from the table using requests posed in English, not a complex query langage. The natural language interface translates English requests into an SQL (structured query language) query, and the system then runs the query for the user. Leading expert systems for business recovery planning extensively use this accessible, yet powerful, control scheme.
A word processor is the best tool for publishing the recovery plan, and relational database is currently the best way to maintain extremely dynamic information, such as ever-changing lists of personnel, equipment, and other resources.
A business recovery planning system that incorporates a word processor, a relational database, and the unique power of an expert system will make the planner’s task that much easier. This type of system will allow a plan to be more quickly and easily published, and it will allow the dynamic information contained within it to be more easily maintained.
The integration of word processor, database, and expert system must be seamless. Products that try to assist with the contingency planning process but require a separate data base and text processor actually create more problems than they solve. Without a close link among the systems modules, trouble can arise.
For example, if a change is made within the database, the same change must then be made everywhere it is found in the text-based plan. There is no automated check to ensure data integrity. An integrated expert system will check the integrity of data entered into the database and then automatically insert the information into the text-based plan.
EASIER TO USE DURING A CRISIS
While there will always be a dependence on paper in contingency planning, the natural language interface is invaluable when the plan is used on line. During a disaster, quick and easy retrieval of information is of the utmost importance. The recovery planner cannot know who will need to access the on-line recovery plan prior to a disaster.
Rather than having to teach every potential user a query or report language, expert systems understand requests in English. This improves the flow of information during a crisis.
For instance, if a disaster occurs on the third floor of Building 9, you could enter the natural language interface and ask, “What departments are located on Floor 3 of Building 9?”Any English paraphrase of this questions will result in the same output by the system. The output can also be sent to the printer. You could go on to ask, “What equipment will be needed by claims processing?” This query method is more efficient and easier to use than searching a document file-by-file or by making an ad hoc report.
The debate over what is the best method for creating a contingency plan—word processor or database—will probably continue for years to come. Both tools have their advantages and disadvantages. However, as outlined here, expert systems that effortlessly integrate both disciplines and offer the additional benefits of speed, flexibility, and ease-of-use, move contingency planning to a higher level of productivity and scope.
Roadway Express Uses Expert System
Business recovery planner Ron LaForce joined Summit Information Systems, the data processing subsidiary of Roadway Express, Inc., in the fall of 1988. He was assigned the responsibility of consolidating and updating previously developed contingency plans.
LaForce’s task was facilitated through the use of a personal computer-based expert system for business recovery planning system, which helped him quickly develop a working plan and manage huge amounts of complex data.
LaForce’s prior experience led him to examine a variety of contingency planning software systems, both conventional and expert system-based. He knew that an automated system could save him countless hours of development time, quickly provide him with a prototype plan, and make plan updates easier.
In addition, LaForce needed a system that would make it easier to access and update large amounts of inventory, personnel, and procedural information.
“Although I’m working for the data processing operation of Roadway,” LaForce says, “our contingency plan will eventually cover all critical functions of the business. Because data processing encompasses many areas, our current plan includes emergency recovery procedures for administration, purchasing, human resources, public relations, legal, real estate, security, and building services.”
LaForce notes that public relations is one of the most critical areas to have in the plan. A company spokesperson must be ready, at a moment’s notice, to meet with the press, stockholders, employees, and the board of directors. The continued flow of accurate and consistent information during a crisis is a critical aspect of business recovery.
Once LaForce had completed a business recovery plan, he began a regular program of testing. “We have to test the computer aspect of our plan at least a couple of times a year,” he says. By testing the plan in a realistic way, he said, his people will be prepared in a real emergency; they know where the back-up site is located, which back-up tapes to use, and what steps to take to activate the back-up system.
Summit has conducted three tests of the contingency plan created by LaForce. “All of our tests so far have been very successful,” he said. “We set and try to meet objectives for each test. If we miss one of our objectives, we make corrections and try to meet them during the next test.”
One objective, he says, is to load all system software and four to five applications. The next step is to inquire and update the applications to verify the data. All of the data used is from offsite storage. Nothing is taken from the main data center, he says, since it is assumed to have been wiped out in the mock disaster.
Repeat testing of contingency plans, he says, accomplishes several goals:
Mark W. Avery is Vice President of Recovery Management, Inc.
This article adapted from Vol. 3 No. 2, p. 39.