Verband der Automobilindustrie Quality Management …v5design.eu/wp/wp-content/uploads/VDA-Band-04-1.-Auflage...Dokument wurde bereitgestellt vom VDA-QMC Internetportal am 01.04.2015

Dokument wurde bereitgestellt vom

VDA-QMC Internetportal am 01.04.2015 um 10:42

Nur zur internen Verwendung für Faurecia Autositze GmbH bestimmt.

Quality Management in the Automotive Industry

Quality Assurance in the Process Landscape - General, risk analyses, methods, process models -

DFSS (Design for Six Sigma) 1

st. edition, December 2011

English edition published in December 2012

Verband der AutomobilindustrieVerband der Automobilindustrie

4




VDA-Volume 4: Design for Six Sigma 1

Foreword to the first edition The present description of the procedural model "Design for 6 Sigma" (DFSS) has been drawn up within the framework of the work of the VDA Working Group 4: "Quality assurance in the process landscape – general, risk analyses, methods, process models".

For project-related reasons, use has not been made of all the methods and risk analyses stated in the DFSS road map in the attached examples from the automotive industry as part of the comprehensive work undertaken. The DFSS procedural model described here represents the general state of technology. In practical use, however, different approaches may be applied, depending on the individual company and this document is therefore to be regarded, as all VDA quality management publications, as a recommendation. We thank all the organisations and their employees for their comments and contributions to the compilation of this document The following firms have cooperated in drawing up the document: BMW AG

Robert Bosch GmbH

Daimler AG

Adam Opel AG

Volkswagen AG

ZF Sachs AG

automotive.business.support (Herr Füller) Our thanks also go to all who have given us encouragement and assistance in generating and improving the document Berlin, October 2011

German Association of the Automotive Industry (VDA e.V.)




2 VDA-Volume 4: Design for Six Sigma

Contents Page

1 The establishment of DFSS 6

2 Objective / purpose of DFSS 7

3 Procedure & phase models 9

4 Contents and objectives of project phases with IDOV 11

4.1 The "Identify" phase 11

4.1.1 Objectives 11

4.1.2 Organisational aspects 12

4.1.3 Product-related aspects 12

4.2 The "Design" phase 12

4.2.1 Objectives 12

4.2.2 Activities 13

4.3 The "Optimize" phase 13

4.3.1 Objectives 13

4.3.2 Activities 14

4.4 The "Verify" phase 14

4.4.1 Objectives 15

4.4.2 Activities 15

5 Methods and risk analyses in the project phases using IDOV 16

6 Introduction and implementation of DFSS in organisations 17

7 Project record documents 21

7.1 Method: Project launch document; project agreement 21

7.2 Method: Stakeholder analysis 22

7.3 Method: Multi-generation plan 23

7.4 Method: Risk classification (project) 26





7.5 Method: The KANO model 28

7.6 Method: Affinity diagram 31

7.7 Method: Quality function deployment (QFD) 32

7.7.1 Method: QFD - Voice of the customer / Critical To Quality 33

7.7.2 Method: QFD - CTQ / layout characteristics 35

7.7.3 Method: QFD for layout and process characteristics 37

7.7.4 Method: QFD for process and production characteristics 38

7.8 Method: Design scorecard 39

7.9 Method: Loss function 41

7.10 Method: DRBFM (Design review based on failure mode) 44

7.11 Method: Pugh matrix 47

7.12 Method: Hypothesis tests 49

7.13 Method: Functional block diagram 51

7.14 Method: Effect diagram 53

7.15 Method: Effects chain analysis 54

7.16 Method: Monte Carlo simulation 55

7.17 Method: Parameter diagram 57

7.18 Method: Value flow design 58

8 Roles and tasks 59

8.1 Tasks of executives (top management – those responsibl for the organisation's results) 59

8.2 Tasks of the champion (middle management – responsible for the results of the processes) 60

8.3 Tasks of the master black belt – responsible for the "Design for Six Sigma" initiative) 60

8.4 Tasks of the black belt (Design for Six Sigma project leader) – responsible for the success of the project 61

8.5 Tasks of the green belts (qualified project operatives or project leaders) 61





9 Abbreviations 62

10 Appendix 64

10.1 Example of a hypothesis test (comprehensive table) 64

11 Example of intuitive one-handed movement 66

12 Example of spring plate 88

13 Example of wire clip 110





Illustrations Page

Fig. 1: DFSS in the product creation process 8

Fig. 2: Examples of phase models 10

Fig. 3: The "Identify" phase 11

Fig. 4: The "Design" phase 12

Fig. 5: The "Optimize" phase 13

Fig. 6: The "Verify" phase 14

Fig. 7: Overview of methods; objectives with associated methods / risk analyses and details of sources 16

Fig. 8: Example of a multi-generation plan - 1 24

Fig. 9: Example of a multi-generation plan - 2 25

Fig. 10: Example of risk classification 27

Fig. 11: Kano model 29

Fig. 13: Example of a design scorecard 40

Fig. 14: Example of a DRBFM 46

Fig. 15: Example of a Pugh matrix 48

Fig. 16: Example of an hypothesis test (selection) 50

Fig. 17: Example of a simple function block diagram for continuous lambda control 51

Fig. 18: Example of an effects diagram for commutator wear 53

Fig. 19: Example of a Monte Carlo simulation of an analog voltage adder 56

Fig. 20: Example of a parameter diagram (to illustrate the principle) 57





1 The establishment of DFSS

Shortly after the development and successful introduction of the six sigma methodology, initially with Motorola in1987 and then with Allied Signal and General Electric, the thought suggested itself that elements of this methodology might also be used in earlier phases of product development. The motivating force behind this was the recognition that, while improvements in manufacturing processes achieved in the foreground with "Six Sigma" brought great advantages to the manufacturers, they were barely visible to the end-customer and therefore made no traceable contribution to success in the market-place.

At the beginning of the 90s first reports came from Motorola of a systematic launch-pad for developing products from the very start in such a way that internal and external quality problems simply did not appear: "Design for Six Sigma" was born. This approach was quickly adopted by other companies; in particular it was taken up and developed further by General Electric in a significant way. The attention of top management was directed increasingly on the early phases of product development, in order to ensure that rugged products were generated, right for the market. Reports on impressive company successes at the end of the 90s had the effect that many consultant firms adopted the Six Sigma and DFSS approach as part of their product range. At the same time, many different versions of DFSS were developed, in some cases specific to individual companies. In the last 10 years, Six Sigma and its successor, DFSS, have also spread increasingly across Europe and are now recognized as the latest state of the art.





2 Objective / purpose of DFSS

Design for Six Sigma - DFSS – is a structured procedure for the systematic support of development work in the course of development of product and process. DFSS expands the Six Sigma philosophy to include the aspect of prevention. In this, Six Sigma represents an extremely small proportion of defects in the product (see also the description of the method in VDA volume 4 "Six Sigma").

DFSS is directed toward the following:

achieving the customer's explicit requirements and also his unspoken expectations in order to achieve total customer satisfaction

preventing defective products from the very beginning, rather than improving them once full production has started

designing the products as robust units, based on a knowledge of transfer functions or inter-actions – that is, to make them immune to unavoidable variations in manufacturing, environmental, production and operating and conditions

and finally, developing and/or providing the necessary capable manufacturing processes at the right time.

In this way, DFSS supports the work of development by the targeted, planned and inter-linked use of methods and tools in part-phases or

