Toyota

Jan 25 2012

Toyota lays off 350 Australians

Via Scoop.it – lean manufacturing

Toyota Australia today announced plans to cut 350 jobs at its Altona manufacturing plant, in what it is referring to as a “response to operating conditions.”

Toyota is an ordinary company, after all… In 2010, they mishandled a quality problem; today, they are laying off people. In 1950, when Kiichiro Toyoda laid off Toyota employees, he resigned as CEO. The article here does not suggest in any way that the CEO of Toyota Australia is likewise falling on his sword.

Another reason to call what we do Lean rather than TPS is that we have some control over how Lean evolves.
Via www.themotorreport.com.au

By • Press clippings • 0 • Tags:

Lean versus Toyota

Jan 24 2012

Lean versus the Toyota Production System

Is there a difference between Lean and the Toyota Production System (TPS)? This is a recurring question. The short answer is yes, but, when you look deeper, it is an issue of packaging as well as of substance.

If you are working in a car company, you cannot openly say that you are using Toyota‘s production system. How could you borrow such things from a competitor, especially if you have been in the business 50 years longer? It is embarrassing to employees, and a weak marketing message. So, regardless of how much you actually use from TPS, you must call it your own “Production Way” or “Operating System,” or…

It is even worse if you are not in car manufacturing. If you maintain aircraft for an airline, applying tools from car production will not appear to make any sense. And, likewise, patients in a hospital may not take kindly to the idea that they are treated like cars on an assembly line.
Company-specific names serve a purpose, but we also need a generic name around which to organize literature, public training, professional conferences, blogs, etc. Several were tried in the early 1980s, such as Just-In-Time, Demand Flow Technology, or World Class Manufacturing, but John Krafcik’s Lean Production, introduced in the late 1980s by the book The Machine that Changed the World, swept all aside and, to my astonishment, is still current after more than 20 years.

A generic name like Lean clearly has many practical advantages over TPS. This being said, the minute Lean branched out from Toyota, divergence was to be expected. Major tools of Lean, like Value-Stream Mapping or Kaizen Events are either minor or non-existent in TPS, while the jidoka column of TPS is largely ignored or misunderstood in Lean. See Art Smalley’s presentation at the 2006 Shingo Prize conference, or Working with Machines. The combination of Lean with Six Sigma is also popular in the US, even though Toyota evaluated and passed on Six Sigma.

The umbilical cord, however, was never broken, and the promoters of Lean still use Toyota as a reference. Clearly, nobody would be interested in Lean if it weren’t backed up by the Toyota story, and this raises the question of how far Lean can drift from TPS and still retain this vital link.

The following two comments in the Leadership and Lean The Top 5% discussion group on LinkedIn, highlight the issues. This is what Allison Corabatir has to say, based on her experience at Magna:

There is a lot in a name…. When one says they are implementing TPS, it usually means they are taking a cookie cutter approach and assuming what worked well for Toyota would work well for them too. Obviously, there is no denying that their tools are great and we should learn from Toyota, but in reality, some of the tools need to be tailored to the culture and operation of the company we are working for. […] some tools like VSM does not get enough attention with TPS ( I am a big fan of VSM) and some approaches are totally missing (We put a lot of importance to employee recognisition and rewards). I prefer using the term “lean” and making the system our own.

Who would argue with that?  Anna Johnson,  on the other hand, describes a very different experience:

My experience with TPS has been that there is a greater emphasis on retention, and lowering of costs through collaboration and teamwork and attrition, whereas while lean equally emphasizes cost cutting, headcount reduction seems more acceptable through RIFs…

When Anna says that Lean “emphasizes cost cutting, headcount reduction,” she describes a 180-degrees turn away from TPS. This version of “Lean” isn’t just a watering down but a betrayal. It is taking the approach with which financial managers have hurt US Manufacturing from the 50s to the 70s, and calling it Lean to mislead audiences into believing that it is Toyota’s approach.

Anybody can slap the Lean label on anything, and it is only a matter of time until this free-for-all makes it worthless. It results in implementations that are best described as L.A.M.E. (Lean As Mistakenly Excecuted) or L.I.N.O (Lean In Name Only). To avoid this, you have to start from the underlying principles of TPS and deploy them in an context-appropriate fashion, but it is easier said than done, because Toyota didn’t do a great job of articulating these principles and we have to reverse-engineer them from TPS.

Lists of principles can be long, abstract, vague and toothless like the UN’s Universal Declaration of Human Rights, or short, specific, and actionable, like the US Bill of Rights. In The Toyota Way, Jeffrey Liker spells out specific and actionable principles, but there are 14 of them, which is too many to remember. The Lean Enterprise Institute has 5 principles,  easier to remember but focused exclusively on the flow of materials. They say nothing, for example about human resources. You could claim to follow these principles while practicing yo-yo staffing, hiring massively in boom times and laying off in recessions.

