Is Cost Reduction the Goal of TPS?

In a rebuttal to John Seddon‘s latest paper, An Exploration into the Failure of Lean,  Bob Emiliani asserts that the original purpose of TPS was to reduce cost. He quotes both Taiichi Ohno and Yasuhiro Monden saying so, and chides Seddon for not reading their works carefully enough. In the context of these documents, however, I think the quotes are misleading. Neither Ohno’s and Monden’s books, nor any other Japanese publication about manufacturing systems that I have seen, contain a discussion of what costs actually are.

Continue reading

Human Resources at Toyota

With Respect for Humanity, bowdlerized as “Respect for People,” made into a pillar of The Toyota Way, you might expect Toyota’s Human Resources (HR) policies to be studied, scrutinized, discusses extensively in the Lean literature, and argued over in numerous forums. But it’s not the case.

Continue reading

EOQ Versus JIT Explained Through Coffee Beans and Raspberries

The “Plan for Every Food” in my household involves different policies for buying coffee beans and fresh raspberries. These simple examples show that  thinking in terms of Economic Order Quantity (EOQ) isn’t always wrong, and Just-In-Time (JIT) isn’t always right.  You need to set appropriate policies for screws, steel bars, engines, microchips, and all other items you may need, and review these policies periodically as circumstances change.

Continue reading

Manufacturing Wordsmanship

What you choose to call objects, ideas, positions, methods, tools, etc., makes a difference in your ability to lead and change the way your organization works. Engineers often believe that it makes no difference what words you use as long as what you do works; marketers know better. They know that “sushi” sells better than “raw fish,” “Lean” better than “TPS,” and “Black Belt” better than “Staff Statistician.” The “Toyota Way” or the “Toyota Production System” sound like appealing approaches; “toyotism,” like yet another plot to enslave workers. Words matter; they engage, motivate, and inspire, or they confuse, offend, and alienate. Following are a few thoughts on Manufacturing Wordsmanship, the art of naming manufacturing improvement tools and concepts:

The contrary body of opinion

In the TPS Principles and Practices discussion group, Dermot Freeman‘s summarized the engineering perception as follows: “Our (insert customers or clients or bosses or colleagues – whichever is appropriate for you) don’t really care what the tools or methods are called as long as they achieve the correct result.” Further in the same thread, Sid Joynson quoted the taoist philosopher Zhuangzi (莊子, 389-286 BCE), as saying:



“The fish trap exists because of the fish. Once you’ve gotten the fish you can forget the trap. The rabbit snare exists because of the rabbit. Once you’ve gotten the rabbit, you can forget the snare. Words exist because of meaning. Once you’ve gotten the meaning, you can forget the words. Where can I find a man who has forgotten words so I can talk with him?”

Sid also quoted Fen Yang, a follower of Zhuangzi 1200 years later, known in Japan as Zen Buddhism founder Funyo Zensho (汾陽善昭, 947-1024 CE) :

“When you are deluded (don’t understand) a thousand books are not enough. But when you have realised understanding, one word is too much.”

Attractive though these  pronouncements may seem, in manufacturing, we not only keep the trap, the snare, and the words, but also their models, revision and serial numbers… It is not a world where understanding exists independently of language. Understanding in manufacturing is not a matter of feeling or enlightenment, but of using words, drawings and numbers to turn materials into products with machines and tools. In Training Within Industry (TWI), the system developed in the US during World War II and later adopted by Toyota, being able to do a job is not enough. To be certified as proficient in it, you must also explain it step by step in words. If you have been doing the same repetitive work for a while, you certainly forget the words and go on automatic. But you have to pay close attention to the words to respond to changes that occur, for example when improving an operation, implementing engineering revisions in the product or process, or making custom-configured products.

How terms are used

An effective term serves not only to communicate with others, but also in your own mind as an address in memory to which you attach everything you learn about an object. If you have a name for it, you will notice it when you see it, and you will remember its characteristics. When you learn a new word in a foreign language, you suddenly start hearing native speakers use it in a variety of contexts. Knowing that this object on the shop floor is called a “broaching machine” lets you attach the broaching process, tools, times, and quality issues to this name and remember them. Conversely, terms that are difficult to remember, ambiguous, offensive, or inconsistently used —  or sound too much like other terms — sow confusion and impair both communication and learning. What you are trying to achieve on a manufacturing shop floor is free and open communication. Mutual understanding is the primary goal. While a challenge, it is an easier one than the restricted or confidential communication characteristic of many other activities. There, in addition to encoding and decoding for electronic communications you still use code words, cant, or jargon to confuse unintended audiences when speaking to someone next to you.

Methods of word formation

Different objectives call for different methods in choosing your words. As an example, I am going to focus on the vocabulary used in Japanese for the Toyota Production System (TPS), and its translation into English. To get the translations right, we need words that not only mean the same but resonate with local manufacturing people as well as the TPS terms do in Japanese. The worst we can do in translating TPS is over-intellectualize it. In the US, factory people rarely read the Harvard Business Review.  We should not translate  TPS terms into words that would fit in this journal. The TPS vocabulary doesn’t include entropyDNA, or Value Stream.

Borrowing from everyday life

"Wagon" or "Pirate ship"

“Wagon” or “Pirate ship”



