DFx

You are currently browsing articles tagged DFx.

When I talk to long-time colleagues about what we do here at Zebulon Solutions, a typical answer is,  “Good luck with that; most folks won’t know they have a problem until it’s too late.” Not strictly true, but also not that far of the mark, unfortunately.  It is in fact common for startups and even established companies to view the transition from ten working prototypes to volume manufacturing as no-big deal.  It is common for the business plan to include zero dollars for this.  And its all to common for the philosophy to be hey that’s why we have a contract manufacturer.

To be fair it very much depends on the nature and maturity of the technology / products.  For mature technologies and / or mature product lines, bringing the n+1 variant of the product into production is in truth not hat difficult.  But we tend to gravitate toward the “weird s___” products and technologies, typically unproven, typically complex, typically falling into the if it was easy someone else would have already done it category.  Yet even for companies who know they have something new, something novel, something complicated, this denial of the productization magnitude is still disturbingly prevalent.

The reasons for this denial are many. Over commitment from a contract manufacturer, who, in order to win a piece of business in today’s tough economy, may well say “I can do that.” Financial pushback is another common root cause, but eliminating the cost form forecasts does not necessarily eliminate the cost from actuals. Academic or R&D centric development teams with little experience in putting such products into productions also can be too blame.

Some questions organizations can ask themselves to see if they are at risk of productization denial:

  • Is my technology mature?
  • Is my product a variant of an existing, proven product?
  • Has my most senior operations executive launched dozens of new products of a similar complexity and maturity into production?
  • Have I seen a manufacturing line where my CM will build this that is building similar products already?
  • Have I budgeted and planned for production test development? Design validation testing?
  • Have I done a DFMEA?  A PFMEAs? A DFx review?

Lots of YESs, sleep well; too many NOs, better rethink.

Chuck

Tags: , , , , ,

In this dreary economy it’s natural for companies large and small to look for every way possible to cut costs. Organizational fat gets slashed, bill of materials (BOM) costs are scoured, vendors are beat up or replaced, and off-shoring is investigated.  Products can be redesigned to save costs; designs and process can be optimized for manufacturability (shameless plug: Zebulon Solutions offers such redesign and DFx services). And at one level, as long as one is looking at holistic cost of ownership with ROI or IRR factored in and appropriately adjusted for risk, these are good steps.

But it’s not all about cost.  At the product level its also about functionality, branding, reliability, performance–really the right metric is, pardon the cliche, bang for the buck. A poorly designed, cheap product will not sell just as surely as a good, overpriced product.

The right approach is that cost should be a factor in every decision, but not the only factor.  We’re working with a company right now whose 3rd party design house choose a cheap clone of a high performance IC for their new design.  The product functions, but it’s power dissipation, a key spec for this class of product, is way above marketing’s target. It may be solvable, with enough engineering thrown at it, but that also has a cost from an ROI / IRR perspective.  Or it may be that there is indeed a trade-off here of product cost vs a performance spec, in which case management will need to make a tough, yet informed decision of how to resolve.,  Maybe cost will win, but then again maybe not.

Cost is one element, a key one, but it’s not the only element.  Just as the days of cost is no object design are long since past, the days of low cost no matter the result are also numbered.

Chuck

Tags: , , , , , ,

DFx–Design for Manufacturing / Assembly / Test / Cost / Reliability /Supply Chain / Environment  etc (hence the x)–should be part of the DNA of every design team, an integral part of designing to meet requirements just like getting the oscillator frequency or the temperature cutoff right.  But despite best efforts and best intents, it’s still prudent to do a DFx review at key milestones.  So then the question is, how best to do the DFx review?

1. Utilize CAD based DFM / DFA tools that check dimensions , spacings, and just about everything imaginable against a set of design rules, flagging the violations

2. Utilize DFx checklists to manually check the design against a predetermined list of subjective criteria

3. Utilize a highly experienced engineer, with gray in his or her proverbial beard, to go through the design, poking it for issues

