Hacker News new | past | comments | ask | show | jobs | submit login
Toyota Manufacturing Principles (josephmcohen.com)
42 points by josephcohen on Dec 29, 2013 | hide | past | favorite | 18 comments



Its hard to talk about Japanese management techniques without talking about Deming.

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.

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.


I always liked Deming's Red Bead experiment.. http://maaw.info/DemingsRedbeads.htm

The red bead experiment is deceptively simple because it provides a powerful message that is difficult for many to grasp. In summary, the misconception that workers can be meaningfully ranked is based on two faulty assumptions. The first assumption is that each worker can control his or her performance. Deming (1986, 315) estimated that 94 percent of the variation in any system is attributable to the system, not to the people working in the system. The second assumption is that any system variation will be equally distributed across workers. Deming (1986, 353) taught that there is no basis for this assumption in real life experiences. The source of the confusion comes from statistical (probability) theory where random numbers are used to obtain samples from a known population. When random numbers are used in an experiment, there is only one source of variation, so the randomness tends to be equally distributed. This is because samples based on random numbers are not influenced by such things as the characteristics of the inputs and tools (e.g., size of the beads and depressions in the paddles) and other real world phenomena. However, in real life experiences, there are many identifiable causes of variation, as well as a great many others that are unknown. The interaction of these forces will produce unbelievably large differences between people (Deming 1986, 110) and there is no logical basis for assuming that these differences will be equally distributed.2


I've never heard a disparaging remark about Deming, personally. When I worked for IBM in the late 1980s and early 90s, he was practically worshipped. When did he become controversial?


Same here, but I was working at Ford.


OK so there's two "american" megacorps I haven't worked at where his ideas are not hated. That's unusual.

Its not so much "we hate Deming", if anything he's usually very superficially liked, but his ideas are considered pure evil, he's the opposite of american management style.

Could there be anything more anti-american or the opposite of traditional MBA indoctrination than for example "Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objectives." Like I claimed, you'd get more corporate traction at a typical company by quoting Marx.

(edited to add the drama looks like this "TQM made some competitors successful. So we're going to do TQM. What that means to me, is we put up a poster of 14 key principles, and continue business as usual doing the near exact opposite of all 14 clearly listed principles. What could possibly go wrong with that implementation plan? I'm sure it will be a glorious success, at least until the next fad." "I like snickers bars, lots of them. Also I'm unhealthy. Dietician gave me a much better formal written diet plan. That's very nice, but I'll continue eating snickers bars as my primary source of calories while telling everyone I have a new diet. Shockingly, I'm still unhealthy. That dietician must really suck.")


Weren't Deming's ideas the genesis of the whole "Total Quality Management" fad in the 90's? What happened?


We'll work on product quality just after we make our numbers for the quarter. Honest.


For those interested in Deming (and as you mention Toyota's management) see Online Resources for W. Edwards Deming’s Management Ideas:

  http://blog.deming.org/2013/09/online-resources-for-w-edwards-demings-management-ideas/
From The W. Edwards Deming Institute Blog.


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.

Poka yoke. My new favourite process term. The other two are important, vital even, but poka yoke has to be paramount.

(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?

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.

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.

At their worst, JRPGs are grindfests where the gameplay consists of finding ways to minimise that grind or maximise efficiency.

At their worst, WRPGs are spreadsheet and inventory management simulators.

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 think tendencies in rpgs and relative success/feasabilty of actually realizing lean production is more likely manifestations of underlying cultural differences than any direct relation with these (concrete) management/process ideas.


Oh yes, that's what I was thinking.

I wasn't implying that kaizen was causing culture which was causing JRPGs. I was implying that the same culture was causing kaizen and JRPGs.

I was also talking only about kaizen, rather than about any of the other management ideas touched on in the article.


If you're interested in Toyota's manufacturing principles, "The Toyota Way" by Jeffrey Liker is worth reading.


That's a good book.

Brief history of TPS: http://www.sae.org/manufacturing/lean/column/leanjun01.htm


I have extended the Toyota stuff in my own special way...

1) Imagine every piece of data in your code is a component, a physical widget.

2) Imagine that component has mass proportional to its size as measured in 1's and 0's.

3) Imagine you have to have some person or some robot move it from place to place, maybe via a warehouse (hard disk somewhere).

4) Now question what you are doing and whether it is efficient.

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.

This whole process is so not 'just in time' manufacturing ways of doing things.

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

  - http://www.gembapantarei.com/
  - http://superfactory.typepad.com/
  - http://www.leanblog.org/
  - http://management.curiouscatblog.net/category/lean-thinking/



Didn't it come out in the trial that the vehicle computer source code was utter crap by any standards?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: