Cognition SAE Whitepaper

8/9/2019 Cognition SAE Whitepaper

1/13

05M-373

Program Level Design for Six Sigma

Thomas C. JuddVP, Six Sigma Solutions

Cognition Corporation

Copyright 2005 Cognition Corporation and SAE International

ABSTRACT

Design for Six Sigma (DFSS) has been an initiativewithin product development for over 5 years now. Mostcompanies start out implementing DFSS by using a

collection of tools within marketing and engineering.Even though this often yields isolated, or localizedimprovement in the development of the product, overallproduct performance, cost, and producibility are notsignificantly improved at launch. Furthermore, focus onthe customer delighters is often neglected, or even lost.DFSS needs to be recognized as a process within theproduct development process and applied at theprogram level to fully realize its total potential value. Thispaper will identify key issues that need to be addressedto achieve the full value from DFSS implementation.

INTRODUCTION

Most companies have implemented a ProductDevelopment Process that uses a stage gatemethodology to guide program managers in developing anew product. Furthermore, most stage gate productdevelopment processes are very similar since theyessentially cover the five fundamental steps ofdeveloping a product; market identification, conceptdesign, detail design, design optimization, and designvalidation and launch.

When a program manager develops the resourcerequirements for a new product, the resource demandtypically follows a classic bell shaped curve betweenprogram inception and product launch, with a smallamount of time planned for post-launch activity asillustrated in Figure 1. Unfortunately, time and timeagain, the actual resource deployment to fully launch aproduct follows a much different curve. The slow rampup of resources typically follows the initial program plan,but when the product is launched for production, chaosensues with a vengeance. Fire fighting becomes theprotocol for the design team until the production of theproduct is stabilized and it can be totally turned over to

manufacturing. These fires are typically a direct result othe design team not doing a diligent and robust effort toaccurately predict the performance, producibility and cosof the product within engineering. In fact, thedevelopment of the product is usually based on the

design teams use of the prototype hardware and thepilot production run to identify performance, cost andproducibility problems. Note the typical split of aprograms engineering budget where the majority of thebudget dollars are spent on post launch support asillustrated in Figure 1. Remember the old carpentersadage, Measure twice, cut once.

One of the core philosophies of DFSS is to abide by thatcarpenters adage. Due diligence of employing provenmethods and tools further upstream in the productdevelopment process will yield a tremendous reduction inthe post-launch fire fighting effort as illustrated in Figure1. This has been proven and documented by industry

leaders, such as GE, 3M, Cummins, Seagate, RaytheonGM, Maytag, Honeywell, Delphi and many others.

Most, corporate leadership, even those not activelyimplementing DFSS, recognize that the overall cost ofthe engineering effort within a product developmenprogram is somewhere between 5-10%. Furthermorethe belief is that once the product performance andconfiguration is defined and released by engineering, thecost to make a significant change to the product isoverwhelming and will cut into the planned profit marginas shown in Figure 2.

Product development budgets are tightly set a projectinception with a small fraction of the budget allocated toproblem resolution during manufacturing pilot andprogram launch. In reality a large fraction of thedevelopment cost occurs during product launch. Thegoal of DFSS is to convince management to plan a smalincrease in time and dollars during the design phase inorder to avoid the large cost over runs typical duringproduct launch.

Transitioning the product development curve based onthe promises of DFSS requires a significant cultural shif


2/13

and tremendous support from all levels within theorganization. Even with compelling case stories andcommon engineering sense, this is much easier saidthan done.

However, more and more companies are discoveringthat approaching DFSS as a process thread within theproduct development process and employing a systemsengineering approach to the development of the productenables teams, methods and tools to work together inmaking this transition, and thus reducing overall time tomarket and development cost

Transitioning the product development process from aslow engineering ramp up with serious post-launch firefighting to one that employs more up front predictiveengineering using DFSS methods and tools requires newinitiatives with significant commitment and effort fromvirtually all levels within the organization. These can becategorized under five major headings:

Management Engagement at all Levels

Weave DFSS in the Product Development Process

Program Launch and Management Considerations Just-In-Time DFSS Training Program

Implement Critical Parameter Management