during the entire product creation process ( DFSS road map). The use of the methods is oriented on a phase model (see "Procedure & phase models").

DFSS should be introduced as early as possible in the product creation process in order to use the maximum freedom for contributing to the final product layout.





Fig. 1: DFSS in the product creation process

The illustration above shows that the cost of changes increases significantly as the project progresses, while the flexibility for making corrections falls away dramatically. DFSS is therefore used in early phases of the project, whereas Six Sigma is applied only when defects have already occurred. DFSS helps to prevent cost-intensive changes in later phases of a project or when the article is in full production. The considered execution of a project using DFSS demands more effort in the early phases. Overall, however, the work is less and the project is completed earlier because unnecessary change loops are prevented (no development continuing into the production phase).

When using DFSS it is sensible to examine the entire value creation chain, involving suppliers where bought-in parts are involved in order to develop a uniform understanding of quality and arrive at an overall optimum.

Change costs

Project Concept Product Pre-production preparations development development Production Product creation process

C

ha

ng

e c

os

ts





3 Procedure & phase models

In the same way as in Six Sigma with the DMAIC phase model, DFSS (design for Six Sigma) divides product and process development into phases.

Objectives and activities are allocated to the individual phases and these are checked at the end of each phase, to determine whether they have been completed. There are numerous methods and tools available to reach the individual phase objectives and carry out the tasks which have been defined; to an extent these methods and tools are familiar from Six Sigma.

Unlike with Six Sigma a wide range of phase models - IDOV, DMADV, IDDOV, etc. – is used. The choice of phase model is based on the industry involved and on history and must be appropriate to the product creation process and/or development process in the individual organisation.

The procedure for product or process development with DFSS is similar, independent of the phase model. The time involved in working through the development tasks can vary but the contents and the methods or tools used are practically identical.

In the automobile sector the phase models IDOV and DMADV are most often used; however, as yet no generally valid standard has been established.

The following chart gives an overview of the common phase models.





Fig. 2: Examples of phase models





4 Contents and objectives of project phases with IDOV

The IDOV phase model has been selected for explanation in this present document.

However, when introducing DFSS into an organisation it is always a question of selecting the phase model which corresponds most closely with the existing procedures in the organisation.

The phases described below are allocated with frequently used methods which can be adapted in terms of application and sequence to the specific project. No reference is made to methods cited in other bibliography, such as "axiomatic design", for which it is not possible to prove any frequent use.

4.1 The "Identify" phase

Fig. 3: The "Identify" phase

The "Identify" phase covers organisational and product-related aspects which are processed sequentially or in parallel.

4.1.1 Objectives

These include a clear definition of the project and prioritized technical requirements (CTQs – "critical to quality" : characteristics with a significant influence on customer satisfaction) and their target values, derived from the customer's requirements (VoC – "voice of the customer").





4.1.2 Organisational aspects

These include the reason for the project, a definition of the project objectives, the make-up of the team, the planning of timings and resources and an examination of the economic feasibility. These points must be recorded in the project launch document.

Methods frequently used include stakeholder analysis, SWOT and project risk classification.

4.1.3 Product-related aspects

The CTQs are derived from the customer's requirements and a competition analysis is drawn up.

Methods frequently used include the Kano model, MSA, multi-generation plan, affinity diagram, product FMEA, design score card, loss function and DRBFM. The QFD method is used to analyse, evaluate and illustrate the association between VoC and CTQs.

4.2 The "Design" phase

Fig. 4: The "Design" phase

4.2.1 Objectives

Definition of functional requirements Choice of the best concept.





4.2.2 Activities

In the design phase the layout characteristics are derived from the CTQs. Alternative concepts are developed and evaluated in terms of their achieving the customer's requirements and the process capability to be expected in production. This is frequently an iterative procedure before the most suitable concept is selected.

In addition to creativity techniques such as TRIZ and morphological cases, other methods frequently used include the Pugh matrix, manufacturing feasibility analysis, DFMA, Poka-Yoke (product-related), product and process FMEAs, DRBFM, functional block diagram, hypotheses test and design score card. The QFD method is used to analyse, evaluate and illustrate the association between CTQs and the layout characteristics.

4.3 The "Optimize" phase

Fig. 5: The "Optimize" phase

4.3.1 Objectives

Specified design elements of the concept which has been chosen, described by design parameters and their tolerances. Capable production processes





4.3.2 Activities

In the "Optimize" phase the elements of the concept which has been chosen are developed in detail, calculated, tested with simulations or test samples and improved in terms of performance and process capability. In this, process development and product development are completed on a mutual basis. The production control plan prototype provided by the VDA can be drawn up and used as the lead document for producing prototypes. Iterative loops are also possible in this phase. The product and the process concept are developed to the point where achievement of the project requirements can be expected with a high degree of certainty. Methods frequently used include the 'P' diagram, Monte Carlo simulation, value flow design and design score card. The QFD method is used to analyse, evaluate and illustrate the association between layout characteristics and process characteristics, as well as between process characteristics and manufacturing parameters.

4.4 The "Verify" phase

Fig. 6: The "Verify" phase





4.4.1 Objectives

- Confirmed product design - Production control plans for pre-production and production (as VDA) - Project documentation for the transfer of knowledge 4.4.2 Activities

In the "Verify" phase proof is generated of the assumptions made previously regarding product performance and process capability. Experience from the production process (pre-production) and from suppliers is incorporated. The information gained is documented and the transfer of knowledge is organised.

Methods frequently used include analyses of the capability of machines, measurement equipment and process, t, SPC, variance analysis, Weibull analysis and design score card.





5 Methods and risk analyses in the project phases using IDOV

Objective Methods – Risk analyses Source

Ide

nti

fy

The start phase contains the basic objectives, the project time-frame and the team make-up. This preliminary phase is the equivalent of "Define"

Project start document Project document

Stakeholder analysis Project document

SWOT VDA volume 4

Multi-generation plan Project document

Risk classification Project document

The "Identify" phase in a development process contains a formal link between the design and the "VoC" (voice of the customer). Here the CTQs are derived and a competition analysis is drawn up

Kano model Project document

Affinity diagram Project document

QFD (VoC) to GTQ) Project document

Product FMEA - DRBFM VDA volume 4

MSA (measurement system analysis) VDA volume 5

Design scorecard Project document

Loss function Project document

DRBFM Project document

Des

ign

The design phase places the emphasis on the CTQs. It contains the deriving of functional requirements, the development, the evaluation of alternative concepts, the choice of the most suitable concept and a determination of 6-Sigma process capability

QFD (CTQs – for layout) Project document

Creativity technique; morphological box; TRIZ VDA volume 4

Manufacturing feasibility analysis VDA volume 4

Pugh matrix Project document

Hypothesis test Project document

Functional block diagram Project document


DoE (design of experiments) VDA volume 4

FMEA (product / process) VDA volume 4

Effect diagram Project document

DFMA VDA volume 4

Effect chain analysis Project document

Poka Yoke - product VDA volume 4

Op

tim

ize

In the "Optimize" phase information on process capability is collected and statistical methods are used for tolerance calculations. In this phase detailed design elements are developed, their performance is predicted and the design is optimized

DFMA VDA volume 4

Product FMEA VDA volume 4


Monte Carlo simulation Project document

Poka Yoke - product VDA volume 4

P diagram Project document


DoE (design of experiments) VDA volume 4