The HBR article on Lean Knowledge Work summarizes Lean principles as follows:

  1. Relentless attention to detail
  2. Commitment to data-driven experimentation
  3. Charging workers with the ongoing task of increasing efficiency and eliminating waste in their jobs.
This is short and specific, and covers ground that the LEI list omits, but it includes no mention of flow.
Following is my own, manufacturing-centric list:
  1. Focus on people are the main driver of performance.
  2. Look for profits in the details of shop floor operations.
  3. All manufacturing is repetitive at some level, even where it doesn’t appear to be.
  4. Make materials, information, and people flow.
  5. Make it easy to do what you do often.
  6. Improve, don’t optimize. Optimization comes to a full stop; improvements never end.

There are good reasons to use the word Lean rather than TPS to designate what we do. Lean evolves in many different directions as it inspires people in different industries to pursue improvement in ways that work in their context, and it is healthy that they should do so. But there will always be bandwagon jumpers just using the label to sell products or services.

By • Asenta selection, Management • 21 • Tags: , , , ,

Jan 24 2012

Lean Knowledge Work

Via Scoop.it – lean manufacturing

Attempts to apply lean approaches to knowledge work have proved frustratingly difficult. Most in the business world believe that knowledge work does not lend itself to lean principles, because, unlike car assembly, it is not repetitive and can’t be unambiguously defined. Consider a bank officer deciding whether to make a loan, an engineer developing a new product, and a social worker ruling on whether a child’s environment is safe: In each instance the work involves expertise and judgment that depend heavily on tacit knowledge—knowledge locked inside the worker’s head.

However, our research in IT, financial, engineering, and legal services reveals that such work can in fact benefit from the principles of the Toyota Production System.

‘Knowledge management’ issues: often just an inability to effectively capture a process.
Via hbr.org

By • Press clippings • 1 • Tags: , ,

Jan 19 2012

Toyota training center in Karnataka, India

Via Scoop.it – lean manufacturing

There is something strange taking place in Bidadi, near Bangalore. Well-dressed young men in some kind of corporate uniform seem to be walking in single file in a marked side-lane that wends its way around a well-groomed, green campus.
Via www.business-standard.com

By • Press clippings • 0 • Tags: , , , ,

House MD with whiteboard

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.

By • Management • 2 • Tags: , , , , ,

hbs

Dec 1 2011

Steven Spear on Problem-Solving with JIT: Not Bad for an Academic Paper

Steven Spear’s The Essence of Just-in-Time:Imbedding diagnostic tests in work-systems to achieve operational excellence  is a working paper from Harvard Business School in 2002 focused on the interaction between JIT and problem-solving. It is an important topic, only briefly alluded to in Lean Logistics and covered in more detail in When to Use Statistics, One-Piece Flow, or Mistake-Proofing to Improve Quality, but there are many other improvement opportunities besides product quality, and shining a light on their relationship with JIT is useful.

Spear’s paper is worth reading because he did his homework: it is based on research that involved immersion in a Toyota supplier support team, visits to seven Toyota plants and 12 suppliers in Japan and the US, and working as an assembler in a non-Toyota plant for comparison. I recommend in particular sections 4 to 7. Section 4 is a case study of mattress manufacturing at Aisin Seiki, from which the following sections draw general conclusions.

You have to look past the other sections, which mainly reflect Spear’s membership in the academia tribe. His research is described as an “ethnographic study,” which conjures up the image of an American or European spending 15 years among the Guaranis of Paraguay recording what they are willing to share of their language and culture. That this vocabulary should be used in a study of Lean reflects how alien the world of manufacturing is to academia.

As an academic, Spear is obligated to reference other academics, but not non-members of the tribe, no matter how major their contributions. For example, the only Japanese author in the bibliography is Takahiro Fujimoto, from the  University of Tokyo, but neither  Taiichi Ohno nor Shigeo Shingo appear. Section 3, on Methods, opens with “Many scholars argue…” With all due respect, the arguments of scholars don’t amount to a hill of beans in Manufacturing, because, unlike Computer Science or Biology, it is not a field to which they have contributed much. From Taylor and Gastev to Ohno and Shingo, the key innovators in Manufacturing have almost all been self-taught, Lillian Gilbreth being the exception with a PhD. Why was Spear’s research not done in an Industrial Engineering department, where its content would normally place it? As I found in my own ethnographic studies of academia, the need for grants pushes researchers in other directions, like genetic algorithms.

By • Management • 2 • Tags: , , , , , , ,

«< 22 23 24 25 26 >