This paper presents an overview of each of these topics.

MANAGEMENT ENGAGEMENT AT ALL LEVELS

Management commitment, and engagement, at all levelsand from several disciplines is imperative for successfulDFSS implementation and deployment. Figure 3

illustrates some of the key management positions thatmust be actively involved in this initiative. This is requiredto shift the product development culture from areactionary, fire fighting mind set to one that isproactive and predictive in nature.

There is a profound difference between managementcommitment and engagement. Many corporatemanagement teams have proclaimed their commitmentto a new initiative and even support the implementationof that initiative via mandate memos, training funds,establishing core focus teams on overhead funds, settingup new procedures and policies, and much more. This

is, indeed, imperative to get momentum behind the newinitiative and to align the corporation with the goals of theinitiative. But this is just the first step for management toensure success.

The real test of management is their response during thedeployment of the DFSS initiative. Once the DFSSinitiative is committed, several more difficult and complexissues will emerge that will test the true level ofmanagement commitment, which will put themanagements passion and faith in this new initiative tothe ultimate test. New issues such as setting newpersonnel and program performance metrics, enforcing

new product development gate deliverables, faithbased investment of additional product developmenfunds, investing in new point solution and infrastructuretools, and keeping the initiative focused on the strategicgoals for success.

The management groups illustrated in Figure 3 are theprimary contributors to successful implementation anddeployment of DFSS. The engineering and programoffice is separated since this represents a classic matrixorganization where engineering supplies the personnel tothe product development programs.

The CEO Office

The CEO Office is the obvious originator and owner ofthe corporate level vision and strategy of the DFSSinitiative. The CEO Office include such positions as theCTO, COO and CFO, all of which need to fully supportthe corporate vision for the initiative. However, the bulkof the engagement will come from the CEO and CTO.

The CEO Office will need to visibly show their support of

the tactical projects that are implemented to accomplishthe strategic vision for DFSS. They must becomeactively engaged in these projects so the entirecorporation sees that DFSS is important to them and thathey are serious about its success. This characteristic ispresent at every company that has been successful inshifting the product development culture via the DFSSinitiative. People need to see their leaders engaged at ahands on level to realize that change is not beingdictated to them, but rather change is being promotedand supported by every level within the leadership team.

Some examples include having the CEO routinely visi

and talk with the people that are in the trenchesimplementing the various projects in support of theinitiative, sit in on gate review meetings, monitor thevarious tactical management teams, personally presenawards, and publish periodic articles or videos in supporof the initiative.

Engineering Management

Engineering management at the vice president anddirector level are the primary owners of the DFSSinitiative, and ultimately the DFSS process whenimplemented. Their implementation responsibility is toset new policies and procedures, define new methods

and tools, support the training and awareness programsand develop a plan to transform the engineering cultureinto a more proactive and predictive mind set via DFSS.

Engineering management needs to work with theprogram managers to show them how DFSS will improvethe program deliverables and add value to the bottomline of the program. They must also keep a morestrategic view of how the DFSS deployment will addvalue to the overall engineering knowledge base andhow to leverage this knowledge for future programsThey must be ready to invest in the training of the


3/13

engineering personnel as well as the new tools that willbe needed to support the DFSS methods and practices.

As part of the implementation leadership team,engineering management must show their engagementin all the aforementioned activities by personally workingwith the various engineering disciplines within their ownorganization as well as cross functional disciplines suchas marketing, supply chain, manufacturing and quality.Since they are the primary owners of this initiative,engineering management must be the most visiblyengaged with the passion, belief and enthusiasm tomake the DFSS initiative a success.

The Program Office

Most large companies have a matrix organization withinengineering where engineering services support theproduct development programs; hence, the programoffice of program managers is a separate group. Inother companies, the program manger may be adiscipline, or role within engineering.

But in either case, the program manager has theresponsibility to develop a product that has a high level ofquality within budget and on schedule. The programmanager can make, or break the DFSS initiative. Theytypically have a tremendous amount of influence sincethey are the ones who ultimately are responsible fordelivering products to the market, and they dont wantanything to get in their way.

