Second Toyota Paradox

From Open Source Ecology
Revision as of 14:36, 10 September 2019 by Marcin (talk | contribs)
Jump to navigation Jump to search

https://sloanreview.mit.edu/article/the-second-toyota-paradox-how-delaying-decisions-can-make-better-cars-faster/

Also known as Set-Based Concurrent Engineering. It is not a linear process - all steps are done at the same time as Concurrent Engineering implies.

For open source product development, modular breakdown and concurrent engineering are kit. Mix in a dash of the Second Toyota Paradox - and we have the most rapid and efficient development method.

set-based concurrent engineering refers to a deliberate effort to define, communicate about, and explore sets of possible solutions, rather than modifying a point solution — and, in some cases, these sets may be deliberately more constrained than common industry practice.

This is consistent with Open Organizations, where constant external feedback drives improvement.

It is about delaying decisions by evaluating sets of prototypes. It involves excessive prototyping.

Concurrent engineering is inherently about horizontal coordination across functions (e.g, managing the interfaces of subsystems), and longitudinal coordination across development stages (e.g., the interface between product design and manufacturing system design).

A Toyota team has, at peak, only about 500 people, as opposed to 750 or so dedicated at peak (Chrysler)