Shipulski On Design

Archive for the ‘Design Engineers’ Category

Axiom 1 – Time is short, so make sure you’re working on the most important stuff.

Axiom 2 – You can’t design out what you can’t see.

In product development, these two axioms can keep you out of trouble. They’re two sides of the same coin, but I’ll describe them one at a time and hope it comes together in the end.

With Axiom 1, how do you make sure you’re working on the most important stuff? We all know it’s function first – no learning there. But, sorry design engineers, it doesn’t end with function. You must also design for lean, for cost, and factory floor space. Great. More things to design for. Didn’t you say time was short? How the hell am I going to design for all that?

Now onto the seeing business of Axiom 2. If we agree that lean, cost, and factory floor space are the right stuff, we must “see it” if we are to design it out. See lean? See cost? See factory floor space? You’re nuts.  How do you expect us to do that?

Pareto to the rescue – use Pareto charts to identify the most important stuff, to prioritize the work. With Pareto, it’s simple: work on the biggest bars at the expense of the smaller ones. But, Paretos of what?

There is no such thing as a clean sheet design – all new product designs have a lineage. A new design is based on an existing design, a baseline design, with improvements made in several areas to realize more features or better function defined by the product specification. The Pareto charts are created from the baseline design to allow you to see the things  to design out (Axiom 2). But what lenses to use to see lean, cost, and factory floor space?

Here are Pareto’s three lenses so see what must be seen:

To lean out lean out your factory, design out the parts. Parts create waste and part count is the surrogate for lean.

To design out cost, measure cost. Cost is the surrogate for cost.

To design out factory floor space, measure assembly time. Since factory floor space scales with assembly time, assembly time is the surrogate for factory floor space.

Now that your design engineers have created the right Pareto charts and can see with the right glasses, they’re ready to focus their efforts on the most important stuff. No boiling the ocean here. For lean, focus on part count of subassembly 1; for cost, focus on the cost of subassemblies 2 and 4; for floor space, focus on assembly time of subassembly 5. Leave the others alone.

Focus is important and difficult, but Pareto can help you see the light.

Many have achieved great success with lean – it’s all over the web. Companies have done 5S, standard work, value stream mapping, and flow-pull-perfection. Waste in value streams has reduced from 95% to 80%, which is magical; productivity gains have been excellent; and costs have dropped dramatically. But the question on everyone’s mind – what’s next? The blogs, articles, and papers are speculating on the question and proposing theories, all of which have merit. But I think we’re asking the wrong question.

Instead of looking forward for the next evolution of lean, we should look back. We must take a fundamental, base-level look at our factories, and ask what did we miss? We must de-evolve our thinking about our factories, and break down their DNA – like mapping the factory genome.

Though lean has achieved radical success, it has not achieved fundamental reduction in factory complexity. Heresy? Let me explain. Lean helped us migrate from batch building to single piece flow. With batch building, a group of parts are processed at machine A, then, when all are finished, the whole family moves to machine B. With single piece flow, a part is processed at machine A then she moves, without her sisters, directly to machine B, resulting in big savings. But in both cases, the fundamental part flow, a surrogate for factory complexity, remains unchanged – parts move from machine A to machine B. Lean did not change it. Lean has taken the bends out of our factory flow and squeezed machines together, but that’s continuous improvement. We’ve got good signals, we’ve got cell-based metrics, and 15 minute pitches. Again, continuous improvement. But what about discontinuous improvement? How can we fundamentally reduce factory complexity?

Factories are what they are because of the parts flowing through them.

Factory flow and complexity are governed by the genetics of the parts. In that way, parts are the building blocks of the factory genome. From the machines and tools to the people, handling equipment, and the incoming power – they’re all shaped by the parts’ genetics. Heavy parts, heavy duty cranes; complex parts, complex flows; big parts, big factories. When we want to make a fundamental change in bacteria to make a vaccine, we change the genetics. When we want to make a fruit immune to a natural enemy or resistant to cold of an unnatural habitat, we change the genetics. So, it follows, if fundamental change in factory complexity is the objective, the factory genome should change.

