top of page

The misunderstanding of set-based concurrent engineering.

Writer's picture: Hatsuo YamadaHatsuo Yamada

There is a field called LEAN product development. Dr Alan Ward of the University of Minnesota and his disciples went to Toyota for half a year in the early 1990s to study Toyota's product development. The result is a book.


It is organized in the contents of the four cornerstones of Toyota's product development.


Set-based development that reduces risk while achieving high innovation


Chief engineer system responsible for development projects both technically and business-wise


Introduced rhythms and pulls into project management to reduce load fluctuations and allow developers to plan their work. They establish the flow and rhythm.


A team of responsible professionals who plan their work, learn from conflicts, create new knowledge and reuse it


This theory is described in a considerable number of characters.

When I saw this for the first time, I had about 5 question marks on my head.


I think it was good to pay attention to 2.

I thought that three referred to the production process, but it's not a big mistake.

Four is that there are experts who are not responsible for the "responsible expert team"? On the contrary, I was worried.


This time, I will write a little about "set-based development," which is the first of these four.


This set-based game seems to have a method called "point-based design", and it seems that it is a method of suddenly jumping to one "solution" for a big development problem and starting to design it.


"Set-based development" was explained as follows.

In product development, Toyota puts out a large number of alternatives in the early stages of development, and without converging them, evaluates a large number of proposals in parallel until just before the start of detailed design and gradually narrows down.

That meant delaying development decisions to the very end.

Another difference was that Toyota did not specify the product specifications in detail from the beginning but gradually refined and embodied it as the design progressed.

Although Toyota develops products in seemingly inefficient ways, it is overwhelmingly more efficient in designing than other companies. This fact was "Toyota's second paradox."


It took me a long time to figure this out.

Then, I expanded the interpretation considerably and tried to expand the interpretation as to whether it refers to one proposal and an alternative proposal to the top when raising a plan.

Still, I wasn't convinced.

Is it possible to come up with a good idea at the end by dragging several alternatives without narrowing down?


I have no experience in the technical part of vehicle development, so I don't know the specific product development method. However, I was worried that the days would pass without any decision if I did this.


Of all the vehicle development activities, the only thing I experienced was cost planning. Still, if the developers were doing such set-based development, they would say, "They will achieve Goals after the start." I can say with certainty that "they cannot achieve the goal ".


It says that an American company has introduced set-based development and is doing well, but I can't believe it.

I'm sorry that it's boiled raw; this time, I'm sorry for the inconvenience.


It should be noted that "set-based development" is different from Toyota's product development.


 

Please forgive me for giving you this detail 1-2 months in advance.

Perhaps Agile seems to be following this trend.


I will explain the details at a later date.

1 view0 comments

コメント


bottom of page