In any highly engineered operation, it is typically assumed that a well-developed process for overseeing and documenting any changes to the operation is firmly in place. Most would even assume that this management of change (MOC) process would be digitized, meaning that all changes would be documented and stored electronically for easy access and that the process may even have electronic workflow directives associated with it.
>> Click here to read a brief timeline of changes in change management.
These assumptions are widely held because many manufacturing and process operations do indeed employ well-documented, digitized MOC procedures. Once you get beyond these model operations, however, the disconnects between best practice and everyone else tend to appear most in two areas: lack of MOC leadership, which can lead to abandonment of the MOC process; and disparities in the processes governing MOC for operations versus MOC for the software that supports it.
Both issues hold the potential of opening the door to system failure and potential catastrophe in terms of lost capital and injuries to workers.
Process vs. software MOC
Before getting into how leadership, or lack thereof, can impact change management oversight, let’s first consider management of change as it pertains to equipment, procedures and related software.
In operations MOC, the most common first step is to establish a scope of the process itself as it currently is, and as it is projected to be after the change. All changes required to achieve the goal are managed from this initial basis.
David McCarthy, president and chief executive officer of TriCore Inc. (www.tricore.com) (a system integration and engineering firm based in Racine, Wis.), says that TriCore, when involved in an MOC project, always begins with a detailed functional specification outlining every automated operation in the facility.
“This description is thoroughly vetted with all stakeholders, and signed off prior to writing any software” involved with the change, McCarthy says.
Within this specification, each automation function is described in detail with regards to the normal sequence of operation down to the device level. All permissives and interlocks are described as well, along with fault definitions and responses. Note: “permissive” refers to a process condition, such as whether a fan is on or off, that is connected to a switch in a control system. Certain conditions must be met for these “permissives” to be engaged; “Interlocks” refer to circuits designed so that the when one contactor is energized in the absence of permissive conditions being met, it prevents another contactor in the system from being energized.
Moving up from the circuit and device level, McCarthy says that all human-machine interface (HMI) screens, operator controls, security, process set point configurations, formulation controls and clean in place (CIP) controls, along with all reports, queries, event tracking and data logging and trending should be defined for MOC.
“As the system develops from design, to factory acceptance test, through final installation, any changes from the original specification are tracked,” McCarthy says. “Any substantial changes are discussed, and approval is received for any cost and/or schedule impacts, prior to implementing the changes. Once scope changes are approved, we issue a formal variation change order should extra cost or credits be required, as well as update any schedule impacts to all stakeholders.”
The MOC process for software differs from an operations procedure MOC in that the MOC process for software is typically an abbreviated process compared to that used for operations.
Four core aspects denote software MOC, according to Coleman Easterly, product manager for operations management software at automation vendor GE Intelligent Platforms (www.ge-ip.com), Charlottesville, Va.:
- Protect from unauthorized change;
- Provide for testing of changes before activating into production instance (this applies mostly to custom software);
- Track who, what, when for audit trail; and
- Provide means to roll back software to previous version.
“Fewer people are involved for approval of the software change and, in many cases, the agreement to make a change is the only approval step,” says Mark Tibbitts, director of operations effectiveness at automation software vendor PAS (www.pas.com), Houston, Texas. “Training and pre-startup safety review (PSSR) will only be done if the change impacts operations.”
Tibbitts notes that one of the big differences between software and procedural MOC is that, in many cases, MOC is not required for software if the change is considered “in-kind.” An example of an “in-kind” change is loop tuning.
A typical software MOC process for industries subject to compliance with 29 CFR 1919.119 (an OSHA standard that governs process safety as it applies to more than 130 specific toxic and reactive chemicals) only involves a multi-disciplinary review and approval for changes that are not “in kind,” says Tibbitts. “This process is usually made up of several steps: approval of the need for a change, detailed hazard review and engineering, circulation and approval of the formal change request, construction, training and PSSR, start up and, finally, MOC close out.”
MOC Leadership
Perhaps the most telling fact about the state of change management in industry today can be gleaned from the results of a survey conducted by PAS of its customers in 2011. This survey captured responses from 108 PAS customers regarding their use of MOC with their automation systems.
“All of them have MOC systems in place at their plant, but only half said that the MOC system was employed with every automation configuration or programming change,” says Tibbitts.
From these results, Tibbitts contends that, “in many cases, even in plants subject to the OSHA 1919.119 regulation, at least part of the time, no one leads software MOC.”
Even in cases where leadership of MOC is taking place, an engineer associated with automation may not be leading it, Tibbitts adds.
“Generally speaking, change management of automation software is done when the changes required affect drawings, procedures, or other elements under MOC control,” says Tibbitts. These change drivers may mean that engineering of the changes could be lead by engineers not normally associated with automation.
“Whether this is appropriate or not really depends upon the scope of the change,” says Tibbitts.
Clarifying his comment about the appropriateness of engineers leading or not leading a control software MOC process, Tibbitts says that an appropriate MOC for engineering leadership would be something like changing a level controller or valve connection to a flow cascade loop. “This would impact the P&ID (process and instrumentation diagram), so an engineer should be involved,” he says.
A circumstance like a virus update to a server on the process control network is an example of an MOC that could be handled by a non-engineer. “An IT resource could handle this because it would be considered a minor, or pre-approved MOC,” Tibbitts says.
The bottom line for system integrator McCarthy is that, for successful change management to take place, there must be a project manager from the client who has the ultimate say over the project. “The project manager may have a technical resource available if they do not have sufficient expertise in the technologies utilized in the project, or sufficient operational knowledge of the processing systems,” says McCarthy, but to manage scope and change, it is essential to have a foundational understanding of what the project requirements are, and the technologies utilized to achieve those requirements.”
Success and failure
It’s clear, even from this brief analysis of change management procedures for process operations and software, that there is a great deal of gray area when it comes to either ensuring success or securing a high potential for failure. Simply focusing on the defining process behind what would be considered an “in kind” change to a software system is rife with possibilities for underestimation or flat out miscalculation of the potential consequences.
On the bright side, all change management programs succeed to some degree in that, even when partially implemented, they tend to drive a higher level of employee safety and health everywhere they are employed, according to Tibbitts. “The degree to which they facilitate, rather than hinder innovation in the plant seems to be the critical issue,” he adds.
And this is where things tend to get bogged down for MOC. The regimen of detailed documentation and approvals that are core to well-managed MOC is exactly where most staff tend to lose patience with the process.
To cut through any unnecessary steps and focus on the MOC aspects that truly need to be front and center, McCarthy says the project should be precisely focused on the basic functionality that needs to be achieved to satisfy all operational requirements, as well as the basic technology required to achieve those objectives.
“Input from operations and engineering are essential to manage scope and change” once these issues have been determined, says McCarthy. “In the project world, the project manager may not be from either of these areas, but would be expected to manage the change process, with support from both operations and engineering.”
As a final thought on ensuring MOC success, Easterly recommends the following two considerations:
- If the MOC process is not digitized (yes, there are many instances where this is still a paper-based process) you should know that it will have less traction in the physical operation; furthermore, if those digitized documents are not integrated with the electronic version of the operation, that also tends to impede adoption.
- MOC changes should be designed from the outset so that they are a seamless part of the production operation, thereby making them the easiest path for staff to follow rather than other alternatives.
