Vous êtes sur la page 1sur 12

(http://www.reliableplant.

com/Read/25905/misperceptions-management-
change)

Eight common misperceptions of


management of change
Sam McNair (/Authors/Detail/963)
Tags: maintenance and reliability (/Meta/Tags/maintenance and reliability),
business management (/Meta/Tags/business management), talent
management (/Meta/Tags/talent management), workplace safety
(/Meta/Tags/workplace safety)
Whenever I mention management of change to plant personnel, I generally
get one of several predictable responses. The knowledgeable ones will cite
the regulation OSHA 1910.119(a)(2) and tell me that they aren’t a “covered
process”, so it does not apply to them – generally with a great sigh of relief.
Another frequent response is: “We have a drawing management procedure,
but we are so far behind it would take years and resources we don’t have to
catch up.” Others still will tell me that they have a perfectly fine procedure
for their managers to approve small projects and alterations. And, a few will
sheepishly think about the pennies and nickels filling up their car’s ash tray.

So, what is management of change (MOC)? Going back to the source,


OSHA 1910.119(l)(1) sets the requirements for MOC as: “The employer
shall establish and implement written procedures to manage changes
(except for “replacements in kind”) to process chemicals, technology,
equipment and procedures; and, changes to facilities that affect a covered
process.”
That short description covers much territory, but since it was promulgated
solely to enhance process safety, it limits the legal applicability to “covered
processes”. Readers whose facilities meet the OSHA requirements of a
“covered process” are well aware of the detailed requirements of MOC.
They have to be or they would not still be operating. And hopefully all of you
know that many of the worst industrial accidents in recent history have as a
root cause the failure of the MOC process. Some sources indicate that as
many as 80 percent of the serious major accidents in industry are related to
uncontrolled change. Thus, one can think of MOC as a sort of life insurance
that pays off by preventing accidents.

But this article is not focused on the intricacies of MOC for covered
processes. And, it is not solely directed toward safety. Why then are we
discussing MOC if it is not “required” for your industry? In short, it is
because every business, regardless of legal requirements, needs to control
potential losses. And MOC, appropriately applied, is an excellent, cost-
effective loss prevention process for almost any business. It is the perfect
complementary process to your loss elimination processes. And, we all
want to be safe and environmentally friendly as well, right?
Please note that MOC addresses only changes to things presently existing.
Design of new processes or facilities is another issue entirely. And, we have
to assume for purposes of MOC discussion that the level of performance of
the existing system, if not adequate, at least has familiar and well-known
virtues and vices.
So, what is MOC in non-regulatory terms, and who does it really apply to?
Let’s work with this simple definition: MOC is a process for preventing or
mitigating business losses – including degradation of safety, health or
environment – as the result of changes made to how you construct,
operate, manage, or repair your facility or your processes. Regulatory
requirements aside, there is no business intending to stay competitive that
can afford to not have an appropriate MOC process in place. In short, MOC
makes sense for safety and it makes financial sense. Does an MOC
process make sense for your business?
What is a ‘change’?
“The most difficult part of management of change is recognizing change.”
The most important starting point for the program is clearly defining for the
organization just what constitutes a “change” that you wish to manage. Or
more simply, what change falls under the MOC process and what sort of
changes do not? A lack of clear definition effectively cripples an MOC
program’s effectiveness, inviting both unnecessary analysis paralysis and
creating loopholes for those who wish to bypass the process.
There are many definitions of change from many different sources. It is the
responsibility of the site leadership to define change in terms consistent
with the business interests and any regulatory precedents. What risks do
you wish to control and what sorts of changes, if not controlled, increase
those risks? Only then can those activities that might reasonably be defined
as “changes” be clearly identified, and once identified must be conveyed in
the most simple and straightforward language possible.
Although a bit messy, the use of lists or tables of examples is often
necessary to get the points across. Keep in mind that a “change” does not
have to occur in a piece of hardware to qualify. Software, procedures,and
process parameters are all examples of non-hardware changes that often
must be rigorously controlled.
When dealing with hardware, the OSHA 1910 source document refers
obliquely to a change as not being a “Replacement in Kind” (RIK) and
further defining RIK as “a replacement which satisfies the design
specifications.” RIK generally refers to equipment or components that are
identical in Form, Fit and Function (referred to as the F3). But there is more
to change than this very narrow hardware-based approach. The OSHA
definition of change also refers to technology, procedures and chemicals
(more broadly interpreted as raw materials.) Obviously more than just
hardware is included in the definition of “change”. I have found that the best
formal definition in use for “change” in the MOC process is found in a
clarification published in OSHA 3313: “Change is an alteration or
adjustment to any component, variable or property within an existing
system (except those within clearly defined boundaries or responsibilities).”
Since every business has different areas of risk exposure and different
tolerance of undesired consequences, it is up to each business to assess
risk and define its tolerance for uncontrolled change. A few (but by no
means all inclusive) examples of the sorts of changes a business may wish
to manage are:
• Addition of new process equipment or critical business system
(including software)
• “Not in kind” replacement of process equipment or parts
• Modifications or minor additions to process equipment
• Modifications or minor additions to critical business system (procedural
or software)
• Modifications or minor additions to infrastructure/non-process
equipment
• Changes to process control and/or instrumentation (includes control
strategies)
• Changes in specifications or sourcing of technical MRO
• Changes in critical process parameter operating limits (outside of
ranges specified in standard operating procedures [SOPs])
• Alterations to safety systems (interlocks, shutdowns, fire or explosion
suppression, etc.)
• Revisions to standard operating procedures (including emergency
procedures)
• Changes in site-level organizational structure
• Changes to maintenance procedures
• Changes in raw material/component specifications or sourcing
• Alterations or new connections to utilities systems (air, electrical, gas,
water, steam, etc.).
• Alterations or new connections to critical data networks
• Changes to QA procedures or critical test equipment
A few hours of quality “what if” brainstorming by a multi-disciplinary team
early in the process design to develop the definitions and examples that are
right for your business will pay huge dividends.
What about ‘temporary’ changes?
Remember this important concept to apply when implementing MOC: Just
as there is nothing in the world as permanent as a temporary tax, there is
no more permanent a change than a “temporary change” which escaped
the MOC process. Experience shows that there are really only permanent
changes that are intended to be temporary until they have been restored to
original conditions. Of all of the uncontrolled changes that occur,
“temporary” changes are the most pernicious and the most frequent cause
of accidents and incidents. Thus, “temporary” changes of a controlled
system never should be exempted from the MOC process.