To communicate with auto workers, TPS uses concrete words, and sometimes imagery like “spaceships” (宇宙船) and “pirate ships” for different types of fixtures. “Spaceships” hover over workstations, providing tools that hang over it; “pirate ships” are level with the work station and “board” it on its side, moving through the station along with the assembly line. These words are borrowed from everyday language. Kanbans are the shingles stores put out in the street. Andons are lanterns. That “Kanban” is borrowed from shop signs may not make it easier to understand how the system works, but it is a revealing choice in word formation: grab a word from common, everyday language and extend its meaning in a way that sort of makes sense to the people who are expected to use it.

Toyota raku-raku seat

Raku-raku seat

On its own website, Toyota gives “ergonomic seat” as translation for the raku-raku seat (楽々シート). The meaning is accurate, but the connotation different. “Ergonomics” is a word made up from Greek roots; “raku-raku,” in Japanese, is colloquial. Its connotation would have been better rendered by “easy seat” or “comfy seat.”

When borrowing a word to give it a new meaning, make sure it comes from a domain that is sufficiently different to avoid ambiguity and confusion. No one will confuse a Kanban used in production with a shop sign on the street. On the other hand, calling a shelf on which you store parts a “Kanban” creates confusion, because it is like using the same word for a theater ticket and for the seat it is for. You can contrast this with importing foreign words, using acronyms or mashing together Greek and Latin roots. Acronyms are the way to go if you want to create a code that excludes the uninitiated. Foreign words work that way too, but not with native speakers of these foreign words.

Borrowing foreign words

TPS also borrowed words that are foreign to Japan, such as:

  1. “Takt,” which is the German word for a musical bar, strokes in car engine or, as David Anderson noted, a regular interval between trains. Takt in German
  2. Phrases built from foreign words, like “just-in-time.”
  3. Acronyms built from oddly used foreign words, like “SMED.” I don’t recall a native speaker of English referring to an interval of less than 10 minutes as “Single Minutes.” In addition “Exchange of Dies” is wording that is specific to stamping presses, for which the method was originally developed, but you apply SMED to many machines that don’t use dies.

Combining roots from dead languages

European scientists mashed together roots from Greek and Latin to concoct new words like “entropy” or “isotope” for Greek and “tyrannosaurus rex” for Latin. Sometimes, they even mixed both Greek and Latin in words like “television” or “heterosexual.” Why didn’t they choose words from their own vernaculars? Today, using Greek and Latin roots shows off your classical education and excludes those who haven’t had one…. It is difficult to imagine another reason to refer to a periodic maintenance task as being “isochronal” in the US today. 200 years ago, a European scientist pushing the use of his own language would have been in trouble with foreign peers. Drawing on dead languages that scientists from Italy to Sweden and Portugal to Russia had studied as kids was a safe way to avoid any appearance of cultural arrogance. In Japan, the equivalent of Greek and Latin roots is Chinese roots, and the Japanese have been at it for 1,500 years, thus creating almost half of their vocabulary. In TPS, this has given us words like Heijunka, Jidoka, or Jishuken. Jidoka (自働化) is a case in point, because the Toyota version sounds exactly like the standard word for automation (自動化), but differing by two strokes added to the middle character, changing it from 動 for “moving” to 働 for “working,” the two strokes added being the radical for human (人). This is as brilliant as it is untranslatable.

CHAdeMO charger in action

CHAdeMO charger in action

In Japan, as in the US and Europe, this mode of word formation is perceived as solemn, official, and old-fashioned. It is still done, but not by anyone who wants to be cool. Combining fragments of English words, as in the “CHAdeMO” charging stations for electric cars, is cool. “CHA” is for “charge,” “MO” for “motion,” and the “de” is there to make the whole word sound like a fragment of a Japanese sentence for offering tea. I don’t know of any such words in the TPS lexicon, where coolness is not pursued.

Creating acronyms

Acronyms in everyday use include OK, laser, snafu, or flak; in manufacturing, JIT, WIP,  SMED, TQC and TPM. They are prized as convenient abbreviations but, unlike everyday words used metaphorically, they hurt communication by having no connection with their meaning. Too many sprinkled in a document or speech can make it unintelligible. It is striking how people qualify acronyms to reconnect them with meaning. Instead of “ATM,” they will say “ATM Machine,” even though the “M” in “ATM” already stands for “Machine.” Likewise, in Manufacturing, you hear of “MES Systems,” where the “S” in “MES” already stands for “System.” Acronyms work best when built from words that provide a clear and accurate definition, as is the case, for example with WIP. When creating acronyms, you should also be careful to avoid the following:

  • Acronyms that are jokes or can embarrass people in any of the languages used in your company. The “Project Information System” (PIS) was unfortunate, and so are the “Semiconductor Equipment Communication Standards” (SECS).
  • Acronyms in which some letters stand for another acronym. They just take too long to decypher.
  • Acronyms that are an exact match to an existing word. It is a good idea to make acronyms pronounceable, but an exact match with an existing word creates confusion, particularly in Google searches.
  • Acronyms that already exist with a different meaning.  It is particularly confusing when it is in the same context. In one plant, for example, successive inspection was called “Touch Quality Control,” abbreviated TQC, which outsiders understood to mean “Total Quality Control.”  Even when used in different contexts, search problems still occur. “5S,” for example brings up not only items about visual management in factories, but about 5-year old children in kindergartens and about the latest version of the iPhone.

