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.
Good point. Great presentation; love the tie-in to the movie line that makes it more meaningful and memorable.
At times, I wonder if we focused too much on the improvement “delivery model” and not the actual problem with which we are concerned – getting the people who do the work involved. In my organization we use many delivery models to solve problems and it is dependent on what works for the problem solving team. Turns out it is difficult (at this point in time for our departments and a problem to solve, we know) for clinicians to participate in improvement work if they are expected to have a clinical day (i.e. see patients). They asked that they be scheduled off the floor/clinic/OR/ER to be able to fully be present in improving the process under study. Based on their feedback, clinical staff are scheduled for at least 4 hour blocks but they prefer full day blocks to be able to focus and make progress. The goal is to get to the point where improvement can be integrated into the workday but we are honestly not there everywhere yet. That won’t prevent us from using whatever improvement delivery model works for the teams. It is PDCA after all…….
While reading, I was thinking it to be a narration of one of my experience, but the how could you know? I think it to be common sight. Do we not find scores for assuming and presuming managers walking down the shop once in a blue moon saying this is kaizen? The solution lies in the place of work and this must float up. The managers will do better to acknowledge this and spend more time in the shop.
Pingback: Blame Wars « Old Lean Dude
Pingback: Mental Muri Migraine « Old Lean Dude
Pingback: Upstream Swimmers | Old Lean Dude
Pingback: Ten Posts for Ten Shingo Principles | Old Lean Dude