So, what do I do to deal with temporary changes that must be made to


perform routine business, such as an interlock bypass to perform periodic
maintenance? If it is truly routine, then what you have is a permanent state
of a periodic deviation from the SOP. And the right way to deal with that is
to treat the situation as a permanent change, incorporating it into approved
procedures with appropriate safeguards. If something is intended as a non-
routine temporary change, treat it as a change. OSHA 3133 in a clarification
says: “MOC procedure should ensure that equipment and procedures are
returned to their original conditions at the end of a temporary change.”
History and prudence would suggest that “temporary” changes should be
managed as “permanent” with special attention to the MOC procedure
because they present the highest risk to your business.
Eight Common Misconceptions of MOC
1) “But I am not making a real modification. I am just making it a little
better.”
If you are not leaving the part/equipment/business system exactly the way
that it was prior to starting the work (absent, of course, any damage that
was the object of the repair), then you have made a change. Whether or not
the change is one that falls under the scope of your MOC process is
determined by the criteria set in your procedures. The default approach to
take is to assume that any change in configuration, form, fit, function,
materials or procedure is covered under MOC until an examination of the
criteria in the procedure proves otherwise.

Second to uncontrolled “temporary changes”, well-intentioned minor


improvements rank as the next largest cause of incidents that fall under the
failure-of-MOC category. Without a thorough evaluation of the total
operating context and environment, who is to say that “better” in one way is
not really much, much worse in another? The same drug given to one
patient can be a powerful cure; to another, it may be a deadly poison. The
same applies to well-intentioned but uncontrolled minor “improvements”,
especially materials substitutions which are particularly risky. Teach your
personnel at all levels to be aware of and avoid this common pitfall and then
enforce it strictly. No one likes to discipline people for breaking the rules,
especially when they do it the spirit of improvement. But, it is infinitely worse
to have to tell a family that someone won’t be coming home tonight.

