“Whatever happened to the paperless office?” is a comment often heard when printing out the procedures for a process unit. While the use of procedures has been growing since I began my career in 1980, the number and length of plant procedures has further accelerated since the 2005 fire and explosion at BP’s Texas City refinery. Operators are off-shift for months to years writing, reviewing and updating procedures. All the procedures for a unit used to fit in a 3-ring binder but now require a bookcase. As the volume of procedures has expanded, it has become increasingly difficult, if not impossible, to ensure they are consistent and up-to-date. Indeed, the thought of revalidating and revising procedures can turn many an operations manager apoplectic.
A number of factors make the task daunting:
Figure 1. Different operators often require different procedures or portions of them.
Unit centric. Despite the increased interest in procedures, the basic approach, formatting and usability haven’t changed or improved. Procedures still are written so there’s one for each event for each unit. This creates a variety of problems. Some events are common to multiple units (e.g., power loss), so multiple procedures will be needed when the event occurs. While a single field operator may handle a given unit (which is not universal), multiple operators may oversee a large unit, or a field operator may look after several units. A console operator likely will keep an eye on multiple units unless a single unit is large. In these cases, one operator often will need multiple procedures to respond to a single event. If the unit is large, only a small portion of the procedure will be relevant to each field operator (Figure 1). Finally, some procedures really are subsets of larger ones — e.g., those for the loss of a steam-turbine-driven compressor really are a subset of the ones for a steam failure.
Inconsistent. Because the procedures frequently are written at different times and by disparate authors, inconsistencies usually abound in terminology and descriptions of the same task. One writer may reference equipment by names or functions while another uses only equipment identification numbers. One author is wordy while another is cryptic. One writer may be very specific as to cautions or when actions should occur while another assumes such information is common knowledge.
Procedure or training manual? Procedures, in many cases, serve as a training tool. This can lead to detail that, while valuable for training, hinders a qualified operator. The procedure writer must weigh how much detail to provide for the trainee against “just the facts” for the experienced operator. Having to scan through extraneous details during a high stress time when quick response is needed can result in an operator missing critical steps. Emergency procedures at one facility had seven pages of boilerplate on such things as personal protective equipment and hazards prior to getting to any operator tasks or action. Text written as both a procedure and a training manual is likely to be poor for both.
A First Step Toward A Solution
These and other issues with procedures surfaced in a knowledge management investigation funded by the Center for Operator Performance (COP, www.operatorperformance.org), Dayton, Ohio, an industry/academia alliance. Sandeep Purao of Pennsylvania State University, State College, Pa., recognized that breaking procedures into modules would provide considerable benefits. Most procedures contain a great deal of content also found in other procedures, resulting in an opportunity to create chunks of information that could be stored in a central location and accessed for use by multiple procedures. These chunks, or modules, would consist of procedure tasks composed of related steps. This approach facilitates the revision process because any change to a module then automatically appears everywhere that module is used. In addition, it allows tailoring of procedures for each operating position, so operators obtain only the procedure data they need and avoid sifting through information that’s irrelevant to their tasks.
Figure 2. Multiple procedures included such steps but often described them differently.
Purao and his students created a software prototype to process procedures and parse them into modules. The software was applied to a set of emergency procedures for an oil refinery hydroprocessing complex, where a single console operator and two field operators managed seven different units.
Eliminate duplication. It quickly became clear that the amount of unique content in the procedures was very small. It also became apparent that the procedures contained numerous inconsistencies and inaccuracies. For instance, “charge heater” steps occurred in more than half the procedures related to the field operator’s tasks but often were described differently (Figure 2). Wouldn’t it be better to create the best description of the common charge heater steps and use it everywhere? The one exception is the last event, tube failure, where the damper opening is unique; “open the damper” would become its own module.
The exercise clearly showed that voluminous procedures aren’t necessary. Fifteen emergency procedures were reduced to 22 task modules totaling 180 steps (Figure 3). The amount of unique text in the procedures (not including any background or training information that should be stored elsewhere) amounted to only 10% of the original volume. The emergency procedures drew upon different combinations of the modules to produce more than 40 pages for a single unit. The unique content of the modules filled less than 4 pages.
Position centric. Just as important, it was easy to create procedures tailored for each operator. The console operator would have a single procedure for a power failure rather than the seven procedures currently necessary in such an event. This was achieved by placing the modules into a relational database. Figure 4 illustrates the basic design — tables define: 1) which units are a given operator’s responsibility; 2) the modules that apply for each event on a unit; and 3) the steps and supporting material for each module.
Figure 3. Fifteen emergency procedures were reduced to less than 180 steps involving 22 tasks.
Enabling procedures to better match position demands would be a significant improvement by itself but modularization generates additional advantages. These include immediate benefits from enhanced consistency and operator-position-focused training. In addition, because most companies foresee their field operators eventually using tablets or other handheld digital devices, procedure modularization will improve both the utility of those devices and the performance of the operators.
Easier procedure management. The process for updating procedures no longer requires a review of reams of material. Instead, time and effort focuses on checking the modules for both accuracy and completeness. The task of updating the 22 modules for the subject hydroprocessing unit is a less daunting effort, in both perception and reality. Moreover, updating a module based on operator experience with one procedure no longer requires editing all the procedures. The procedure writer simply must assess if the change is universal or applicable to only a subset of the procedures in which it is used. If the change isn’t universal, a new module can be created for use in affected procedures or the step can be made conditional in the existing module using “if/then” statements.
Consistency. An additional benefit is that the wording for common tasks is uniform. No longer will some procedures use equipment numbers while others use names. For the hydroprocessing unit, some unusual “one off” steps appeared in the procedures. It wasn’t clear initially if this was because of something unique for a particular event or an oversight that the step wasn’t included with similar tasks in other procedures; it turned out to be an oversight. The modular approach enables examination of procedures for similar process units within and between process plant facilities.
Improved training. A secondary benefit of the process is a reduction and focusing of training requirements. Current training entails learning the emergency procedures. Instead of covering every procedure, the training can focus on the key modules. Understanding the commonality across different events will enhance learning. The modular approach allows additional detail for training to be built into the database, so procedures can be expanded to include, e.g., photographs and process diagrams as needed, and turned into detailed training material during the learning phases.
Figure 4. Placing modules into a relational database enables tailoring of procedures and adding details for training.
Improved delivery. Finally, this format likely would work well on handheld digital devices for field operators. The operator would see the tasks for an event, with each task expandable to detail the individual steps. Figure 5 shows a handheld interface developed by Subhashini Ganapathy of Wright State University, Dayton, Ohio, as part of a project for the COP. The procedures appear as one tab on the handheld device’s screen. Selecting a procedure opens a window that shows tasks, steps and the operator responsible. The user can filter this as well as call up supporting information (e.g., drawings) as needed. Because the procedures would come from the procedure database, the operator always would see the most current procedural information.
Next Steps
The COP now has defined an integrated solution for linking the chunking prototype directly into a relational database, and is awaiting development of a completed tool for user testing. The goal is to enable an operating company to feed in its current set of procedures for modularization, with the parsed modules directly going into the relational database once they have been reviewed and approved by a subject matter expert.
Figure 5. New approach eases making procedures available on tablets and other digital devices.
The objective of the software will be to allow a user to:
1. Import existing procedures as text files;
2. Analyze those procedures for common word usage, parts of speech and creation of modules;
3. Save both modules and taxonomy of terms in a database with consent or override by user/subject matter expert;
4. Search the database for similar modules that can be further combined;
5. Create new modules from scratch as the need arises;
6. Search and replace so the same module can be used on similar units/equipment; and
7. Create procedure(s) by combining modules along with meta-information (headings, units, etc.).
The software will be free to member companies and may be made available for purchase by non-members.
DAVID STROBHAR is principal human factors engineer for Beville Engineering, Dayton, Ohio. E-mail him at [email protected].