The modern proxy for conventional wisdom overwhelming supports approach 1. It’s repeatable, automated and can be run by inexperienced personnel and / or in low cost regions.    There are two main issues however with approach 1:

a) GIGO–garbage in garbage out–the check is only as good as the database of design rules.  It’s challenging to do this in a classic, self contained design-and-manufacturing-all-under-one-roof type company; it’s next to impossible to do this in a global enterprise.

b) You find lots of trees but no forest.

The next most politically correct answer is checklists. The underpinnings of many an ISO process, checklists are also repeatable and have the ability to be checked by lower skilled or remotely outsourced personnel.  The challenge here is that the answers are subjective and also more dependent on the skill level of the person doing the check.  It also of course is not nearly as accurate for minute tolerance issues etc that rely on accurate numbers.  All this said, checklists are an invaluable augment to other DFx options.  Zebulon Solutions’s DFx checklist is available for free on our website.

The bottom on most manager’s list is to let the gray-bearded types with years of experience and manufacturing in their blood have a go at the design.  This is typically at the  forest level with zoom downs into the trees and often into the bark and sap and…  Downside is that this only works with highly talented engineers with the right experience; the upside is this path yields the best results over and over.  The winner by a landslide.  And as bonuses, a) because such engineers can do their view in a fraction of the time of a greenhorn with a checklist, it’s often the most cost effective; and b) in the course of doing a DFx review these same engineers can often spot other issues in functionality.

Of course, combo approaches are often even better, and arming a graybeard with a  checklist and an automated rule checker can only help.  And getting ahead of the curve–learning how to design for manufacturability etc up front and utilizing predictive tools like DFMEAs–is even better.

Here’s to the graybeards!

Chuck

Tags: , , , , , ,

V1.5s–product redesigns typically aimed at cost reduction, bug fixes, supply chain optimization, and / or manufacturabilty improvements–have none of the glamour of their high-bred cousin, the V1.0 new product design, or even their favored step-sibling the much touted Widget2.  Often a V1.5 redesign is transparent to the end user, or changes are downplayed rather than hyped.  While the most common driver for doing a V1.5 redesign is cost reduction, plain and simple, there can be other drivers, including better optimization of the supply chain–either proactively or reactively (e.g. EOL components); optimizing for manufacturing / assembly / yield / test; and bug fixes, or attempts to turn lemons into lemonade.

Occasionally a V1.5 can also provide a marketing or a pricing upside as well, although this is rare.  Years ago I led a V1.5 redesign of the then best selling Palm III pda.  In the end we were not only able to achieve a substantial cost down, but we added a feature twist that actually allowed for a new, higher price point in what became the Palm IIIe/x family. Of course this was not at all publicized, for obvious reasons, but  a brown bag is the lunch of choice for us productization types in general

But most of the time redesigning is below the radar, digging for savings often to the right of the decimal place.  Designing out boutique components and designing in no-name equivalents. Optimizing assembly, spending money on fixtures design optimization and automation instead of labor. Improving test coverage and lowering test time. Simplifying what is too complex and spending the extra effort to do the tough engineering for that which is too simple.  Many world class design teams actually lager their V1.5 hit list even during the V1.0 design, whether for risk avoidance or time-to-market, and pull these back out to capture the costs savings before the true volumes hit with a quick V1.5 spin. Its also a great time to pull out the DFMEA  (Design Failure Mode Effects Analysis) that hopefully was done way back when and double check for fixes that were postponed or deprioritized during the rush to V1.0 release.

Another V1.5 driver can be lessons learned from the design post mortem and from the V1.0 production ramp results.  Despite best engineering efforts up front, its rare that a design is perfect.  This is where its crucial to get feedback from out side of the design world: listen to what the production engineers have to say, discuss yield with a  test engineer, go over failure reports with the reliability and sales teams, and listen to what the customer service and field technicians have learned.

And redesign is often not just a one shot deal–there can be V1.1, V1.2, V1.3, depending of course on product life.  Cost reduction should be an ongoing effort, and  its no something that should just be left to the factory and the supply chain managers. But working in conjunction with these groups is crucial.

