Dec 9 2011
Sundaram-Clayton wins Platinum in India Manufacturing Excellence Awards
Via Scoop.it – lean manufacturing
Continuing our round-the-world tour of awards, prizes and cups for Lean Manufacturing.
Via www.wheelsunplugged.com
Dec 9 2011
Lean in the operating room
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…
Via www.news-medical.net
Dec 9 2011
Six Sigma R.I.P.
If you google Six Sigma, you get the impression that it is a going concern, with all sorts of organizations offering training and consulting on how to implement it. If you dig just a bit deeper, you run into a Business Week article from June 11, 2007 entitled Six Sigma: So Yesterday? It explained how the best known Six Sigma icons, like GE, 3M, Home Depot, or Motorola were “dialing it back.” Whatever this may mean, it is difficult to imagine ambitious employees in a company showing enthusiasm for a program that is being “dialed back.”
The same article attributes the following statement to GE’s former CEO Jack Welch about Six Sigma: “Even if the concept is applied in areas where perhaps it shouldn’t be, it’ll be worth it in the long run.” It makes you wonder how he would have liked to work in such an area, with management knowingly pressuring him to implement an irrelevant method.
Now that the Six Sigma craze is over, there is no much merit in criticizing it. Ever since I was first exposed to it in the 1990s, I have perceived it as a welcome update of the now 90-year-old tools of Statistical Process Control (SPC), useful in industries where, if your process is mature, your product is obsolete. This applies in semiconductors and other high-technology manufacturing sectors, but not in mature sectors like automotive.
It never struck me as having the potential to be a revolution in business or comparable in scope and impact to Lean. Saying so 10 years ago made many people angry but I did worse: I put in writing, in an article entitled Six Sigma and Lean Manufacturing that was published by the SME in a Six Sigma newsletter in July, 2002.
If you google Motorola +Six-Sigma, you learn that Motorola no longer teaches Six Sigma business improvement. Given that Motorola is where Six Sigma was invented, the equivalent would be for Toyota to dump Lean. Maybe it is time to dial down the Six Sigma training programs.
Dec 7 2011
Did Citroen Use Too Many Phone Calls and Emails in Developing the C5?
Wiegand’s Watch is a monthly letter from Dr. Bodo Wiegand, who runs the Lean Management Institut, the German affiliate of the Lean Enterprise Institute. This month, he focuses on what he perceives to be a wasted use of email and cell phones in the development of the Citroen C5 car. Following is a translation of his letter, followed by my comments:
€ 16 million wasted in the development of the C5 car
Today I was at the airport and saw a billboard.
The development of the C5 at Citroen used 1,410,475 cell phone calls and 3,155,546 e-mails. This is madness. If a phone conversation lasts an average of 2.5 minutes, it works out to 14 670 man-days or 73 man-years.
Assuming writing a technical e-mail on average takes four minutes and that it is read six-times, then these emails took up 65,741 man-days or 321 man-years. Assuming that 50% of these cell phone calls and 50% of e-mails were necessary but non value-added, this adds up to 40,000 man-days or 200 man-years, or € 16 million were needed to do the following:
- Fix processes that are out of control.
- Define nterfaces that were not specified.
- Rethink procedures with qualitative gaps.
- To answer questions.
- To solve problems.
What a huge waste!
What a potential for improvement!
And Citroen boasts about it.
My first reaction is to wonder what is wrong with >1,000 people involved in a multi-year project like the development of a new car communicating extensively? It brings to mind Frederick Brooks’s famous audit of the Tower of Babel project in The Mythical Man-Month. The goal was clear and its lack of feasibility played no part in the failure. Human and material resources were plentiful in Mesopotamia, and were not a problem either. What caused the project to fail was that team members could not communicate.
Product development generates many documents that need to be reviewed, discussed, annotated, updated, revised, and organized. These documents must also be available easily to all those with a need to know, and kept secret from all others. I don’t know on what basis Dr. Wiegand concludes that a large part of Citroen’s communications by phone and email were waste. For all I know, they may have been meaty technical exchanges that improved the design of the C5…
Of course, you don’t need electronic means of communication if everybody is in one big room, but that only works for teams that are small enough. You would need a convention hall for a team in the latter stages of car development, and some activities, like testing in a hot desert or snow, or ramping up production, take place at multiple locations. While always desirable, face-to-face communication is not feasible for everything at all times.
Just based on the statements from Citroen, if I would fault them for anything, it would be for relying on nothing more sophisticated than phones and emails, which is so 20th century. There are now collaboration and on-line meeting tools that combine much richer exchanges with better data security and revision control. For example, engineers at different locations can view the same drawing on their screens, annotate it while discussing through an audio conference, and read each other’s body language through webcams.
Instead of having multiple copies of documents floating around in individual mailboxes, you can keep them in a library on a server to ensure that all participants in a discussion are looking at the same version, and to prevent these documents from leaking out.
You can also fault emails for lacking the kind of structure you find in A3 reports, which discipline authors in providing particular data items while helping readers find them. But again, more advanced communication tools can provide that structure through on-line forms .
For voice communication, there are also alternatives to cell phones. For people whose work causes them to move around within the range of WIFI network, for example, there are wearable devices that allow them to call each other by name and communicate by voice instantly, as if they were side by side.
So maybe the issue is not that Citroen C5 development used to many engineer-years communicating, but that, next time, they should use the state of the art to do it.
Dec 5 2011
Total: All Encompassing or Involving Everybody?
“Total” is used in the names of improvement programs like Total Quality Control (TQC), Total Productive Maintenance (TPM), Total Quality Management (TQM), or Total Flow Management (TFM), but the meaning is different on both sides of the Pacific. In the US, a Total program addresses all the issues related to its object; in Japan, it involves everybody.
When Armand V. Feigenbaum coined the term Total Quality Control in 1951, he meant that Quality Control should start with product development and end with customer support. When Kaoru Ishikawa took the concept to Japan, the acronym TQC was retained, but “Total” translated as “Zensha teki” (全社的), meaning “Company-Wide,” implying the involvement of every department in the organization. A more precise translation “Zenyin sanka” (全員参加) was later introduced, which means “with participation by every employee” and shifts the emphasis even further. Back in the US, the notion of involving everybody arrived in the 1980s when TQC morphed into TQM, but elsewhere, as in Euclides Coimbra’s TFM, it means encompassing an entire supply chain.
Programs that “involve everybody” are programs that every employee is the company must participate in. They are not volunteers but draftees. Understandably, such programs are difficult to implement, and often result in individuals just going through motions to humor their bosses and wait out the program. When joining a company, employees accept rules pertaining to working hours, compensation, expense reports, and interpersonal relations, but these general rules at the corporate level do not specify, for example, which tools are to be used in each job. Individuals don’t necessarily get to choose, particularly in production, but the standards they follow are set at a lower level than top management.
Starting a program that is “Total” in the Japanese sense means extending the reach of corporate mandates. It is easier to do in organizations to which employees have a career commitment than where employees are recruited for specific skills that they have acquired and can re-market elsewhere. Be it easy or hard, you have to consider whether it is wise. A company-wide program is a centralization effort and reduces the autonomy of lower-level business units. As most companies are trying to go in the opposite direction, you really don’t want to start such a program unless (1) its benefits are obvious, and (2) there is no other way.
A TQM program may mandate that the Plan-Do-Check-Adjust (PDCA) process be used when implementing any change throughout the company. Since everybody must participate, the PhD-level scientists at R&D will be required to undergo PDCA training and to formally use it to organize all their activities. As a group, they will be offended and some may quit. Elsewhere in the company, project leaders will dutifully reports their action items as being in a state of P, D, C or A. The organization can claim to be on board with the program but truly is not.
5S, on the other hand, is a program that can only be successful if everybody participates. The benefits of 5S are not easy to quantify, but everybody likes the outcome: given the choice of working on a shop floor with or without 5S in place, few would choose without. The problem is that even fewer show any enthusiasm for doing the work necessary to achieve and sustain this outcome, and this resistance can only be overcome if everybody from top management on down gets physically involved. When touring Japanese plants, you so often see the plant manager pick up a stray scrap of paper off the floor and put it in a dustbin that you feel the incident has been staged, but the message is clear: everyone should behave as if the tidiness of the whole plant depends on the individual behavior of each.
A more modern and successful program involving all employees is Hoshin Planning, a strategy deployment approach that is well described in Pascal Dennis’s Getting the Right Things Done. It results in employees having small, actionable sets of strategic directions, determined with their input and consistent across levels. It is much more sophisticated than the target numbers game that management-by-objectives has degenerated into in many companies, and the vertical and horizontal interactivity of the process makes it impossible for any segment of the organization to opt-out.
A company-wide program is implemented top-down, starting with top management and cascading to the shop floor, with appropriate training at each level. It is different from Robert Schaffer’s Breakthrough Strategy, which starts with a pilot projects effecting a deep transformation of a small segment of the organization, whose success makes it go viral. By providing rapid improvements and building the skills base, the breakthrough strategy bootstraps the Lean transformation of a plant but can take it only so far. Once the leaders of local projects start wondering what their successes add up to and where they are leading, they are ready to pull together and take on the challenge of involving all employees in the parts of Lean for which it is necessary. It is top management’s role to sense when an organization is ready for this transition.
Dec 11 2011
Problem-solving: Dr. House versus the Shop Floor
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.
Share this:
Like this:
By Michel Baudin • Management • 2 • Tags: Continuous improvement, Lean, problem-solving, Project management, Quality, Toyota