DRBFM Project document

Statistical tolerancing VDA volume 4

Poka Yoke - process VDA volume 4

QFD (layout for process characteristics) Project document

QFD (process characteristics – prod'n parameters) Project document

Value flow design Project document

Process FMEA VDA volume 4

Ve

rify

ANOVA VDA volume 5


SPC control charts technique VDA volume 4

Machine capabilities VDA volume 4 + 5

Process capability VDA volume 4

Weibull analyses VDA volume 3

Fig. 7: Overview of methods; objectives with associated methods / risk analyses and details of sources





6 Introduction and implementation of DFSS in organisations

Great significance is attached to the layout of the processes and structures of an organisation, with the objective of developing products and services in a customer-oriented form, speedily and in a cost-efficient manner. In this, DFSS plays a special role in ensuring a methodical and systematic approach. It is aimed at the development of innovative products and processes which can be created robustly.

The crucial significance of DFSS lies in the multi-dimensional examination of development tasks. A systematically structured procedure is linked to a definition of quality, binding on all functional areas and suppliers, together with the cross-functional use of development and quality methods and the application of objective measurement metrics in such a way that the probability of success of development projects is increased throughout the entire value creation chain for the product or process development.

Various procedures for the successful introduction of DFSS in organisations are recommended in different publications and these will not be dealt with in detail here. In principle, the same general conditions apply as for the introduction of the classic Six Sigma DMAIC approach (see VDA volume 4, ring binder). While it is not absolutely necessary to establish the classic Six Sigma DMAIC approach when introducing DFSS, it does make things very much easier, for example in convincing top management, achieving integration into the organisation culture and the selection of personnel as DFSS candidates.

The most promising approach is the so-called "top down" method, where top management regards DFSS as the right course, encourages it and introduces it in the organisation's management systems. In doing so, it must be ensured that DFSS is appropriate for the organisation strategy, its image and its QM system. Only when DFSS integrated carefully and comprehensively into the systems can contradictions be prevented. However, the "bottom up" approach can also be employed to implement DFSS into an organisation. Here, the interest of the work-force is wakened by successful projects and the intelligent us of DFSS methods.

Organisationally, in most automobile companies, DFSS is located in central or de-centralised quality management. However, this is not an essential requirement, since preventive quality work must take place within the development processes. Thus it is not only credible but in fact essential that the methods are used by the development personnel. The





quality departments can make an additional contribution, by statistical analyses, for example, or by presenting the use of individual methods.

Success in implementing DFSS is not based solely on a stringent procedure – the overall concept is of significant importance. To provide a better illustration of the framework in which a successful DFSS project can operate, there follows a description of eight factors for success which should always be kept in mind.

Control of the DFSS project by management and/or the board: The lasting success of DFSS projects can be achieved only if managers and top management stand wholeheartedly behind the system and thereby make a contribution to motivating and supporting employees in good times and bad. Continuous control of a DFSS project is essential.

Clearly structured choice of project and consistent project management:

When selecting a DFSS project is important to realize that it must be shown to be of use and that the IDOV phases can be applied in a sensible manner. In addition, particular value is placed on an orderly and continuous project management, so that projects can be completed in the planned time. DFSS should always be adapted to the development project and not the other way round !

Oriented to the customer: The objective of such a quality program must always be to satisfy the customer's wishes. To achieve this, DFSS demands a strong focus on the customer and his wishes. The customer's wishes and requirements (the voice of the customer) must be defined clearly because they determine the objective of the project. In working on the project, consideration is given both to internal and external customers. The external customer is usually the end-user and buyer of the product, while internal customers are frequently the partners at interfaces in the value creation chain.

Use proven methods in a structured procedure: Processes within a development are creative operations which can seldom be formalised fully into a plan when they are first used. Within the framework of DFSS a structured cycle (e.g., IDOV, DMADV, IDDOV) is mainly operated by known methods. The advantage of this lies in the systematic and consistent use of the methods, as well as in the combination of individual tools. To an extent these can be processed with the aid of special software support.





Method training for suitable employees: Various defined roles are provided for employees within the framework of DFSS. In his/her position manager, a "champion" charges methods experts with the implementation of the DFSS project. Typically, so-called DFSS "black belts" or "DFSS "green belts" will take on the methodical tracking of development projects. A "master black belt" supports the champion in managing the DFSS initiative and in selecting the employees for the various projects. In addition, master black belts take the lead in managing DFSS projects where complex tasks are involved. They also instruct and coach employees in DFSS programmes. Master black belts are also responsible for coordinating changes. In executing DFSS projects the DFSS black belt leads the team and supports the use of different methods. He/she works actively with or takes over to an extent the management of such activities. The DFSS green belts are of particular relevance, because they not only make the DFSS project known in the departments involved but also support the project team in carrying out part-projects. Following the end of the "verify" phase the team and the champion check to ensure the permanence of the results achieved.

Planned introduction of resources: The consistent and structured procedure of DFSS makes it easier to plan resources over the course of the development project. The team should also be established on a cross-functional basis – that is, operating across different departments. Depending on the contents of the project and its extent, the core team should not have more than 8 members. Technical specialists – from market research, legal and sales departments, for example, can be co-opted as required. Personnel from the supply chain should also be considered. If a lack of resources occurs, the champion and/or the DFSS black belt or DFSS green belt must immediately take action and find solutions. If necessary, the project contract must be withdrawn or revised.

Decision based on data, facts and figures: In the same way as with Six Sigma (DMAIC) all indicators and targets in DFSS projects must be made measurable, so that decisions are taken based on data, facts and figures. In this way, arbitrary decisions and decisions based purely on "feel" are prevented and the principle of "cause and effect" is applied in a reliable manner. This is particularly important where there is a complex interplay between individual vehicle components, as a failure can frequently have many different causes.





Rapid and traceable successes: The money spent by an organisation in introducing DFSS is very soon recouped. Even during the training of personnel to DFSS green belt or DFSS black belt level, participants will handle their first practical projects. This enables cost savings to be made even in the earliest stages of training. In addition the non-monetary gains which can be achieved in terms of quality improvements or minimizing risks must also be considered.

The factors for success listed above must be taken into account when applying the procedure covered in IDOV, DMADV or the IDDOV cycle (chapter x, procedures with DFSS). Only in this way can a problem-free execution and successful conclusion of the project can be achieved. In addition, it must be ensured that employees are permanently motivated and that they are kept up-to-date continuously on the progress of the project.

Keeping employees informed is very important; frequently a sequential procedure with communication problems at organisational interfaces will lead to repeated changes, individual improvements and the resulting non-compliance with development times and costs. A joint understanding of product and process requirements is prevented by different departmental objectives and cultures, so that the opportunity to develop successful products and services goes to waste.





7 Project record documents

7.1 Method: Project launch document; project agreement

Objective: A binding agreement between the internal customer, those involved in the project and the project manager on the contents and execution of a project before it begins.

Ideally it also serves as a release for the project, via the control group for example.

User group: Those responsible for the project.

Execution: The project launch document comprises several elements, in which essential information is set out before the start of the project. Once agreed, the complete project launch document is signed by all those involved in the project.

Project fundamentals Fundamental information such as the roles of those involved, the objective of the project and possible problems, the value of the project and the business case.

Extent of the project The item covered by the project, with a definition of input, output and reference to any existing multi-generation plan, and defining the project limits.

Project sequence A clear illustration of milestones and possible risks.

Result: An overview of essential information (resources, project members with their roles, project objective, etc.) and binding agreements. Changes in the course of the project are permitted only in exceptional circumstances and by consensus.





7.2 Method: Stakeholder analysis

Objective: To create a climate which is favourable to the execution of the project or, as a minimum, a resistance-free climate.

User group: The project manager and (where appropriate) project team members.

Execution: 1. Identify the stakeholders (representing interests) in the context

of the project.

2. Evaluate the expectations, attitudes and influence of the stakeholders. A differentiation can be made between positive (+), neutral (o) and negative (-) if necessary at different levels

3. Develop strategic actions to improve negative attitudes and maintain the positive attitudes of the stakeholders.

4. Establish a communication plan which specifies who is to be informed, when, about what and by whom.

Result: Illustrate contradictions, potential conflicts and any resistance detected in the interested parties involved, including evaluation, actions and a plan for implementation.





7.3 Method: Multi-generation plan

Objective: To allocate individual development projects within the greater framework of technology development.

User group: Development.

Execution: The multi-generation plan describes 3 product generations, each building upon the other, covering the existing product, the product to be developed and a product to be envisaged in the future. Visions, objectives, characteristics and essential resources are included.

Generation 1: Describe the concept and technology of the existing product (Generation 1) in as much detail as required.

Generation 2: Describe the generation to be developed, with additional information and elements from Generation 1 ("lessons learned").

Generation 3: Set out the vision of an imaginable, future product.

Involve the experience and ideas of the stakeholders and include market information.

Result: Long-term planning contributing, among other factors, to the definition and restrictions applicable to individual development projects.





Fig. 8: Example of a multi-generation plan - 1





Fig. 9: Example of a multi-generation plan - 2





7.4 Method: Risk classification (project)

Objective: Recognize and evaluate potential risks in the project at an early stage, so that they can be countered with appropriate actions, timing plans and responsibilities.

User group: Project manager and project team members.

Execution: 1. The project manager initiates the risk assessment before the

start of the project.

2. Risk classification (set priorities) for all parts of the project at the start of the project, jointly with the team members and important stakeholders (those involved in the project).

3. If appropriate, project-specific matters can be added to the evaluation criteria or modified.

4. Discuss and evaluate the risk classification in the project team. The presentation should ideally be made by a neutral, experienced presenter.

5. Agree on actions to minimize risks.

6. Implement and monitor the actions and up-date the risk assessment.

Result: Recognized risks are illustrated, potential critical paths are identified and appropriate counter-measures are taken at an early stage.





Fig. 10: Example of risk classification. Source: Standard formula from VDA publication "Maturity level assurance for new parts“





7.5 Method: The KANO model

Objective: To evaluate the customer's needs and performance characteristics against the following categories:

- Characteristics which surprise and "delight")

