Management of Change (MOC) Business Process
There are many forms of communication that can be represented and analyzed using a “stack” model. The left hand diagram of Figure 1 shows a simplified stack for speech. At the physical level, speech requires sound waves—vocal cords and hearing apparatus are necessary for communication at this Physical Level to occur. Vocabulary and the rules of grammar govern communication in the Language Layer. Finally, the Semantic Layer represents that meaning that is implied by the words. For example, the words, “I saw a tokamak yesterday” are acceptable words, used in proper sentence structure (language). But the meaning is “yesterday I saw a tokomak nuclear reactor, so I must have been at a nuclear power or research facility” (semantic).
The second example is the well-known Internet Protocol Stack1. And finally, there is the MOC Business Process Stack.
Figure 1. Protocol stacks.
Note how each layer “uses” the facilities provided to it by the lower layer. Note also, that the higher layers are more useful for conceptual discussions than the lower layers.
It’s very difficult to discuss MOC business processes, when the discussion begins at the task level. Unfortunately, many MOC improvement initiatives begin with a current flowchart of tasks, and then an attempt is made to generalize the flowchart into a set of guiding principles. Regrettably, the important goals and objectives of MOC are lost in the minutiae of individual tasks (“…and then the environmental rep. fills out the ENV-123 form…”) and all the necessary exceptions (“…except if it’s a temporary MOC, and then we…”).
The author contends that MOC best practices are best discussed using a top-down approach, beginning with a high level “Phase” model, decomposing that into a “Lifecycle” model, and finally decomposing that into “Task” models (when necessary).
Some readers may be familiar with the Open Systems Interconnection (“OSI”) Basic Reference Model which describes a 7-layer stack. The diagram in Figure 1 shows the Internet Protocol stack which is not intended to be OSI compliant.
Management of Change (MOC) Phase Model
At the highest level, MOC’s can be represented by a Phase model, as shown in Figure 2.
Figure 2. MOC phase model.
“Problems” can be identified in a number of ways. Common examples are:
- Audit findings may suggest a change to equipment or process
- Incident investigations may reveal problems
- Other MOC’s may identify problems
- Inspections may discover problems
- An issue tracking or management system may house a list of “things to do”
- Engineering studies may identify how a chemical process would be improved by making certain changes.
Although Problem Identification is the necessary first phase, it is very diverse, and generally considered a precursor to the MOC process, not an integral part of the MOC process. Noting the similarity among the entries in the bulleted list, above, if one were to inclined to automate the problem identification phase, the logical tool would be an “issue management” (computer) application.
In the United States, the OSHA Process Safety Management1 regulations are rather explicit, describing various elements which occur during Change Request: document the technical basis for change, update process safety information, assess the impact of the change, and acquire proper approvals. Also, the OSHA PSM regulations describe various elements which occur during Change Implementation: mechanical integrity inspections, pre-startup safety review, procedure updates, and training. Consequently, the Change Request phase and the Change Implementation phase are generally combined into a single business process, in the U.S., and that process is called the Management of Change, or “MOC”, process. Other regulations2 and recommended practices3 also identify elements of both the change request and the change implementation phases.
2 29CFR1910.119. The Process Safety Management regulations promulgated by the U.S. Occupational Health and Safety Administration.
3 40CFR68.75. The Risk Management Plan regulations promulgated by the U.S. Environmental Protection Agency.
4 API RP-75, Recommended Practice for Development of a Safety and Environmental Management Program for Offshore Operations and Facilities, American Petroleum Institute, Washington, May 2004.
The combining of request and implementation into a single business process, is not universal. For instance, the author was recently involved in two MOC projects outside of the U.S. The first project had a comprehensive change request phase, similar to the US approach. However, change implementation was outside the scope of the management of change business process at this site, and was handled as a routine work order. The second project had a comprehensive change implementation phase, similar to the US approach. However, the change request was outside the scope of the management of change business process, and was handled like an extension to the issue management system.
Based on these observations, it appears that the combination of both the Change Request phase and the Change Implementation phase is the superset of all MOC business processes. So, henceforth, we shall consider Management of Change to be a business process which consists of both the Change Request phase and the Change Implementation phase.
Management of Change Business Models
The Change Request phase and the Change Implementation phase can each be decomposed into a number of states. The collection and sequence of states is termed the lifecycle. The essential difference between different kinds of MOC’s (e.g. full, short, permanent, temporary, normal, emergency, etc.) is that they have different lifecycles. A lifecycle for a full, permanent MOC is shown in Figure 3.
Figure 3. MOC lifecycle model—full, permanent MOC.
The diagram indicates that the lifecycle begins with the Initiation state. The MOC is “promoted” from one state to the next. An MOC can often be “demoted” from a state to the previous state. Also, there is a possibility of looping back to a much earlier state, as would be the case if the physical change is in the process of being made and an inspection discovers an unexpected configuration which warrants additional design work—this would cause the MOC to loop back to the Design the Change state.