Management of Change “MOC” Lifecycles
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.
Problem identification is generally 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 inclined to automate the problem identification process, the logical tools to consider would be the Issue Management, Audit Management or Corrective and Preventive Action FACILEX™ applications.
In the United States, the OSHA Process Safety Management 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 and the Change Implementation are generally combined into a single business process, in the U.S., and that process is called the Management of Change, or “MOC” process.
MOC Lifecycle Models
The MOC process can 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 below.
Figure 1. 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.
States: A state is “a set of properties that describe the condition of something”. In the context of MOC, a state:
- has a set of rules associated with it.
- governs access control.
- generally does not require its subordinate tasks to be done in a certain order.
Rules: The most important rules, associated with a state, are those governing promotion. In order for the MOC to be promoted from one state to the next, certain things have to be completed. These “things” can be broadly categorized as:
- Work item completion: typically, certain documents must be created, or updated
- Approvals: sometimes, certain persons must approve the work items or the MOC itself
- Notifications: often, various stakeholders must be notified
Access Control: is usually different for each state. Access controls govern which person can perform which actions on which documents, forms and other work items. The person can be an individual (e.g. J. Brown), have a certain role (e.g. MOC_Coordinator), or be a member of a group (e.g. Area_Managers). There are many possible actions in an electronic MOC system, but the most common are query, search, view, modify and delete. The work items may include documents, forms, database entries, and, of course, the MOC form itself.
It’s clear that different access rights are needed at different states. For example, during Initiation, it’s reasonable that an Initiator can delete an MOC if s/he decides an MOC isn’t warranted by the circumstances. But, at any other state, especially Close Out, there’s no ability to delete an MOC.
Subordinate Tasks: that need to be completed in order for the MOC to be promoted, do not generally need to be done in any particular order—they just need to be completed prior to state promotion. This is an area where trying to optimize MOC’s using a task-based, workflow model (rather than a lifecycle model, as discussed herein) usually fails; task-based models tend to order things unnecessarily.
There are several other common MOC lifecycles which are listed in Table 1 below. Each one of these alternate lifecycles warrants its own lengthy discussion, and will be a topic for future blogs.
|MOC Lifecycle Name||Brief Description|
|Full, Permanent||The “normal” MOC lifecycle.|
|Short, permanent||Changes are routine to the point that documentation can be pre-defined|
|Full, temporary||Changes which are intended to be “undone” prior to a predefined deadline|
|Short, temporary||Changes are routine to the point that the documentation can be pre-defined, yet the change must be removed prior to a predefined deadline.|
|Emergency||Change initiated, usually off-hours, to address an immediate need. Emergency MOC’s must terminate in the creation of a Follow-Up MOC|
|Urgent||Changes needed to overcome imminent danger, where even the Emergency MOC is too cumbersome.|
|Follow-up||A formal documentation of Emergency and Urgent changes.|
Table 1. MOC lifecycles.