Sometimes acronyms are used as mnemonics rather than abbreviations. TIMWOOD, for example, is a way to remember Ohno’s list of waste categories. It stands for “Transportation, Inventory,Motion, Waiting, Overproduction, Overprocessing, and Defects.” Acronyms are sometimes used to deliberately exclude the uninitiated. When Gus Pagonis, the general in charge of logistics for the first Gulf War, on p, 90 of his book Moving Mountains, discusses the Time-Phased Force Deployment List or TPFDL, pronounced “tipfiddle,” the purpose of using this term is obviously not to be universally understood.

Naming things after people

I can’t think of any TPS concepts that are named after people. On this subject, Frederick Stimson Harriman wrote the following:

“The Japanese practitioners that I know won’t even call a Gantt Chart a Gantt Chart. I have often heard Japanese call Gantt Charts 予定表 YOTEIHYOU (“schedule” or “plan”). What is called a “Pareto Chart” in the US among TPS/Lean practitioners is often called simply バーチャート BAA CHAATO “bar chart.” What many people call an “Ishikawa Diagram” is often referred to in Japanese as 特性要因図 TOK– USEI YOUIN-ZU literally “characteristic factor diagram” but “cause and effect diagram” is not an inaccurate translation. The Consultants I have worked with expect it to be translated either as “fishbone diagram” or “cause and effect diagram.” Of course these are all tools that are not specific to TPS, but are often used by practitioners in problem solving, etc. From my experience, Japanese have a general aversion to naming things after people. Note that Americans have no trouble immortalizing Gantt, Pareto, and Ishikawa, and it seems to be something that Japanese feel more comfortable avoiding. Even the name Toyota of “Toyota Production System” is for the company and not the family, which continues to pronounce its name ‘Toyoda.'”

This comment about the Japanese not naming things after people, besides being a challenge to find exceptions, raises the question of whether it is a good practice. Many Japanese companies are named after founders, like Matsushita or Honda. 20 years ago, a Japanese colleague of mine used a system of stickers to make flow charts that was called, as I recall, the Kitagawa method; my son took violin lessons on the Suzuki method; Norman Bodek is promoting  the Harada method; and, like everywhere else, Japanese scientific discoveries and theories are named after the researchers who are credited for making them, like the Ito integral.  But none of that is TPS. Generally, we can think of several good reasons to name things after people:

  1. It is gratifying to have people use something you invented and call it by your name.
  2. It tells everyone in the organization that they have a chance at immortality.
  3. It connects the thing with the context in which it was invented.

But there are downsides as well:

  1. A person’s name tells you nothing about what the idea is or what the thing does. “Pressure cooker” or “schedule chart” does.
  2. Individual recognition can create jealousy and conflicts about attribution, which discourages teamwork.
  3. People’s names are not always easy to pronounce.

Gantt charts were actually invented by Karol Adamiecki in Poland a few years ahead of Henry Gantt. Adamiecki called them “harmonograms.” So why do we call them “Gantt charts” and not “Adamiecki Harmonograms”? Who has time for eight syllables when two will do, especially when they roll off the tongue like “Gantt Chart”? Adamiecki may have been first, but he had the wrong name.

The Toyota Way 2001: the Necronomicon of Lean

Unlike Jeffrey Liker’s 2004 The Toyota Way, The Toyota Way 2001 is not a publication but an internal company document distributed to US employees, who were not supposed to reproduce it. 12 years on, many consultants are quoting it, borrowing its terminology, and describing it as representing the essence of Lean. It is floating around, but it is still not readily available. If you google it, you find plenty of inquiries about it, but the document itself does not pop up. Unlike the Necronomicon, however, it does exist.

I have read it and my reaction was as follows:

About the document as a whole

It’s only 14 pages long, and probably worked as a “wrapper” for the methods Toyota employees were already using.  As a stand-alone document, however, it’s not that useful, as it does not clearly state what is special about the company. Based on its content alone, it would be difficult to tell the Toyota Way apart from other corporate philosophies like the HP way. A manager of a mid-size traditional plant, reading The Toyota Way 2001, would reasonably conclude that all he or she needed to do to emulate Toyota was follow its recommendations. With all the wheels that would have to be reinvented, this approach in such a plant might yield results in, say, 60 years.

In his introduction, Fujio Cho, then president of Toyota, describes the document as a statement of the company’s “DNA” and applicable everywhere in the world. The five major headings that follow — Challenge, Kaizen, Genchi-Genbutsu, Respect, and Teamwork — have come to be often used outside of Toyota, for example as a structure to explain why middle managers don’t practice A3 thinking.

A collection of quotations

The introduction is followed by a breakdown of each of these five headings, leading, for each subtopic, to a paragraph or two of explanations followed by a series of quotations from Toyota executives, including three Americans. I counted 73 quotations, which really make up the bulk of the document. The sources are as follows:
Sources Quotes
Eiji Toyoda 19
Kiichiro Toyoda 12
Alex Warren   9
Taiichi Ohno   9
Sakichi Toyoda   6
The Toyoda Precepts   4
Robert B. McCurry   3
Shoichiro Toyoda   2
Yale Gieszl   2
Hiroshi Okuda   2
Akira Takahashi   1
Declaration between TMC and Workers’ Union, 1962   1
Shotaro Kamiya   1
Taizo Ishida   1
Yukiyasu Togo   1
Total 73

