Product Development for the Lean Enterprise: Why Toyota's System Is Four Times More Productive and How You Can Implement It

by Michael N. Kennedy

This is the must-read of the decade for anyone whose livelihood depends on new products. Those familiar with industry today know western companies are scrambling to emulate the Toyota Production System. But most don't realize that Toyota's new product development system is every bit as important to Toyota's ongoing success. If they've heard that Toyota's development engineers are four times more productive than their western counterparts, they probably chalk it up to Toyota Production System techniques. But they're wrong in doing so. While both systems deliver extremely high productivity, and both free people to do their best, there really aren't many similarities in how the systems work. Such techniques as concurrent engineering and parallel development are used to increase options and creative possibilities while at the same time lowering the risk of failure. No company that depends on an ongoing flow of new and improved products can afford to ignore the revelations this book contains or the potential advantages in terms of productivity and creativity that can accrue from the Toyota method.

Genres: Business, Management, Productivity, Reference

254 pages, Hardcover

First published January 1, 2003

Reviews

[Aigars · Rating 5 out of 5]

For me personally this book explained quite a lot of Knowledge based vs Structure based product development approaches and systems. Also it was book that made me rethink quite a lot of behavoirs I see in my work life, thus I am giving it 5 star rating.
It made me think and .. after this I feel ready to consume more professional literature, as I was trying to avoid that in a past.

[Tomas Lundborg · Rating 5 out of 5]

Problemet består i att Toyotas ingenjörer säger att de lägger 80 % av sin tid på värdeaddereande aktviteter, jämfört med 20 % för deras konkurrenter. (16)

problem med en förändringsprocess kan vara att ett antal personers karriärer är beroende med det gamla sättet, dessa kommer att göra motstånd (26)

många utvecklingsprocesser domineras av command and control tanken, vilket medöfr ett administrativ kontrollapparat där uppfyllelse av de regler som finns blir centralt (26)

Önsketänkande är normen för många organisationer, de gör planer och följer planer som inte har en tydlig vision och som många känner är orealistiska. (39)

ett grundproblem är när man har ledare som har ett administrativt fokus, snarare än ett operativt (tekniskt) fokus, det gör att de lättare tappar tråden (40)

när man ska genomföra en stor strukturell förändring är det viktigt att först definiera ett nu-läge, en baseline, utifrån den kan man ta reda på 2 saker 1) vad i vårt nuvarande sätt är orsaken till våra problem, varför ser den ut som den gör, vad är den underliggande orsaken till att det ser ut så, vilka probelm/behov är den tänkt att lösa 2) hur skiljer sig nuläge och drömläge (50-57)

processer kan ibland bli för administrativt tunga, detta gör att värdeadderande aktiviteter för individer sjunker (75)
andra problem som kan uppkomma är a) man lär sig inte emellan projekt b) tekniker har för låg komptens/erfrenhet, oftast för att karriärvägar pekar mot administrativa ledarposter, det saknas vägar att avancera som tekniker, status är låg

ett bra sätt att definera de problem man upplever, samt organisationens försök att lösa dem är att skapa en matris, dels med problemen, dels med en projektmodell, utifrån den kan man sen bedöma huruvida varje "lösning" botar, gör ingen skillnad eller förvärrar problemet (81)

när man genomför en större organisationsförändring så gäller det att a) vara tydlig med ATT det krävs en förändring, varför vi har ett problem idag, och att detta måste lösas. Man bör etablera en "sense of urgency" kring förändringsprocessen. b) sätta upp aggresiva mål som även de förmedlar till resten vart vi ska någonstans c) skapa en förståelse över hur scopet är kring förändringen. d) den ledare som hanterar förändringsprocessen måste vara öppen för nya perspektiv, så att den under väg kan ta i n information och ta korrekta beslut e) skapa en tvärfunktionellt team som hanterar förändringsprocessen, som kan skapa en vy av helheten.

på Toyota så är specifikationen en dokumentation av resultatet, inte ett recept för planen. Dessutom är man nogrann med att skapa en (1) cheif engineer som ansvarar för hela bilen, tutti. Det skapar ett personligt ansvar. Denna person försöker följa upp empririskt, att utvrdera ex. prototyper snarare än att kolla på genomförda aktiviteter. (101)

på Toyota har man arbetat med att hitta alternativa karriärvägar för ingenjörer. Belöningen för att göra ett bra jobb är att få göra det igen, på så sätt har man många som varit med ett antal designcykler. De har ingen ambition att gå och bli administrativa chefer. (116)