- Performance characteristics; expressed needs which will "satisfy"

- Basic requirements, unexpressed needs and self-evident requirements, the absence of which will "dissatisfy")

This information is used to support prioritizing - e.g., when using QFD.

User group: Sales/marketing; development; quality management

Execution: 1. Determine the basic requirements. Sources of this information

can include customer complaints and rejects, the technical press, service and maintenance reports.

Typically, customers do not demand the basic requirements explicitly; instead, they react with violent complaints if these basic requirements are not met. For example, a customer would not specify that a car door must be rain-tight but he would not accept a wet interior when driving n rain. Self-evident requirements must always be met; they cannot be prioritized against each other.

2. Determine the performance requirements. Sources of information can include market studies, trend analyses, customer questionnaires.

Performance requirements are typically expressed as explicitly stated customer requirements. However, the explicitly expressed requirement often implies the need. For example, a customer may require heated seats – that is, he quotes the technical solution which he knows. His real need, however is to sense a comfortable temperature at the point of contact between his body and the seat, even at low outside temperatures. As a general rule, performance requirements can be prioritized against each other





3. Determine the characteristics which cause "delight". Sources can include trend analyses, personal research and the use of innovation methods such as TRIZ.

Typically these are innovative technical solutions which are not stated explicitly by the customer (he may well not know them at all or may not expect them in the product or product segment) but which fulfil a latent need – or a need which has been created by appropriate advertising. As a general rule, one or two characteristics causing "delight" are sufficient, so that there is usually no need to prioritize between them. Such characteristics are often used to differentiate the product from the competition and are actively advertised.

In the course of time, characteristics causing "delight" become performance requirements and performance requirements become basic requirements.

Result: Overview of characteristics causing "delight", performance requirements and basic requirements.

Fig. 11: Kano model





Explanatory examples: A characteristic causing "delight"

When the first automobile manufacturers introduced a double air-bag system in the 1990s for the driver and front-seat passenger in a medium-class vehicle as a special option at a reasonable price, customers were delighted – they even accepted longer delivery times for this special option.

Explicit requirement / performance requirement / a characteristic causing satisfaction:

It was not long before customers were actively demanding this option. Double air-bag systems were offered in more and more models, even in smaller vehicle classes. In less than 10 years the double air-bag system became a standard fitment in medium-class vehicles.

An expected characteristic, not explicitly demanded but causing dissatisfaction if not provided:

At the time this present document is published it is unthinkable that a medium-class car would be offered for sale in Germany without a double air-bag system. Customers not longer ask explicitly for this – it is simply assumed to be fitted.





7.6 Method: Affinity diagram

Objective: Organise large amounts of data, facts and figures, opinions, ideas, etc. which at present are available in a disorganised form or are not aligned in terms of time.

User group: Project team (planning, development, production, quality management, sales).

Execution: Data, facts and figures, opinions, etc. must be:

1. collected,

2. organised into selected categories (clusters) and

3. documented in an appropriate form.

Result: Ordered and structured presentation of data, facts and figures, opinions, ideas, etc., available in documented form for further use.

Reference: Philipp Theden, Hubertus Colsman. "Quality techniques & tools for problem-solving and continuous improvement". 3rd edition, Hanser 2002. pages 43-45.

Level

Warning

Noise Temperature

Tone Materials when touched

Air / interior

Controllability

Inward radiation

Comfort

Continuity

Function feedback





7.7 Method: Quality function deployment (QFD)

Preliminary comments: QFD is a method which is used as an accompaniment to the development. With its help the requirements of the end-customer and the market (VoC = Voice of the customer) are used, step by step, to arrive at performance characteristics or functions (CTQ = critical to quality) which are initially neutral in terms of solutions. These are then used to decide on the layout characteristics of the solution which is selected, the process characteristics required to manufacture the product and, finally, the associated, essential manufacturing characteristics. The number of steps is not limited to the four stages shown here and depends much more on the complexity of the product or system under consideration. When moving from the performance characteristics to the layout characteristics it can be useful to insert intermediate steps, where functions of sub-systems and then functions of components are considered, before coming to the layout characteristics of these components. For this reason, this present document does not give numbers to the stages (e.g., QFD 1 to QFD 4) as is widely practised in other literature. A common feature of all the stages is the presentation of results in matrix form, prioritisation and the specification of target values (with tolerances) which can be checked. The matrices represent the level of knowledge achieved in the course of the project and serve as structured project documentation. The actual development work, however, the completion of the individual development tasks, takes place outside the matrices. Fundamentally, there is no compelling reason to use QFD in full from the start to the very end of a development project. The method should be used only where clear advantages can be expected. These advantages may be gained with a single matrix, particularly where the personnel involved in the project enter into a productive discussion which would otherwise not have taken place.





