Dec 16 2011
Dec 16 2011
Discussions of Lean often contain statements like the following:
In a lean manufacturing environment, waste is defined as spending resources on any activity that does not add value to the end customer.
While such statements sound deep in casual conversation, they are impractical. First, not having access to end customers, most employees are left to guess what they might value, and second, much of the work of manufacturing is unintelligible to end customers, like revision control on engineering changes. Everyone recognizes the existence of such activities, but the above definition of waste leads to calling them “non-value added but necessary” or, even worse, “necessary waste.”
Having to resort to such convoluted oxymorons is a clear sign that there is something amiss in the definition. The English literature on Lean uses “waste” as translation of the Japanese “muda,” which just means unnecessary. If an activity is muda, you are better off not doing it. Overproduction is muda because you don’t need it, and so are excess inventory, overprocessing, etc.
More formally, if you eliminate muda, your performance does not degrade in any way. It also means that muda is what keeps your operations from being Pareto-efficient, because, if you didn’t have any muda, there would be no way to improve any aspect of your performance without making others worse.
The bottom line is that there are only two kinds of activities in manufacturing: those you need to do and those you don’t. And you can tell them apart without asking an end customer, by using, for example, Ohno’s famous list of 7 categories.
In what you need to do, you pursue effectiveness and efficiency; for what you don’t, elimination. It is a simple idea. It gets complicated enough when we work out its practical consequences. But we don’t need to make it unnecessarily complicated.
Dec 15 2011
Like warehouses, libraries are storage and retrieval systems, and have the same need to identify and locate physical objects. Almost all manufacturing companies and libraries use numbering systems that are “smart” in that they encode information in the IDs. While it may have been a good idea in 1876, when the libraries’ Dewey Decimal Classification was invented, it is obsolete in the age of databases. But the weight of tradition keeps it going.
Encoding information in part numbers is just as obsolete in Manufacturing, where it increases training costs, unnecessarily complicates information systems, encourages confusion between similar parts having similar IDs, and makes data analysis contingent on the ability to extract the encoded information out of the part numbers. But you hear almost no voices making these points in the manufacturing world.
This article is from 2007 — not exactly breaking news — but it is the most recent I could find about a public library district, in Maricopa County, AZ, that has gotten rid of the Dewey system, uses the books’ ISBNs for IDs, and organizes the library floors like bookstores do. The readers no longer need to learn to decode the book IDs, the categorization of the books is independent of their IDs and can be changed, and all the book data can be retrieved on line without needing the ID, including availability status in branches.
Dec 11 2011
General statements about “the Japanese people” are never right. There are 130M of them, all with different personalities, and >1M companies. There is more to Lean than customer orientation and continuous improvement, namely specific tools developed over 60+ years, which must be learned rather than reinvented. People involvement, while necessary, is not sufficient. Company culture transcends national culture. We worked for Unilever in the Netherlands, the UK, Italy and the US, and the plants in all these different countries had much more in common than with plants of other companies in the same countries. Each country is special in some way, but these special characteristics mean little on a production shop floor. The only people who bring them up are those who want to prevent change.
Dec 11 2011
Dr. House‘s fictional team of doctors may be the most famous problem-solving group on the planet. Week after week, they solve daunting medical mysteries under an abrasive, unfeeling leader, working in their differential diagnosis sessions with nothing more than a tiny white board to write lists of symptoms.
In real life, Steve Jobs, a man with character flaws on a par with Dr. House, was able to lead teams in the development of products from the Apple II to the iPad. In light of this, you may wonder why, when faced with problems like an occasionally warped plastic part or wrong gasket, we need to have a team go through brainstorming sessions in which no idea is called stupid, draw fishbone diagrams and formally ask five times why the defect was produced and why it escaped.
House’s team, Apple engineers and Pixar animators are in professions they chose and for which a thick skin is required. They are the product of an education, training and experience in which abuse is used to filter the uncommitted. By contrast, assemblers and machinists are there not to realize childhood dreams but because these are the best jobs they could get. In addition, if they have even a few years of experience in a non-Lean plant, they have been trained to do as they are told. Outside of work, they can be artists, do-it-yourselfers, or community leaders, but they have not been expected to use the corresponding skills at work.
Over the past decades, many manufacturers have realized that this is a mistake, and that there are emergency response situations that are resolved faster with the participation of the people who do the work than without it, and many small improvement opportunities that are never taken unless operators take them on. But welcoming and soliciting their help is not enough. Historically, the first attempt was the suggestion system, dating back to 1880. It is still in use at many companies, including Toyota, but, while it is part of continuous improvement, it is not an approach to problem-solving. Employees make suggestions about whatever they have ideas about; problem-solving, instead, requires a focus on a subject identified by management or by customers, and usually needs a team rather than an individual.
Kaoru Ishikawa’s concept of the Quality Circle in 1962 was a breakthrough, not only in organizing participants in small groups but also in teaching them the 7 tools of QC to solve quality problems, as well as brainstorming, PDCA, and presentation techniques. The key idea was that pulling a group of shop floor people together was not enough. Quality Circles still exist, primarily in Japan, but the ideas of providing technical tools and a structure to organize small-group activities around projects have propagated many other areas. Setup time reduction projects for example, can be run effectively like Quality Circles but with the SMED methodology taught instead of QC tools. Conversely, if working on quality issues, a Kaizen Event team may use the same technical tools as Quality Circles, but is managed differently.
To an uninvolved engineer, a scientist or a medical doctor, “problem-solving” as practiced by shop floor teams may appear crude and simplistic. He or she may, for example, view a fishbone diagram as a poor excuse for a fault-tree because it makes no distinction between “OR,” “XOR” or “AND” combination of causes. In the fishbone diagram, these details are not omitted for lack of sophistication but instead by due consideration of the purpose. You can fill out a useful fishbone diagram in a brainstorming session with a problem-solving team, but you would get bogged down in details if you tried to generate a full-blown fault-tree. There are many simple techniques that could potentially be applied. The value of a problem-solving method is that, for a given range of problems, it has shown itself both sophisticated enough to work and simple enough to be applied by the teams at hand.
In this as in every other aspect of Lean, it makes a difference whether an approach is adopted for internal reasons or to comply with an external mandate. A customer that has developed a problem-solving methodology may require suppliers to adopt it when responding to quality problem reports. The suppliers then formally comply, but it may or may not be effective in their circumstances. For example, a car company that buys chips from a semiconductor manufacturing may mandate failure analysis on all defective chips, but this analysis will provide information on process conditions as they were six months before, when the chip was made. Since then, the process that caused the defect has gone through three engineering changes that make the results irrelevant. These results would have been relevant for mechanical parts with shorter processes and less frequent engineering changes, but the car company doesn’t differentiate between suppliers.
Dec 9 2011
Via Scoop.it – lean manufacturing
This article points out that Lean in health care shouldn’t be just about administration and patient handling but should reach into the medical and surgical acts, and presents the case of a Danish hospital doing just that. After all, the current operating room procedures are based on the work of industrial engineer Frank Gilbreth in the 1910s. Maybe it is time to revisit them…