2) “I am so far behind I can’t start doing MOC. I’ll never catch up with
all of those unrevised drawings.”
Document control is a process that complements a well-designed MOC
process, and is often the first thing people think of when you mention MOC.
The need to update documents is certainly a frequent outcome of an MOC
and necessary for the long-term integrity of your processes and facilities,
but it is not MOC. It is merely a frequent outcome.

Often when implementing MOC with a document control process, you


inherit quite a mess from those who preceded you: no drawings, inaccurate
drawings, out-of-date documents ... you name it. If the situation is dire, you
may be forced to prioritize your corrective actions – if any are based on the
criticality of the systems. Some may not need to be and will never get
corrected. Certainly a method to correct vital information when it is
discovered can and should be easily incorporated into your work control
procedures. But do not add to the task by continuing bad habits.

You cannot change what has happened in the past. If the business case
exists to correct or mitigate past mistakes, then do so. MOC is about future
loss prevention. So the one thing that any organization can do is to start
implementing MOC right now. Today is the day to stop creating more
problems for tomorrow. A succinct piece of folk wisdom says: “If you have
to fill in a real big hole, the first thing to do is to stop digging it deeper.” The
same applies to a gap created by poor MOC. Stop making it bigger.

3) “I don’t have time to wait for the MOC evaluation. This is an


emergency!”
During an emergency is precisely when the self discipline imposed by a
well-established MOC process is most necessary. When an airliner has an
in-flight problem, the pilots don’t do the first thing that comes to mind.
Rather they pull out the checklist and they think, then they act. When there
is an “emergency”, so should you. Is this “minor modification” to allow a
substitution really going to save that much downtime compared to getting
the correct part? Minor changes often take much more time than expected.

Be realistic in your evaluation of how long, how much money and how much
risk increase this “fast work around” will really take. It is good to be
optimistic in an emergency. It is best to be prepared for the worst. As the
saying goes: “If you are in a leaky boat far out to sea, it is best to pray
toward Heaven, but to row toward shore.” Is the risk to your business
associated with a “temporary” bypass worth the savings in time? Can you
really control the risk to an acceptable level by “special operating
procedures”?

Accident reports show that hasty decisions, made under pressure, without a
balanced evaluation, have been at the root of many serious problems. Time
to think in a disciplined manner is not time wasted. And if your MOC
process is efficient, it will not unduly impede progress on the rare occasion
when it is a true emergency. Just as there is a procedure to authorize and
issue an emergency work order when needed, a good MOC procedure will
have a mechanism to address real emergencies. But that mechanism
should not be to ignore the MOC. Do not allow expediency during one
“emergency” to set you up for a bigger and more serious second
emergency. Do not defuse a bomb just to plant a landmine.

Are you experiencing frequent failures that require a work-around to deal


with, constantly having to make midnight parts substitutions to recover from
an unexpected failure, or constant process alterations to accommodate
unstable components or raw materials? Then, your challenge is not to
ignore MOC or to design an MOC process that supports anarchy. Rather,
you should focus your efforts on eliminating these situations by
implementing an effective root cause failure analysis (RCFA) process and
preventive maintenance/predictive maintenance programs to eliminate the
chronic failures. Next, focus on correcting the deficiencies in your MRO
processes to ensure you always have the right parts. And, finally, you
should be stabilizing your process with standard work procedures and
materials supplier qualification programs.

4) “Routing this form for approval takes so long we can never get
anything done.”
An effective MOC process requires an appropriate level of approval and
communication. Poorly designed MOC approval procedures confuse the
need to be informed of a change after it happens with the need to approve
a change before it happens. The levels of approval required need to be
both appropriate to the change and the potential risk associated with it.
They also need to be flexible enough so that they can be tailored to the
situation at hand. Minimize the number of approvers, and make them the
right ones. Your MOC process can then be safely streamlined.

5) “But my area manager already has to approve funds for changes.”


Do not confuse the authority to make a decision with possession of the
knowledge necessary to make that decision. Not all changes, and often the
most critical ones, even pass through funding approval. Often, the persons
most competent to evaluate the risk of making a change or the technical
validity of a change are not the area manager but the operators, mechanics,
supervisors or engineers most familiar with it.