Don’t try to simplify the factory directly, change the parts to let the factory simplify itself.

Discontinuous reduction of factory complexity is the result of something – changing the products that flow through the factory. Only design engineers can do that. Only design engineers can eliminate features on the design so machine B is not required. Only design engineers can redesign the product to eliminate the part altogether – no more need for machine A or B. In both cases, the design engineer did what lean could not.

Lean is a powerful tool, and I’m an advocate. But we missed an important part of the lean family. We drove right by. We had the chance to engage the design community in lean, but we did not. Let’s get in the car, drive back to the design community, and pick them up. We’ll tell them anything they want to hear, just as long as they get in the car. Then, as fast as we can, we’ll drive them to the lean pool party. Because as Darwin knew, diversity is powerful, powerful enough to mutate lean into a strain that can help us survive in the future.

As an engineering leader I work with design engineers every day. I like working with them, it’s fun. It’s comfortable for me because I understand us.  Yes, I am an engineer.

I know what we’re good at, and I know we’re not good at. I’ve heard the jokes. Some funny, some not.  But when engineers and non-engineers work well together, there’s lots of money to be made. I figure it’s time to explain how engineers tick so we can make more money. An engineer explaining engineers, to non-engineers – a flawed premise?  Maybe, but I’ll roll the dice.

Everyone knows why design engineers are great to have around.  Want a new product?  Put some design engineers on it.  Want to solve a tough technical problem?  Put some design engineers on it. Want to create something from nothing? Design engineers. Everyone also knows we can be difficult to work with. (I know I can be.) How can we be high performing in some contexts and low performing in others? What causes the flip between modes? Understanding what’s behind this dichotomy is the key to understanding engineers. What’s behind this?  In a word, “change”.  And if you understand change from an engineer’s perspective, you understand engineers.  If you remember just one sentence, here it is:

To engineers, change equals risk, and risk is bad.

Why do we think that way?  Because that’s who we are; we’re walking risk reduction machines. And that’s good because in this time of doing more, doing it with less, and doing it faster, companies are taking more risk.  Engineers make sure risk is always part of  the risk-reward equation.

The best way to explain how engineers think about change and risk is to give examples.  Here three examples.

Changing a drawing for manufacturing

Several months after product launch, with things running well, there is a request to change an engineering print.  Change the print? That print is my recipe. I know how it works and when it doesn’t.  That recipe works.  My job is to make sure it works, and someone wants to change it?  I’m not sure it will work.  Did I tell you it’s my job to make sure it works? I don’t have time to test it thoroughly. Remember, when I say it will work, you expect that it will.  I’m not sure the change will work.  I don’t want to take the risk.  Change is risk.

Changing the specification

This is a big one.  Three months into a new product development project, the performance specification is changed, moving it north into unknown territory.  The customer will benefit from the increased performance, we understand this, but the change created risk. The knowledge we created over the last three months may not be relevant, and we may have to recreate it. We want to meet the new specification (we’re passionate about product and technology), but we don’t know if we can. You count on us to be sure that things will work, and we pride ourselves on our ability to do that for you.  But with the recent specification change, we’re not sure we can get it done. That’s risk, that’s uncomfortable for us, and that’s the reason we respond as we do to specification changes.  Change is risk.

Changing how we do product development

This is the big one. We have our ways of doing things and we like them. Our design processes are linear, rational, and make sense (to us). We know what we can deliver when we follow our processes; we know about how long it will take; and we know the product will work when we’re done. Low risk. Why do you want us to change how we do things? Why do you want to add risk to our processes? All we’re trying to do is deliver a great product for you. Change is risk.

Engineers have a natural bias toward risk reduction. I am not rationalizing or criticizing, just explaining. We don’t expect zero risk; we know it’s about risk optimization and not risk minimization.  But it’s important to keep your eye on us to make sure our risk pendulum does not swing too far toward minimization. The great American philosopher Mae West said, “Too much of a good thing can be wonderful.”   But that’s not the case here.