man använder ett ansvarsbaserat system till skillnad från ett aktivitetsbaserat system. Det gör att man fokuserar på resultatet, snarare än att alla aktiviteter i en plan genomförs som man först trodde. Detta tillsammans med set-based engineering (att man har en framtung process där man utvärderar många alternativ parallellt i början, för att sedan elimniera otillräckliga alternativ) gör att man aldrig missar deadlines. (136)

process --> många alternativ, till skillnad från ett eller få alternativ (vilket gör att om man missar med det alternativet så blir det dyrt)
ledarskap --> tekniskt, coachande ledarskap, till skillnad från ett administrativt ledarskap
planering/kontroll --> baseras på de resultat som uppkommer (flexibelt), till skillnad från att det baserar på uppgifter och aktiviteter (som är oflexibla, då de inte tar hänsyn till vad som händer under vägen)
arbbetsgruppen --> individuell ecxellens och personligt ansvar, till skillnad från ett utspritt ansvar.

när man ska genomföra en förändring så bör man 1) skapa en angelägenhet kring förändring genom att prata om orsakerna till förändringen 2) att etablera en framtida vision samt väldigt tydliga mål (154)

en strukturellt baserad utvecklingsmiljö bygger på strukturen av de operationella aktiviteterna dvs. procedurer, kontroll, grad av lydnad, utbildning
en kunskapsbaserad utvecklingsmiljö bygger på kunskapen hos individerna dvs. förståelsen kring behoven, information tillgänglig, ansvar och interaktioner i teamen. (173)

att gå från stuktururerad prcess mot mer individuellt ansvar, och i samband med det också ett tekniskt ledarskap som fokkar på att ta operationella beslut som gangar kunden, snarare än det som följer en viss struktur (comliance, structural excellence) (175)

för att en förändring verkligen ska få effekt krävs det att ledaren verkligen committar, att ledaren i magen förstår varför, att ledaren förblir involverad och är redo att agera och att ledaren (176)

till skillnad från den traditionella övertygande, övertalande modellen vid organisationsförändringar så rekommenderar Kennedy en deltagande förändringsprocess. i den deltagande prcessen så låter man de berörda genomföra själva förändringen, ledaren har ansvar att sätta upp vision och mål och tidslinjer. varje förändring ska ha agressiva tidsmål, försök att genomföra förändringen snabbt, en för långsam förändring kan ge sken av obeslutsamhet och att ledingen inte står bakom förändringen. (206)

förändringscykeln: det MÅSTE finnas 1) ett behov för förändring 2) en etablerat nuläge 3) möjligheterna vid förändringarna måste synliggöras 4) dess möjligheter måste utvärderas och beslutas kring 5) definiera de organisatoriska förändringarna 6) förbinda sig till förändringen, säärskilt ledningen 7) förändra organisationen

[Victoria Kuntz · Rating 3 out of 5]

3/5 – This book helps you understand the differences between lean manufacturing and lean product development, wrapped in a storyline with enough plot to keep you engaged. It offers lots of good concepts about shifting your company’s product development philosophy and provides practical insights on implementing Toyota’s lean system.

While the narrative keeps things interesting, some sections felt a bit repetitive. It was tough to make it through to the end especially with the same concepts reiterated multiple times throughout. If you’re looking to grasp how lean principles can boost productivity and drive innovation in product development, this book delivers a solid foundation. It shares a lot of information about the importance of technical leadership and failing fast and removing over standardizing. It’s a decent read for anyone curious about applying Toyota’s methodologies beyond manufacturing, even if it doesn’t dive as deep as some technical readers might hope.

[Randall O. Watkins · Rating 4 out of 5]

This is a great primer about Toyota "Lean" product development.

[Paulina Alarcón · Rating 5 out of 5]

Un libro donde puedes aprender a cambiar de paradigmas explicado con palabras simples

[T Budiman · Rating 4 out of 5]

Product Development is different from Manufacturing, so unlike manufacturing processes, doing product development shouldn't be task-based (or structured-based). Toyota uses what author called Knowledge-based Development (avoiding the word 'lean' to draw its contrast with its usage in manufacturing).

This books also explains how to actually do the necessary cultural and philosophical change in the whole organization through something called participative change.

The only thing that prevent me in giving 5 star to this book is its sloppy editing: there are several typo and in one case there is a double paragraph.

[Ron · Rating 4 out of 5]

There's a big push at my work to adopt the Toyota lean product development philosophy. This book explains that philosophy very well.

[Troy Swinehart · Rating 4 out of 5]

The Boss asked me to read...so I read.

[Stefan · Rating 5 out of 5]

Super Lean Einsteigerbuch leicht durchgängig und nachhaltig erklärt

[Robb · Rating 2 out of 5]

A good "cheerleading" book (aka advertising) for the author's consulting business.