7.7.1 Method: QFD - Voice of the customer / Critical To Quality

Objective: To translate the "voice of the customer, (VoC) into the language of the organisation (critical to quality, CTQ). CTQs are functions, performance characteristics or features which are important, within the framework of the product requirements, in taking account of the quality expectations of the customer. The objective is to illustrate the relationship between the customer's needs (VoC) and the CTQs for the product, as well as prioritising the CTQs.

User group: Sales/marketing, development, quality management, planning

Execution: 1. Identify the customer's needs (taking up the results of market

research, trend analyses, competition analyses). Here, it is important that the degree of detailing is equal for all the needs. As a general rule, the customer's needs are entered in the header lines of the matrix.

2. Prioritise the customer needs which have been identified. Here it is necessary to differentiate between basic requirements, characteristics which "delight" or performance requirements (from the Kano model). 100% achievement of the basic requirements is essential and these are not usually weighted against each other.

3. Determine the functions, features and performance characteristics of the product (CTQs, taking up the definitions of the organisation's own product description, initially neutral and without reference to possible solutions). The organisation's definitions are usually entered in the header lines of the matrix. CTQs are measurable metrics.

4. Relationships between the customer's needs and the product description used by the organisation(functions / features / performance characteristics) are evaluated in the relationships matrix. It is possible to work with positive or negative relationship values.

5. Analyse the relationships matrix: which customer needs show weak, negative or no relationships? Which features / performance characteristics defined by the organisation show weak, negative or no relationships? Are there customer needs which show strong relationships in several respects (redundancies)? Are there





features / performance characteristics defined by the organisation which show strong relationships in several respects (redundancies)?

6. Calculate from the relationships matrix (priority multiplied by the relationship, added up for each column). Identify the most important features / performance characteristics. If negative relationship figures are used, these must be calculated separately. Many users identify only the highly-prioritised functions / features / performance characteristics as CTQs.

7. Carry out a comparison with the competition (benchmarking) if comparable products are known. Illustrate the degree of achievement of the customer's needs for each product made by the competition and compare against the product which the organisation is planning to manufacture. This comparison can be useful in determining the market positioning of the organisation's own product and influence the prioritising of the CTQs.

8. Specify the target figures and tolerances of the CTQs and decide on paths for improvement.

9. Illustrate inter-actions between the CTQs in a correlations matrix ("roof")*) and identify conflicts of objectives with the paths for improvement.

*) The overall illustration of QFD information takes the form of a house with rooms and a roof, which is why it is also referred to as the "House of Quality".

Result: Overview of the degree of achievement of customer's needs by the planned concept.

Prioritised features and characteristics from the customer's stand-point. Illustration of product weaknesses from the customer's stand-point and redundancies in the product.

Reference: General description of the QFD method in VDA 4 DGQ 13-21





7.7.2 Method: QFD - CTQ / layout characteristics

Objective: To illustrate the relationships between the CTQs, weighted from the customer's stand-point, taken from the QFD "Voice of the customer / Critical to Quality", and the layout characteristics of the product, using measurement metrics and integrated prioritisation.

User group: Sales/marketing, development, quality management, planning

Execution: The "House of Quality" is drawn up completely in the following steps:

1. Take the CTQs from previous analyses.

2. Enter the benchmarking results (from the comparison of levels of achievement of the CTQs against various competitor products) in the planning matrix.

3. List the CTQs and layout characteristics which have been determined.

4. Determine the path for improvement of the individual layout characteristics (1 = maximize; 0 = achieve; -1 = minimize; illustrate with alternative arrows).

5. Relationships are evaluated in the relationships matrix. It is possible to work with positive or negative relationships. Alternatively, quantitative effective inter-relationships can be entered.

6. Analyse the relationships matrix: are there layout characteristics which show weak, negative or no relationships? Are there CTQs which show weak, negative or no relationships? Are there layout characteristics which show several strong relationships (redundancies)? Are there CTQs which show several strong relationships, (redundancies)?

7. Calculate from the relationships matrix (priority multiplied by the relationship, added up for each column). Identify the most important layout characteristics. If negative relationship figures are used, these must be calculated separately.

8. Compare current performance capability against the competition with regard to the layout characteristics which have been determined, insofar the same technical solutions apply.





9. Determine precise target values and tolerances for the layout characteristics, taking account of the benchmarking.

10. Draw up the correlation matrix (the "roof") with which the inter-dependencies of the individual layout characteristics can be identified. In this way, any inter-actions will be highlighted.

Result: Identification, definition and prioritisation of the layout characteristics for a concrete technical solution. Summarized illustration in matrices (House of Quality).






7.7.3 Method: QFD for layout and process characteristics

Objective: To identify and evaluate the process characteristics required for the manufacture of the product, derived from the defined layout characteristics.

User group: Development, production, quality management, planning

Execution: 1. Take the layout characteristics from previous analyses and

enter them in the QFD matrix with prioritisation details, target values and tolerances. Identify the process characteristics and enter them in the QFD matrix.

2. Analyse the relationships between process characteristics and layout characteristics. Enter effective inter-actions. Where appropriate, positive and negative relationship values can be used.

3. Analyse the inter-actions between the process characteristics (the "roof").

4. Analyse the QFD matrix: identify areas with weak, negative or no relationships and areas with several strong relationships.

5. Calculate from the QFD matrix (priority multiplied by relationship, added up by column). Identify the most important process characteristics. If negative relationship values are used, they must be calculated separately.

6. Specify the target values for the process characteristics, including tolerances and the monitoring procedure.

Result: Identification and prioritisation of process characteristics and their associations, with each other and with the layout characteristics. Illustrate the results as summaries in matrices.






7.7.4 Method: QFD for process and production characteristics

Objective: To identify and evaluate the necessary production parameters from the process characteristics which have been defined.

User group: Quality management, planning, production

Execution: 1. Take process characteristics and priorities established in

previous analyses and enter them in the QFD matrix. Determine the production parameters and enter them.

2. Analyse the relationships between process characteristics and production characteristics. Where appropriate, positive and negative relationship values can be used.

3. Analyse the inter-actions between the production characteristics (the "roof").

4. Analyse the QFD matrix: areas with weak, negative or no relationships; areas with several strong relationships.

5. Calculate from the QFD matrix (priority multiplied by relationship, added up by column). If negative relationship values are used, they must be calculated separately.

6. Specify the target values (and tolerances if relevant) and the monitoring procedure for the production characteristics.

Result: Identification and prioritisation of the production characteristics and their associations, both with each other and with process characteristics. Illustrate the results as summaries in matrices.






7.8 Method: Design scorecard

Objective: To monitor relevant product and process characteristics over the product creation process.

User group: Development, planning, production, quality management

Execution: 1. Select relevant product and process characteristics (from the

QFD/ requirements specification, for example), which ensure the quality of the result of the development.

2. Specify the metrics for measuring the relevant product / process characteristics

3. Specify the values required for these characteristics, with tolerance limits and the distribution ("scatter") of measurements. If appropriate, relevant process capabilities should also be stated as target values.

4. Estimate the distribution ("scatter") of measurements and process capabilities which can be achieved securely, depending on the state of the product development.

5. Continue this estimate over the enter development process with increasing precision and checks at all relevant milestones.

