Product Development Field Notes

My blog has moved! Redirecting...

You should be automatically redirected. If not, visit http://www.whittierconsulting.com/fieldnotes/ and update your bookmarks.

Tuesday, April 10, 2007

Set-Based Concurrent Engineering: Lean Friend or Foe?

Set-based concurrent engineering (AKA set-based design) is one of the more intriguing and difficult-to-explain practices that Toyota uses in its product development process. Set-based concurrent engineering is a technique for resolving design issues that explores a range of alternatives simultaneously. Over time, those alternatives converge to a final solution. When design decisions cross boundaries, multiple subsystem teams may work concurrently to explore alternatives, meeting up at integration events to evaluate their progress from a whole system perspective.

On the face of it, it seems anti-lean: pursuing multiple alternatives at once, delaying specifications, insisting that downstream partners operate with incomplete information, spending more money on the front end in the hopes that the back end is less expensive. From the perspective of a part design, it sure seems wasteful.

Meanwhile, the research shows that this is one of the most powerful weapons in Toyota's PD arsenal by eliminating a ton of rework in late-stage development. It is also one of the most difficult for lean product development organizations to adapt. Unfortunately, I've seen badly-implemented SBCE derail an entire lean product development effort.

There are two problems that I see in Lean Product Development implementations with respect to SBCE:
--Assuming that the alternatives that don't end up in the product are waste, and refusing to consider it.
--Rushing into it too quickly before the team has a good grounding in lean problem-solving and decision-making.

The way to avoid the first problem is to remind people that the product design is the value that flows in product development. SBCE strengthens the design, making it more robust to changes late in the design process. The way to avoid the second problem is to start slowly. Use convergence techniques on small, isolated problems before trying to solve full-scale system-wide problems. And get some help from someone who's done it before. This is one area where a few days spent with a guide can pay big dividends for the team.

0 Comments:

Post a Comment

<< Home