Except for two quotes by Hiroshi Okuda, who was still running the company in 2001, all the authors were either retired or dead; Okuda himself retired in 2006.  With the exception of Fujio Cho in the introduction, the document does not reference any current leader. Eiji Toyoda, the most quoted author, is founder Sakichi Toyoda‘s nephew and will turn 100 this September. The second most quoted is Kiichiro Toyoda, who started Toyota in car manufacturing but died in 1952. The man best known outside Toyota as the father of the Toyota Production System, Taiichi Ohno, is only in 3rd place, with nine quotes. 80% of the quotes are from Japanese sources, and 53% are from three generations of the Toyoda family.

Influence of the US Lean movement

Outside of the quotes, the subtitles and the summary paragraphs use terms like “Lean,” “DNA” and “value” that are from the American Lean  literature. “Value” is used in multiple senses, sometimes for ethical principles as in “values and beliefs,” and other times as an abstraction of what the company delivers to its stakeholders, listed as “customers, shareholders, associates, business partners and the global community.”  The order in the sequence obviously matters, but there is a contrast with the US Lean literature and its exclusive focus on customers.

“Value added” appears once, in a definition of Muda as “no value added.” In the Japanese literature, Muda is not defined, and used in its common, everyday sense of “unnecessary.” “Added value” is used four times, and designates a quantity that can be high or low, as in  “goods and services with high added value.”  While it is not explicitly stated, this usage is consistent with added value being the difference between sales and the materials, energy and outsourced services consumed in producing the goods sold. This is the metric used to compute productivity, contribution to GDP, and Value-Added Taxes in countries that charge them. There is no reference to “value added” as an attribute of activities that customers are willing to pay for.

Improvement versus optimization

There is a reference to “Optimization,”  which surprised me, as I see the optimization mindset is antithetical to continuous improvement. Once you have optimized something, then, by definition, no more improvement is possible. I have heard managers say “We’ve optimized this line…” as a way to say that they had moved on to other areas and would not address glaring problems that remained. With continuous improvement, on the other hand, the completion of an improvement step is not an occasion to declare “mission accomplished”; it just sets up the stage for the next step.

Remarkable quotes

Following are comments on a few of the quotes in the document that I found most striking.

Eiji Toyoda on time

Eiji Toyoda is quote as saying: “A person’s life is an accumulation of time – just one hour is equivalent to a person’s life. Employees provide their precious hours of life to the company, so we have to use it effectively, otherwise, we are wasting their life.”

It  builds on the famous Benjamin Franklin quote  “Dost thou love life? Then do not squander time, for that’s the stuff life is made of.” (‘Poor Richard’s Almanack, June 1746). But Franklin’s exhortation is for individuals and about themselves. The twist Eiji Toyoda adds is that the company should not squander its employees‘ time, and the reason given is not that it is paid for, as Taylor would have said, but that it is a piece of that person’s life. I don’t recall seeing such an expression of respect for humanity in the American management literature.

Taking this further, if we squander an employee’s time, we are also sending a message. We are telling the employee that we can afford to waste his or her time and therefore that it is worthless. And since that is “the stuff life is made of,” the employee’s life is worthless, so that the final message is “You are worthless.” It is difficult to imagine a  more disrespectful or insulting stance.

Most discussions of respect for humanity in TPS are about making full use of employees’ skills, and, in particular, their intellectual and creative abilities. What Eiji Toyoda says here is that it is also about their time.

Squeezing water out of a dry rag

About Kaizen, Eiji Toyoda is quoted as saying “Even a dry towel can produce water when ideas are conceived.”

In Japan, I had heard it said admiringly of Toyota that “they could squeeze water out of a dry rag,” (乾いている雑巾を絞ると水が出る) but I didn’t know it was a quote from Eiji Toyoda. And it was about rags, not towels.  I suppose the translator just thought “towel” sounded more professional, but “rag” is more true to life.

About software and manufacturing

Eiji Toyoda is also quoted as saying “Why make only software? Software exists only because there is product manufacturing.”To this resident of Silicon Valley in 2013, it is obvious that, even though Photoshop and Netflix are not made of materials you can touch, they are as tangible as goods and services as cars and oil changes.  I understand why a man born 100 years ago who spent his life growing the best car manufacturing company in the world would feel that way, but, on this one, I respectfully differ.

JIT and GM

 Kiichiro Toyoda is quoted as writing the following about JIT in 1938:

“I plan to cut down on the slack time within work processes and in the shipping of parts and materials as much as is possible. As the basic principle in realizing this plan. I will uphold the ‘just·in.time’ approach. The guiding rule is not to have goods shipped too early or too late.”

In 1927, 11 years earlier, this is what GM’s Alfred P. Sloan said in a speech on the same subject:

“The quicker merchandise can be moved from the raw material to the ultimate consumer and the minimum amount of merchandise, of whatever it may consist, involved in the ‘float,’ the more efficient and more stable industry becomes.” Speech to Automobile Editors of American Newspapers, 9/28/1927.

Of course, stating a goal and achieving it are two different things. Alfred P. Sloan was the manager who led GM back from near bankruptcy to overtake Ford in the 1920s, become the largest car maker in the world until that position was snatched by Toyota. He knew that JIT was worth pursuing but, for all his management savvy, he was not able to make it happen.

Standardization and the “Best Way”

