Second Toyota Paradox: Difference between revisions
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
It is about delaying decisions by evaluating sets of prototypes. It involves excessive prototyping. | 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).''' | |||
Revision as of 14:33, 10 September 2019
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).