Program managers often push back on the DFSSinitiative since they see it as yet another layer of work forthem to do on top of their already overburdenedschedule. Thus, two important things must be done to

win over the program managers, one is a pulltechnique, and the other is push.

The best way to get program managers to adopt DFSS isto show them the value add it will bring to their bottomline. Showing them the value of predictive engineering toreduce the amount of engineering changes, optimizationof the product performance to ensure on time delivery,minimizing the risks of rework at launch and meeting thestated customer needs will develop a pull from programmanagers. Once some of these success stories arepresented to the program office, more and moreprogram managers will want to apply the DFSS processto their programs.

However, generating pull from program managers isoften not enough to fully implement DFSS across theprogram since this will typically result in point solution, orBlack Belt level projects only. Upper management mustalso push the program managers by setting newmetrics for program success and holding the programsaccountable to those metrics. The programmanagement must also be held accountable for the newDFSS inspired deliverable at the gate reviews. Too oftenthe metrics for program success is to release the productto manufacturing on time and within budget. The quality

of the product is an unspoken expectation. Delivery oproduct performance and producibility quality needs tobecome a stated demand via the new set of deliverablesthat ensures program management is using the processmethods and tools in DFSS to ensure productperformance, reliability, manufacturability and of coursemeets customer needs.

Marketing

The old saying, Garbage In, Garbage Out, applies tothe inclusion of marketing in the DFSS initiative. Toooften, marketing is not adequately involved in the DFSSinitiative. One problem is that the D, that is Design inthe DFSS acronym allows marketing to claim that DFSSis for engineering and does not apply to marketingActually, maybe DFSS should be renamed to SSPD, SixSigma Product Development, to avoid the innuendo thait belongs only in engineering.

Of course, nothing could be farther from the truth. It isimperative that marketing is included as an integral teamin deploying DFSS. They are responsible in gathe

meaningful and accurate customer requirements for thenew product development. They need to be trained andmentored on all the methods and tools that apply in theirdomain. They need to supply the guiding light toengineering so that the delivered product meets thecustomer expectations. Without this guidanceengineering will still produce a robust product, but will beforced to make assumptions of what will please thecustomer.

The marketing executive management must become atrue ally with engineering executive management toensure a successful DFSS implementation and

deployment program. Without marketing involvementDFSS ends up becoming nothing more than a set oftechnical tools for engineering.

Manufacturing

Since manufacturing is the recipient of the producdeveloped by engineering, they inherit all the problemsthat are buried in the product due to a lack of predictiveengineering. Hence, manufacturing is typically atremendous supporter of the DFSS initiative and shouldbe included in championing the DFSS implementationinitiative.

To make matters worse, it is the manufacturing budgethat typically is used for the fire fighting effort duringproduct launch. Some companies even have an entiregroup, or department whose sole responsibility is todebug the product launch into production. This efforwill never go away since even with the best effort inpredictive engineering, there will still be some issuesduring production launch. But DFSS will significantlyreduce this effort and capture the residual from themanufacturing budget as pure bottom line profit.


4/13

The DFSS process also mandates the involvement ofmanufacturing during product development in suchactivities as Design for Manufacturability& Assembly,process capability studies, tolerance allocation andprocess controls to meet design specifications. Again,manufacturing typically welcomes this participation withopen arms since they will have some influence on settingthe design specifications to meet manufacturing process,thus minimizing surprises during product launch.

In summary, management at all levels must display theircommitment by visibly engaging in the DFSSimplementation and deployment activities and by holdingtheir subordinates, their peers and themselvesaccountable to the execution of the implementation anddeployment plan.

WEAVE DFSS INTO THE PRODUCT

DEVELOPMENT PROCESS

Design for Six Sigma is more than a collection of tools.In fact, the vast majority of tools prescribed in DFSS hasbeen around for many years, and have been recognizedby other organizations, such as AIAG. (e.g. QFD,DFMEA, DFM/A, Tolerance Analysis, Robust Design,DOE, MSA, etc.). Unfortunately, many companies treatDFSS merely as a collection of tools for designengineering and thus, do not reap the benefits ofdeploying DFSS at the program level.

