Shipulski On Design

Archive for January, 2010

Lean is all about parts. Don’t think so? What do your manufacturing processes make? Parts. What do your suppliers ship you? Parts. What do you put into inventory? Parts. What do your shelves hold? Parts. What is your supply chain all about? Parts.

Still not convinced parts are the key? Take a look at the seven wastes and add “of parts” to the end of each one. Here is what it looks like:

1. Waste of overproduction (of parts)
2. Waste of time on hand – waiting (for parts)
3. Waste in transportation (of parts)
4. Waste of processing itself (of parts)
5. Waste of stock on hand – inventory (of parts)
6. Waste of movement (from parts)
7. Waste of making defective products (made of parts)

And look at Suzaki’s cartoons. (Click them to enlarge.) What do you see? Parts.

Take out the parts and the waste is not reduced, it’s eliminated. Let’s do a thought experiment, and pretend your product had 50% fewer parts. (I know it’s a stretch.) What would your factory look like? How about your supply chain? There would be: fewer parts to ship, fewer to receive, fewer to move, fewer to store, fewer to handle, fewer opportunities to wait for late parts, and fewer opportunities for incorrect assembly. Loosen your thinking a bit more, and the benefits broaden: fewer suppliers, fewer supplier qualifications, fewer late payments; fewer supplier quality issues, and fewer expensive black belt projects. Most importantly, however, may be the reduction in the transactions, e.g., work in process tracking, labor reporting, material cost tracking, inventory control and valuation, BOMs, routings, backflushing, work orders, and engineering changes.

However, there is a big problem with the thought experiment — there is no one to design out the parts. Since company leadership does not thrust greatness on the design community, design engineers do not have to participate in lean. No one makes them do DFA-driven part count reduction to compliment lean. Don’t think you need the design community? Ask your best manufacturing engineer to write an engineering change to eliminates parts, and see where it goes — nowhere. No design engineer, no design change. No design change, no part elimination.

It’s staggering to think of the savings that would be achieved with the powerful pairing of DFA and lean. It would go like this: The design community would create a low waste design on which the lean community would squeeze out the remaining waste. It’s like the thought experiment; a new product with 50% fewer parts is given to the lean folks, and they lean out the low waste value stream from there. DFA and lean make such a powerful one-two punch because they hit both sides of the waste equation.

DFA eliminates parts, and lean reduces waste from the ones that remain.

There are no technical reasons that prevent DFA and lean from being done together, but there are real failure modes that get in the way. The failure modes are emotional, organizational, and cultural in nature, and are all about people. For example, shared responsibility for design and manufacturing typically resides in the organizational stratosphere – above the VP or Senior VP levels. And because of the failure modes’ nature (organizational, cultural), the countermeasures are largely company-specific.

What’s in the way of your company making the DFA/lean thought experiment a reality?

I can’t believe everyone isn’t doing Design for Assembly (DFA), especially in these tough economic times. It’s almost like CEOs really don’t want to grow stock price. DFA, where the product design is changed to reduce the cost of putting things together, routinely achieves savings of 20-50% in material cost, and the same for labor cost. And the beauty of the material savings is that it falls right to the bottom line. For a product that costs $1000 with 60% material cost ($600) and 10% profit margin ($100), a 10% reduction in material cost increases bottom line contribution by 60% (from $100 to $160). That sounds pretty good to me. But, remember, DFA can reduce material cost by 50%. Do that math and, when you get up off the floor, read on.

Unfortunately for DFA, the savings are a problem – they’re too big to be believed. That’s right, I said too big. Here’s how it goes. An engineer (usually an older one who doesn’t mind getting fired, or a young one who doesn’t know any better) brings up DFA in a meeting and says something like, “There’s this crazy guy on the web writing about DFA who says we can design out 20-50% of our material cost. That’s just what we need.” A pained silence floods the room. One of the leaders says something like, “Listen, kid, the only part you got right is calling that guy crazy. We’re the world leaders in our field. Don’t you think we would have done that already if it was possible? We struggle to take out 2-3% material cost per year. Don’t talk about 20-50% because is not possible.” DFA is down for the count.

Also unfortunate is the name – DFA. You’ve got to admit DFA doesn’t roll off the tongue like six sigma which also happens to sound like sex sigma, where DFA does not. I think we should follow the lean sigma trend and glom some letters onto DFA so it can ride the coat tails of the better known methodologies. Here are some letters that could help:

Lean DFA; DFA Lean; Six Sigma DFA; Six DFA Sigma (this one doesn’t work for me); Lean DFA Sigma

