Doormats
O ne of Shigeo Shingo's popular status quo targets was engineers, whom he placed in three categories: table engineers, those who just sit around a table and talk about problems; catalog engineers, those who think the solution to every problem can be found in a catalog; and nyet engineers, those who say no to every request ( nyet is Russian for "no").
On one rare occasion, I heard Shingo retell his engineer category story in the presence of my company's CEO, Bob R., who was himself an engineer. "I'm a can-do engineer!" Bob bristled in response. Although I'm not a big fan of stereotypes, I smiled at Bob's retort. I think Shingo made jibes to shock people, in this case our CEO, into consciousness.
Similarly, another teacher, Ryuji Fukuda, once commented, "Engineers should polish their brains, not their shoes." Fukuda offered the comment as light humor, but I recall a couple engineers in our group were not amused. "I feel like a doormat," one engineer said to me. "When things go wrong, production just blames us."
Full disclosure: I am not an engineer, and I might on occasion have been one of those production folks who walked all over engineering. While the same barbs slung by Shingo and Fukuda could just as easily be directed at other occupations, in Toyota Production System (TPS) lore, the role of engineers seems to be more critical. Engineers play such pivotal roles in a company's success that the need for them to be involved in continuous improvement is that much greater than other occupations. If their work isn't done "right the first time," internal as well as external customers are adversely affected. Design for assembly (DFA) proponents, Boothroyd and Dewhurst, for example, point out that every assembly fixture is essentially a workaround for a design that didn't adequately consider the folks who do the assembly. And Shingo noted that the best way to avoid production mistakes is to design them out before the product is released to production.
So why aren't these things considered before product launch, and why do problems take so long to be fixed after launch? Perhaps the answer to these questions is that engineers are subject to the same cockamamie rules as production. Here's a short list:
• Engineers typically have far too much work in process. Studies have demonstrated that two projects at once is an ideal number for a design engineer, yet most designers have many more.
• Engineers aren't typically rewarded for other people's designs (OPD), which creates pointless complexity, i.e., redesigning the wheel.
• Fixing problems with existing designs is seen to be far less important than creating new designs. Engineers are not encouraged to get into 'old plumbing.'
• Design tools make seemingly simple changes arduous.
• Cost accounting provides no encouragement for engineers to design for assembly, maintenance, testability, or ease of changeover. Only functional cost is considered important.
• Most engineering departments are function-cloisters of cubicles that limit information flow between engineers in the same way that is often seen in production. Donald Reinertsen and Preston Smith, authors of The Principles of Product Development Flow (Celeritas Publishing, 2012), quip, "Communication between engineers is inversely proportional to the square of the distance between them."
When W. Edwards Deming commented that 95-percent of an organization's performance problems are caused by systems, he clearly wasn't referring only to production. On the positive side, engineering departments that are able to break through status quo rules are creating huge competitive advantage for their organizations. Those who can't break through, however, will regrettably continue to be doormats.
Can you think of any other "rules" that impede engineers? Please share them .
Enviado desde mi iPad
Comentarios