The document includes a  quote from Alex Warren that describes standardized work as the best known way to complete a job.  Art Smalley and Mike Rother  disagree, specifically with the notion that this is the way standardized work is used within Toyota. To Art Smalley, the standard is a basis for comparison; to Mike Rother, a target condition. I consider Standardized Work to be just a set of rules published for the purpose of ensuring that different people perform the same tasks in the same way. Because it has to be enforced, it is more than a basis for comparison, and it cannot be a target.  While it may be the best known way, describing it as such is hardly a way to encourage improvement.

The risks and benefits of publishing your “way”

A document of this type about the way a company does business gives employees a framework to understand management decisions and business processes.

The challenge in publishing it — even if only for employees — is to actually say something without binding management to courses of action that may become inadequate as business conditions evolve. When crises occur, as it did for Toyota in 2010, management is easily accused of having acted in contradiction to the company’s way by expanding too fast. HP is likewise blamed for having strayed from the “HP way.”

By definition, the Toyota Way is what Toyota says it is. But the Toyota Way 2001 document is intended to serve a specific purpose for the specific audience of Toyota employees in the US. As outsiders, we must consider it on its own merits and see what use we can make of it as a stand-alone document, taken out of context. My read on it is that it is misleading for readers who are just starting their Lean implementation in that they may believe that all they have to do is continuous improvement with respect for people.

The Purpose of Standard Work in Manufacturing

The articles by Art Smalley‘s and  Mike Rother about Standards in The Lean Edge  puzzle me, because it seems we all mean different things by “standard.” On a manufacturing shop floor, in particular, I don’t see Standard Work as a basis for comparison, the best way known to perform a task, or a target condition.  Instead, it is a set of rules published for the purpose of ensuring that different people perform the same tasks in the same way. This is consistent with the Wikipedia definition of a technical standard.

A process can only produce a consistent output at a consistent pace on different shifts in the same plant, as well as in different plants, if it is performed on the same materials, with the same equipment, and by the same methods. That is what standard work is supposed to accomplish, and it is, for both human and technical reasons, more difficult than meets the eye.

So here are a few thoughts I would like to share on this subject:

Standard Work versus Craft Control

When operators on a manufacturing shop floor remain on the same job for years, they come up with their private tricks on how to perform it. They attach “cheater bars” to wrenches, rearrange parts around their stations, and develop the ability to detect anomalies by sight, sound, touch, or smell. By default, as operators perceive this knowledge to be the key to job security, they make sure it remains hidden away in their heads.

British 19th-century craftsman

19th-century craftsman

It leads to a situation that economist William Lazonick called Craft Control, in which management leaves the organization of work on the shop floor to the operators. The focus of Frederick Taylor’s “scientific management” was to replace craft control with managerial control, and it entailed the detailed specification of all operations by specialists. For decades after Taylor’s death in 1915, the management of American manufacturing companies engaged in a tug-of-war with labor to put an end to craft control, and ultimately failed,  resulting in shelves of binders full of specs that nobody pays attention to, except external auditors.

Human resource policies that involved laying off whenever business slows down were an incentive to retain rather than share information. And leaving operators on the same job for years made the specs unnecessary except to train new operators but, when you tried to use them for this purpose, more often than not you found them to be obsolete.

TPS/Lean pursues managerial control too, but in ways that differ as follows:

  1. Operators are hired for a career in the company and retained through downturns.
  2. They are frequently rotated between jobs and become multi-skilled, which requires them to share what they know.
  3. They participate in continuous improvement, leading to the integration of their private tricks into the shared specs.
  4. Instead of Victorian novels in binders, the specs are concise memory joggers on A3 sheets of paper posted above work stations. 

See last July’s post on What are standards for? for examples and details. These differences do not make it easy to implement, but they remove the key obstacles that account for the earlier failure.

Use of A3 instruction sheets

A3 instruction sheets above work stations help supervisors notice discrepancies between the standard and the practice of the operators. When there is such a discrepancy, however, the supervisors must investigate it rather than always “retrain” the operator to conform to the standard. The operator may in fact have improved the process; this improvement needs to be documented and  the standard updated so as to propagate this improvement to all other operators doing the same process. When walking through a shop floor that has such posted instructions, one should check the signature block to see when it was last updated. If it was five years ago, the sheet is useless. In fact, It should have been updated in the last six months.

In The Birth of Lean (p. 9), are Taiichi Ohno’s own words on the subject:

 “…the standard work display panels […] let the foremen and supervisors see easily if the operators were adhering to the standard work procedures. […] I told everyone that they weren’t earning their pay if they left the standard work unchanged for a whole month.”

Changing specs once a month for every operation seems a hectic pace, leaving operators barely enough time to master the new method before changing it. Perhaps it was justified in Toyota’s single machine shop, that Ohno was running  in the early 1950s. Managing revisions in a network with dozens of factories worldwide that is Toyota today is a different kind of challenge.

Avoiding Lean Wallpaper

Posting too many instructions, maps, charts, forms, before-and-after pictures, etc., is counterproductive. The result is visual clutter rather than visual management. Producing, posting, and maintaining displays is work, and it should be done selectively, when it has a clear purpose and is worth the effort.