Companies who actively enagge in design based redesigns can also realize substantial benefits from their existing vendors.  Many classes of components are sold based on the idea of  sole source design wins, which allows s for clout in sustaining high prices.  I once had a high level product marketing executive for a leading boutique analog IC company, famed for their design support and high prices, come to me and told me that his team had just realized that my design group was were redesigning them out on product after product .  I answered truthfully that it was because they weren’t listening when our buyers asked for price breaks and favored allocations based on rapidly increasing volumes.  He laughed and said, “We’re listening now.” And for a while at least they did listen, and we stopped designing them out.

Cost reduction needs to be holistic–understanding true cradle to grave costs–and also needs to be in tune with business subtleties.  A purchasing manager may be already buying a  component at below its standard cost (resulting in a favorable PPV, or Purchase Price Variance) or cash flow constraints may in fact favor paying more in return for favorable terms.  And both risk and ROI analysis are essential to make sure that the effort to do the redesign will be repaid, even when risk is factored in

Chuck

Tags: , , , , , , ,

This was the most interesting email subject line I had seen in a while, so I jumped at the chance to be a shark for a day, torturing–er, judging–business plan pitches from MBA wannabes at the local b-school. I do a lot of deal screens for the local venture club, so it was not too far afield, even though perhaps productization was not the number one concern on many of these new companies.

The flip side of that coin, however, is that business plans are, or should be, a top concern of many of our productization customers, especially in the clean-tech sector, where we work with a disproportionate number of startups.  As I commented on in a previous blog, it is challenging for clean-tech companies to raise money despite record high prices for oil. And from our own biased little corner of the world, a fair amount of capital is required to get a product into manufacturing.  Besides productization costs (shameless plug: including the services Zebulon Solutions offers)–DFx, tooling, industrialization, production test development, regulatory approval, design validation testing, supply chain set up, process optimization, etc.–there are boring yet expensive things like buying inventory. All this takes capital for a physical product (software is a whole ‘nother beast…).  So raising money is crucial for many companies, and it all starts with a business plan.

This is not a business blog–there are many such critters out there–but the quick basics of a business plan include:

* Market need: what the itch is that needs scratching

* Product solution: how the itch will be scratched

* Market details: how big the market is, what it looks like, and who the competitors are

* Go to market plan: sales channels and get to production strategy

* The team: investors are in violent agreement that this is the most important  part

* Financials: P&L and balance sheet summary (cash is king!)

* Investment opportunity: how much money is being solicited and what is being offered

As to the b-school competition, I did channel my inner shark , ripping gaping chunks of flesh—OK, more like gaping chunks of marketing lapses and financial gaps.  While many plans were a bit underdeveloped, there were in fact several companies with promise, companies that had made some progress, had a team and a market, and had promise for a return for investors.  Not for me to give details but the top two companies were into blimps and cupcakes respectively.  Two of my favorite things…

Chuck

Tags: , , , , , ,

Normally I don’t use this bully pulpit to hawk our wares directly, but a number of folks have been clamoring for more information as to what real productization engagements look like (hey I must be hanging with Zeb too much; I’m beginning to sound like him).  Accordingly we have recently updated our  presentation of case studies, available on our web site under, yup, you guessed it, Case Studies. No points for originality, but we do provide some good real world examples across the spectrum of productization services, from fractional executive engagements to thorough design reviews for manufacturability / testability / etc (aka DFx) to simple, or not so simple, DFMEAs. We also show how these services were applied to a variety of market segments, including medical, clean-tech and industrial.

Chuck

Tags: , , , , , , , ,

