MOC for Plant Control Systems
Management of change (MOC) can apply to nearly anything from organizations to projects to IT infrastructure. But does it apply to plant control systems? Considering that control systems need to change over time – process optimization drives changes in control logic and software updates occur on at least a monthly basis ??? the answer is: MOC is essential for plant control systems.
You will make at least a handful of changes to your control systems on a monthly basis. It pays to approach these changes in a consistent manner. After all, if your SCADA system fails, your operators find themselves flying blind, without a means to control the system. If your PLC or DCS fails, plant production will come to a screeching halt.
Most plants have some form of MOC process. But not every plant???s process is well-reasoned and documented ??? or effective. Processes range from simply ???asking Joe, the Sr. Technician, if it???s OK to make that change??? to a full-blown, 50-step process that takes days to complete. So the question becomes, what is right for my plant?
Here???s some advice:
Have a documented MOC process and follow it religiously
No matter if it???s three steps or 50, have a documented process and follow it every time. Without one, you???ll be relying on the tribal knowledge of your employees for the system to run smoothly. With 40 percent of today???s control systems workforce facing retirement, it pays to document processes.
Allow for emergency changes
The goal is to keep the plant running and to keep employees safe. If it???s broken and jeopardizing production or safety, it requires immediate attention. Encourage first responders to use their best judgment to fix problems.
If it???s not an emergency, take the time to plan it properly
Take advantage of the time that you have to plan. A plant manager recently told me, ???The hardest problems to stomach are those that are self-inflicted.??? Control system problems don???t typically surface while the plant has been running smoothly. More often than not, they happen while someone is making changes.
Analyze your stakeholders
Determine who could be affected by the change. Involve them in the process. Determine who needs to approve and who should just be informed.
Determine potential impact of the change
Define what technologies and process areas the change could affect. If you don???t have the knowledge to personally assess each, find subject matter experts (SMEs) to help with assessment and approval.
Obtain approval from key SME???s and stakeholders
Make sure that you get approval. Passive approval doesn???t count, e.g., “I sent him an email and never heard back, I guess it???s OK.??? Get confirmation from those who could be affected before proceeding.
Minimize impact through scheduling
Engage Production to determine the best timeframe to make the change. If there is an upcoming planned shutdown or changeover, it may make sense wait until then rather than risking unplanned downtime by making it now.
Minimize impact through execution method
Test changes on a bench before deploying them to the production environment. If you don???t have a test system, first apply it to a low-risk area before wholesale deployment.
Verify that the change was successful
Determine your criteria for success. Lack of negative feedback does not constitute positive feedback. i.e., just because production isn???t complaining about a problem doesn???t mean that there isn???t one. Take the time to check in with them and confirm sustained success.
Don???t let your MOC software drive your processes
If you???re reading this blog, you???re likely to have an automation background and are thinking ???there???s an app for that.??? True, there are MOC software packages on the market today. But be cautious in choosing one that allows you to use your own processes; don???t change your processes to fit the software.