In daily life, we use complex products like computers, cars, or kitchen appliances without posted instruction sheets. We can, because these products have been engineered for usability and mistake-proofed. Usability engineering is the art of designing human-machine interfaces so that users find the right actions to take without prompting or instruction; it is widely applied to household appliances, based on techniques described in Don Norman’s The Design of Everyday Things. In Taming HAL, Asaf Degani expands on these techniques for application to airliner cockpits and ship control rooms, and Chapters 1 and 2 of  Working with Machines summarizes them as they apply to production equipment. Usability engineering is about making mistakes unlikely, but not impossible; this is why, whenever possible, it is supplemented by mistake-proofing. The following pictures illustrate one of the usability engineering principles. In Pixar’s “Lifted,” the young alien taking a test cannot tell which switch to press; Don Norman shows an example of a control room in a nuclear power plant where technicians have replaced identical joysticks with different beer keg handles to make them easier to tell apart.

Toyota in recent years has been pursuing a reduction in the amount of information posted on the shop floor. They simplified the tasks to eliminate the need for posted instructions, which also made it easier to train new people. This has been going on in several plants worldwide for several years, resulting in continuing improvements in quality and productivity. Instruction materials are kept off line and brought out as needed, like a car’s owner manual.

Stop the Music! | Bill Waddell

See on Scoop.itlean manufacturing

Harley-Davidson has announced a no music in the factory rule – period – no exceptions – no ifs, ands or buts.

“Hundreds of Harley-Davidson employees learned through a memo last week that their radios and music being piped onto the factory floor would be kaput by Wednesday — part of a continuous effort to improve safety.”

“‘It’s a distraction,’ said Maripat Blankenheim, director of external communications for Harley. ‘It’s really important for people – no matter what they do – to be focused on what they do.’”[…]

Behavior policies for working adults & the lean principle of treating people with respect are polar opposites:

Michel Baudin‘s insight:

Bill Waddell takes exception to a policy recently issued by Harley Davidson to stop piping music onto the factory floor. According to him, such policies are demeaning. I can’t follow him there, for the following reasons:

  1. In my book, respect for people includes allowing each person to work without being bothered by somebody else’s music. If you love Country, working all day to Wagner operas would be torture, and vice versa. If you recall Mars Attacks, humankind is saved by the discovery that yodeling makes Martians’ heads explode.
  2. Sound, on a manufacturing shop floor is used for communications. In some factories, specific tunes are used to mark the start and end of shifts and breaks, and to signal alarms coming from different areas. Piping music for entertainment through the public address system interferes with these messages.
  3. If you allow distractions at work, where does it stop? I once visited a car assembly plant in the US, where I saw an operator watch Oprah on TV while screwing on a dome light, and immediately resolved never to buy a car made in that plant. Does music diminish performance? Software engineering guru Tom DeMarco described an experiment where multiple computer programmers were given the same assignment in two rooms, one with music and the other one without. The assignment was to write a program to execute a given series of calculations, which ended up always coming out to zero. Half the programmers in the quiet room noticed it and wrote a program that just printed “0.” None of the programmers in the music room did, and all of them implemented the given series of instructions to calculate 0.
  4. Music plays different roles in different circumstances. When you are driving 100 miles alone on Highway 35 from Minneapolis to Albert Lea, the radio can save your life by keeping you awake. If you need music to stay awake on a production shop floor, it means that your job has been badly designed.

See on

Using project charters: not as easy as it seems

In a comment on a previous post, the Virginia MEP’s Bill Donohue  listed several tools that he feels are particularly useful, among which were Project Charters, and I would like to share my experience with them. The concept is self-explanatory, and you can see a variety of examples by just googling “project charter.” It is simply a form intended to provide a one-page summary of a project.

I have been involved with two multi-year projects with clients who wanted to use this tool, and it seemed such a simple, common-sense approach that I embraced it with gusto. To my great surprise, the project teams didn’t. It just required them to fill in such data as the name of the project, the list of team members and roles, short descriptions of current, ideal and future states, the main implementation milestones, and estimates of what good it would do.  It would be a great summary on an A3 sheet of paper, and a perfect tool to communicate with peers and management, while keeping the team focused on the goals.

But it didn’t turn out that way. Working with teams to generate charters took much longer than anticipated. These documents were perceived as a hurdle to clear before implementation could start. Once generated, they were never referenced in the inner workings of the team but only trotted out for management meetings. They were generated on Excel worksheets based on templates supplied by management and primarily used in PowerPoint slides, in which the font was too small to read on screen. Since most teams did not have access to a large format printer, whenever they were printed, it was on A4/letter-size paper rather than A3.

I wondered why the teams were not embracing this tool. They had a feed-the-bears attitude to it. Managers were the bears that periodically had to be fed, and the charters were offerings to keep them at bay. I thought the charter should instead be a project management tool used primarily used by the team itself, and only secondarily for management communications.

I had previously used a more informal approach, where we would write a one-page memo explaining in plain text the who-what-where-when-why-how of the project. With the signature of the manager in charge of the target area, this memo would then be posted on the shop floor for every affected person to know what was going on and the extent to which their cooperation was needed. It was generally well accepted by project teams as “Communications 101.” One reason management wanted formal charters was standardization. They wanted all projects in the program to have descriptions in a common format to make them easier to review.

Lean implementation was starting in these companies, with management keen to engage employees at all levels and tap into their creativity, but filling out a form is not an activity that we usually associate with creativity. Possibly, management’s demand for charters was sending a mixed message: be creative but follow these standards. It was saying “think out of the box but stay within this box!”