Even if the manager is very competent, it’s rare for one person to be
competent in all aspects or consequences of a given change. In an effective
MOC process, it is the manager’s responsibility to ensure that the
appropriate designated resources are involved in a well-balanced
evaluation of the proposed change. Approval authority is secondary to
competence to evaluate and a well-balanced team will give more
consistently good results than depending upon one smart individual.

6) “We are a warehouse / light manufacturing / data center / repair


facility. … We don’t have anything that could be dangerous.”
Remember, MOC is a process for preventing or mitigating all potential self-
inflicted business losses associated with a change. There are other losses
besides just process safety. It is a loss if an uncontrolled process change
causes you to lose a valued customer because of contaminated or faulty
product. It is a loss if your data center is down and troubleshooting takes
several hours instead of minutes because electrical drawings have not kept
up with changes. It is a loss if the automatic stacker is down and you can’t
ship product because a midnight part substitution requiring a “small
modification” caused the only replacement part you have in stock to no
longer fit. It is a loss if an undocumented modification to the control
software causes your automatic testing machine to fail when the latest
security patch is installed. All of these are real examples, and the list is
endless. Even though the potential for changes to create dangerous
situations in your environment are small, we all have something to lose
when our facility or processes fail in their primary missions.

7) “But MOC won’t catch every possible problem, so why do it?”


You are absolutely right. Despite your best efforts, some problems will slip
by undetected. But how many will slip by if you don’t do MOC? Risk
management is all about changing the odds to be more in your favor. This
argument does not hold water – no more than the argument some people
use against air bags: “They might deploy and cause an accident, so I turn
them off.” The statistics just don’t support that line of thinking any more than
they support not having MOC.
So, what if you miss an unintended consequence? A valuable additional
benefit of MOC in complex systems is when doing an RCFA. If there are
adverse consequences from a change and the cause is not immediately
discernable, the RCFA goes much quicker if you have a list of all of the
deliberate changes that have been made. And that time can be real money.
In one case, researching MOC records cut weeks off of the time necessary
to find the root cause of a string of process plant failures. At $250,000 per
day in avoided downtime losses, the MOC effort had quite a good return on
investment even though it did not prevent the problem.
8) “This is just a software/procedure change. It’s not like we were
changing a pipe or something. We don’t need to approve or
document.”
Some extremely serious incidents and severe losses have occurred in a
number of industries because of software or procedure changes that were
not subject to MOC. Furthermore, just because a document or code has
been altered and reflects the change does not mean that the change is
documented. I know that comments in the code and revision flags in the
document allow the searcher to look for changes. But when unexpected
problems occur because the software or procedure change was not
adequately reviewed, then what good is it?

Have you had a production line down while you searched desperately
though thousand of lines of code looking for the change that was made by
the control engineer two months before he left for another job?
Programmers and control engineers in particular tend to “play around” with
software without due regard for MOC. This applies not only to your process
control but to your critical business systems software as well. If the potential
risk exists and justifies it, then treat changing a line of code no differently
than rewiring a safety shut-down system; it should receive the same level of
scrutiny and control.
Conclusion
In conclusion, a well-designed MOC process is an essential loss prevention
tool for any business. It is not just for certain hazardous industries. The
process applies to any company that wishes to avoid future losses resulting
from today’s changes. MOC does not have to be overwhelming or so
difficult to use that it inhibits change. It cannot effortlessly compensate for
past omissions, only reduce your future risk. So, the time to start developing
and implementing an effective and efficient MOC process is today.
This article first appeared in the July edition of Life Cycle Engineering’s
newsletter, RxToday.
About the author:
Sam McNair is a senior consultant with Life Cycle Engineering (LCE). A
Professional Engineer and Certified Maintenance and Reliability
Professional, Sam has more than 32 years of experience in discrete
manufacturing, chemical process industries, mining, machine processes,
automation, aviation, construction and utilities. Sam specializes in reliability
engineering with a focus on the integration of maintenance and
manufacturing functions. You can reach Sam at smcnair@LCE.com
(mailto:smcnair@lce.com). For more information about Life Cycle
Engineering, visit www.LCE.com (http://www.lce.com/).

Vous aimerez peut-être aussi