DFSS is actually a process that prescribes these tools inan orderly method that matches the common productdevelopment process. Hence, DFSS can be viewed as aprocess thread within the product development process.

Critical Parameter Management (CPM) is, in turn, aprocess thread within the DFSS process, which will becovered in more detail later in this paper. Figure 4 usesthe AIAG APQP to illustrate the concept of mapping theclassic five steps of the DFSS process as a thread withina product development process.

In order to effectively develop the DFSS process threadwithin the product development process, the processowners need to establish a cross functional team toinitiate this change. Team members would includerepresentatives from such groups as engineering,marketing, manufacturing, regulatory control, quality,

purchasing and supply chain management. Each teammember will contribute to specific areas within theproduct development process.

The starting point is to determine new, and modify someexisting stage gate deliverables. These deliverablesmust be developed to drive behavioral change ratherthan a mere check box of items. The deliverable muststate quantitative metrics that require the use of DFSSmethods and tools rather than specifying the use ofDFSS tools themselves. An example of this would be torequire the submission of a list identifying the mostcritical, top level system requirements (i.e. CTQs) that

are mandatory to analyze, monitor and validate progressthroughout the product development process. Thiswould drive the behavior to use such DFSS tools asAffinity Diagrams (i.e. KJ Analysis), Quality FunctionaDeployment (i.e. House of Quality), and Design FailureMode Effects Analysis (DFMEA). On the other hand, iuse of these specific tools were listed as the stage gatedeliverables, then the behavior could be to just use thesetools just before the gate review to prove that they weredone, which in turn, hence the check box scenario.

But doing a good job at defining stage gate deliverableswith good, quantifiable metrics is only the beginningHolding the programs accountable for those deliverablesis absolutely mandatory for behavior change successThere are many companies that go to the effort oredefining gate deliverables, but when a program showsup at the gate review without the deliverables, the reviewboard succumbs to the pressures of product releaseschedules and budget constraints. This is a critica

juncture in DFSS deployment where upper managementmust become engaged to enforce the accountability ofprogram deliverables at gate reviews. This is also a key

area where program management performance metricsmust include abiding by the new set of gate deliverablesagain, a mandate from upper management. This is oneof the most telling issue where the rubber meets theroad for upper management commitment andengagement.

Some companies, however, have developed a method togive some flexibility in allowing the stage gate reviewboards to pass programs that have a critical mission toget to production as fast as possible. The deliverablesare ranked, or weighted as to how important they are foprogram success. These rankings are also set as a

metric in the product development process gate reviewsAn example would be that of ten gate deliverables, threeof them require a director level approval to be waved athe review in order to proceed to the next gate, fouwould need a vice president level approval to be wavedand the remaining three deliverables are absolutelymandatory to proceed on to the next gate.

In summary, the DFSS process needs to be woven as athread into the existing product development processthat will inevitably require new, or modified deliverablesat the gate reviews. However, managemenenforcement to hold the programs accountable to thesenew deliverables is the key to successful implementation

of this new process.

PROGRAM LAUNCH AND MANAGEMENT

Implementing DFSS within a product program entails twofundamental requirements; mapping out a plan forsuccess and selecting an initial product program that wilensure success.


5/13

There are several aspects to program implementationplanning that need to be addressed to ensure successfulDFSS integration into the product development program:

Upper management support and engagement iscrucial for the program to be successful. Asmentioned before, this includes the CEO Office andthe Vice Presidents of Engineering, Marketing andManufacturing. This group of people needs tosupport the program via funding and resources andbe engaged in the program activities by enforcingaccountability of the established success metrics.

Develop specific DFSS deliverables and metrics thatcan be used to determine the progress and successof the program. It is imperative to do this to setproper expectations at all levels and to ensure thateveryone is on the same page. This will also assistin the assignment of tasks to the various individualsand teams within the program. This is sometimesvery difficult since many DFSS success metrics areeither somewhat intangible or for cost avoidance,which does not allow for a definitive cost benefit

during the execution of the program. Most of thebenefits of DFSS come from statistically improvedproduction launch and in customer satisfaction.DFSS does have definite ROI, albeit long term afterthe completion of the product development program.Thus, setting quality predictive metrics for productperformance, reliability, producibility and affordabilitywith a constant customer focus should beimplemented during the product developmentprogram.