Perhaps the form itself was a problem. In both cases, it had been designed by a committee of managers who were as new to Lean as the rest of the organization, and I thought the following features were mistakes:

  1. There were too many different roles identified for team members. The relevant distinction in practice is between core members, who are committed to the project, and the others, who are only involved. In a line redesign project, for example, the production supervisor in charge and the manufacturing engineer are both core members, but the plant safety expert who needs to approve the design is only involved. In the form, members could be assigned one of four different roles. Some were accountable for the outcome, others executed the project, others yet were consulted on it, and finally, there were those who were just kept informed. It sounded great, but, in fact, created unnecessary complexity and wasted time in discussions of which category each member should be in.
  2. The form confused PDCA with a project plan. The main phases of any project were identified as Plan, Do, Check and Adjust. It really didn’t fit any non-trivial project, which you would break down into smaller tasks each defined by deliverables. PDCA is a discipline you would apply to each of the tasks, as well as to the project as a whole, but Plan, Do, Check, or Adjust would not appear as bars in a Gantt chart or entries in an action item list.  In a setup time reduction project, for example, one task is to shoot a video of the current method, but you cannot fit it under Plan, Do, Check, or Adjust.
  3. The form had boxes for information that the teams could not possess until the project was completed. If you are a carpenter building your 50th staircase, you should be able to summarize current and future states, how long you will need, what good it will do, etc. But if you are a team undertaking setup time reduction on a machine for the first time, you are entering what is for you uncharted territory. Upfront, you don’t even know the details of the existing state, let alone the future. At this point, all your setup time reduction team knows is that its goal is to achieve changeovers under 10 minutes on a specific machine in daily practice. When JFK said “this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth,” this one sentence was enough of a charter to focus the work of tens of thousands of people for the following eight years. There would have been no way, at that point, for fill out an A3 form with more details, because they were unknown.
  4. Project teams are also ill equipped to estimate the economic benefits of their project, and wary of writing down amounts they may be held accountable for. In fact, the first few projects that mark the beginning of Lean implementation are never grassroots initiatives. They are selected by management, for their combination of economic value and skill development potential. The setup time reduction team in our example does not need to estimate the benefits of quick setups; they just need to achieve them, promptly and within budget.
  5. The committee that designed the charter form had also come up with a “smart” naming scheme for projects.  It had codes for site, department, project category, and start date. It was a conditioned reflex for people who had grown up with such naming systems, but it served no useful purpose while adding complexity.

After a long struggle, the teams managed to produce at least partial charters. The managers  were not happy, but they had to make do and let the projects proceed. As they did, however, the charters rapidly became obsolete. The teams did not pay much attention, but the charters had to be updated for management presentations, which revealed another problem: there had been no plan for revision management on the charters. The charters had been generated as worksheets in Excel books, that had been emailed around, copied on memory sticks, and printed. There are technical solutions to manage documents so that revisions are made by authorized editors, reviewed properly, and stored in such a way that you can trace back the history of revisions, but this was not one of them.

What lessons have I learned from this experience? Not wanting to throw out the baby with the bath water, I still think of project charters as a useful tool, but it has to be introduced in phases, initially giving project teams the freedom to experiment with both content and format to come up with documents that are useful to them. The handful of pilot projects at the start of Lean implementation requires management attention, but not much administrative paperwork. Never mind standardization at this stage. Soon afterwards, you have tens of projects running in parallel, orchestrated by a steering committee, and, at that point, project charter A3s can be helpful.

Rather than being defined upfront by a committee of managers, charter formats should be allowed to emerge from the organization’s project experience, with current and past project leaders in charge. There may also be different templates by category of project, considering that different contents may be appropriate for setup time reduction, assembly cells, machining cells, milk runs, supermarkets, kanban, etc. The need for revision control on these documents should also be considered when selecting tools to generate them, which requires more IT expertise than either the project leaders, the managers, and even most Lean consultants have. Their first choice is almost always Excel, and it does not meet the needs. Alternatives to be considered include, for example, Infopath for form generation and Sharepoint for storage, retrieval and revision control on charters.

Why 5S fails

In the Lean CEO discussion group on LinkedIn, Paul Renoir started a discussion on why 5S implementations are not sustained. As one of the participants, Sammy Obara, pointed out, if it’s not sustained, by definition it’s not 5S. The discussion is really about why 5S fails, and failing it does, massively and systematically.  Among the 22 contributions to this discussion to date, there isn’t a single one contradicting its basic premise, and asserting what a great success 5S has been in specific facilities.

What I have written on 5S in this blog before may make me sound as if I thought of it as worthless. It’s not the case. 5S  is a valuable tool, and it is implemented with success in many factories in Japan. The failures that can be seen in the US and Europe are due to misunderstandings, translation errors, and wrong decisions as to when and why it should be implemented. My previous posts on the subjects are as follows:

Why consultants recommend starting with 5S

Consultants often recommend that a company start with 5S for the wrong reasons. One quick look at a plant and you know that it would be better with 5S, but that doesn’t mean that 5S would solve its problems or that the organization is capable of implementing it.

It’s like a kid with problems at school who has a messy room. It’s easy to tell the kid to tidy up the room, but it won’t solve the problems at school, and it won’t be sustained. Whether with a plant or a kid, figuring out what the problems are takes more time and effort, but it is necessary if you want to identify projects (1) that put the organization on track to a solution, (2) that it has the skills and the will to conduct successfully, and (3) that entail changes that will be sustained.

Initial projects that work