Result: Continuous illustration of the evaluation of all relevant product / process characteristics in terms of compliance with the specified tolerances, with an increasing reliability of prediction. An illustration of how well and how securely the development objective has been achieved and whether further actions are necessary.





Fig. 13: Example of a design scorecard





7.9 Method: Loss function

Objective: To predict customer (dis)satisfaction, based on the association between the customer's wishes and variations in the performance characteristics (CTQ).

User group: Development, quality management.

Execution: 1. The customer's wish (Q) and the associated performance

characteristic (CTQ) are specified.

2. Customer data are collected regarding variations in customers' wishes (several customers; different CTQ levels).

3. The customer loss function is drawn up, based on customer data. (for example, CTQ = ambient temperature)

4. Performance characteristic distribution; the CTQ variation is measured.

= Loss function : area too warm

Ambient temperature (°C)

= Ambient temperature

distribution with setting at 23°C


Custo

me

r dis

satisfa

ction

(%

)

are

a is t

oo

wa

rm

Am

bie

nt te

mpe

ratu

re

Fre

qu

ency (

%)

at

23°C





5. Customer dissatisfaction before the improvement is measured (frequency of the performance characteristic [%] x customer satisfaction [%] for the STQ levels in total).

In the example, 18% of customers asked were dissatisfied with the ambient temperature (too warm) at a setting of 23°C and σ = 1,5.

6. Customer dissatisfaction is determined after the improvement (the blue line).

In the example, only 7% of the customers asked were dissatisfied with the ambient temperature (too warm) at a setting of 22.5 °C and σ = 1,0 (blue distribution).

An improvement of 61% was achieved with the improvement with CTQ = ambient temperature "too warm".

A

mbie

nt te

mpe

ratu

re

Fre

qu

ency (

%)



= Loss function (area too warm)

(area too warm)

A

mbie

nt te

mpe

ratu

re

Fre

qu

ency (

%)

Custo

me

r dis

satisfa

ction

(%

) C

usto

me

r dis

satisfa

ction

(%

) a

rea

is t

oo w

arm

a

rea

is t

oo w

arm

= Temperature distribution at 23°C

= Loss function

= Temperature

= Temperature distribution

at 22°C, ơ = 1

distribution

at 23°C, ơ = 1,5





Result: Customer (dis)satisfaction determined before and after the improvement.

Reference: TAGUCHI'S QUALITY ENGINEERING HANDBOOK by Genichi Taguchi, Subir Chowdury, Yuin Wu ISBN 0-471-41334-8





7.10 Method: DRBFM (Design review based on failure mode)

Objective: To detect, prevent and eliminate existing and/or potential failures and causes of failure before the start of production, if changes occur in a known and controlled situation, or in the case of new developments based on an existing development / design.

User group: Development / design and downstream departments with the focus on validation and manufacture.

Execution: Possible failures and causes are derived exclusively from an examination of the changes – for example, in the design, at interfaces (integration environment), in the requirements (operational environment) or in manufacture.

Directly after drawing up a technical description of the change, the design/ development engineer prepares the DRBFM by describing the design element with its change, the function, potential defects, reasons and effects with significance. He/she also describes how the design has been secured up to this point.

This is followed by a review by the team of experts. Here the associations described by the design/development engineer are examined again and expanded if appropriate. In addition, the need for action regarding design improvements, suitable verification actions and influences on manufacturing are determined. It is important that the discussion of the change and its potential effects goes into full detail, with the aid of current drawings and components and the involvement of all those concerned (organisational interfaces).

If the review finds that a further design change is necessary, a review must also be carried out on that design change.

Result: An action plan to improve a design, ensure its validation to make the necessary changes to the manufacturing process.

An improved, defect-free product at the start of full production.





Core points:

The right time: immediately after the design is completed or the modified application and/or manufacturing environment is defined

Divide into two operations: preparation by the design/development engineer and a review by the team of experts

The designer, not a presenter, completes the form as preparation and no FMEA is used as a basis

The review must be carried out by a team of experts with the participation of the downstream departments – not by the design department and presenter (communication)

The discussion of the change and its potential effects should be carried out with full commitment and in detail, with the aid of current drawings and components

The examination is always restricted to the change to a design known to be good, together with the application/manufacturing environment

The focus of the action plan to be drawn up must be on improvement of the design, as well as the effects of the change on validation and manufacture

All failures and causes should be eliminated before the start of production

DRBFM is not designed as a tool for tracking action, for documenting a design standard (lessons learned) or to satisfy documentation obligations set out in law or in ISO standards





Fig. 14: Example of a DRBFM





7.11 Method: Pugh matrix

Objective: To identify the best possible design concept.

User group: Project team (development, planning).

Execution: 1. Identify the concepts to be compared and a standard concept,

against which they are to be compared. The standard concept is usually the current concept (that is, of the previous product) or a benchmarking concept.

2. Determine the criteria against which the evaluation is to be made.

3. Apply a weighting to the selected criteria.

4. Evaluate the concepts against the criteria, marking them as better (+), worse (-) or neutral (0). Other evaluation classifications can be used.

5. Calculate weighted totals, examining (+) and (-) separately.

6. The concept is decided on the basis of the overall evaluation.

Possible addition:

7. Carry out a strengths and weaknesses analysis.

8. As far as possible, combine the strengths of the different concepts to achieve an optimum concept.

9. Compare this optimum concept against the standard (this is an iterative procedure)

Result: The best possible concept.





Fig. 15: Example of a Pugh matrix





7.12 Method: Hypothesis tests

Objective: Hypothesis tests are statistical methods which are used to check the validity of assumptions / hypotheses which have been made. Frequent applications include:

- verifying the significance of influencing factors on a process output - verifying the differences between two or more data sets - verifying significant changes after implementing an action Wit the aid of hypothesis tests, assumptions, suppositions and hypotheses are transferred to experts in the form of data, facts and figures.

User group: Development, test, production

Execution: Establish two complementary hypotheses:

the "zero" hypothesis (also referred to as H0 ) which is to be tested for validity.

As a general rule the zero hypothesis H0 states:

- there is no difference between data-sets - the influencing factor is not significant - that a certain distribution can be assumed an alternative hypothesis (also referred to as Ha or H1) which

applies if the zero hypothesis H0 is rejected. As a rule the alternative hypothesis Ha states:

- there is a change - there are differences between data-sets - the influencing factor is significant, the assumed distribution does not apply. - the test is to be carried out. In this case a suitable test statistics must be selected. Given the large number of different hypothesis tests, expert knowledge is required. - an interpretation of the result must be made on the basis of the 'p' value (the probability that the zero hypothesis is incorrect). As standard, a limit value of 0.05 is selected for p. There is an easily remembered rule : "If p is low, H0 must go!"





If p ≥ 0,05

The zero hypothesis H0 cannot be rejected because the probability of error would be too high.

If p < 0,05

The zero hypothesis is rejected. The alternative hypothesis Ha is accepted.

Result: Statement as to whether a difference observed between various data-sets is random or statistically significant.

Acceptance or rejection of an hypothesis

Observed figure

Confidence range

Comparison with one

target figure

Comparison between two

random samples

Comparison between > 2

random samples

Mean value nv t distribution Single sample t test

2 sample t test

ANOVA

Median non nv

u distribution Prefix test Wilcoxon text

Mann-Whitney test

Kruskal-Wallis T

Mood-Median T

Distrib- nv

2 distribution

2 test

F test Barlett test