I’ve (been) volunteered to lead a workshop for the Rockies Venture Club’s Investor Pitch Academy focused on “Understanding Team Building Dynamics for Business Growth” in February (see https://netforum.avectra.com/eWeb/DynamicPage.aspx?Site=RVC&WebCode=InvestorPitchAcademy).  Would not have been my first choice on topics to talk about but I’ve been helping pull the whole Investor Pitch Academy together for some months and, well,  here I am.  So I started thinking about what this means for productization teams—test development, industrialization, process development, validation testing, DFx, supply chain development, DFMEAs, and the like—and realized that the challenges faced by start-ups on this are really no different from those faced by companies who are serious about building up their productization teams.  So I thought I would attempt to opine on the subject of building a world class productization team:

  1. Make sure you have management buy-off and an effective productization leader. Otherwise you are wasting your time.
  2. A people hire other A people. B people hire C people, C people hire D people, etc.  Therefore never compromise on quality of hires.
  3. Hiring should be treated in a generic way.  There are in fact a number of alternatives from full time, “permanent hires” to contractors to partners to temps.  Of course be cognizant of IRS or other tax issues—as always the advice here is “consult yoru tax advisor”
  4. While one should never generalize, for productization engineers, more so perhaps than many other professions, a little gray in the proverbial beard is often a real necessity.  Many of the issues faced by productization engineers require decisions made based on experience bringing similar products into production.  This can’t be taught at the university.  So while age, flippancy aside, is not a requirement, having a handful of successful product launches under one’s belt is pretty much mandatory.
  5. Generalists have an advantage here:While the trend these days is to hire specialists, for productization there is a real benefit finding engineers who have a breadth of experience in many of the interrelated design, test and manufacturing engineering sub specialties.  For example a mechanical engineer with both design and test experience adds a lot of value.

While traditional hiring is the default choice, outsourcing (warning, shameless plug follows) to a productization services company like Zebulon Solutions can provide a few benefits.

  • Fractional, a key word to know in any case, can be a big cost savings if you need a particular skill set but not full time
  • If your needs are project based—you need such a skill set for the next six months but not permanently—these are also good choices
  • If you do not have the skills sets in your management team to effective manage productization engineers, it may be more effective to outsource the ownership as well as the actual labor
  • The last reason to outsource is to get access to specific skills and world class expertise that are not easy to find.  For productization, especially in the US, finding engineers who have extensive design and manufacturing experience under one roof with a couple of pockets full of successful launches is increasingly rare.  Many competent design engineers have not only never fully launched a product, and many have never even set foot in a factory (I asked this question once to a roomful of engineers at a client for which I was acting as interim VP of engineering.  The answer was only one had launched a product into production before and only one more had ever been in a factory…)

All for now.  Wish me luck on doing this workshop.

Chuck

Tags: , , , , , , , , , , ,

It’s shockingly easy for guys like me to get up on our virtual soapboxes and basically say, “You gotta do the right thing.”  Let’s face it—we all want to take the high road; we all thinkthat we do take that road more times than not.  So wanna be blog-meisters like me can easily say “thou shalt test more” or “thou shalt conduct design reviews” or whatever and it sounds good, albeit a bit pompous.  But let’s face it: business is, for better or for worse, about making money.  So when we make decisions on productization—or most other topics—we gotta do the right thing  and make money.

So to the question at hand—how do we make the right decisions on investing (incurring expenses) on productization?  The answer can be summarized in two words: Risk and IRR.

Risk is easy to understand but tough to quantify.  In general productization efforts lower risk.  Examples of risks that proper productization efforts can mitigate include:

  •  Risk of delays
  • Risk of field failures
  • Risk to brand / image
  • Risk of damage to property or person
  • Liability risks
  • Inventory risks

Examples of productization efforts that fundamentally reduce risk include:

  • Design Validation Testing (see our earlier Productization blog on this topic http://www.zebulonsolutions.com/productizationblog/?p=50/ ), which can mitigate the risk of field failures, property damages, risk to life and limb, and liability risks.
  • Production test development basically mitigates the risk of test escapes that can lead to field failures, returns, and damage to brand, as well as potential risk to property, life and limb
  • DFx reviews address schedule risks, can mitigate inventory risks if proper attention is paid to Design for Supply Chain, etc

The other topic is IRR—Internal Rate of Return—is not so easy to comprehend but easy to calculate.  IRR is a form of return on investment calculation that better handles non steady state conditions than traditional ROI or ROIC calculations.  IRR calculates the return from a series of disparate cash flows—often a negative cash flow representing monthly investments in say a cost reduction redesign and then positive cash flows in the term of lowered cost in production.  Sounds complicated but fortunately spreadsheets can do this calculation easily (almost easily—it’s actually an iterative solver at least in Excel so sometimes needs help to converge, and there is the tricky issue of salvage value.  I can expand on either of these offline if anyone is interested in the details…).  IRR is thus a way to quantify the benefits received from investments in productization.  IRR can deal with time easily by using appropriate time units—months, quarter, weeks, years.

Then the really cool part (I show my age—does anyone use “cool” anymore?)  is one can combine both risk and IRR by using an expected value methodology for calculating IRR.  For example, if one can reduce the risk of field returns by say 10% by doing extensive Design Validation Testing, then one should calculate an IRR using 10% of the current cost of field returns as the payback. In fact even for mundane tasks such as cost reductions the return is never 100.0% certain (Murphy’s Law if nothing else) so one should really use expected value, in such cases as a derating factor,  in any IRR calculation.

The tricky part of course is assigning the right costs, the right risks, the right expected values and the right time frames.  But even if the calculation is not perfect, it’s far better than nothing or the omnipotent finger in the air.

Chuck

Tags: , , , , , , , , ,

Old Zeb has been bellyaching again over on his blog, http://www.zebulonsolutions.com/zebsblog/, about the proliferation of what he calls alphabet leek soup—acronym—that we use in the productization business.  So as a courtesy to Zeb and everyone else, I thought I would take a shot at listing a few of the acronyms we use around the shop regularly.

In return maybe Zeb can tell me what the #&$%$ acknowledge the corn means.

Chuck

Product Development

DFE or DfE    Design for Environment

Environmental conscious design and design for environmental regulations such as WEEE and RoHS

DFM               Design for Manufacturing

DFT                 Design for Test

DFx                 Design For x  

Design review of everything: manufacturing, assembly, cost, test, molding, fabrication, supply chain, environment etc

DVT                Design Validation Test

FMEA             Failure Mode Effect Analysis

DFMEA          Design Failure Mode Effect Analysis

PFMEA           Process Failure Mode Effect Analysis

FEA                Finite Element Analysis

GD&T             Geometric Dimensioning and Tolerancing

HW                 Hardware

SW                  Software

FW                  Firmware

Embedded software

R&D               Research and Development

BOM               Bill of Materials

CR                   Cost Reduction

RF                   Radio Frequency

RFID               Radio Frequency Identification

LED                Light Emitting Diode

SLA                Stereolithograpically produced plastic prototypes

SLS                 Selective Laser Sintering prototypes

PCB                Printed Circuit Board

The raw board or fab

PCBA             Printed Circuit Board Assembly

The assembled PCB

Regulatory

CE                   Conformité Européenne,

“European conformity” in French.  The European Union’s mark of product conformity.

RoHS              Regulation of Hazardous Substances

Government regulations, originally in Europe, pertaining to what hazardous materials may not be included in electrical and electronics products

WEEE             Waste Electrical and Electronic Equipment directive

Government regulations, originally in Europe, pertaining recycling and disposal of electrical and electronics products

UL                   Underwriters Laboratory

FCC                Federal Communications Commission

Program Management

PM                  Project Manager or Program Manager

A program is larger in scope than a project and typically includes multiple projects

PGM               Program Manager

PJM                 Project Manager

PMO               Program Management Office or Project Management Office

PPMO             Program and Project Management Office

P3MO             Portfolio, Program and Project Management Office

PMI                 Project Management Institute

EOL                End of Life

PLC                 Product Life Cycle

Financial

ROI                 Return on Investment

IRR                 Internal Rate of Return

NPV and IRR are inverse functions

NPV                Net Present Value

NPV and IRR are inverse functions

P&L                Profit and Loss

B/S                  Balance Sheet

OP                   Operating Profit

EBITDA         Earnings before interest, taxes, depreciation and amortization

VC                  Venture Capitalist

Tags: , , , , , , , , , , , , ,