Art Byrne, among others, recommend giving stretch goals to projects. The point of stretch goals is that they cannot be reached just by putting in extra effort temporarily. Instead, stretch goals require you to make substantial, physical changes to the work, including modifications of machines or fixtures. Once you have made such changes, not only do you achieve your stretch goals, but you don’t easily revert to the old way. In the initial stages of Lean implementation, the only way you get any 5S to stick is by making it the “finishing touches” on other projects, like cells or SMED. If, instead, 5S is the project, it won’t be sustainable.

5S and involvement by everyone

One aspect of 5S that is lacking in just about every discussion of it that I have seen in English is that, when you make 5S a project on its own, it must involve everyone. Participation is not on a voluntary basis. Everyone from the CEO to the janitor must participate, and it fails unless this actually happens. Most employees consider this cleaning up to be beneath them, and top managers’ direct participation is essential to prevent them from feeling this way and acting accordingly.

This is why 5S is so difficult to implement, especially as your first step towards Lean. On the other hand, if you have taken the content of 5S and, as I suggested before, made it part of such other projects as cells or SMED, you may have, after a year or two, about 20% of your work force unknowingly practicing 5S. At that point, you may choose to make 5S your next project and leverage this 20% to achieve 100% involvement. Then you a have a chance to make it stick.

There are other features of Lean that require participation by everyone, particularly autonomous maintenance, which is the only aspect of TPM that you see widely implemented. Somewhere along your Lean journey, you have to learn how to implement practices that require participation by everyone, which is what, in Japan, is meant by “Total.”

5S is a good choice for your first “Total” program and, in particular, works as a stepping stone to TPM. Once you have your 5S daily routine in place, it is a natural transition to enhance it to include checks on the vital signs of your equipment.

Translation errors about 5S

If 5S efforts were broadly successful, there would be no point in raising an issue. Since, however, they are almost universal failures, it might help to communicate accurately on what 5S actually means.

I first learned about “4S” in Japan in the 1980s, from my mentor Kei Abe, and studied it in the Japanese literature. As the time, it was translated into English as R.I.C.K., for Remove, Identify, Clean, and Keep clean, and I thought it was a reasonable approximation. A few years later, my colleague Crispin Vincenti-Brown introduced me to a major American corporation with plants that bore the traces of a failed 5S implementations, from fading banners on the walls to obsolete markings and dirty work stations. Three years before, the top management had been on a tour of Japan, had seen 5S in action there, and had committed to implement it, going as far as putting a Vice President in charge of it. And this was the result. The operators’ version of the meaning of 5S was “Some Stupid Supervisor Said So.”

By then, it was no longer 4S but 5S, and someone had seen fit to translate the five Japanese words with English words that also started with S. While it was undoubtedly clever, the meaning of these five words just didn’t match the original, and these mistranslations, frequently repeated, now have  become some sort of standard.

Following are explanations of the original five S’s, to the best of my ability:

  • Seiri (整理) does not mean Sort. In everyday Japanese, it means sort out, as in resolving administrative problems. In 5S, it means removing from the shop floor the items you don’t use routinely.
  • Seiton (整頓) does not mean Set in order. In everyday Japanese, it means arranging neatly. In 5S, it refers to having assigned locations and labels for everything you retain on the shop floor.
  • Seiso (清掃) means Clean, not Shine. The idea is to have production operators clean their own workplaces at shift end, so that they notice details like spills, frayed cables, or broken lamps. It is not about making them pretty.
  • Seiketsu (清潔) does not mean Standardize. In everyday Japanese, it is a noun meaning cleanliness. In 5S, it is the reduction of the first three S’s to daily practice by management enforcement, through things like checklists, assignment of responsibility for daily housekeeping activities, and routine audits.
  • Shitsuke (躾) does not mean Sustain. In everyday Japanese, it is a noun, meaning upbringing. It is not an action but the condition you reach when the performance of the first three S’s has become second-nature to the organization.  As long as you tell your kid to brush his teeth every day, you are practicing Seiketsu; once he does it without prompting, you have achieved Shitsuke.

Lean Leadership

In the SME Society of Manufacturing Engineers discussion group on LinkedIn, Sam MacPherson asked for comments on the idea that Lean’s greatest need is he willingness and ability to lead.

Following is the response I posted:

“Willingness and ability to lead”  is too generic, and not what I would answer if asked what Lean’s greatest need is.

I look at it from a manufacturing perspective. As Art Smalley pointed out in his 2006 Shingo Prize conference presentation, what goes by the name of Lean in the US gives short shrift to the engineering of production lines. To me, the greatest need still is to put the proper focus on it.

Applications outside of manufacturing are not my focus, but I think that, likewise, the greatest need is to focus on the core of the activity. When the Gilbreths worked on hospitals 100 years ago, they didn’t try to streamline peripheral functions like billing; instead, they worked on the design of operating rooms, and came up with the now standard way, where nurses prepare tools and pass them to surgeons.

Of course, top management must be willing and able to lead, but it has to be in the right direction, to put the focus on the way work is done. And it is tricky.

On the one hand, Art Byrne tells CEOs to personally participate in Kaizen events, which certainly is a way to convey the message that this activity matters.

On the other hand, it can lead the organization to overemphasize Kaizen events, at the expense of other types of necessary actions. It is also impossible for other employees to forget who is on the team.

Generally speaking, whether on a Kaizen even or a Gemba walk, if the CEO expresses an idea on a technical issue, most will agree because it comes from the CEO, and a few will make a point of disagreeing, because it comes from the CEO. In neither case does the idea receive an objective assessment.