Excerpts from An Interview with Taiichi Ohno, July 16, 1984

an interview with taiichi ohno 1984.jpgOne of the rewards of last week’s office kaizen activity at Gemba was the discover a copy of the 1984 interview with Taiichi Ohno. The original paper An Interview with Taiichi Ohno, July 16, 1984 is in Japanese and can be found on the University of Tokyo website. The authors are professors Koichi Shimokawa and Takahiro Fujimoto who also penned The Birth of Lean in 2009, available from Lean Enterprise Institute.
The interview with Mr. Ohno was conducted over three hours during which he recounted the history of development of the Toyota Production System. In the foreword the authors explain that the text is a transcript of Ohno’s spoken word, free of interpretation by the two professors. The following is my own translation of the sections that were either interesting or novel.
On deciding what parts to outsource and what to produce in-house:

There was a belief within Toyota that “We can export our products, just like bicycles, if we thoroughly use inexpensive suppliers and make them deliver parts just in time.” However I held the opposite idea, that “We should make the lower volume parts in-house and outsource the high volume parts that any supplier could make inexpensively. If we produce low volume parts in-house of course the cost will be higher so this will create pressure to do kaizen in order to reduce cost.” I saw the importance not only of just in time for supplier parts but also for parts we made in-house.

Assigned responsibility for the final assembly line at the Honsha plant, Ohno recalls:

[…] I was very demanding that the upstream process practice heijunka, and as a result they said “Why don’t you do it then?” and I was given responsibility for the machining processes.

Ohno found that it was relatively easy to triple or quadruple productivity by assigning one person per machine, as pre-war some critical machines typically had 3 or 4 operators assigned per machine. Ohno recalls:

Workers who considered themselves craftsmen resisted this, but there were many who left the company so manpower reduction was relatively easy.

The machining processes progressed from four person per machine to one person and then towards multi-process handling in which one machinist ran several machines in a flow. This reduced inventories and enabled the pull system. However the following passage is revealing in that it addresses the need during a lean transformation to invest in more equipment and operate them at a lower utilization in order to optimize the total flow:

We took two years to convert to a processes-sequenced flow layout. As a result the number of machines increased, for example from 50 drill presses to 200, and the utilization of each machine was reduced. This was wasteful, but our policy was not to worry about utilization. However we prevented adding workers through the practice of “multi-process handling”.

In a section of the interview that discussed standard work, work standards and the early stages of doing kaizen within the machining operation, Ohno makes a few noteworthy points:

The kanban exist for the purpose for the same reason as signage on a shop; so that people from the outside can see it.


I tasked the shop floor leaders with regular kaizen of work methods and revision of the standard work, telling them “If the kanbans do not change for one month you are salary thieves.”

The authors make a special note that “kanban” here refers to standard work documents, and not the accepted TPS definition of the kanban card as a pull system tool. During the discussion on the kanban (pull system definition), Taiichi Ohno reveals when and how the kanban system was given its name:

The name “kanban” came afterward. We came up with it as a catch phrase when we won the Deming Prize in 1964.

On the thinking that led to the development of the kanban system, Ohno states:

Kanban brings about “the automation of production control”. Therefore, if we have kanban we do not need computers. For example when there is a change in production plans, the computer takes two weeks to processes this, delaying our response. Even if computers can instantly calculate inventories, if the shop floor response is slow, there is delay. On the other hand kanban card quantities can be adjusted incrementally so that people naturally know, “Based on the fact that kanban cards are not coming back the plan must have changed.” As long as heijunka is done, changes can be made even the next day.

What is most interesting is the other motive for the kanban system: the elimination of ledgers. The goal of eliminating paper record keeping was once abandoned due to requirements by Japanese tax authorities. When computers were introduced into the offices in the early 1950s and the elimination of the ledgers was finally allowed by the tax authorities, the kanban system finally became possible. Ohno speculates on the timing and impact of computer technology on the development of kanban:

If Toyota had implemented computers two or three years earlier, the computer may have given instructions for delivery or production instead of kanban, and the kanban system may have never been developed at all.

We can imagine the quaint computer technology at Toyota in the days when it took two weeks to recalculate stock levels. Even today with the ubiquity of computers that can “instantly calculate inventories” the fundamental reasons why kanban is so important to an operating system based on continuous improvement are unchanged:

The aim of kanban is to make troubles come to the surface and link them to kaizen activity. I tell people, “Let idle people play rather than do unnecessary work.”

In this quote we have the essential beauty of kanban and much of the Toyota Production System: the exposure of problems, limiting overproduction and stimulating continuous improvement.
On the last page of the interview, Taiichi Ohno talks briefly about quality control and jidoka. The points he makes about the need to strengthen quality awareness at the team member-team leader level, and the need to stop the line in order to expose problems early are especially poignant in light of Toyota’s quality problems, a quarter century after the interview. These are timeless lessons, so easy to understand yet so difficult it seems even for Toyota after so many decades of practice to consistently apply and keep in the front of our minds.


  1. Roy Waterhouse

    February 17, 2010 - 3:23 am

    Are there any sources for reading the entire interview in English? What you translated was intersting.

  2. breat

    February 17, 2010 - 3:29 am

    Congrats and thanks for interview vision.The bicycle is probably one of the most successful attempt by man to exploit physics and manpower to make transportation faster. The bicycle is made up of different parts put together to facilitate faster transportation.

  3. Harish

    February 17, 2010 - 3:39 am

    Wow Jon. Thank you so much for this.
    “The aim of kanban is to make troubles come to the surface and link them to kaizen activity.”
    That quote was awesome to say the least. I have always thought of TPS’s goal as revealing waste and now I get the connection – link it to kaizen activity. The common lean definition of waste elimination needs to be rewritten.
    Thanks again.
    Hope you do more kaizen activities and find more gems like this 🙂

  4. Jamie Flinchbaugh

    February 17, 2010 - 5:05 am

    Great gem, thanks for sharing.
    I think this perspective sheds light that TPS was not invented as a system, but as solutions to problems. One problem, whether large or small, was solved at a time. The result of that continual process is what most people see as TPS. But I contend that TPS is not the solution set, it is the process of problem solving. Don’t copy Toyota’s answers to their problems. Use the process of lean thinking to solve your own problems.
    Jamie Flinchbaugh

  5. Jon Miller

    February 17, 2010 - 4:59 pm

    Roy – I haven’t found an English version of this article. I will let you know if I do.
    Jamie – great point about TPS being the result of persistent problem solving rather than an intentionally designed system.

  6. Umbahli

    February 26, 2010 - 12:04 am

    Thanks for the great reminder that its not about duplicating a system but about continuous problem solving–the process of creating unique systems and solutions based on the specific issues at hand.