Its hard to talk about Japanese management techniques without talking about Deming.<p>So Jidoka is pretty much Deming #11. Poka-yoke is obviously Deming #3. Kaizen is Deming #5. At least according to the "Out of the Crisis" poster I used to have.<p>I keep my Deming fandom quiet, he's about as anti-american as you can get. I'd get less flack if I said I was a Marxist. Its too bad, Deming was a genius. I'd say this whole topic is NSFW because you can't get further away from modern American management than Deming. Its safer to quote Marx at work than Deming.
It amazes me how many of us are willing to endure non-poka-yoke, that is, processes that are inherently mistake-ready. My current fave is timesheet rekeying by our admin. We're small, so it isn't too bad, but it cannot scale, and as the admin becomes more harried as we grow, mistakes will be made. Guaranteed.<p>Poka yoke. My new favourite process term. The other two are important, vital even, but poka yoke has to be paramount.<p>(If you jidoka without poka yoke, how long before a worker is hurt by a machine?)
Could such attitudes form part of an explanation for the JRPG/WRPG gulf?<p>JRPGs typically encourage training, finding efficient ways to grind (improving processes) and perfecting character builds through trial and error - at least on the first playthrough. This seems like a Kaizen approach.<p>WRPGs typically encourage a focus on fight-by-fight tactics and a priori evaluation of build options and strategies to find an 'optimal' team, tactic, strategy and build. This seems like a 'secret formula' approach to management I've seen a lot in my own professional life.<p>At their worst, JRPGs are grindfests where the gameplay consists of finding ways to minimise that grind or maximise efficiency.<p>At their worst, WRPGs are spreadsheet and inventory management simulators.<p>I think I am stretching a little here (many Japanese RPGs are indistinguishable from so-called WRPGs), and I appreciate that this is something of a tangent, it was just something that struck me.
I have extended the Toyota stuff in my own special way...<p>1) Imagine every piece of data in your code is a component, a physical widget.<p>2) Imagine that component has mass proportional to its size as measured in 1's and 0's.<p>3) Imagine you have to have some person or some robot move it from place to place, maybe via a warehouse (hard disk somewhere).<p>4) Now question what you are doing and whether it is efficient.<p>Take the simple but common scenario of working with someone that knows Dropbox but not how to use FTP, e.g. a graphic designer. They upload their stuff to Dropbox, taking hours to do because they are on the slow end of an ADSL connection. They then send you the Dropbox link for you to then download and upload to the server for them. Now imagine all of those 1's and 0's have physical mass and have to move physical distances back and fore across the Atlantic.<p>This whole process is so not 'just in time' manufacturing ways of doing things.<p>Clearly this also goes on in your own code as well as with inane procedures needed to work with non-techies. Sometimes thinking data has physical mass helps you see whether what you are doing is efficient.
Some blogs for those interested in Toyota's management practices<p><pre><code> - http://www.gembapantarei.com/
- http://superfactory.typepad.com/
- http://www.leanblog.org/
- http://management.curiouscatblog.net/category/lean-thinking/</code></pre>
Am I the only one who remembers this?<p><a href="http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences" rel="nofollow">http://www.edn.com/design/automotive/4423428/Toyota-s-killer...</a>