» » next post - Jeff Liker: The key to Jidoka: small span of control and a disciplined method of problem solving
« « previous post - Michael Ballé: Pick to light and learning to teach Jidoka
Jim Huntzinger

Jim Huntzinger: Jidoka: the TPS house collapses without it

By Jim Huntzinger, - Last updated: Thursday, August 12, 2010 - Save & Share - Leave a comment

Art Smalley and the others give great explanations about Jidoka so I won’t add too much in light of their responses, other than comment that either pillar (JIT and Jidoka) cannot exist without the other without the roof of the TPS House model collapsing.  As Art states – they are equally important to the system.

From my experience here are examples and how Jidoka manifested itself….

(Note:  Let me qualify this by stating that I don’t mean this to be any definitive definition, solution, or end-all of Jidoka – just examples I was involved with as I implemented and learned over the years.)

Jidoka came to me through two routes – first, reflection back to my days working for Aisin Seiki when I knew of it, somewhat, but in a rather vague manner as actually implementing it was not a direct responsibility of mine at that time – so simply I was not giving it much direct thought.  Second, was when I was actually trying to do it and referenced the “Orange Kanban book” (that was the name we had for Kanban Just-In-Time at Toyota: Management Begins at the Workplace from Productivity Press) and the few pages of explanation along with basic explanation for Jidoka from attending the original 5 Days and 1 Night workshop at Danaher, and my recollection back to my experience at Aisin Seiki, so that I could explain what it meant to the engineers I was working with at the company I worked for after Aisin Seiki.

Jidoka manifested in CNC/PLC programming, fixture design, parts chute design, line layout, part presentation, Standard Work, mistake proofing, operator training, supervisor roles and responsibility, check lists, etc., etc.  We saw it had both mechanical devices that prevented or enhanced problems and visual systems connected with the people working on or around the line to quickly see problems and prevent and correct them.  We saw an overlap between poka-yoke and Jidoka and between Jidoka and people.  (Not saying we were always successful or did a good job with it, but this was our understanding and vision of it.).  So, as much as we could, we would implement these ideas into our machines and manufacturing lines – assuming there was not much cost to doing them!

For example, we would put small holes into fixture pads were parts were to be seated with airlines and pressure switches in circuit and logic programmed into the PLC that would not allow the machine to cycle completely if, once the part was clamped, the pressure switch was not signaled properly.  This would have been due to improper loading of the part into the fixture or a chip on the fixture rest pad not allow the part to properly and tightly clamp down.  We also added small coolant flow lines to wash over the fixture to prevent chips from remaining on the fixture pads (simple, cheap countermeasure).

We would work hard to design fixtures that were nearly impossible to load other than the proper orientation of the part.  Obviously this could be very difficult depending on the orientation needed for the processing of the part and, even, the basic shape of the part.  But we would try none-the-less.

We would design simple part chutes between work zones (the zones were based on takt time and Standard Work) to transfer parts (even if only a foot or two) to both eliminate excess walking, but also to minimize the number of parts that could build up between work zones.  If too many parts built up (usually 2 to 5 parts maximum) it signaled that an operator had an issue so the supervisor needed to investigate and support.  If a parts chute had to be longer than we really wanted – due to the size of a machine – we would add prox switches that would signal if more than a specific number of parts accumulated on the chute which would either stop the machine or switch on an andon light.

We added some basic pneumatic actuated levels and a diameter gauge to 1940s (I mean this literally, as the manuals for these machines were dated prior to Pearl Habor being bombed!) era manual grinders to both; free up the operator from monitoring the machine and give the machine the intelligence to monitor and measure itself while processing and alarm out if the correct diameter was not reached.  And we added this simple system for just a couple thousand dollars – significantly less expensive than a new grinder by 10s to 100s of thousands of dollars.  I was very pleasantly surprised, as it worked much better than I thought it would – but it was simple PDCA in action.

We even saw Standard Work as a critical link between one-piece flow (JIT pillar) and the Jidoka pillar.  If Standard Work was not planned and deployed well – even with a very good cell layout and mechanical Jidoka devices in place – the entire function of the line was in jeopardy.  And, believe me, this was a constant issue!  We did work very hard at devising good Standard Work, observing it in action and discussing issues with operators and supervisors – but it was still very difficult for it to integrate.  This is why many years later when I discovered TWI, I jumped right on it.

These are just a few examples I have had experience with over the years.  Jidoka is very simple in concept, but very broad and integrating in implementation and manifestation from my experience.  Anything that prevents problems first, or highlights issues immediately, and helps machines, people, and systems discover, pinpoint, and countermeasure/correct/resolve problems quickly, effectively and safely is Jidoka.

Post to Twitter

Share this post...Tweet about this on TwitterShare on Google+Share on LinkedInBuffer this pageShare on FacebookEmail this to someonePin on PinterestShare on Tumblr
Posted in Uncategorized • Tags: , , , , , Top Of Page

Write a comment

*