A few years back I was working on the shop floor at an aerospace plant with a group of engineers who were determined to “do a Kaizen” to correct a defect caused by a perceived mistake. My sense from the start was that conclusions had preceded actual observation. I noted also that the class was comprised mostly of manufacturing engineers -- a little lopsided. I had intended to present a short workshop on Poka-Yoke before we went to the floor, but spent time instead in a debate over the efficacy of ‘event-type’ improvement. When I alluded to the term ‘kaizen event’ as an oxymoron, a manager became red-faced. As we traveled to the floor, the manager scolded me: “You don’t understand,” he said, “this is the defense industry. Nothing happens here unless we put a stick of dynamite under people" (referring in this case to the engineers.)
“Okay,” I conceded, “so it’s a tough environment for creating change, but what do you hope to accomplish with the dynamite?”
“We’re going to just do it, get the job done and then move on,” he said. “We can’t be expending the time of this many engineers without a result.”
“Why don’t you have any folks from the shop on this team?” I asked.
“Because this is a problem for engineers to solve,” he impatiently responded. “Look,” he said, “the defect is occurring on an assembly we almost never make. It’s understandable that a mistake might occur. We’re not blaming anyone. We just want to put a Poka-yoke in place to prevent the mistake from occurring again."
“Okay then,” I said, “lets go take a look.” Out to the floor we marched, two dozen kaizen crusaders. As we approached the wing strut assembly area, the manager announced to an employee in the department, “We’re having a kaizen event to determine the cause of a defect that sometimes occurs in this part.”
“Defect?” questioned the assembler, “It would be hard to tell what’s right and what’s not. Look here,“ he said holding up a print. “Do you think I should follow the specs on the assembly drawing?” Then, pointing to instructions fastened to the assembly fixture he asked, “Or should I follow the specs on the assembly fixture? They don’t agree you know.”
“I see what you mean,” the manager acknowledged, comparing the two instructions, “but why didn’t you bring this up before.”
“I did,” said the assembler, “I thought you knew.”
The manager turned to me, paused for a moment, and said, “There have been mistakes here – in our documentation process and in our corrective action process.” He then thanked the assembler for his input.
What we had learned from the floor that morning was much more valuable than the technical aspects of Poka-Yoke. The tacit learning for the manager and his engineers was that the best information often comes from the people who do the work.
Sometimes in our roles as managers or engineers we are pressured to round up the usual suspects and are thereby prevented from solving the real problems.
Has this kind of learning opportunity ever presented itself to you? Please share with us.
O.L.D.
