“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:
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.
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.