For the first several DFSS Programs, augmentingthe program budget and resource pool will be

necessary. A team led by a seasoned DFSS BlackBelt, or Master Black Belt needs to be assigned tothe program team to ensure proper execution of theDFSS deliverables. The funding for this team isusually not charged the program, but rather out ofgeneral engineering overhead. Funding will also benecessary for additional engineering tools such as,software and testing equipment. This is one of thebiggest challenges to upper management and will bea definite indicator of their support to shift theproduct development culture.

Implementation of a DFSS Training Program to

match the program deliverables is another keyaspect to success. The Just-In-Time trainingmethod, as described in the next section, is a veryeffective way to transfer the DFSS tools andmethodology knowledge to the program engineers,designers, technicians and managers. But additionalSubject Matter Expert (SME) training will also benecessary for such complex tools as DOE, statisticaltolerancing and measurement system analysis.

Finally, as the program is under way, there should bea method to capture and document all the DFSSknowledge and lessons learned that resulted in this

effort. This should also include debugging theDFSS Process Thread within the ProducDevelopment Process as well as establishing the keybusiness benefits to implementing DFSS on aproduct development program.

Selecting a program to ensure success relies on properselection of the program itself and the qualifications ofthe program manager.

In selecting a program, this may actually be a majosubsystem within a very large, complex program, or itmay be an upgrade to an existing product, or it may be arelatively small program, or it may be identifying the topcritical parameters that will be developed within theprogram. The best scenario is to have a mixture of althese types of programs to get a variety of knowledgecapture and lessons learned that would accumulate ovetime and be applicable to future programs. This concepis illustrated in Figure 5. In all cases, the program needsto be aligned with the current, well known DFSSapplications. This specifically includes mechanicaproducts, electro-mechanical products and chemical, o

process based products. DFSS is not currently weldefined in the industry for embedded softwaredevelopment and definitions of a new transactionaservice. The definitions of these DFSS processes will bedeveloped within the next year, but until then, the initiaDFSS programs should not include these applications.

The program manager is another crucial ingredient forsuccess. This person must believe that the program wilreap several benefits by applying the DFSS process tothe product development activities. This person will needto express their passion in their belief of DFSS andenforce the development of the stated DFSS

deliverables. Ultimately, this person must have an openmind to change in order to brake the paradigm of thatsthe way is has always been done. Hence this personmust have strong leadership qualities and have therespect of upper management, as well as their peersObviously, this will be a very unique individual, but thesescharacteristics are absolutely essential for success.

Another new aspect to program management that isinvolved in implementing DFSS is the embracing ofpredictive engineering analysis as a core activity withinthe program. Since the DFSS process calls fopredictive engineering with variations throughout thedevelopment of the product, an Analysis Roadmap wil

need to be developed to ensure collaboration between althe discrete analyses. Critical Parameter Managementas described in a later section, is a key methodology indeveloping this Analysis Roadmap.

In summary, to ensure successful implementation anddeployment of DFSS at the program level requiresproper planning with definitive success metrics, selectinga program aligned with the DFSS methodology andhaving a program manager that believes in the benefitsof applying DFSS to the program.


6/13

JUST-IN-TIME DFSS TRAINING PROGRAM

Most companies initially implement DFSS using theclassic Wave Training approach used to implementDMAIC Six Sigma in operations. While this method hassome benefits, it usually does not shift the productdevelopment culture at the program level.

Some of the benefits to this approach is that the discrete

DFSS tools will get applied at a very local, or Black Beltproject level. This training will also allow for some of thekey people within the organization to bubble up tobecome the DFSS technical leaders. This method alsobegins to establish a common language of statistics, rootcause effects, and other classic Six Sigma themes withinengineering and marketing. In some respects, this couldbe viewed as getting a DFSS Bachelors Degree

But the only way to get a Masters Degree and on to aPhD in DFSS is to implement DFSS at the program level.Since this entails such a focus on the productdevelopment process, the classic Wave Training modeldoes not fit. In fact, it can actually be a negative.

