Hazards of the technical solution
During the French Revolution, a doctor, a lawyer, and an engineer were scheduled to be executed. The doctor was taken to the guillotine, saying his last prayers. The blade dropped, and jammed halfway down. After some discussion, the guards and officials decided to let him go. The doctor went away rejoicing, planning to open a clinic for the poor out of gratitude. When the lawyer was taken to the guillotine, again the blade jammed halfway down. He was also set free. He left happily, planning to devote the rest of his career to pro bono work. As the engineer was led to the guillotine he looked up at the device and said, “You know, I think I see what’s wrong with it.”
It rings true, doesn’t it? Engineers and other technical professionals are drawn to problem solving. In itself, that’s a wonderful thing. But like our colleague with his insight into guillotine maintenance, we can get into trouble if we only consider the technical part of a problem.
Finding the technical solution is fun. The problem is clearly defined, control systems offer a plethora of tools, and the proposed solution can be tested and refined. Given enough time, you might build several solutions, using every block in the control system’s library! But splendid as the control system is, it is only part of a much larger and more complex system.
Your beautiful, elegant, nearly perfect solution will be used by other people. Later in its lifecycle it will be maintained or modified by other people. Processes change over time and their controls must change to match. People who don’t understand what your solution does won’t use it. People who don’t understand how it works won’t or can’t maintain it.
Working in harmony with the larger system that includes operators, maintenance personnel, and production managers leads to more robust solutions. Documentation, particularly any notes you can include in the configuration itself, is your ally. It will continue to vouch for you five years down the road, at 2 a.m., when those other people are troubleshooting. Creating your solution using the form of existing configuration standards will also help you. It will make your configuration easier to follow and easier for other people to understand.
The operators are also on your team. If they understand how your solution effectively addresses one of their problems, they’ll use it. The production engineers and leaders will more readily approve implementing your solution if they understand the business benefits.
Implementing robust solutions builds your credibility within the larger system. The rest of the team gains confidence by seeing that your solution led to improved operation. Improved operation yielded better business performance. Better business performance usually means more money for your company—a popular outcome. Positive results will smooth the way for your next brilliant solution to a process problem.
Has anyone fixed any guillotines lately?
This post was written by MayAnn Stroup. MayAnn is a senior engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.