Its pedigree is also a problem – it’s not from Toyota, so it can’t be worth a damn. Maybe we should make up a story that Deming brought it to Japan because no one in the west would listen to him, and it’s the real secret behind Toyota’s success. Or, we can call it Toyota DFA. That may work.

Though there is some truth to the previous paragraphs, the main reason no one is doing DFA is simple:

No one is asking the design community to do DFA.

Here is the rationalization: The design community is busy and behind schedule (late product launches). If we bother them with DFA, they may rebel and the product will never launch. If we leave them alone and cross our fingers, maybe things will be all right. That is a decision made in fear, which, by definition, is a mistake.

The design community needs greatness thrust upon them. It’s the only way.

Just as the manufacturing community was given no choice about doing six sigma and lean, so should the design community be given no choice about doing DFA.

No way around it, the first DFA effort is a leap of faith. The only way to get it off the ground is for a leader in the organization to stand up and say “I want to do DFA.” and then rally the troops to make it happen.

I urge you to think about DFA in the same light as six sigma or lean: If your company had a lean or six sigma project that would save you 20-50% on your product cost, would you do it? I think so.

Who in your organization is going to stand up and make it happen?

There is a healthy tension between level of improvement, or level of innovation, and time to market. Marketing wants radical improvement, infinitely short project schedules, and no change to the product. Engineers want to sign up for the minimum level of improvement, project schedules sufficiently long to study everything to death, and want to change everything about the new product. It’s healthy because there is balance – both are pulling equally hard in opposite directions and things end up somewhere in the middle. It’s not a stress-free environment, but it’s not too bad. But, sometimes the tension is unhealthy.

There are two flavors of unhealthy tension. First is when engineering has too much pull; they (we) sandbag on product performance and project timelines and change the design willy-nilly simply because they can (and it’s fun). The results are long project timelines, highly innovative designs that don’t work well, a lack of product robustness, and a boatload of new parts and assemblies. (Product complexity.) Second is when Marketing has too much pull; they ask for radical improvement in product functionality with project timelines too short for the level of innovation, and tightly constrain product changes such that solutions are not within the constraints. The results are long project timelines and un-innovative designs that don’t meet product specifications. (The solutions are outside the constraints.) Both sides are at fault in both scenarios. There are no clean hands.

What are the fundamentals behind all this gamesmanship? For engineering it’s technical risk; for marketing it’s schedule risk. Engineering minimizes what it signs up for in order to reduce technical risk and petitions for long project timelines to reduce it. Marketing minimizes product changes (constraints) to reduce schedule risk and petitions for short project timelines to reduce it. (Product development teams work harder with short schedules.) Something’s got to change. Read the rest of this entry »

There is no question that Six Sigma helps companies make money. So much so that everyone in the manufacturing community knows the five hallowed letters: DMAIC (Define, Measure, Analyze, Improve, Control). It’s straightforward and fully wrung-out. But that’s not the case for the wicked step sister Design for Six Sigma (DFSS). She’s fundamentally different and more complicated. To start, it’s an alphabet soup out there. Here are some of the letters: DMADV, DMADOV, IDOV, and DMEDI, and there are likely more. Does everyone know these letters and what they stand for? Not me. But here is the fundamental difference: with DMAIC the thing to be improved already exists and with DFSS the thing to be created does not. In essence, there is no formalized problem to solve. So what you say?

With DMAIC it’s all about reducing variation relative to the specification; with DFSS there is no specification. In fact, there is no product yet a process on which we can measure variation. First the product itself must be created and its functional performance must be defined over a range of parameters. Only then is manufacturing variation measured relative to the range functional parameters (DMAIC). But I got ahead of myself.

Before creating the thing that does not exist and make sure it meets the functional specification, some mind reading of customer needs is required, an even lesser defined thing. So, there is a round of reading customers minds followed by round of creating something that does not exist to satisfy the customer needs define in the mind reading sessions. Oh yea, then the tolerances must be defined so the product always functions the way it’s supposed to. All this before we turn the DMAIC crank.

My point with all this is to help set expectations when dealing with product design/DFSS. It is wrong to expect the predictability and standardization of DMAIC when doing product design/DFSS.  It’s different.  Product design/DFSS is not the same turn-the-crank kind of operation. That is not to say there is zero predictability and standard work or that predictability is not something to strive for. It’s just different. With product design the problems are unknown at the start and sometime even the fundamental physics are unknown. Please keep this in mind when your product development projects are late relative to hyper aggressive, non-work-content-based schedules or when new products don’t meet the arbitrary cost targets.