Poke-Yoke the Engineers

Being an engineer and forced into a box did not "feel" right.  How am I supposed to use my technical creativity to take these requirements and turn them into something you can hold in your hand?  Get away from me with your process stuff, I'm here to (hold up your shield) support the customer!!

I acted this way for a time while adjusting from being a recent college graduate to a responsible and productive member of society.  I had my office, with three computers, bookshelves full of component specs and design books, and my attitude of "THESE HANDS WERE TOUCHED BY GOD!!".  Obviously those people don't understand my brilliance and I must dumb-down my methods to meet their level of intelligence.  Now, if I could automate the human out of the equation quality and productivity would instantly improve.

Wow!! Was I really that full of myself?  I don't think I was very helpful during that time in my career.  I had just left Uncle Sam's Misguided Children two years before and graduated with my Manufacturing Engineering degree a few months prior. I had a few career successes and my level of confidence in my abilities were over-the-top.  I had lost my touch with reality and the work relationships suffered.

It only took a project or two to learn that my work produced a product that was needed for another team on the floor and their success (read as OUR success) was based on how well I performed, not just technically but to their schedule. I learned there was enough variation in my output to disrupt everything on the floor when I worked in my own smoke-stake or rice bowl.

We started by paying attention to the feedback coming from the floor.  How often were they coming back for us to fix something, how much time was spent during changeover, and how often did we deliver our products late to their need?  Simple, but powerful measures to gauge performance.  When we analyzed the data coming from the floor, we found the enemy and he was us.

Continuous Learning Cycle

Our first move was to document changes being made on the fly and changes being made at our desks.  Most of the changes had been made on the floor, which hid most of the problems and the information showed us how bad our product was.  A picture began to form showing what exactly who the culprits were and they were quickly standardized through our purchasing department.

Next we checked all our computers to ensure we were all connected to the right data sources.  Some had "drifted" off course and was quickly realigned to master libraries.  We saw a vast quality improvement after the last of the "bad" product had gone through the system.  It looked like the worst was behind us, but in reality we were still in a fragile state.  We still needed to update our standard desk guides.

When we stabilized our output, we began to chance variation in the inputs.  The design engineers had their design software connected to standard data sources linked to our MRP system.  We tracked our requests to them to fix their problems, shared that data in a professional manner, and saw results.  We found problems in the MRP system also and many times the reason was they did not think that option mattered to anyone.

It is great to feel like the hero that saves the day, but after a while we get tired of the same old problems.  It looks like no one cares when things do not improve on their own.  We live in the information age, and when there are problems with the information flow we have to address those to closure.

What has been your experience working in the data flow?  Have you seen improvements over the last few years?