Consider Person A, who is at the beginning of a programand Person B who is at the end of a program. In classicWave Training, people are recruited to attend theDFSS Black/Green Belt Training, regardless of wherethey are in the program. So, in Week 1 of the DFSSTraining, Person A will get significant benefit of learningthose tools (e.g. QFD, Pugh Selection, TRIZ, etc.), butthere will be no applicability for Person B, and being abusy engineer, may even get annoyed by wasting theirtime. Just the opposite is Week 4 of the DFSS Trainingwhere Person B will get significant benefit of learningthose tools (e.g. Robust Design, Statistical Tolerancing,MSA, etc.), but Person A will get no immediate benefit

from this since their program my not use those tools formonths, or maybe even years.

Just-In-Time (JIT) DFSS Training maps the training tothe product development program as illustrated in Figure6. General awareness training should be made availableto all the members of the program. In fact, thisawareness training may actually be split into technicaland managerial agendas for the respective targetaudiences. In both agendas, DFSS as a process threadwithin the product development process must be thecore theme. The goal of this training is to shift theculture and describe the changes required to do so.

Note that the technical DFSS training is mapped directlyto the stages in the product development process. Thisallows the trainees to immediately apply these new toolswith the help of the assigned DFSS ImplementationTeam. This training can either be offered to eachprogram as they are progressing through the productdevelopment process. Or, it can be set up on a morecorporate level basis with one of the prerequisites ofbeing at a certain stage phase within the productdevelopment process before taking the incrementalclasses.

This method of JIT DFSS Training has been proven tobe extremely effective in both the transfer of knowledgeof the discrete DFSS tools, as well as enforcing thephilosophy that DFSS is a process thread within theproduct development process.

CRITICAL PARAMETER MANAGEMENT

Consider the definition and prediction of the producperformance during a product development programand pose these questions:

How can focus on customer satisfaction bemaintained during the development of a productright down to the component and supplier level?

Which design features control the top-level producperformance requirements, and how much?

Where is all the product performance information

and data, and who controls this?

How often does a product development programreinvent the wheel since there is no way to transfeor share this knowledge from previous products?

How can the DFSS process thread be enabledwithin the product development process?

Critical Parameter Management (CPM) answers all thesequestions, and more. CPM can become the go toresource for the product performance definition.

For those involved in Systems Engineering, CPM is asubset of the classic Systems RequirementsManagement (SRM) activity that deals primarily withwhich some systems engineers call, TechnicaPerformance Measures (TPM). Another name for thissubset of requirements that has been adopted within thegeneral DFSS community is Critical to Quality (CTQ)parameters, a term that originated at GE. But in bothcases, the Critical Parameters of CPM primarily focuson the key performance characteristics (KPC) of theproduct. CPM is the technical infrastructure thread thauses a disciplined methodology to capture all the producperformance information and data into a structuredrepository. It also pulls together all the DFSS tools and

information, which enables the DFSS process within theproduct development process.

The fundamental concept of CPM is illustrated in Figure6, which is sometimes referred to as the V DiagramThe left hand side illustrates the notion of flowing downthe product requirements. This could be seen as theclassic Systems Engineering activity that occurs in manycompanies and includes all types of requirementsHowever, in this environment, there are usually twoshortcomings. The first is that in most cases, theSystems Engineering group architects the produc


7/13

configuration and flows down requirements to a certainlevel within the product hierarchy and then dishes offthe responsibility for a subsystem design team todevelop their portion of the product to the statedrequirements. Also, there is no traceability of the designspecifications up to the system level requirements.Second, the studies, or analyses done at the systemlevel to develop the architecture and requirements arenot tied together to allow for contention management orfor flowing up of design predictions.

This paper will only focus on the flow down ofperformance requirements/parameters. Thus, the leftside of the V Diagram in Figure 7 represents thetechnical performance requirements. The right sideillustrates the concept of flowing up a prediction of thesesame performance parameters via quantitative,mathematical relationships, often referred to as transferfunctions in the DFSS community. Note that thesepredictions include both the nominal and variations. Thepredicted results of these performance parameters canthen be compared against the established target limits ofthe requirements to get a Cp and Cpk, a metric to