When it comes to engineers and risk reduction, too much of a good thing is not wonderful.

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?

Improving product robustness is straightforward and difficult. Here’s how to do it.

Identify specific failure modes, prioritize them, and go after the biggest ones first. Failure modes can be identified through multiple sources. Warranty data is sometimes coded by failure mode (more precisely, symptom type), so start there. The number one failure mode in this type of data is typically “no problem found”, so be ready for it. Analysis of the actual products that come back is another good way. Returned product is routed to the appropriate engineer who analyzes it and enters the failure mode into a database. A formal design FMEA generates a list of prioritized failure modes through the risk priority number (RPN), where larger is more important. To do this, engineers are hauled into a room and a facilitator helps them come up with potential failure modes. One caution – the process can generate many failure modes, more than you can fix, so make the top five or ten go away and don’t argue the bottom fifty. It makes no sense to even talk about number eleven if you haven’t fixed the top ten. But the best way I have found to identify failure modes (problems) that are meaningful to the customer is to ask the technical services group for their top five things to fix. They will give you the right answer because they interact daily with customers who have broken product. They won’t expect you to listen to them (you never listened before), so surprise them by fixing one or two on their list. They will be grateful you listened (they’ll likely want to buy you coffee for the rest of your career) and your customers will notice.

Once failure modes are identified, define the physics of failure – why the product breaks. This is tough work and requires focused thought and analysis. If, when you break the product, it “looks like” the ones coming back from the field, you have defined the physics of failure. This is the same thing as replicating the problem in the lab. Once that’s defined, create an automated test rig or experimental setup that breaks the product in a way that captures the physics of failure. I call this test rig a robustness surrogate because it stands in for the actual failure mode seen in the field. The robustness surrogate should break the product as fast as possible while retaining the physics of failure so you can break it and fix it many times before product launch. The robustness surrogate should be designed to break the product within minutes, not hours or days – the faster the better.

To know if product robustness is improved, the baseline (or existing) design is broken on the robustness surrogate. The new design must survive longer on the robustness surrogate than the baseline design. The result is A/B data (baseline design/ new design) that is presented at the design review using a simple bar graph format which I call big-bar-little-bar. Keep improving robustness of the new design even if it outperforms the baseline design by a factor of ten – that’s not good enough for your customers.

Don’t stop improving robustness until you run out of time, and don’t stop if you meet the arbitrary MTBF specification. Customers like improved robustness, and in this case too much of a good thing is wonderful.

Using this method, I reduced warranty cost per unit by 75% over a five year period. It worked.

Lean has been beneficial for many companies, helping improve competitiveness and profitability. But, lean has not been nearly as effective as it can be because there is a missing ingredient – product design. Where lean can reduce the waste of making and moving parts, product design can eliminate the parts altogether; where lean can reduce setup times for big machines, product design can change the parts so they no longer need the big machines; where lean can reduce inventory, product design can eliminate it by designing out parts; where lean can make the supply chain more efficient, product design can radically shorten it by designing out the long lead time elements.

The power of product design is even more evident when considering the breakdown of product cost. Here is some data from Nick Dewhurst taken from multiple-hundred DFMA analyses showing the typical cost breakdown of products.

Of the three buckets of cost, material cost is by far the largest 74%, and this is where product development shines. Product design can eliminate 40 to 50% of material cost resulting in radical cost savings. Lean cannot. I will go a bit further and say that material cost reductions are largely off limits to the lean folks since it requires fundamental product changes.

Side note – Probably most surprising about cost breakdown data is labor cost is only 4%. Why we move our manufacturing to “low cost countires” to chase 50% labor reductions to net a whopping 2% cost reduction is beyond me, but that’s for a different post.

