-
Best Practice Management of Change & PSSR Process
Michael Bearrow PE Rolls-Royce plc
[email protected]
Keywords: MOC, process safety code, recommendation, PSSR, best
practice, lesson learned, PSM, RMP, SEMS, OSHA, EPA Management of
Change (MOC) and Pre Start-up Safety Review (PSSR) are still the
most challenging elements of OSHA’s Process Safety Management (PSM)
standard, the EPA’s Risk Management Program (RMP) rule, and now,
the US Department of Interior’s Bureau of Safety and Environmental
Enforcement’s Safety and Environmental Management Systems (SEMS).
Even though the PSM standard has been around since 1992 and the
industry has been managing change for several decades, we still can
get it wrong, sometimes with disastrous results. The mindful or
diligent efforts of many working in concert are necessary to ensure
that change is identified, analyzed and executed in a quality way.
Just when we get it right on paper and get the workforce
up-to-speed, we have employee turnover, neglect and sometimes
regulatory change. New actors and a constantly changing script make
it hard to manage change efficiently and effectively. This paper
discusses how the chemical process industry has defined the MOC and
PSSR best management practices and how they should be automated.
Many high-profile companies have addressed this challenge by
creating and automating standard processes across their
manufacturing or production facilities. MOC and PSSR are two of
these major processes that have been successfully automated.
Technology has been used to automate each step of the MOC workflow,
enabling the collection of change ideas, formalizing the analysis
of the ideas, and documenting the approval and execution of the
change. Reports and dashboards can provide visibility of the health
or current state of your MOC and PSSR processes. The use of
software can enable the standardization of best practices. This
paper discusses how the chemical process industry has defined the
MOC and PSSR best management practices and how they should be
automated.
What is a best practice?
“Best Practice” is an overused buzzword, like so many, and they
are hard to define. Similar terms include Industry Standard, Best
of Breed, Lesson Learned, Core
-
competency, and Customer-centric, Downsizing, Drinking the
Kool-Aid, Eating your own dog food, Granular, Herding cats,
Holistic, Low Hanging Fruit, Mindshare, Mission Critical,
Management Visibility, Pain point, Return on Investment, Seamless,
Touch point, Value-add and Visibility. Fortunately, there is a
working definition of a best practice.
A best practice is a method, process or technique that
consistently shows results superior to those achieved by other
means. It is hard to prove that you have developed a standard
process--like MOC--that enables your company, facility or
organization to achieve repeatable superior performance, but it has
been done.
Some other terms synonymous with best practices are good
operating practice, good agricultural practices, good manufacturing
practice, good laboratory practice, good clinical practice, good
distribution practice, and Recognized And Generally Accepted Good
Engineering Practices (REGAGEP). In the chemical process industry,
the PSM standard relies on REGAGEP to ensure facilities adopt best
practices. REGAGEP is specified in federal statutes from OSHA and
EPA, and is also mentioned in the American Chemistry Council (ACC)
Responsible Care® Process Safety Code.
How do you identify a Best Practice?
Everyone would like to be known as the best practice company.
Even if you did not create the best practice, identifying them and
using them can achieve the same results. If you can tick the box
next to these five requirements, then you may have a best
practice:
1. Gives a company or facility a tangible competitive advantage.
2. Takes advantage of technology. 3. Improves EHS performance,
product quality, and also lowers cost. 4. Gives management more
visibility, control and influence over outcomes. 5. Must be a
working system; i.e. not a theoretical best practice
The benefits of having such a best practice might separate your
company from your competition or keep you from costly business
disruption, fines and/or law suits. Many of the best practices have
common themes, including: ensuring consistency; standardization;
simplifying processes; zero redundancies; leveraging technology and
web-based software solutions; and single source for all data (one
source of truth). It may be difficult for you to prove you have
adopted/created a best practice. However, it is easy to identify a
best practice when a confluence of large and small companies adopt
the same technique or process and are successful.
In the context of this paper, we are focused on best practice
MOC and PSSR automation. Now that we know what a best practice is,
let’s define change and discuss how to manage it.
What is Change & Why Do We Manage it?
http://en.wikipedia.org/wiki/Downsizinghttp://en.wikipedia.org/wiki/Eating_your_own_dogfoodhttp://en.wikipedia.org/wiki/Eating_your_own_dogfoodhttp://en.wikipedia.org/w/index.php?title=Herding_cats_(linguistics)&action=edit&redlink=1http://en.wikipedia.org/wiki/Touchpointhttp://en.wikipedia.org/wiki/Touchpoint
-
“Change” means to transform or cause to be different. In the
chemical process industry, change is omnipresent and required to
stay competitive. William Edwards Deming, a famous American
statistician, professor, author, lecturer and consultant, once
said, “It is not necessary to change. Survival is not mandatory."
In order to survive, a company must learn, change and continuously
improve to survive. Successful change requires you to learn from
your experience and the experience of your peers and make changes
that will improve your competitiveness.
Change is a normal part of business, but uncontrolled or poorly
managed change has resulted in some of the worst disasters in the
chemical process, oil and gas and refining businesses. According to
Ian Sutton, a noted PSM expert, “The root cause of all accidents is
uncontrolled change. Leaving aside sabotage and other malicious
acts, all industrial facilities are designed and operated to be
safe, clean and profitable - yet incidents continue to occur. In
every case, the fundamental cause of the incident is that someone,
somewhere lost control of the operation, i.e., they allowed
operating conditions to deviate beyond their safe range. Hence, the
proper management of change is the foundation of all safety and
accident prevention programs; an effective Management of Change
(MOC) creates an
atmosphere of "no surprises". Whether it is Bhopal, Piper Alpha
or Deepwater Horizon, time after time the difficulty of managing
change confounds some of the most proven processes of the most
successful companies in the world. As a consequence of these
disasters and hundreds more, we have rules, standards, regulations
and laws to help ensure that companies manage change better.
Guidance documents on managing change include the following
sources:
US EPA’s Risk Management Programs for Chemical Accident
Prevention (40 CFR PART 68) or EPA RMP
US OSHA’s Process Safety Management of Highly Hazardous
Chemicals standard (29 CFR OSHA 1910.119) or PSM,
US Department of Interior’s Bureau or Safety and Environmental
Enforcement (BSSE) - 30 CFR Part 250 Subpart S - Safety and
Environmental Management Systems (SEMS),
OHSAS 18001, 2007 revision - ANSI/AIHA Z10-2005.
European Union Law Seveso II Directive (see Annex III of EU
Council Directive 96/82/EC).
API-691 - Risk Based Machinery Management (RBMM) (in
development)
What kinds of change are there?
All ideas for improvement require change. No one ever suggests
that we should do exactly what we are doing today, tomorrow. This
fact is lost on a segment of the chemical process industry who does
not think of recommendations as changes. Recommendations should be
treated as “in-kind” changes because they are. They do not have to
follow a formal and rigorous MOC and PSSR process, but they are
certainly recommendation for change.
-
All change can be separated into three categories: corrective
actions; preventive actions; and continuous improvements.
Corrective actions are meant to fix something that is broken, or at
least to improve efficiency and functionality. These ideas for
change originate from accident investigations, incidents and
negative operating experiences. Preventive actions can also come
from incidents, but are more commonly created from near misses,
safety observations, audits, hazard reviews, inspections, emergency
response critiques, and/or general surveillance or observations.
These ideas for change help ensure that we address upstream issues
or causes before a negative outcome (incident, fine, loss) results.
The final kind of change is continuous improvement. These are
generally ideas for increasing production, reducing manufacturing
costs or increasing product quality. No matter what kinds of
changes you have, they all should be managed. No matter how good an
idea is, it must be analyzed for impact (positive and negative) and
executed expertly. Ideas can also be rejected or denied if the risk
or cost of implementation exceeds the benefits or value of the
change. If the change affects the design and/or operation of a
facility, it is likely going to require formal change management or
MOC. The diagram below illustrates three kinds of change in the
idea universe.
Figure 1.0 – The Idea Universe
OSHA’S Two Categories of Change The common way to refer to an
idea that requires formal change management as defined by OSHA PSM
or EPA RMP is an MOC or Management of Change (Not in Kind). MOCs
are managed for changes to equipment, materials, technology,
personnel,
-
processes, procedures or anything that deviates from the
original design, processes, operating procedures, or maintenance
program. In the chemical process industry, we refer to two
categories of change. These are “Replacement In-Kind” and
“Replacement Not In-Kind”. These odd-sounding categories can have
ambiguous meanings, but are explained by Ian Sutton, a noted
process management expert, as follows: “If an equipment item is to
be replaced with one that is functionally identical, i.e., if the
new item is built to the same
specification as the old one, then the change is "in-kind".
Otherwise it is "not-in-kind", and the MOC process has to be
followed before the change can be implemented.” … The most
challenging aspect of managing change is identifying that the
proposed modification is in fact a change.
1. Management of Change is needed if the change is Not-In-Kind.
2. A Not-In-Kind change is one where Management of Change is
needed.
In other words, the terms "Management of Change" and
"Not-in-Kind" tend to be defined in terms of one another. The
second difficulty to do with the In-Kind/Not-In-Kind decision,
noted above, is that all changes are, when analyzed deeply enough,
not-in-kind.” What is the role of PSSR in the MOC process?
Pre-Startup Safety Review, or PSSR, is not actually part of the
MOC process per se. It is intended to be a redundant check or
review to ensure that an MOC has been implemented in a quality and
safe manner. The PSM standard states:
The employer shall perform a pre-startup safety review for new
facilities and for modified facilities when the modification is
significant enough to require a change in the process safety
information. Process safety information includes all information
about the process. That covers about everything. The pre-startup
safety review shall confirm that prior to the introduction of
highly hazardous chemicals to a process:
Construction and equipment is in accordance with design
specifications;
Safety, operating, maintenance, and emergency procedures are in
place and are adequate;
For new facilities, a process hazard analysis has been performed
and recommendations have been resolved or implemented before
startup; and modified facilities meet the requirements contained in
management of change, paragraph (l);
Training of each employee involved in operating a process has
been completed.
When is Management of Change (MOC) Required?
-
OSHA requires the employer to establish and implement written
procedures to manage changes (except for "replacements in kind") to
process chemicals, technology, equipment, and procedures, as well
as changes to facilities that affect a covered process. The MOC
procedures shall assure that the following considerations are
addressed prior to any change:
The technical basis for the proposed change;
Impact of change on safety and health;
Modifications to operating procedures;
Necessary time period for the change;
Authorization requirements for the proposed change;
Employees involved in operating a process and maintenance and
contract employees whose job tasks will be affected by a change in
the process shall be informed of, and trained in, the change prior
to start-up of the process or affected part of the process;
Updates to process safety information and operating
procedures.
The industry has been practicing process safety for over 20
years. The definition of MOC and PSSR are well understood. Some
companies have developed great procedures for addressing both of
these elements in an integrated fashion using Internet-based web
applications and powerful database engines. These software systems
simplify the complex MOC process and enable standardization,
ensuring a higher level rigor which is difficult to impose with
paper-based execution. While the best practices for MOC and PSSR
work practices continue to evolve, the following sections reveal
what is currently accepted as best practice.
Best Practice MOC Part 1 – Collecting Change Ideas from the Idea
Generators As established above, continuous improvement is
impossible without implementing change ideas that can come from
anywhere. The problem is how can organizations empower their
workforce to initiate ideas, capture and evaluate them then act on
the ones that will improve the business? Can you imagine how
successful your business would be if you could leverage all of the
grey matter at your disposal to solve production problems? In order
to efficiently and effectively capture these ideas, we need to
leverage technology. Using Internet–based software can make it easy
for ideas to be collected at the source. The easier we make it for
staff members to pass on their ideas, the more of these ideas we
will receive with time to act on them. One best practice that has
surfaced to address this need is to design an electronic suggestion
or idea box. Web-based quick entry screens can be accessed using a
browser on any company computer to easily suggest a change or
improvement. Once these ideas are entered, they are automatically
communicated to idea reviewers (supervisors) for vetting,
categorization (in-kind or not in-kind) and prioritization. No
matter what happens to these ideas, the reviewer must provide
feedback to the idea initiators on what happened to their ideas.
If
-
an idea results in tangible savings or competitive advantage, a
tangible reward will serve to prime the idea generator for the
future.
You can visualize the best practice MOC process using a series
of funnels (below). Changes begin as ideas and they can be entered
by anyone in the company into a single quick entry screen and
collected in the main funnel. The supervisor is automatically
notified that a new idea has been entered for their unit or area.
Each idea is meticulously reviewed and categorized as a
recommendation or a MOC. Using electronic submission, this
centralized collection funneling system is infinitely more
efficient and effective than word-of-mouth, a paper system and/or
multiple systems that collect and manage ideas. One common system
for collecting, vetting, prioritizing and categorizing ideas is a
best practice.
Figure 2.0 – Ideal Idea Funnel
Best Practice MOC Part 2 – Managing the Recommendations (In-Kind
Change) Recommendations can come from audits, incidents, risk
assessments, process hazard analysis, emergency response critiques,
inspections, reviews, and surveillances. These recommendations are
generally ideas for continuous improvement aimed at improving
safety, environmental performance, quality or efficiency.
Automating and standardizing the recommendation management process
makes it repeatable, measurable and more readily understood.
Utilizing software that illustrates the correct process and
visually
-
progresses users through the workflow is key to the acceptance
and the eventual success of the MOC program. Once the idea has been
reviewed, assigned and categorized as a recommendation, or in-kind
change, a simple workflow can be leveraged to ensure the idea is
addressed in an efficient manner. A simple database can be used to
document the steps in this process, but a best practice is to use
software that illustrates the work process on screen as it is
executed. The use of a visual workflow to navigate from step to
step, showing progress with check marks or color-coding and
enabling steps only when precursors (predecessor steps) are
satisfied is a best practice. In addition, email notifications
should be used to alert persons assigned to manage, approve and
execute actions along the workflow. The more proactive the
communication and visual the workflow is, the more intuitive it is
to the end-user. The workflow presented below is used for hundreds
of thousands of recommendations per year. The entire work process
is automated from beginning to end.
Figure 3.0 – In-Kind Change
The workflow begins in the proposal step or in the “idea
generator’s” mind. The recommendation proposal must contain a
title, a description (what needs to be done), a justification (why
it is important) and a deadline (when it needs to be done) for
getting this idea accomplished and a responsible person (RP). The
reviewers of the proposal will ensure the accuracy and the
resources are available to address the idea. The next step is to
accept the idea into the system and automatically notify the RP.
The acceptance is illustrated by a check or tick mark in the
proposal icon. After a review of the recommendation, the RP moves
to the Approval step. It is in this step that they must decide
whether to approve the idea, refute the idea, close the idea
-
as an acceptable risk or decide it needs to be treated as an
MOC. Approval of the idea will enable the creation of action items.
Refuting a recommendation or addressing it as an acceptable risk
should require proof or explanation. These comments must be
documented for future reporting and analysis and automatically
communicated to the idea generator. Best Practice MOC Part 3 –
Managing MOCs (Not In-Kind Change) If the idea needs to be managed
as a “Not in-Kind” change or MOC, a more complex workflow is
required. Similar to the “In-Kind” change, it still requires a
proposal, acceptance and assignment to a RP, but additionally will
need a formal hazard review and planning. In almost all cases, a
MOC also requires the pre-startup safety review (PSSR) step, a
Startup Approval step and some post startup steps. Because of its
complexity and the need to enforce a rigorous process, a “live”
workflow showing what steps are necessary, which ones have been
accomplished and which ones are left to do is essential. The
workflow below is considered the best practice MOC and PSSR. There
are no steps left out and no superfluous steps either.
Figure 4.0 - Not In-Kind Change (Front End)
After the acceptance of the idea into the system, the RP
receives a notification that they have been assigned a MOC to
manage. The next step in the workflow is to “Evaluate” the MOC.
This evaluation process is meant to ensure that the hazards of the
change are reviewed, understood and mitigated, or at least a plan
for mitigation is created. It is also meant to reveal the process
safety information that will be affected and the training that will
be necessary. Of vital importance is the creation of an action plan
to make sure hazards are addressed and that appropriate training is
done and all process safety information is completed. Just
identifying the need falls very short of hitting the target.
-
In fact, if you identify the need for action and then do not
follow through, you have created the proverbial “smoking gun” and a
red flag for auditors.
A smart checklist of questions should be presented to the RP in
this step which are based on the category of the change. This
eliminates the need to answer questions that have nothing to do
with the change. Automation gives you the ability to tailor the
evaluation process so that it is more effective and efficient to
use. Asking evaluation questions unrelated to the change is very
inefficient and can also make finding the right questions
difficult. Even more automation can be leveraged to pre-assign
reviewers to questions that only they should be answering and
configuring automatic/predictable actions with associated
questions. Here in this step we can make the comments and closure
of all questions mandatory for moving to the next step. Until all
questions are closed, we cannot move to the next step, the Approval
step.
The Approval (to implement) step can be done by a person or
groups of people. Their job is to look back at the MOC proposal,
review the evaluation that was undertaken and judge whether it was
done effectively by the right people. They should also take notice
of the mitigating actions that resulted from that review. If more
evaluation is required, the reviewer can loop back in the process
and create more evaluation questions to satisfy. They should also
ensure that actions have been tagged appropriately as pre- or
post-startup. If the resulting actions or time have otherwise made
this MOC a bad idea to execute, the MOC can be denied at this point
with closure comments. Those comments are sent to the idea
generator and should be documented in the system. If they are
satisfied, then approval can be selected and we can begin
implementing the MOC.
The MOC Action Step
Now the real work begins--updating procedures, marking up
drawings, making sure all affected personnel are trained, writing
work orders, getting an environmental permit, and all of the other
actions required for completion to do a quality job. Once all
actions (pre-startup) are completed, then you get a check mark over
the action icon and we move on to the PSSR step.
-
Figure 5.0 - Not In-Kind Change (backend)
The PSSR Step
As previously stated, the PSSR is a redundant check to ensure
the MOC has been properly executed. Like the Evaluation step, once
we have chosen a category of change, automation can be used to
ensure that the appropriate PSSR checklists/questions are presented
to the RP. This increases the efficiency and effectiveness of this
step as well. Once the PSSR is completed, we receive our check mark
in that workflow step, and an automatic email is sent to the
appropriate manager asking for permission to Startup (Startup
Approval).
Startup approval is the formal acceptance of the change and the
acceptance of the risk associated with it by operations or
production. The person who completes this step should review all of
the previous work steps in the workflow as well as physically
review the work in the field.
The last two steps in the MOC workflow are closure items and
post-startup actions. Although these are not referred to in any of
the governing regulations, there will be non-safety related
activities that are not required to be completed by startup and
still need to be managed. This best practice will ensure these
actions are accomplished and documented. Past Due email
notifications are sent appropriately if the MOC becomes past
due.
There are some distinct advantages to adopting the best practice
MOC and PSRRs workflows discussed herein. As the best practice
evolves, so must the users of the technology. Refresher training,
upgrades and constant tuning and tweaking of the workflow are all
part of continuous improvement of an MOC and PSSR program. This
minimal investment is a small price to pay to avoid poorly managed
changes or the opportunity cost of not collecting ideas from your
idea generators.
-
How does Automation help?
Automation of the MOC and PSSR process helps in several ways.
First, we can collect ideas at the source of the risk, whether it
is the plant or on the platform. This is where the risk is and
where continuous improvement is accomplished. Furthermore, it is
also where most of the practical/achievable ideas for continuous
improvement come from. The best practices must be useful and used
where the money is made. Technology makes that possible.
Today’s technology is perfectly suited for collecting, analyzing
and sharing ideas. Accomplishing these actions without automation
is nearly impossible. The days of paper-based MOCs are almost
non-existent because automation makes these tasks more efficient
and effective as well as less likely to be overlooked.
Reporting metrics and automatic alerts when MOC and PSSR actions
are assigned, closed and past due ensure diligence and
accountability. Technology can spread the news quickly to those who
can create and execute a plan of action and do something with new
ideas. Morse code, paper reports and snail mail do not get the job
done like email communication and automatic reminders.
A central corrective and preventive action tracking software can
help ensure that identified issues are dealt with in a safe and
timely manner. Idea or recommendation management and action
tracking can be accomplished with one database engine worldwide.
That means one system to learn, maintain and continuously improve.
It also means you have one global change management system to get
things done, communicated and for generating reports. Managers can
get the visibility they need to measure performance without
bothering the people making the money.
An automated best practice MOC and PSSR system helps ensure that
once you get it “right”, you keep it “right”. It also makes sure
that change is appropriately identified, evaluated, approved and
executed. It also makes poor change management easy to identify and
correct through management surveillance.
Automation is not the goal; best practice is. Like reporting and
management visibility and lots of other byproducts of this best
practice, the goal is managing change efficiently and
effectively.
-
Words of Caution A cardinal sin of MOC & PSSR process
automation is using a finance or maintenance technology that you
already have to automate your best practice, because you already
have it. This will sub-optimize a best practice faster than
anything you can do, and it will likely defeat the purpose of the
automation. Remember that 95% of your users are engineers,
operators and managers--not accountants, IT “geeks” or maintenance
planners. And finally, you can develop your own best practice MOC
and PSSR, but to be successful as best practice software, you must
have a full-time MOC best practice expert leading the development.
Otherwise there will be several months of trial and error. Make no
mistake; software development is difficult enough with unlimited
resources, expert developers and patient end users. You cannot
automate a business process you do not understand. Remember that
managing change is a complicated management system for operations
or production personnel. You cannot write a requirements document
so thoroughly and clearly that a software development team can
automate your MOC best practice workflow without constant oversight
from the MOC experts.