measure the variability of the performance parameter.Of course, a Cp of 2, and a Cpk of 1.5 represent aparameter that will perform at the Six Sigma level.

The first step is to capture a qualitative representation ofthe product performance into a hierarchy of parameters.This knowledge exists in every engineering organizationsince most companies are producing products thatperform as intended by design (how well is anotherquestion). This is sometimes referred to as the TribalKnowledge of the product performance. There areseveral resources of that knowledge, marketing, systemsengineering, product design teams, subject matter

experts, manufacturing, partners, and suppliers. Theflow down of the performance parameters along withtheir interactions can be developed by simply interviewall the aforementioned knowledge resources that makeup the Tribal Knowledge. This is illustrated in Figure 8.

Even thought this product performance information set isqualitative and a result of essentially opinions and gutfeel of the various knowledge resources, CPM pulls allthese groups and individuals together to take a top down,or systems level view point of the product performance.This reverses the approach of designing in silos, thentrying to bring the silos together into the product. Also,it exposes all the interactions between the silos and

enables a forum to discuss these interactions and toremain cognizant of them during the product designprocess. This CPM exercise alone brings tremendousvalue to the product development program and creates atemplate of captured knowledge that can be referred tothroughout the program.

Many of the classic DFSS tools directly assist in thedevelopment of this CPM tree, such as gathering theVoice of Customer, the House of Quality and the PughSelection Matrix. Other DFSS tools that indirectly

contribute to the development of this CPM tree are KJand Kano analyses, TRIZ, and DFMEA.

However, the holy grail of CPM is the development of thetransfer functions to quantifiably relate the parametersThis will inevitably prove, or disprove the TribaKnowledge relationship established in the flow downexercise of CPM. It also then allows for the flow up oproduct performance predictions, both to prove thedesign performance viability and to make theperformance parameters robust against producibilityvariations, as well as use case variations. Figure 9illustrates the flow up of performance predictions.

Given the multiple interactions of both the individuacontributors, as well as the transfer functionsthemselves, the program management will need todevelop an Analysis Roadmap. This essentially mapsthe inputs and outputs of the multiple transfer functionswhich are made up of several disassociated resourcessuch as spreadsheets, point solution software and high-end simulation modeling. The CPM tree essentiallydevelops this Analysis Roadmap, as well as manages al

the interactions and interrelationships.

Even without transfer functions the qualitative CPM treeserves as an excellent investigative resource if aparameter fails a validation test. As shown in Figure 9on the right hand side, if a parameter fails a validationtest, the CPM tree allows the design team to firstinvestigate what this failure will affect (i.e. flow up fromthis point), and secondly, it will allow the design team toinvestigate those subordinate parameters that couldpossibly be modified to adjust the measured parameteto pass the test (i.e. flow down from that point). Ocourse, all the interactions between the design silos are

also traceable.

There are many benefits that CPM brings to the productdevelopment program, as well as to the individual teammembers:

Maintains a customer focus via traceability toVOCs.

Determines where to focus resources to develop transfefunctions.

Assists in the development of an Analysis

Roadmap.

Tracks performance predictions and test results.

New, or replacement resources get up to speedquicker via the CPM Tree

Communication tool for review meetings, reportsetc.

Transfer to manufacturing to reduce post launchinvolvement.


8/13


9/13

APPENDIX -- FIGURES

FIGURE 1. THE PRODCUT DEVELOPMENT GOAL OF DFSS

FIGURE 2. PRODUCT COST BREAKDOWN


10/13

FIGURE 3. MANAGEMENT COMMITMENT TO DFSS

FIGURE 4. DFSS IN THE PRODCUT DEVELOPMENT PROCESS


11/13

FIGURE 5. DFSS PROGRAM SELECTION

FIGURE 6. DFSS JUST-IN-TIME TRAINING


12/13

FIGURE 7. THE CPM V DIAGRAM

FIGURE 8. DEVELOPMENT OF THE CPM TREE


13/13

FIGURE 9. THE ANALYTICS OF CPM

FIGURE 10. KNOWLEDGE CAPTURE AND SHARING VIA CPM

Documents

Cognition SAE Whitepaper