ution non nv Levene test Levene test

Attributive proportional

figure

Binomial distribution

2 test

2 test

2 test

Fig. 16: Example of an hypothesis test (selection)

Reference: Comprehensive table attached

Stephan Lunau (Hrsg.), Olin Roenpage, Christian Staudter, Renata Meran, Alexander John, Carmen Beernaert: Six Sigma+Lean Toolset, Frankfurt, Springer Verlag, 2. Auflage, 2007





7.13 Method: Functional block diagram

Objective: To describe and provide a clear illustration of the structure and function, the behaviour or the processes of a system.

In control technology, system analysis and model building, function block diagrams serve as the basis for the mathematical description of the behaviour of a system.

User group: Development, production, quality management.

Execution: 1. Divide the system into functional elements – so-called function

blocks

2. Switch the function blocks around according to the mathematical and/or physical function. The result is a "signal flow plan" or function flow block diagram.

3. Describe the function – i.e., the associations of the input and output values of the function blocks – using a graph (function diagram), mathematical means (formula) or a verbal description in the function block.

Fig. 17: Example of a simple function block diagram for continuous lambda control

Air mass

meter

Air

Broad-band sensor

Nernst sensor

Fuel

Catalyser

Pre- regulation

Con- troller

Conversion

I-Controller

Leading control

Spec. value

Exhaust gas





Result: A graphical illustration of the structure and function of a system, using function blocks and the functional associations of the input and output values of the function blocks.





7.14 Method: Effect diagram

Objective: To identify the significant causes, parameters or factors which result in a particular effect or exercise an influence on a particular product characteristic, by illustrating the physical and technical associations. This is a very good preliminary analysis for creating a DoE.

User group: Planning, development, production, quality management.

Execution:

1. Collect all possible, imaginable or supposed influences

2. Group these influences into appropriate categories

3. Expand any cross-connections (inter-dependencies)

4. Evaluate the influences (effects) using lines of different thicknesses

5. Document the main influencing factors

Result: Illustration of mutual dependencies (relationships) of the influencing parameters, together with a ranking of the most important parameters. A structured, clear illustration of all the causes, parameters and influencing factors with an effect on a certain result, effect or influence.

Fig. 18: Example of an effects diagram for commutator wear

Reference: Ronninger, C.U.: Reliability analysis with Weibull in development and production ATZ – Automobiltechnische Zeitschrift 101 (1999) 11, pages 942-949





7.15 Method: Effects chain analysis

Objective: To analyse and understand the overall effect of several functions. To eliminate useless or harmful functions. To recognize conflicts in the system at an early stage and eliminate them if appropriate. To optimize the system at an abstract level without knowing the precise design.

User group: Development

Execution: After the necessary system functions have been derived from the CTQs an effects chain analysis can be carried out.

1. Examine the association of effects between tools, objects and their environment. Describe the procedures in as far as possible on an abstract level.

2. Differentiate between different actions in order to arrive at deficits:

3. Improve: eliminate useless or harmful actions

Result: A system optimized in terms of functionality. System conflicts recognized and can be eliminated at the next stage, with TRIZ for example.

unvollständige nützliche Aktion

fehlende nützliche Aktion

nützliche Aktion

X

schädliche Aktion

unvollständige nützliche Aktion

fehlende nützliche Aktion

nützliche Aktion

X

schädliche Aktion

Tool Action 1

Object Action 2

Environment Tool Action 1

Object Action 2

Environ-

m

e

n

t

ment m

e

n

t

Useful actions

Missing useful actions

Incomplete useful actions

Harmful actions





7.16 Method: Monte Carlo simulation

Objective: To predict the distribution frequency of a product characteristic or the probability of a certain (desired or unwelcome) event or result.

User group: Development, quality management.

Execution: In order to carry out this method it is essential to have a physical or mathematical model or an algorithm which illustrates the association of effects between target factors and influencing factors. The core of the procedure is the calculation of the target factor from a large number of accidental, or random value-combinations of influencing factors. The distributions of all influencing factors must be known or specified on the basis of appropriate assumptions.

The basic procedure is as follows:

1. Prepare the model or algorithm

2. Take the influencing / incoming factors

3. Generate the accidental or random value-combinations of influencing / incoming factors and determine the value of the target factor for each of them

4. Determine the distribution of the product characteristic (target factor) and the probability of occurrence of the event under examination.

Result: Illustration of the expected distribution of a product characteristic or the probability of occurrence of a certain event.

Example: Voltage adder The switch circuit shown in Fig. 17 illustrates the sum Vo of the two input voltages V1 and V2. If the resistances R1 ... R5 are equal, the ideal situation is that (R1 = R2 = R3 = R4 = R5) Vo = V1 + V2. An investigation is required to determine the effect of random deviations in the resistances and input voltages on Vo. It is assumed that the resistances each have a nominal value of 1 kOhm with a standard deviation of 3 ‰ (normal distribution), while the voltages can be





adjusted within ± 10 mV of the nominal V1 = 0.5 V and V2 = 1.0 V (equal distribution).

Using an IT program 1000 (for example) random value combinations are generated, with the individual values more or less meeting the assumed distributions and their characteristics. For an output voltage Vo this gives an roughly normal distribution with the mean at 1.4996 V and a standard deviation of 0.0116 V. If the specification limits are set at ± 50 mV, this is the equivalent of a Cpk of 1.42.

Fig. 19: Example of a Monte Carlo simulation of an analog voltage adder

Note: To be carried out with the aid of an IT program

1,5451,5301,5151,5001,4851,4701,455

90

80

70

60

50

40

30

20

10

0

Vo/Volt

Hä

ufi

gke

it

1,551,51,45

Histogramm von Vo

V2 R2

R1 R3

R4

V1

Vo

-

+

-

+

R5

V2 R2

R1 R3

R4

V1

Vo

-

+

-

+

-

+

-

+

R5

1,0081,0051,0020,9990,9960,9930,990

70

60

50

40

30

20

10

0

R1/kOhm

Hä

ufi

gke

it

1,0110,99

Histogramm von R1

1,0081,0051,0020,9990,9960,9930,990

40

30

20

10

0

V2/Volt

Hä

ufi

gke

it

1,0110,99

Histogramm von V2

Vo = V1 + V2

R5 R3 R3

R4 R1 R2

Vo = V1 + V2

R5 R3 R3

R4 R1 R2





7.17 Method: Parameter diagram

Objective: - a better understanding of the product or process system - input for the layout of the test plan and improvements

User group: Project management, development, test, quality management.

Execution: The parameter diagram is a structured illustration to allow an understanding of the physical associations and method of operation of the designs / processes.

It is an analysis of the input/output parameters, illustrating the controllable and non-controllable factors which define the performance of the system.

The input value of the system and its target value determine the results, with separation onto values which can be influenced and interference factors.

1. Specify the extent of the task or system limits.

2. Determine the input and output values.

3. Determine the values which can be influenced and interference factors (uncontrolled input factors such as environmental conditions, ageing, wear, tolerances) and the input factors (used in operation to influence the output).

4. Identify the undesired output.

5. Establish a mathematical function between input and output factors.

Fig. 20: Example of a parameter diagram (to illustrate the principle)

Result: - Visual illustration of the physical system or process - Input for creating a test plan (simulation or real tests)





7.18 Method: Value flow design

Objective: To illustrate and analyse processes (material and information) along the value creation chain with the subsequent shaping of processes with am optimized value flow.