Let’s face it – material cost reduction is where it’s at, and lean does not have the toolbox to reduce material cost. There’s no mystery here. What is mysterious, however, is that companies looking to survive at all costs are not pulling the biggest lever at their disposal – product design. Here is a bit of old data from Ford showing that Product Design has the biggest lever on cost. We’ve know this for a long time, but we still don’t do it.

Clearly, the best approach of is to combine the power of product design with lean. It goes like this: the engineers design a low cost, low waste product that is introduced to the production line, and the lean folks improve efficiency and reduce cost from there. We’ve got the lean part down, but not the product design part.

There are two things in the way of designing low cost, low waste products in a way that helps take lean to the next level. First, product development teams don’t know how to do the work. To overcome this, train them in DFMA. Second, and most important, company leaders don’t give the product development teams the tools, time, and training to do the work. Company leaders won’t take the time to do the work because they think it will delay product launches. Also, they don’t want to invest in the tools and training because the cost is too high, even though a little math shows the investment is more than paid back with the first product launch. To fix that, educate them on the methods, the resource needs, and the savings.

Good luck.

Congratulations. You’ve managed to keep your product development engine running. Good work.  But now the hard part. Marketing and sales know new products are a key to profitability, and so does the CEO. So they’ve all asked for more new products, and now you have more active product development projects in the pipeline. The product development folks will do whatever they can to crank out the products. But can they get it done?

When does the product pipeline become too much for your product development engine to handle? We all know you can’t keep adding more new product development projects without adding capacity or improving productivity. Sure you can ask your product development engine to do more (and more), and it will try; but at some point it will run out of gas. So, ask yourself: Has your product development engine run out of gas? How can you tell? If it hasn’t, do you know how many miles are left in the tank?

If you don’t measure it you can’t improve it, that’s what the black belts say. But what to measure? What are the right metrics to tell you if your product development engine is out of gas? One of the best books on the subject is Managing the Design Factory, by Don Reinertsen. The rest of the post is strongly shaped by Don’s book, if not taken directly from it. Remember, genius steals.

The best metrics are simple, relevant to the objective, and are leading indicators. Simple so they’re easy to interpret; relevant so they move you toward the objective, in this case launching more new products; and are leading indicators, in that they are predictors of outcomes, so you can take action before catastrophic outcomes occur.  Here are three good ones. Read the rest of this entry »

Like you, I have been thinking a lot about the recession.  We all want to know how to move ourselves to the other side, where things are somewhat normal (the old normal, not the new one).  Like usual, my mind immediately goes to products.  To me, having the right products is vital to pulling ourselves out of this thing.  There is nothing novel in this thinking;  I think we all agree that products are important.  But, there are two follow-on questions that are important.  First, what makes products “right” to move you quickly to the other side?  Second, do you have the capability to engineer the “right” products?

The first question – what makes products “right” for these times?  Capacity is important to understanding what makes products right.  Capacity utilization is at record lows with most industries suffering from a significant capacity glut.  With decreased sales and idle machines, customers are no longer interested in products that improve productivity of their existing product lines because they can simply run their idle machines more.  And, they are not interested in buying more capacity (your products) at a reduced price.  They will simply run their idle machines more.  You can’t offer an improvement of your same old product that enables customers to make their same old products a bit faster and you can’t offer them your same old products at a lower price.  However, you can sell them products that enable them to capture business they currently do not have.  For example, enable them to manufacture products that their idle machines CANNOT make at all.  To do that means your new products must do something radically different than before; they must have radically improved functionality or radically new features.  This is what makes products right for these times.

On to the second question – do you have the capability to engineer the right products?  Read the rest of this entry »

I wrote an article on the level of savings when product designers are engaged in DFMA. 

Here is an excerpt:

 This month, Shipulski details the company’s lean product-design efforts as he issues a “call to action” for lean manufacturers everywhere to involve their product-design teams. 

Why should the manufacturing engineering community care about engaging the product design community in pursuits such as design for manufacturing (DFM) and design for assembly (DFM)? The answer is simple—to make (and save) money