Second Toyota Paradox

The "Second Paradox" refers to the Strategy of delaying decisions, as discussed in an article at MITSolan Management Review (signup/pay-wall) [1]. It is about delaying decisions by evaluating sets of prototypes. It involves excessive prototyping.

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 key. 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. More constrained that common industry practice means adherence to the 60 elements of OSE Specifications.

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).

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

OSE Relevance

The Paradox is particularly interesting to OSE because it is the essence of involving large teams. In fact, this is what allows the scaling the design process without limits - as part of a larger process involving Modular Design and a Construction Set Approach. This promotes Distributed Market Substitution as a natural outcome, and is well suited to gathering large teams for Solving Pressing World Issues.

By allowing large numbers of independent prototypes to be created, this paradigm allows for as many people to participate as needed. There is no specific limit to the number of people that can participate - it can be thousands or millions for any single product - while allowing project tracking to occur at the same time - without bottlenecks. The key is modularization and Contract-First Design

Assessing Toyota

• A Toyota team has, at peak, only about 500 people, as opposed to 750 or so dedicated at peak (Chrysler)
• Ironically, however, Toyota’s success cannot be attributed to some of the concurrent engineering mechanisms U.S. companies consider essential, such as collocated, dedicated multifunctional teams, a highly structured development process, and frequent meetings with suppliers. First, Toyota does not use collocated, dedicated teams; most development personnel are organized in the traditional “chimney” structure. Toyota has a matrix organization housed within a number of platform divisions (e.g., front-wheel drive, rear-wheel drive, etc.). The general manager of a functional group (e.g., body engineering), in consultation with the chief engineer (shusa) for a car platform, assigns engineers to a vehicle program as they are needed. A handful of engineers will stay with the vehicle program throughout its duration, but most work on the program full-time only during the peak period (in the prototype stages), then move on to another vehicle program, often reporting to a different shusa.
• Excessive prototypes up to 20, 30, or 50 prototypes for parts - [2]

USA

• Shigley is the industry standard method for mechanical design in the USA - Shigley’s Mechanical Engineering Design

It involves point-to-point design -

Toyota

Hint: Yes! This looks better and reflects what we want to do at OSE.

• 

1. The team defines a set of solutions at the system level, rather than a single solution.
2. It defines sets of possible solutions for various subsystems.
3. It explores these possible subsystems in parallel, using analysis, design rules, and experiments to characterize a set of possible solutions.
4. It uses the analysis to gradually narrow the sets of solutions, converging slowly toward a single solution. In particular, the team uses analysis of the set of possibilities for subsystems to determine the appropriate specifications to impose on those subsystems.
5. Once the team establishes the single solution for any part of the design, it does not change it unless absolutely necessary. In particular, the single solution is not changed to gain improvements — to climb the hill.

Summary

Interestingly, authors conclude that Toyota's set-based concurrent engineering is not for everyone - it requires more judgment and skill. Whille they do not reject American efforts of Concurrent Engineering (CE), they conclude that Toyota's method is superior - in a politely-phrased conclusion: We believe these CE approaches will inevitably move companies in the direction of set-based concurrent engineering. This is similar to the inevitability of open source hardware as the new paradigm of physical production.

While open source hardware will be co-opted just like software was - the current question remains: how do we transition from competitive to collaborative in the economy? Open hardware is an insufficient prerequisite. OSE believes that the transformation comes from a cultural shift to a collaborative mindset - collaborative design for a transparent and inclusive economy of abundance.

Related: Paper on 3 Paradoxes of the Toyota Production System (TPS)

• Toyota is a highly successful, highly collaborative, and highly proprietary. It is worth studying for how we build upon the Toyota model and evolve it to a Distributive Enterprise.
• Paper - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.539.485&rep=rep1&type=pdf

1. Paradox or Immutability and Inimitability - 'realizing that Toyota’s success is not in the tools and tactics (what is visible) but instead they have focused on the application of the underlying principles (Spear, 2004b).' Same for OSE. We don't want to prescribe tactics - only suggest them - but we do want to prescribe principles - ie - specify tactics only at the highest level but not in detail. The highest level 'tactic' is collaborative design for a transparent and inclusive economy of abundance.
2. Paradox of autonomy - measuring metrics, not individual people. Measure outcomes of the group.