Zibb
Subscribe to Control Engineering
FirstLight
Standard profits: Make2Pack and ISA88   


Link This | Email this | Blog This | Comments (1)


We need to protect stupid people from doing dumb things
January 16, 2008

I’ve heard the statement, “We need to protect stupid people from doing dumb things,” more than once from automation engineers as they design and implement very complex solutions for manufacturing needs. These automation engineers are often supported in this sentiment by the mechanical and process engineers who select the physical devices that make up a manufacturing process or machine and specify how they should be used in the manufacturing environment.

This leads to manufacturing solutions that are difficult to use and costly to keep running. The ISA88 Part 5 Make2Pack effort will provide guidance for solutions that are much more useable by operations, which will lead to reduced cost of every aspect involved in delivering manufacturing solutions. ( ISA88 Part 5 drafts in progress are here. Related Make2Pack supporting materials are here.)

Don't touch my tools: Another statement that I’ve often heard from automaton engineers is that the tools used to satisfy the needs specified by the process and mechanical engineers are too sharp and unprotected for anyone other than themselves to use without hurting someone or something. That leads to large automations that are often only “Go/No-Go.” When the “No-Go” happens (which it almost always does at the worst possible time), often the only way to get back to the “Go” is to find the automation engineer who created the difficult-to-understand-inner-workings of these large automations (made up may different “sharp tools”) that only the automation engineer is qualified to use.

It seems to me that in such cases the “stupid” people referred to are generally everybody out side of the small select group of engineers responsible for design of the physical equipment and how it is to be used and automated, especially manufacturing operations. When I’ve worked closely with the manufacturing operations that use equipment to make a product I’ve generally found highly intelligent individuals who are quite trainable. These same people also may be ignorant of how to get beyond the “Go/No-Go” interface they are given when faced with a “No-Go” situation that the automation can’t figure out or deal with.

I continue to be amazed at the creativity and ingenuity of these operating individuals as over time they create their own external modifications that allow them to bypass the automation and make the equipment operate as needed rather than as implemented. The time it takes for operations to learn how to deal with the situations that cause the “No-Go” and create workarounds is long and costly, but in the end, they almost always find a way (might not be the best way), but a way to succeed. I find it unfortunate that the true costs of success are not always clear to the business managers, leading them to continue to make buying decisions based upon the false perceptions that all is well, because manufacturing is successful in spite of what they have to do to achieve success.

What goes into a successful implementation? I'll add more tomorrow.

Please scroll to the bottom of the page and use the comments tool provided to add your views or share experiences. (Comments may not appear immediately.)

If you’d like to help with the ISA88 Part 5 standard, please contact me directly; we have a conference call scheduled tomorrow, Jan. 17.

Posted by David Chappell on January 16, 2008 | Comments (1)


January 17, 2008
In response to: We need to protect stupid people from doing dumb things
Francis commented:

Hear hear It is true that some automation engineers make the mistake of assuming that operators are incapable of making sensible decisions. If fact, once a system is running, the operators are the people who know best. Automation engineers should recognise that and ensure that they provide the operators the means to do what they need, when they need to. Most especially this applies during exception handling, when the operator needs to be able to manually recover the situation. Incidentally it is not always the automation engineers fault, I have for example seen such problems caused by the requirements so called validation engineers who like to restrict systems capabilities. Francis www.controldraw.co.uk





POST A COMMENT
Display Name or Registered Users Login Here.

Before submitting this form, please type the characters displayed above:


Advertisement



Advertisements



About Us   |   Advertising Info   |   Site Map   |   Contact Us   |   Useful Sites   |   FREE Subscription   |   RSS
© 2008 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy
Please visit these other Reed Business sites