Engineers face unique problems when it comes to making changes to equipment on the manufacturing floor. Not only are there large (and expensive) components which have to be precisely installed and tested, but from a programming perspective, engineers also have to manage the PLC (Programmable Logic Controller). The PLC, like source code, contains the specific instructions which make the machinery on the plant floor do work. The PLC is the software behind he hardware.

Priorities on the Plant Floor

In my experience, the major difference between typical software changes and changes made in the manufacturing environment is that manufacturing changes manifest themselves in physical ways (rather than virtual). That means that an engineer spends a lot more time making sure the nuts and bolts of a specific component are installed correctly than following a defined change management process. Given the “hands on” nature of changes in the manufacturing environment there are a few considerations:

1. Changes to manufacturing equipment or plant processes are difficult to test in a “test” environment. Often changes in the PLC are tested physically on a trial and error basis. (You can’t really have a test plant sitting around.)
2. It is not uncommon for the PLC to “live” on one computer on the plant floor or in the engineer’s office. Sometimes without backup, without a test environment, and with a single shared account.
3. At many facilities there are only one or two engineers capable of programming the PLC. This fact can make standard change management practices difficult to enforce or too timely to implement.
4. The Infrastructure and technology (servers, support staff, etc.) to implement typical change management solutions may not exist on the plant floor.

Change Management Risk on the Plant Floor

There are good reasons plant engineers do not implement effective change management procedures (see above), but it is important to understand and balance operations concerns with business risks. Here are a few questions consultants and engineers should consider when framing a change management program.

1. Plant Downtime, Revenue Loss: If the PLC goes down does this stop production? What is the impact on revenue?
2. Physical Danger: Does the PLC control pressure valves of fire suppression systems? Can malicious or mismanaged changes result in physical harm?
3. Product Quality: Can changes to the PLC result in poor product quality? This may lead to customer dissatisfaction, product returns, and reputation damage.

Four Suggestions for Effective Change Management of the Manufacturing Environment

Given both the resource struggles and related risks on the plant floor there are still quite a few things engineers and IT management can implement to manage risks around change management. Here are a few suggestions that are almost universally acceptable:

1. Back-up the PLC prior to making changes: Backing up the PLC prior to making changes in production creates a restoration point. I have had conversations with engineers who made changes directly in production, corrupted their program, and had to start over. This can halt product production and mean loss of revenue.
2. Regular Maintenance vs Major Changes: Given limited resources all changes shouldn’t necessarily be treated equally. For example, changing the speed of a conveyor belt may not be treated the same as implementing a totally new component. Understanding when it is appropriate to dedicated additional resources to sound change management and when it may be appropriate to make changes on the fly is vital to efficient operations.
3. Testing and QA: It can be a struggle to test manufacturing processes outside of the production environment, but simple peer reviews of source code and process logic can reduce the risk of errors. These reviews should be formalized, documented, and reviewed by the plant manager.
4. Change Documentation: Doers hate documentation, but data is vital to tracking trends and progress. Changes should be documented and stored in a centralized repository.