User group: Planning, production, sales, development.

Execution:

Analysis:

1. Identify the processes to be analysed and specify process limits.

2. List process stages and associated material and information flows.

3. Analyse each individual process stage in the overall process (e.g., for measurement metric (value flow diagram).

4. Take the process stages which have been analysed and identify them as adding value, not adding value or permitting added value.

Improvement:

5. Develop new or improved process stages with a higher added-value and eliminate process stages which are unnecessary or do not add value. In this, the 7 types of waste must be borne in mind: over-production, waiting times, rework / scrap, stocks, movements, areas, transport.

6. Bring the new / improved process stages together in an improved process.

7. Implement the newly created processes. Measure them and check them continuously.

Result: Processes with the minimum level of waste and the maximum added value.





8 Roles and tasks

A crucial component of the "Design for Six Sigma" procedure and its success lies in the precisely defined roles of the individual persons in the hierarchy of an organisation in the introduction and use of DFSS.

For each DFSS project there is the need for a comprehensive knowledge base and improvement methodology, statistics, personnel and resources, project management and soft skills (such as presentation techniques) in order to work effectively.

To bring all these skills and knowledge together, there are different roles and tasks, involving training with quite specific levels and contents.

These are based on the belts system in certain wrestling sports:

Executive (sponsor)

Champion

Master black belt

Black belt

Green belt

8.1 Tasks of executives (top management – those responsible for the organisation's results)

Determine and communicate the organisation's objectives & strategy

Establish a comprehensive development process for the objectives (top down)

Set up a comprehensive controlling system for financial and technical metrics

Pursue the further development of the management systems in the direction of process orientation (the organisation follows the process and not the other way round)

Introduce personal agreements on objectives at a management and employee level

Integrate DFSS objectives into the personal agreements on objectives at a management level





Define the framework conditions for "Design for Six Sigma" projects

Personal commitment in presentations of results and recognition / commendation of success

Evaluate the whole implementation of "Design for Six Sigma"

8.2 Tasks of the champion (middle management – responsible for the results of the processes)

Identify and launch "Design for Six Sigma" projects

Determine potential for improvement in a systematic manner

Communicate process results, potential for improvement and projects which have been launched

Provide resources for "Design for Six Sigma" projects (time, money, employees)

Monitor the progress of the project and escalate if necessary

Evaluate and communicate project results

Release the black belt and team after successful implementation

Comply with the framework conditions for "Design for Six Sigma" projects

Integrate "Design for Six Sigma" objectives into the personal agreements on objectives at the employee level

8.3 Tasks of the master black belt – responsible for the "Design for Six Sigma" initiative)

Lead the black belts at a technical level

Methodical evaluation of "Design for Six Sigma" projects

Further development of the "Design for Six Sigma" initiative, including framework conditions

Establish and maintain the communication process for "Design for Six Sigma"





Specify training standards

Establish and maintain the documentation standard to secure the know-how developed in the projects

Carry out internal training and project coaching

8.4 Tasks of the black belt (Design for Six Sigma project leader) – responsible for the success of the project

Identify potential projects jointly with the champions

Develop a definition of the project, draw up the team and the timing plan

Lead "Design for Six Sigma" projects

Train the project team in the methods used

Coaching in green belt projects

Documentation and archiving of project records

Carry out internal training for members of the project team

8.5 Tasks of the green belts (qualified project operatives or project leaders)

Identify potential projects jointly with the champions and black belts

Cooperate in defining the project and establishing the team

Lead or cooperate in "Design for Six Sigma" projects

Documentation and archiving of project records





9 Abbreviations

ANOVA Analysis of Variance

CAE Computer Aided Engineering

CDOV Concept Design Optimize Verify

CTQ Critical to Quality

DCCDI Define Customer Concept Design Implement

DCOV Design, Characterize, Optimize, Verify

DFMA Design for Manufacturing and Assembly

DFSS Design for Six Sigma

DKOV Define the concept Optimize Validate

DMAIC Define Measure Analyse Improve Control

DMADOV Define, Measure, Analyse, Design, Optimize, Verify

DMADV Define, Measure, Analyse, Design, Verify

DMEDI Define, Measure, Explore, Design, Implement

DoE Design of Experiments

Dpmo Defects per million opportunities

DRBFM Design Review Based on Failure Mode

DRBTR Design Review Based On Test Results

HoQ House of Quality

ICOV Identify, Characterize, Optimize, Verify

IDOV Identify, Design, Optimize, Verify





IPTV Incident Per Thousand Vehicles

LSL Lower Specification Limit

LTB Larger The Better

MIS Months In Service

MSA Measurement System Analysis

POK Partly OK

PPH Problems Per Hundred

PLP Production control plan

QFD Quality Function Deployment

QTS Quality Tracking System

SPC Statistical Process Control

STB Smaller The Better

SWOT Strengths, Weaknesses, Opportunities, Threats

TBD To Be Defined

TRIZ Teorija Resenija Isobretatelskih Zadac – Theory for the solution of invention tasks

USL Upper Specification Limit

VoC Voice of the Customer

W-PPH Weighted Problems Per Hundred





10 Appendix

10.1 Example of a hypothesis test (comprehensive table)

Constant data with normal distribution – test for mean values

Test When Hypotheses

One sample 't' test Compare the mean value of a random sample with a target value

H 0: µ = µtarget H A: µ ≠ µtarget

One sample 'z' test Compare the mean value of a random sample with a target value; σ is known

H 0: µ = µtarget H A: µ ≠ µtarget

Two sample 't' test Compare the mean values of 2 independent samples

H 0: µ1 = µ2 H A: µ1 ≠ µ2

Paired two sample 't' test

Compare the mean values of 2 dependent samples

H 0: µ1 = µ2 H A: µ1 ≠ µ2

One-way ANOVA Compare the mean values of several independent samples

H 0: µ1 = µ2 = µ3 = ... = µn H A: at least one mean value is different

Constant data with normal distribution – test for variances

Test Test Test

One sample 2 test

Compare the variance of a random sample with a target value

H 0: σ2 = σ

2 target

H A: σ2 ≠ σ

2 target

Two sample 'F' test Compare the variances of 2 independent samples

H 0: σ2

1 = σ2

2 H A: σ

2 1 ≠ σ

2 2

Test for equal variances (Bartlett test)

Compare the variances of several independent samples

H 0: σ2

1 = σ2

2 = σ2

3 = ... = σ

2 n

H A: at least one mean variant is different





Discrete, binomial-distributed data – test for proportions

Test When Hypotheses

One proportion test (one sample)

Compare a proportion with a theoretical/specified proportion e.g., good (OK)/bad (NOK) test

H 0: p = pHypothesis H A: p ≠ pHypothesis

Two proportion test (two samples)

Compare proportions of a characteristic of two samples

H 0: p1 = p2 H A: p1 ≠ p2

2-Test Chi-quadrate test

Compare proportions of a characteristic with two or more samples

H 0: p1 = p2 = p3 = ... = pn H A: at least one proportion is different





11 Example of intuitive one-handed movement

























































































12 Example of spring plate

























































































13 Example of wire clip

















































































Documents

Verband der Automobilindustrie Quality Management …v5design.eu/wp/wp-content/uploads/VDA-Band-04-1.-Auflage...Dokument wurde bereitgestellt vom VDA-QMC Internetportal am 01.04.2015