文档库 最新最全的文档下载
当前位置:文档库 › FMEA - SAE J1739 - 2009

FMEA - SAE J1739 - 2009

FMEA - SAE J1739 - 2009
FMEA - SAE J1739 - 2009

__________________________________________________________________________________________________________________________________________ SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions. Copyright ? 2009 SAE International

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE.

TO PLACE A DOCUMENT ORDER:

Tel: 877-606-7323 (inside USA and Canada)

Tel: 724-776-4970 (outside USA)

SURFACE VEHICLE STANDARD

J1739 JAN2009 Issued 1994-07 Revised 2009-01

Superseding J1739

AUG2002

(R) Potential Failure Mode and Effects Analysis in Design (Design FMEA),

Potential Failure Mode and Effects Analysis in Manufacturing and

Assembly Processes (Process FMEA)

RATIONALE

Widespread use of design and process FMEA is a benefit to consumers and manufacturers. The application of FMEA has been in place in the automotive industry since the late 1960’s with emphasis on standard ranking criteria and forms since the early 1990’s. The FMEA methodology has proven itself useful in the prevention and mitigation of potential failure modes. However, a growing need developed for improved failure mode ranking criteria and a change in thinking about the use of the Risk Priority Number (RPN). This standard includes updated ranking charts and de-emphasizes the use of an RPN threshold as the primary factor in determining preventive or corrective action efforts. It also includes a Boundary Diagram and Process Flow Diagram example as use of these tools has increased. The section for Potential Failure Mode and Effects Analysis for Machinery (Machinery FMEA) is a form of Design FMEA and has been removed. Machinery FMEA is a type of Design FMEA for equipment. There are numerous books, reference manuals and training references on the subject of FMEA. This standard serves as a common starting point for the development of an effective DFMEA and PFMEA.

FOREWORD

The former Recommended Practice for Potential Failure Mode and Effects Analysis in Design (DFMEA) and Potential Failure Mode and Effects Analysis in Manufacturing and Assembly Processes (PFMEA) has been revised and approved as a Standard. As such, it contains requirements and recommendations for effective use of DFMEA and PFMEA as a potential failure analysis tool. This document was revised by a balanced committee and represents current thoughts and practices on the subject from the viewpoint of OEM (Original Equipment Manufacturers) and their suppliers.

1. SCOPE

This FMEA Standard describes Potential Failure Mode and Effects Analysis in Design (DFMEA) and Potential Failure Mode and Effects Analysis in Manufacturing and Assembly Processes (PFMEA). It assists users in the identification and mitigation of risk by providing appropriate terms, requirements, ranking charts, and worksheets. As a Standard, this document contains requirements “must” and recommendations “should” to guide the user through the FMEA process. The FMEA process and documentation must comply with this Standard as well as any corporate policy concerning this Standard. Documented rationale and agreement with the customer is necessary for deviations in order to justify new work or changed methods during customer or third-party audit reviews.

2. REFERENCES

2.1 Related Information

The following referenced documents may be useful in connection with the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Publication

2.1.1 SAE

Available from SAE International, 400 Commonwealth Drive, Warrendale, PA 15096-0001, Tel: 877-606-7323 (inside USA and Canada) or 724-776-4970 (outside USA), https://www.wendangku.net/doc/cb8073240.html,.

ARP5880 Recommended Failure Modes and Effects Analysis (FMEA) Practices for Non-Automobile Applications, Issued July 2001, (Replaces MIL-STD-1629a)

Publication

2.1.2 IEC

Available from International Electrotechnical Commission, 3, rue de Verambe, P.O. Box 131, 1211 Geneva 20, Switzerland, Tel: +41-22-919-02-11, www.iec.ch.

IEC 60812 Analysis Techniques for System Reliability – Procedure for Failure Mode and Effects Analysis (FMEA), January 2006

Publication

2.1.3 AIAG

Available from Automotive Industry Action Group, 26200 Lahser Road, Suite 200, Southfield, MI 48034-7100, Tel: 248-358-3570, https://www.wendangku.net/doc/cb8073240.html,.

Potential Failure Mode and Effects Analysis (FMEA) Reference Manual, Chrysler LLC, Ford Motor Company, General Motors Corporation, Fourth Edition, June 2008

3.TERMS AND DEFINITIONS

For the purposes of this document, the following terms and definitions apply.

3.1 Baseline FMEA

A baseline FMEA document contains enough similarities when compared to the new FMEA project, to promote it’s usefulness as a starting point for that new FMEA project. The baseline FMEA is not program specific and its use is optional. Common names for a baseline FMEA also include Generic, Best Practice, and Gold Standard.

3.2 Block Diagram

The Block or Boundary Diagram is a pictorial tool to facilitate analysis of system interfaces usually used in Design FMEAs. It defines the analysis scope and responsibility and it provides guidelines for structured brainstorming. The scope of analysis is defined by the boundaries of the system; however interfaces with external factors/systems are to be addressed. An example of a block diagram can be found in Appendix D. An example of a boundary diagram can be found in Appendix E.

3.3 Control Plan

Written descriptions of the system used for controlling parts and processes. It can be component or process specific, or family where multiple parts are produced using the same processing line. The control plan describes the actions that are required at each phase of the process including receiving, processing, material handling, and periodic requirements to assure that all process outputs will be in control. The control plan provides the process monitoring and control methods that will be used to control product or process characteristics. Typical types include Prototype, Pre-Launch and Production.

3.4 Customer

The customer includes all users of the product. Customers are end users (external), manufacturing and assembly operations (internal) and service operations (external). Internal customers can be interim users of the product such as the next higher-level assembly or users of the process such as subsequent manufacturing operations.

3.5 FMEA Team

A team consists of knowledgeable individuals who perform the FMEA analysis. This may include but is not limited to representatives from: Design, Manufacturing, Validation, Suppliers, Materials, Service, Quality, Reliability and Technical Experts.

3.6 FMEA Worksheet

The content of the FMEA worksheet is the output of a Design or Process FMEA. The worksheet provides a structure for conducting risk analysis. An example of a DFMEA worksheet can be found in Appendix F. An example of a PFMEA worksheet can be found in Appendix I. These worksheets can be modified to meet company requirements (e.g. add or move columns, but column headings are standardized and should not change so the logic of the analysis is not lost).

3.7 Hidden Factory

A hidden factory is a deviation from the planned process flow. A hidden factory occurs when the product is handled other than in accordance with the planned process flow (all operations included in a process flow such as rework/repair, scrap, material movement, etc. are planned). Examples such as ad hoc repairs in a storage facility, hand torque due to equipment being down for repair, handling of parts that have failed in-process tests, and extra parts at a station may be considered part of a hidden factory. Hidden factory processes may contribute to the realization of failure modes or defects in a manufacturing or assembly process because a hidden factory doesn’t prevent reject parts from re-entering the line or parts being mixed.

3.8 Product Family DFMEA

A product family FMEA is a specialized baseline design FMEA that generally contains consistent product boundaries and related functions. These would not typically change from one application to another. Added to this product family FMEA would be the new project specific components and related functions to complete the new product FMEA.

3.9 Process Family PFMEA

A process family FMEA is a PFMEA covering a series of operations that produce multiple products or part numbers. Processes producing many similar products do not need unique FMEA’s for each product. The family PFMEA is dictated by the manufacturing process that is used to make the product, not by the product’s functional requirements or application. When the manufacturing process is the same as other parts in the family then a family PFMEA is appropriate.

3.10 Process Flow Diagram

A process flow diagram is a graphical representation of the movement of product or a service as they travel through the processing cycle. A process flow includes the primary process flow as well as secondary operations such as off-line inspection or off-line repair and material movement. It can be macro level listing all operation steps or micro level detailing each incremental step of work or processing being performed within an operation. A process flow diagram may also include potential sources of variation (some of which may be process characteristics) and necessary product or process requirements. An example of a process flow diagram can be found in Appendix H.

3.11 Risk Mitigation

The primary objective of the FMEA process is to identify potential high risks and try to keep those high risks from occurring in the end product or if that cannot be accomplished, then to minimize the risk effect(s) to the end product user. There are only three ways (factors) one can mitigate risk: change the design, prevent the risk from occurring or detect it so that a follow up action can take place to eliminate or reduce the risk effect(s).

4. OVERVIEW

4.1 Introduction

An FMEA can be described as a systematic group of activities intended to: (a) recognize and evaluate the potential failure of a product/process and the effects and causes of that failure, (b) identify actions that could eliminate or reduce the chance of the potential failure occurring, and (c) document the process. It is complementary to the process of defining what a design or process must do to satisfy the customer.

The earlier the FMEAs are started during the development phase, the better the chances of optimizing the various activities/designs/processes in a cost and time effective manner. One of the most important factors for the successful implementation of an FMEA program is timeliness. It is meant to be a “before-the-event” action, not an “after-the-fact” exercise. To achieve the greatest value, the FMEA should be done before a product or process failure mode has been incorporated into a product or process. Up front time spent properly completing an FMEA, when product/process changes can be most easily and inexpensively implemented, will minimize late change crises. An FMEA can reduce or eliminate the chance of implementing a preventive/corrective change that would create an even larger concern.

There are three basic cases for which FMEAs are generated, each with a different scope or focus:

Case 1: New designs, new technology, or new process. The scope of the FMEA is the complete design, technology, or process.

Case 2: Modifications to existing design or process (assumes there is an FMEA for the existing design or process). The scope of the revision efforts should focus on the modification to design or process, possible interactions due to the modification, and field performance. Modifications include removal or addition of new parts or processing operations. Modifications also include changes to existing product or process functions

Case 3: Use of existing design or process in a new environment, location, or application (assumes there is an FMEA for the existing design or process). The scope of the revision is the impact of the new environment or location on the existing design or process.

Although responsibility for the preparation of the FMEA is usually assigned to an individual, FMEA input should be a team effort. A team of knowledgeable individuals should be consulted (e.g., engineers with expertise in design, analysis/testing, manufacturing, assembly, service, recycling, quality, and reliability). The FMEA should be a catalyst to stimulate the interchange of ideas between the functions affected and thus promote a team approach.

It is not appropriate to compare the ratings of one team’s FMEA with the ratings of another team’s FMEA, even if the product/process appear to be identical, since each team’s environment is unique and thus their respective individual ratings will be unique (i.e., the ratings are subjective).

4.2 Purpose and Objectives

The intended purpose of the Design and Process FMEA is to support the processes used to design, manufacture, or assemble a product. The objectives can best be met by considering the following:

a. Risk identification

b. Risk prioritization

c. Risk mitigation

The fundamental value of the FMEA process is to identify potential risks, rank those risks, and then mitigate as many of those risks over time as possible. There are at least three key categories of risks discussed during the FMEA process including design risks (i.e., requirements and specification errors, engineering calculation error or material selection error, etc.), failure to warn risks (i.e., inadequate or missing labels/information, etc.), and process risks (i.e., manufacturing errors, etc.).

5. FMEA GENERAL REQUIREMENTS

5.1 Ownership

Management must establish design and process FMEA ownership for the analysis. The owner of the FMEA will establish the FMEA team, as necessary, to suit the needs of the scope and ensure timely analysis.

Management must establish ownership for FMEA procedures and methodology.

5.2 Storage and retrieval

Management must ensure a system is in place for storage and retrieval of FMEA documents.

5.3 Confidentiality

Management or the FMEA team must determine when a FMEA is deemed Confidential.

NOTE: Proprietary, Confidential and Secret document handling is not prescribed by this document.

5.4 Usage

Management must establish a corporate policy regarding the application of FMEA as related to the corporation’s product development program from concept design through validation, start of production and beyond.

6. DESIGN FMEA

6.1 Timing

The Design FMEA should typically be started after project initiation and completed prior to design release. Baseline FMEAs or product family FMEAs from similar products are the starting point for the risk management process when available. The baseline FMEA or product family FMEA should be edited to document those specific design and application differences between the baseline project and the current project. Changes to the Design FMEA can be made throughout product development and regular production.

6.2 Scope

The scope of a DFMEA depends on many factors including:

a. design-responsibility

b. interfaces/interactions

c. system architecture

The scope of a Design FMEA can more easily be defined by using a block diagram, interface diagram, functional diagram, structure tree, schematic illustration or similar tool that represents elements being analyzed. This diagram illustrates the primary relationship between the items covered in the analysis and establishes a logical order to the analysis. Copies of the diagrams used in FMEA preparation should be available upon request.

Responsibility

6.2.1 Design

The scope should define the hardware for which the team is responsible for designing. This defines the elements that will be analyzed. This is the item for which the engineering team has design ownership and risk mitigation.

6.2.2 Interfaces and Interactions

The team should discuss and document the interfaces to other components, subsystems or systems. These are the physical interfaces that are required for securing the item, transmitting signals, fluids, or power. They also include non-physical interactions that could influence the products functionality such as High Intensity Radiated Frequencies. These interfaces and interactions may be analyzed using an interface FMEA or included in a component, subsystem or system analysis.

Architecture

6.2.3 System

The team should discuss and document information about the item being analyzed by defining what role the item plays in the overall design (e.g. the item is a component in the AC compressor, or a sub-assembly to the instrument cluster). This also defines design architecture levied by the customer (e.g. the console will have four cup holders, two power points, two ashtrays, and a coin holder).

6.3 Inputs

The DFMEA team should review various inputs such as:

a. Warranty

b. Recalls

c. Engineering requirements

d. Drawings

e. Lessons learned

f. Preliminary design verification plan

g. Best Practices

h. Baseline/family or prior DFMEA

i. Higher level FMEA (System FMEA or Design FMEA)

j. Bill of Material

k. Manufacturing feasibility study

l. Diagrams such as a Block Diagram or Boundary Diagram

6.4 Outputs

The DFMEA team should produce various outputs such as:

a. Failure mode risk assessment

b. Failure mode risk mitigation (recommended actions)

c. DFMEA document(s)

6.5 Assumptions

The DFMEA should address the design intent and assume the design will be manufactured /assembled to this intent. The PFMEA should address manufacturing and assembly risk. However, this does not prevent a team from considering design for assembly and design for manufacturing functions as part of the DFMEA (e.g. when known failures have occurred in the past).

The DFMEA should not rely on manufacturing process controls to overcome potential design weaknesses, but it does take the technical/physical limits of a manufacturing/assembly process into consideration, for example:

a. Necessary mold drafts

b. Limited surface finish

c. Assembling space/access for tooling

d. Limited harden ability of steels

e. Tolerances/process capability/performance

f. Die capability and limitations

The DFMEA, as an analytical engineering tool, records the ideas and concerns of a design team; therefore it is understood that failures shown in the DFMEA are potential. As such, failures described in the DFMEA may or may not occur.

6.6 Procedure

Information

6.6.1 Header

The DFMEA worksheet contains important information about the analysis. The header must include a project name, latest revision date, and organization, department, and group or individual who is design responsible. Additional information such as DFMEA number, model year, program number, key date (analysis completion target date), system/sub-system/component, core and support team member names, and team facilitator, etc. may be documented in the header to provide useful information for tracking or storage and retrieval purposes. A team member list including names and departments is recommended.

6.6.2 Item

The name or other pertinent information (e.g. the number, the part class, etc.) of the item being analyzed must be written in the DFMEA.

6.6.3 Function and Requirement

A design function is a description of the design intent for a system, subsystem, or component. The function(s) of each Item being analyzed must be written in the DFMEA. A product may have more than one function.

The more precise the function, the easier it is to identify potential failure modes for preventive/corrective action. If the item has more than one function with different potential modes of failure, list all the functions separately in the DFMEA worksheet.

A product requirement defines how a product function should perform. A product function may have multiple requirements. Product requirements relate to the desired output of a function such as power or fluid flow. Requirements are measurable characteristics of a product function or its operation and may be documented in the DFMEA worksheet. Values for requirements should be included in the product specification to define the acceptance criteria for the validation test plan. Design features should be included in the product drawing.

Typical functions could be, but are not limited to:

Transforms (speed and torque)

Operates (quietly)

Contains (operating fluids)

Attaches to (mating part)

Typical requirements could be, but are not limited to:

Pressure (xx psi)

Flow rate (xx lpm)

Noise levels (at cold start)

Noise levels (during operation)

External leakage specification

Positive contact

6.6.4 Potential Failure Mode

The failure modes are the manner in which a component, subsystem, or system could potentially fail to meet or deliver the intended function(s) and its requirements. The failure mode(s) should be written in the DFMEA for each function identified. The team determines the priority in which to analyze functions. Each potential failure mode in an FMEA is considered independently of another failure mode. This enables the team to address the unique reasons (causes of failure) independently of other failure modes. Grouping multiple potential failure modes in one cell in a worksheet is not recommended.

There are at least five different types of potential failure modes discussed during the FMEA process including loss of function (i.e. inoperable, etc.), partial function (i.e. performance loss, etc.), intermittent function (i.e. operation starts/stops/starts often as a result of moisture, temperature, etc.), degradation (i.e. performance loss over time, etc.), and unintended function (i.e. operation at the wrong time, unintended direction, etc.). The team should describe component/system failure behavior in physical terms, different from the desired outcome or function.

Typical functional failure modes could be, but are not limited to:

Does not transmit torque Slips (does not hold full torque)

No support (structural) I nadequate support (structural)

No signal I ntermittent signal

Complete fluid loss L eaking more than xx

Does not disengage D isengages too fast

Typical component-level failure modes could be, but are not limited to:

cracked

d eformed

o xidized

sticking

l oose

fractured

NOTE: A detailed component failure mode can be the cause of an integrated system failure mode in a higher-level subsystem.

Effects

6.6.5 Potential

The effects are consequences or results of each failure mode. The effect(s) must be listed in the DFMEA for each failure mode in the Potential Effects column. The effects of the failure mode should be considered against the next level up assembly, the final product, and the end customer when known. End customer effects should state what the user might notice or experience. They should clearly state if the effect of a failure mode could impact safety or non-compliance to regulations, when applicable. The intent is to forecast the failure effects consistent with the team's level of knowledge.

Typical effects could be, but are not limited to:

1. No discernable effect

2. Noise e.g. misalignment/rub, squeak/rattle

3. Poor appearance e.g. unsightly close-out, color fade, cosmetic corrosion

4. Noise e.g. fluid-borne noise, squeak/rattle, chirp, squawk

5. Unpleasant odor, rough feel, increased efforts

6. Operation impaired, intermittent, unable to operate, electro-magnetic incompatibility (EMC)

7. External leak resulting in performance loss, erratic operation, unstable

8. Unable to drive vehicle (walk home)

9. Loss of steering or braking with warning to driver, regulatory non-compliance with warning

10. Loss of steering or braking without warning to driver, regulatory non-compliance without warning

NOTE: In some cases, the team conducting the analysis may not know the end user effect (e.g. commodity parts such as screws and bolts). When this information is not known, the effects should be defined in terms of the part function and specification.

NOTE: Some failures may be considered failure modes, effects or causes (e.g. leaks) depending on the function and requirements of a system, subsystem or component.

6.6.6 Severity Ranking Number

Severity is a ranking number associated with the most serious effect for a given failure mode for the function being evaluated. It is a relative ranking within the scope of the individual FMEA and is determined without regard for occurrence or detection.

Severity should be estimated using the criteria in Appendix A – Suggested DFMEA Severity Evaluation Criteria. The table may be augmented to include product-specific examples. The team should agree on an evaluation criteria and ranking system, which is consistent, even if modified for individual design analysis (e.g. passenger car, truck, motorcycle, tractor, golf cart, etc.).

Accurate assessment of severity depends on the team’s understanding of product safety, product functions and functional requirements as related to the vehicle and sub-assembly or part being supplied. Assessing the severity may lie outside the immediate design engineer’s/team’s field or experience or knowledge. In these cases, an interfacing system team or customer should be consulted in order to comprehend the propagation of effects.

In the case of commodity parts (e.g. design-responsible for screws, bolts, connectors, etc.), the severity ranking criteria will be limited to the immediate function and its related requirements so that severity reflects the impact on fit/finish, partial function and loss of function rather than the impact on the system or end user.

One of the goals of the FMEA process is to mitigate risk or lessen the impact of a potential failure mode. The severity ranking itself can not be changed without eliminating the failure mode and its effects.

NOTE: Writing the individual severity numbers for each effect as part of the effects description is considered a best practice with the highest (worst case) effect used as the severity number.

6.6.7 Classification

The use of the classification column is optional in a DFMEA. This column may be used to highlight failure modes or causes for the purpose of identifying issues to be further discussed with the team as well as others outside the team including management and a Process FMEA team to determine if additional action is necessary. Certain letter codes or symbols may be used. Companies may use various criteria for including:

?High priority failure modes (based on Severity, Severity and Occurrence, Severity and Detection)

?Special characteristics (examples include safety, government, critical, and key characteristics which are directed by specific company policy and are not standardized in this document)

?Warranty campaigns and recalls

?Other criteria specified by the team

6.6.8 Potential Cause of Failure

A potential cause of failure is an indication of how the failure could occur. The consequence of a cause is the failure mode. Identify, to the extent possible, every potential cause for each failure mode. The cause should be listed as concisely and completely as possible so that remedial efforts (controls and actions) can be aimed at appropriate causes.

Types of potential causes of failure could be, but are not limited to:

– Design for functional performance (incorrect material specified, incorrect geometry, incorrect part selected for application, incorrect surface finish specified, inadequate travel specification, improper friction material specified, insufficient lubrication capability, inadequate design life assumption, incorrect algorithm, improper software specification, improper maintenance instructions, etc.)

– System interactions (mechanical interfaces, fluid flow, heat sources, controller feedback, etc.)

– Changes over time (yield, fatigue, material instability, creep, wear, corrosion, chemical oxidation, electro migration, over-stressing, etc.)

– External environment (heat, cold, moisture, vibration, road debris, road salt, etc.)

– Customer use (high speeds, towing, fuel types, service damage, etc.)

– Piece to piece variation (variation within tolerance)

– Design for manufacturing (part geometry allows part installation backwards or upside down, part lacks distinguishing design features, shipping container design causes parts to scratch or stick together, part handling causes damage, etc.)

NOTE: The above examples represent categories. Specific details need to be added to complete the cause description.

Only specific failure causes (e.g. radius too small) should be listed; ambiguous phrases (e.g., poor design) should not be used.

NOTE: The Design FMEA team should include appropriate subject matter experts that can provide accurate information about how the proposed design can impact the vehicle driver, interfacing systems, manufacturing, etc. Similarly, the Process FMEA team should include appropriate subject matter experts that can provide accurate information about how the proposed manufacturing process and error proofing solutions can impact the vehicle driver, interfacing systems, and the functionality of the product.

6.6.9 Occurrence Ranking Number

Occurrence is a ranking number associated with each cause for a given failure mode being evaluated. The occurrence ranking considers the likelihood of occurrence during the design life of the product. The occurrence ranking number has a relative meaning rather than an absolute value and is determined without regard for severity or detection. The occurrence ranking takes into account the prevention-type design controls.

Occurrence should be estimated using the criteria in Appendix B – Suggested DFMEA Occurrence Evaluation Criteria. The table may be supplemented with warranty data. The occurrence ranking number is a relative rating within the scope of the FMEA and may not reflect the actual occurrence.

The occurrence ranking itself can not be changed without changing the design to decrease the chance of the failure cause and subsequent failure mode from happening. In the case of a new design (new technology), the occurrence number can be reduced from a 10 (new design, no history) once test or field data/experience has been gained.

NOTE: The team should agree on an evaluation criteria and ranking system that is consistent, even if modified for individual analysis. Any modifications to the table should add value to the risk-mitigation process.

6.6.10 Current Design Controls – Prevention

Current design controls are controls that are being used with the same or similar designs. Prevention types of design controls should be considered when developing the DFMEA, as applicable. A prevention control may not be applicable for every cause and/or failure mode. When not applicable, the prevention controls column on the worksheet can be left blank.

Prevention type design controls describe how a cause, failure mode or effect is prevented. It is part of the basis for determining the rate of occurrence. It is an input to the occurrence ranking when integrated as part of the design intent. Prevention design controls are based on the application of standards, specifications, design rules, design guides, lessons learned, legal standards, design norms or best practices, etc. as a means prevent field failure.

Causes or failure modes that are managed by system detection, decisions and/or actions during normal operation can also be considered prevention design controls because detection controls in the typical DFMEA are limited to product development prior to customer usage. The intent of risk mitigating systems is to detect, by design, a condition or problem and once detected, either take appropriate actions to reduce or eliminate the risk effects or communicate to the end user to take action as failure could be inevitable. Some mitigating prevention controls may also influence the failure effects

and severity.

The Design FMEA Example in Appendix G has two columns for the design controls (i.e., separate columns for Prevention Controls and Detection Controls) to assist the team in clearly distinguishing between these two types of design controls. This allows for a quick visual determination that both types of design controls have been considered. If a one-column (for design controls) form is used, then the following prefix should be used. For prevention controls, place a ‘P’ before each prevention control listed.

Typical current design controls – prevention could be, but are not limited to:

?Published design standard for thread class

?Heat treat specification on drawing

?Redundant design includes sensor shield

?Corporate best practice standard design

?System detection and driver notification for service

?System detection and operational status displayed to driver

NOTE: Use of “carryover design” as a prevention control can only be applied when the application, duty cycle, etc. are the same (no change). Poor field history for a “carryover design” will mean “carryover quality”. The Design FMEA team should consider improvements to a carryover design as necessary.

6.6.11 Current Design Controls – Detection

Detection design controls should be considered when developing the DFMEA as applicable. The detection type of design control describes how a cause and/or failure mode is detected, either by analytical or physical methods, before the item is released to production and is used as an input to the detection ranking. A detection control may not be applicable for every cause and/or failure mode. When not known or not applicable, the detection controls column on the worksheet can be left blank and should be ranked according to the Detection ranking criteria (i.e. Detection 10).

The Design FMEA Example in Appendix G has two columns for the design controls (i.e., separate columns for Prevention Controls and Detection Controls) to assist the team in clearly distinguishing between these two types of design controls. This allows for a quick visual determination that both types of design controls have been considered. If a one-column (for design controls) form is used, then the following prefix should be used. For detection controls, place a ‘D’ before each detection control listed.

Typical current design controls – detection could be, but are not limited to:

?Finite Element Analysis (FEA)

? CAE analytics

?Tolerance stack analysis

?Validation testing (fatigue, water intrusion, vibration, ride and handling, etc.)

NOTE: Manufacturing process controls are not valid design controls.

NOTE: Writing the individual detection numbers for each design control as part of the design control description is considered a best practice with the lowest (best case) detection method used as the detection number.

6.6.12 Detection Ranking Number

Detection is the rank associated with the best design control from the list of detection-type design controls. Detection is a relative ranking, within the scope of the individual FMEA and is determined without regard for severity or occurrence. Detection should be estimated using the criteria in Appendix C – Suggested DFMEA Detection Evaluation Criteria. This table may be augmented with examples of common detection methods used by the company. The team should agree on an evaluation criteria and ranking system, which is consistent, even if modified for individual process analysis.

One of the goals of the DFMEA process is to increase the ability to validate a design prior to start of production. The detection ranking itself can not be improved without changing the sensitivity to detect failure modes during validation and/or verification activities as well as the timing of such activities.

NOTE: Controls such as those that detect and react to faults during vehicle operation are considered mitigating controls.

Mitigating controls (e.g. limp home mode) alter the effect of failures in order to protect vehicle occupants.

Warning mechanisms (e.g. seat belt tone, anti-lock brake light, etc.) alert the driver to take action. Mitigating controls and warning mechanisms are important aspects of product design and should be considered as part of product functionality. The detection ranking criteria reflects those activities done before design release including the validation or verification of the functionality of mitigation controls.

6.6.13 Risk Priority Number (RPN) and Criticality Number (SO)

The risk priority number (RPN) is the product of the severity (S), occurrence (O), and detection (D) ranking. Within the scope of the individual FMEA, this value (between “1” and “1000”). The use of RPN is optional.

RPN = (S) * (O) * (D) E xample: Severity 7, Occurrence 3, Detection 5 is RPN 105

Risk priority number is one of many tools available to a team for evaluating potential risk. It provides an indicator of improvement (before and after actions taken) that reduces any one factor of Severity, Occurrence or Detection. The risk priority number is a tool available to allow review with others outside the team who need to share in the risk assessment process and contribute to risk mitigation.

Final RPN ratings are relative to a particular analysis and are subjective; therefore selecting an RPN threshold is not an acceptable practice. In other words, there is no value above which it is mandatory to take a recommended action or below which the team is automatically excused from an action.

Applying (RPN or SO) thresholds assumes that RPNs are a measure of relative risk (which they often are not) and that continuous improvement is not required (which it is). For example, if the customer applied an arbitrary threshold of 100 to the following, the supplier would be required to take action on Item B with the RPN of 112.

TABLE 1 - RPN COMPARISON

Item Severity Occurrence Detection RPN

A 9 2 5 90

B 7 4 4 112

In this example, the RPN is higher for Item B than Item A. However, the priority should be to work on Item A with the higher severity 9, although its RPN is 90 which is lower and below the threshold. Establishing such thresholds may promote the wrong behavior causing team members to spend time trying to justify a lower occurrence or detection ranking value to reduce the RPN. This type of behavior avoids addressing the real problem that underlies the cause of the failure mode and merely keeps the RPN below the threshold. It is important to recognize that determining reasonable risk is desirable, it should be based on an analysis of severity, occurrence and detection and not through the application of RPN thresholds.

The severity and occurrence risk priority number (SO) is the product of the severity (S) and occurrence (O) ranking. It is sometimes referred to as the Criticality Number. Within the scope of the individual FMEA, this value (between “1” and “100”). The use of SO is an alternative to RPN and is optional.

SO = (S) * (O) E xample: Severity 7, Occurrence 3, Detection 5 is SO 21

In using this index, the organization may focus on how to reduce SO by reducing the value of “O” through preventive actions. Furthermore, this may lead to subsequent detection improvements for those with the highest SO value.

TABLE 2 - CONTRAST AMONG RPN AND SO

S, O, D Rank RPN SO

8, 10, 2 160 80

8, 2, 10 160 16

10, 8, 2 160 80

10, 2, 8 160 20

2, 10, 8 160 20

2, 8, 10 160 16

6.6.14 Recommended Actions

The intent of a recommended action is to prevent or mitigate the risk of the failure (Severity). This is achieved by reducing the likelihood of failure (Occurrence) and/or improving the ability to detect failures prior to production release (Detection).

The primary objective of recommended actions is to reduce risks and increase customer satisfaction by improving the design. Only a design revision can bring about a reduction in the severity ranking. A reduction in the occurrence ranking can be effected only by removing or controlling one or more of the causes of the failure mode through a design revision. An increase in design validation/verification actions will result in a reduction in the detection ranking only. Increasing the design validation / verification actions is a less desirable engineering action since it does not address the severity or occurrence of the failure mode and normally occurs late in the design cycle. Emphasis should be placed on preventing failures (i.e., reducing the occurrence) rather than detecting them.

When the severity is a “9” or “10”, the potential risk must be reviewed regardless of the RPN. In all cases where the effect of an identified potential failure mode could be a hazard to the end-user, preventive/ corrective actions should be considered to avoid the failure mode by eliminating, mitigating, or controlling the cause(s).

The Recommended Action column should be left blank until the team has had the opportunity to assess the risk. If engineering assessment leads to no recommended actions for a specific failure mode/cause/control combination, indicate this by entering “None” in this column.

NOTE: It is recommended that Severity 9 or 10 issues be communicated to the process-responsible team for consideration in a Process FMEA and/or Control Plan. The method for communicating issues from the Design FMEA to the Process FMEA may vary by company.

It is acceptable to include the name of an organization or department with a recommended action; however a person’s name is required for the Responsibility and Target Completion Date.

Actions such as, but are not limited to, the following should be considered:

a. Revised Design Geometry and/or tolerances,

b. Revised Material Specification,

c. Design of experiments (particularly when multiple or interactive causes are present)/or other problem solving

techniques, and

d. Revised Test Plan

e. Confirmation/verification of information (test results, analytical studies, etc.)

f. Communication of information (PFMEA team, Control Plan team, Customer, Supplier, etc.)

g. Other as needed

6.6.15 Responsibility and target completion date

Enter the individual responsible for completing each recommended action by the due date. Additional information such as organization or department may be added to the recommended action statement or responsibility.

6.6.16 Action taken

After an action has been implemented, enter a brief description of the action taken and effective date.

6.6.17 Revised ratings

After the action been implemented, write the revised occurrence and detection rankings (the Severity ranking itself can not be changed without eliminating the failure mode and its effects). Calculate and record the resulting RPN (when used). If no actions were taken, leave the related ranking columns blank. If further action is considered necessary, repeat the analysis. The focus of the DFMEA should be on continual improvement.

NOTE: The DFMEA serves as a historical record for the design, therefore the original Severity, Occurrence, and Detection numbers are not modified once actions have been taken.

NOTE: Original ratings may be modified for basis, family or generic DFMEAs because the information is used as a starting point for an application-specific analysis.

7. PROCESS FMEA

7.1 Timing

The Process FMEA should be started before or at the feasibility stage and prior to tooling for production. Basis, Baseline, Generic FMEAs or process family FMEAs from similar manufacturing processes are the starting point for the risk management process when available. The basis FMEA or process family FMEA should be edited to document those specific manufacturing and assembly differences between the basis project and the current project. Early review and analysis of new or revised processes allows the team to anticipate, resolve or monitor potential process concerns during the manufacturing planning stages of a new model or component program.

The FMEA should be “in principle” complete prior to tooling release. There may be more than one tooling release date for a complex project and if so, than each of those areas of risk connected with the specific tool can be completed “in principle” by the appropriate tooling date constraint. The tooling date can be considered as actual tooling die release or it can be more broadly understood as the software release date, integrated circuit mask release date, wire harness release date, manufacturing plant layout, specific machine design release date, etc. The tooling release date is the date at which further design changes to the actual tooling become difficult or impossible to incorporate beyond drawing or other supporting document changes.

7.2 Scope

The scope of a PFMEA depends on many factors including:

a. process-responsibility

b. process interfaces

The scope of a Process FMEA can more easily be defined by using a process flow diagram. The process flow diagram should take into account every possible process step a part is anticipated to take through the manufacturing or assembly process. A detailed process flow diagram provides a roadmap for analysis of each step in the process. The process flow diagram provides a format to consider how process characteristics (inputs) help control the effect on product characteristics (outputs) within a given operation. Copies of the diagrams used in FMEA preparation should be available upon request.

Responsibility

7.2.1 Process

The scope defines the operations for which the team is responsible for designing. This defines the elements that will be analyzed. This is the item for which the engineering team has process design ownership and risk mitigation.

Interfaces

7.2.2 Process

The scope defines the process boundary. At the process boundaries there are interfaces with other processes such as receiving, off-line repair, off-line inspection, dunnage and shipping. Process FMEA can be used to analyze these interfacing processes by their owners.

7.3 Inputs

The PFMEA team should review various inputs such as:

a. Warranty

b. Recalls

c. Engineering requirements

d. Drawings

e. Lessons learned

f. Preliminary process verification plan

g. Family or product-specific DFMEA

h. Family or prior PFMEA

i. Bill of material

j. Manufacturing feasibility study

k. Process flow diagram

l. Characteristic matrix

m. other

7.4 Output

The PFMEA team should produce various outputs such as:

a. High-severity failure modes

b. High-risk failure modes

c. Updated characteristic classification list

d. Design features that may require additional controls

e. Action plans for design, verification, manufacturing, supplier, etc.

f. PFMEA worksheet

g. A summary document comprised of some or all the above

h. Preventive and detective controls which are detailed on the pre-launch or production control plans

7.5 Assumptions

The PFMEA should address manufacturing/assembly risk and assume the product, as designed, will meet the design intent. The Design FMEA should address the design intent and assume the design will be manufactured/assembled to this intent.

In preparation for the PFMEA, the assumption may be made that incoming part(s)/material(s) are correct. Exceptions can be made as experience dictates (e.g. known deficiencies in incoming part quality).

The PFMEA, as an analytical engineering tool, records the ideas and concerns of a process team; therefore, it is understood that failures shown in the PFMEA are potential. As such, failures described in the PFMEA may or may not occur.

7.6 Procedure

Information

7.6.1 Header

The PFMEA worksheet contains important information about the analysis. The header must include a project name, latest revision date, and organization, department, and group or individual who is process responsible. Additional information such as PFMEA number, model year, program number, key date analysis completion target date, core and support team member names, and team facilitator, etc. may be documented in the header to provide useful information for tracking or storage and retrieval purposes. A separate team member list including names and departments is optional.

Step

7.6.2 Process

The process step is an identification of the operation or steps in an operation being analyzed and must be written in the PFMEA. The process step identification (e.g. department number, operation number, work element number, etc.) should be consistent with other process documents including the process flow diagram and control plans.

7.6.3 Function and Requirement

A process function describes what is happening to the part within a detailed step of a given operation. The function(s) of each operation being analyzed must be written in the PFMEA. A process may have more than one operation.

Wording of the operation description should consider the operation (Do this), the part (To this) and tooling (With this). Operations include, but are not limited to, fabrication, move, store, get, inspect, rework, scrap, changeover, quality audits and other planned process activities. The more precise the description of the process functions, the easier it is to identify potential failure modes for preventive/corrective controls and actions. If the operation has more than one step with different potential modes of failure, list each of the steps separately in the PFMEA worksheet.

A process requirement defines the desired outcome of the process or operation. A process function may have multiple requirements. Requirements are measurable characteristics of a product or process and may be documented in the PFMEA worksheet. Values for requirements should be included in the product specification to define the acceptance criteria for the control plan.

NOTE: If the operations within the Process Flow Diagram (PFD) are well defined, the operation description in the PFD should be identical to the process function in the PFMEA. The process function within the PFMEA should become the operation description within the Process Control Plan (PCP). This provides a clear linkage between the PFD, PFMEA and PCP. It is recommended to link operation number between PFD, PFMEA and PCP as well.

Typical process functions could be, but are not limited to:

Load

Unload

Induction Harden

Grind

Wash

Inspect

Repair

Typical requirements could be, but are not limited to:

Correct part number loaded

Hardness

Outside Diameter

Inside Diameter

Length

Concentricity

Cleanliness

Reject bad parts

7.6.4 Potential Failure Mode

A potential failure mode is the manner in which the manufacturing and assembly process could potentially fail to meet the product and process requirements. It is a description of the product or process failure mode at that specific operation. Each potential failure mode (product defect or process non-conformance) should be considered independently of other potential failure modes. This enables the team to address the unique reasons (causes of failure) independently of other failure modes. Grouping multiple potential failure modes in one cell in a worksheet is not recommended.

Typical failure modes could be, but are not limited to:

– Hole too shallow

– Hole too deep

– Hole missing

– Hole off-location

– Dirty

– Deformed

– Surface finish too smooth

– Burred

– Open circuited

– Short circuited

– Bent

– Cracked

– Misaligned

– Missing label

7.6.5 Potential

Effects

The effects of the failure mode on the customer in terms of what the customer might notice or experience. The effects can be the effect at the operation, subsequent operations, customer operations as well as the end customer. It should clearly state if the effect of a failure mode could impact safety or non-compliance to regulations, when applicable.

NOTE: In some cases, the team conducting the analysis may not know the end user effect. For example, the application for the hinge may not be known (emergency exit door, dumpster lid, gate, etc.) or it may not be known how this hinge affects the next level system. When this information is not known, the effects should be defined in terms of the operation. Manufacturing/assembly customers are those that require the feature not necessarily the next step in the operation.

Typical failure effects could be, but are not limited to:

For the End User, the effects should be stated in terms of product or system performance (refer to the Design FMEA when applicable) such as:

End User: Vehicle control impaired, inoperative, erratic operation, intermittent operation, operation impaired, unstable, rough, external leaks, noise, poor appearance, unpleasant odor, draft

Government: Non-compliance with regulations

If the customer is the operator or next operation or subsequent operation(s)/location(s), the effects should be stated in terms of process/operation performance, such as:

Operator: Ergonomics, operator safety

Operation: Cannot fasten, cannot mount, does not fit, does not match, cannot bore/tap

D oes not connect, can not face, excessive tool wear, equipment damage, s crap, rework

7.6.6 Severity Ranking Number

Severity is a ranking number associated with the most serious effect for a given failure mode for the operation being evaluated. It is a relative ranking within the scope of the individual FMEA and is determined without regard for occurrence or detection.

Severity should be estimated using the criteria in Appendix A – Suggested PFMEA Severity Evaluation Criteria. The table may be augmented to include product-specific examples. The team should agree on an evaluation criteria and ranking system, which is consistent, even if modified for individual process analysis.

NOTE: If the customer affected by a failure mode is the next manufacturing or assembly plant or the product user, assessing the severity may lie outside the immediate process engineer's/team's field of experience or knowledge.

In these cases, the design FMEA, design engineer, and/or subsequent manufacturing or assembly plant process engineer, should be consulted in order to comprehend the propagation of effects.

One of the goals of the FMEA process is to mitigate risk or lessen the impact of a potential failure mode. The severity ranking itself can not be changed without eliminating the failure mode and its effects.

NOTE: Writing the individual severity numbers for each effect as part of the effects description is considered a best practice with the highest (worst case) effect used as the severity number.

7.6.7 Classification

The use of the classification column is optional in a PFMEA. This column may be used to highlight failure modes or causes for the purpose of identifying issues to be further discussed with the team as well as others outside the team including management and a Design FMEA team to determine if additional action is necessary. Certain letter codes or symbols may be used. Companies may use various criteria for including:

?High priority failure modes (based on Severity, Severity and Occurrence, Severity and Detection)

?Special characteristics (examples include safety, government, critical, and key characteristics which are directed by specific company policy and are not standardized in this document)

?Warranty campaigns and recalls

?Other criteria specified by the team

7.6.8 Potential Cause of Failure

A potential cause of failure is an indication of how the failure could occur. The consequence of a cause is the failure mode. Identify, to the extent possible, every potential manufacturing or assembly cause for each failure mode. The cause should be listed as concisely and completely as possible so that remedial efforts (controls and actions) can be aimed at appropriate causes.

Typical failure causes may include, but are not limited to:

– Machine/Equipment (machine capability, initial setup adjustment, machine wear over time, inadequate gating/venting, inadequate or no lubrication, tool wear over time, tool breakage, tool-to-tool differences, fixture tolerance, fixture adjustment, fixture wear over time, chip on locator, worn locator, weld current too high or low, weld pressure, heat treat temperature too high or low, equipment maintenance including repair, replacement, reassembly, and adjustment, inspection gauging failures including inaccuracies, and ineffectiveness, etc.)

– Methods/Systems (sequence, procedures, layout, off-line rework/repair, off-line inspection, material flow, process control programming, etc.)

– Material/Components (part missing, part mis-located, incoming raw material, purchased parts, previous operations)

– Manpower/Operator (manual over torque, manual under torque, operator skill, ergonomic factors, time, visual aids, etc.)

– Environment (plant temperature, humidity, dust, noise, etc.)

NOTE: The above examples represent categories. Specific details need to be added to complete the cause description.

Only specific errors or malfunctions (e.g. part installed upside down) should be listed; ambiguous phrases (e.g., operator error, machine malfunction) should not be used.

NOTE: Refer to assumptions for failure causes that may, or may not be included in the analysis.

7.6.9 Occurrence Ranking Number

Occurrence is a ranking number associated with each cause for a given failure mode being evaluated. The occurrence ranking considers the likelihood of occurrence during production. The occurrence ranking number has a relative meaning rather than an absolute value and is determined without regard for severity or detection. The occurrence ranking takes into account the prevention-type process controls.

Occurrence should be estimated using the criteria in Appendix B – Suggested PFMEA Occurrence Evaluation Criteria. The table may be supplemented with volumes and quality levels such as parts per million or statistical measures such as capability and performance indices. In other cases, a subjective assessment can be made by using the word descriptions from the left column of the table. The occurrence ranking number is a relative rating within the scope of the FMEA and may not reflect the actual occurrence.

The occurrence ranking itself can not be changed without changing the design or process to decrease the chance of the failure cause and subsequent failure mode from happening.

NOTE: The team should agree on an evaluation criteria and ranking system that is consistent, even if modified for individual process analysis. Any modifications to the table should add value to the risk mitigation process.

7.6.10 Current Process Controls – Prevention

Prevention process controls should be considered when developing the PFMEA as applicable. The prevention controls describe how a cause and/or failure mode is prevented or how the rate of occurrence is reduced and is used as input to the occurrence ranking when integrated as part of the process. A prevention control may not be applicable for every cause and/or failure mode. When not applicable, the prevention controls column on the worksheet can be left blank.

The Process FMEA Example in Appendix J has two columns for the process controls (i.e., separate columns for Prevention Controls and Detection Controls) to assist the team in clearly distinguishing between these two types of process controls. This allows for a quick visual determination that both types of process controls have been considered. If a one-column (for process controls) form is used, then the following prefix should be used. For prevention controls, place a ‘P’ before each prevention control listed.

Product and process error proofing features and devices and automated process controls are examples of prevention controls.

Prevention Process Controls

Error proofing

Equipment maintenance (e.g. skilled trades performed)

Operator maintenance (e.g. blow chips out of nest)

Work instructions / Visual aids

Machine controls (e.g. machine monitoring of fluid levels)

7.6.11 Current Process Controls – Detection

Detection process controls should be considered when developing the PFMEA as applicable. The detection control assumes a failure has occurred and describes how a cause and/or failure mode is detected. The process control may occur at the subject operation or at subsequent operations. Detection controls are used as an input to the detection ranking. When not known or not applicable, the detection controls column on the worksheet can be left blank and should be ranked according to the Detection ranking criteria (i.e. Detection 10).

The Process FMEA Example in Appendix J has two columns for the process controls (i.e., separate columns for Prevention Controls and Detection Controls) to assist the team in clearly distinguishing between these two types of process controls. This allows for a quick visual determination that both types of process controls have been considered. If a one-column (for process controls) form is used, then the following prefix should be used. For detection controls, place a “D” before each detection control listed.

Detection Process Controls

Gauging

End of line test

Visual inspection

7.6.12 Detection Ranking Number

Detection is a ranking number associated with the capabilities of all the current process controls for a given cause and/or failure mode. Do not automatically presume the detection ranking is low because the occurrence ranking is low, instead assume the failure has occurred then assess the capabilities of all the detection-type design controls to detect low-frequency failure modes. The detection ranking is identified without regard for severity or occurrence.

Detection is a relative ranking, within the scope of the individual FMEA. Detection should be estimated using the criteria in Appendix C – Suggested PFMEA Detection Evaluation Criteria. This table may be augmented with examples of common detection methods used by the company. The team should agree on an evaluation criteria and ranking system, which is consistent, even if modified for individual process analysis.

NOTE: Writing the individual detection numbers for each design control as part of the design control description is considered a best practice with the lowest (best case) detection method used as the detection number.

7.6.13 Risk Priority Number (RPN) and Criticality Number (SO)

The risk priority number (RPN) is the product of the severity (S), occurrence (O), and detection (D) ranking. Within the scope of the individual FMEA, this value (between “1” and “1000”). The use of RPN is optional.

RPN = (S) * (O) * (D) E xample: Severity 7, Occurrence 3, Detection 5 is RPN 105

Risk priority number is one of many tools available to a team for evaluating potential risk. It provides an indicator of improvement (before and after actions taken) that reduces any one factor of Severity, Occurrence or Detection. The risk priority number is a tool available to allow review with others outside the team who need to share in the risk assessment process and contribute to risk mitigation.

Final RPN ratings are relative to a particular analysis and are subjective, therefore selecting an RPN threshold is not an acceptable practice. In other words, there is no value above which it is mandatory to take a recommended action or below which the team is automatically excused from an action.

Applying (RPN or SO) thresholds assumes that RPNs are a measure of relative risk (which they often are not) and that continuous improvement is not required (which it is). For example if the customer applied an arbitrary threshold of 100 to the following, the supplier would be required to take action on the characteristic B with the RPN of 112.

TABLE 3 - RPN COMPARISON

Item Severity Occurrence Detection RPN

A 9 2 5 90

B 7 4 4 112

五大工具手册APQP、PPAP、SPC、MSA、FMEA

五大工具手册APQP、PPAP、SPC、MSA、FMEA 1.产品质量先期策划(APQP)、 2.测量系统分析(MSA)、 3.统计过程控制(SPC)、 4.生产件批准(PPAP) 5.潜在失效模式与后果分析(FMEA) 一、APQP(Advanced Product Quality Planning)即产品质量先期策划,是一种结构化的方法,用来确定和制定确保某产品使顾客满意所需的步骤。产品质量策划的目标是促进与所涉及的每一个人的联系,以确保所要求的步骤按时完成。有效的产品质量策划依赖于公司高层管理者对努力达到使顾客满意这一宗旨的承诺。 产品质量策划有如下的益处: ◆引导资源,使顾客满意; ◆促进对所需更改的早期识别; ◆避免晚期更改; ◆以最低的成本及时提供优质产品 二、PPAP:生产件批准程序(Production part approval process)

ppap生产件提交保证书:主要有生产件尺寸检验报告,外观检验报告,功能检验报告, 材料检验报告;外加一些零件控制方法和供应商控制方法;主要是制造形企业要求供应商在提交产品时做ppap文件及首件,只有当ppap文件全部合格后才能提交;当工程变更后还须提交报告。 ppap是对生产件的控制程序,也是对质量的一种管理方法。 三、SPC(Statistical Process Control)即统计过程控制,主要是指应用统计分析技术对生产过程进行适时监控,科学区分出生产过程中产品质量的随机波动与异常波动,从而对生产过程的异常趋势提出预警,以便生产管理人员及时采取措施,消除异常,恢复过程的稳定从而达到提高和控制质量的目的。 SPC非常适用于重复性的生产过程,它能够帮助组织对过程作出可靠的评估,确定过程的统计控制界限判断过程是否失控和过程是否有能力;为过程提供一个早期报警系统,及时监控过程的情况,以防止废品的产生,减少对常规检验的依赖性,定时以观察以及系统的测量方法替代大量检测和验证工作。 2.SPC实施意义 可以使企业:

五大工具手册APQPPAPSPCMSAFMEA

五大工具手册 A P Q P P A P S P C M S A F M E A Document serial number【UU89WT-UU98YT-UU8CB-UUUT-UUT108】

五大工具手册APQP、PPAP、SPC、MSA、FMEA? 1.产品质量先期策划(APQP)、 2.测量系统分析(MSA)、 3.统计过程控制(SPC)、 4.生产件批准(PPAP) 5.潜在失效模式与后果分析(FMEA) 一、APQP(Advanced Product Quality Planning)即产品质量先期策划,是一种结构化的方法,用来确定和制定确保某产品使顾客满意所需的步骤。产品质量策划的目标是促进与所涉及的每一个人的联系,以确保所要求的步骤按时完成。有效的产品质量策划依赖于公司高层管理者对努力达到使顾客满意这一宗旨的承诺。 产品质量策划有如下的益处: ◆引导资源,使顾客满意; ◆促进对所需更改的早期识别; ◆避免晚期更改; ◆以最低的成本及时提供优质产品 二、PPAP:生产件批准程序(Production part approval process) ppap生产件提交保证书:主要有生产件尺寸检验报告,外观检验报告,功能检验报告, 材料检验报告;外加一些零件控制方法和供应商控制方法; 主要是制造形企业要求供应商在提交产品时做ppap文件及首件,只有当ppap文件全部合格后才能提交;当工程变更后还须提交报告。 ppap是对生产件的控制程序,也是对质量的一种管理方法。

三、SPC(Statistical Process Control)即统计过程控制,主要是指应用统计分析技术对生产过程进行适时监控,科学区分出生产过程中产品质量的随机波动与异常波动,从而对生产过程的异常趋势提出预警,以便生产管理人员及时采取措施,消除异常,恢复过程的稳定从而达到提高和控制质量的目的。 SPC非常适用于重复性的生产过程,它能够帮助组织对过程作出可靠的评估,确定过程的统计控制界限判断过程是否失控和过程是否有能力;为过程提供一个早期报警系统,及时监控过程的情况,以防止废品的产生,减少对常规检验的依赖性,定时以观察以及系统的测量方法替代大量检测和验证工作。 2.SPC实施意义 可以使企业: ◆降低成本 ◆降低不良率,减少返工和浪费 ◆提高劳动生产率 ◆提供核心竞争力 ◆赢得广泛客户 3.实施SPC两个阶段 分析阶段:运用控制图、直方图、过程能力分析等使过程处于统计稳态,使过程能力足够。 监控阶段:运用控制图等监控过程 SPC的产生: 工业革命以后,随着生产力的进一步发展,大规模生产的形成,如何控制大批量产品质量成为一个突出问题,单纯依靠事后检验的质量控制方法已不能适应当时经济发展的要求,必须改进质量管理方式。于是,英、美等国开始着手研究用统计方法代替事后检验的质量控制方法。 1924年,美国的休哈特博士提出将3Sigma原理运用于生产过程当中,并发表了着名的“控制图法”,对过程变量进行控制,为统计质量管理奠定了理论和方法基础。

质量管理体系及五大工具知识

质量管理体系及16949五大工具知识 二〇一一年三月 质量管理体系及16949五大工具知识 1、我公司为什么要实施16949:2009《质量管理体系汽车生产件及相关服务件组织执行9001:2008的具体要求》? 1)贯彻、实施16949规范是汽车整车厂对供方的普遍要求。

2)16949:2009内容上增加了一些适合汽车行业特点的要求, 如进行潜在失效模式及后果分析、防错等。 3)9000标准中可能存在的一些薄弱环节得到加强,如采用手 册,帮助企业建立策划新产品设计和开发的步骤。 4)使企业的质量管理体系更加完善。引入持续改进的概念、采 用潜在失效模式和后果分析()等。 5)引入了一些新的质量理念,如实行过程控制,而不是产品控 制。 2、八项质量管理原则的内容是什么? 以顾客为关注焦点;领导作用;全员参与;过程方法;管理的系统方法;持续改进;基于事实的决策方法;与供方互利的关系。 3、我公司的质量方针是什么? 质量方针:以顾客满意为宗旨,全员参与持续改进,打造“潍 柴”驰名品牌。 4、16949:2009的结构。 包含:9001:2008的内容;增加了适合汽车及相关服务件组织的79个条款;先期产品质量策划和控制计划、潜在失效模式及后果分析、测量系统分析、统计过程控制、生产件批准程序等五本手册。 5、什么是?(先期产品质量策划和控制计划)为什么 进行?分几个阶段?各阶段主要任务是什么? 是一种系统的方法,用于确定并建立保证产品满足顾客需求的 必需步骤。 因为采用了多方论证的方式,利用不同职能人员的集体智慧, 通过早期策划,找出以后可能出现的质量问题,并采取预防措施, 最大限度的减少变差和浪费,以最经济、最合理的资源配置生产, 满足顾客要求。 分为五个阶段:计划和项目的确定,产品设计和开发,过程设

质量管理五大工具

质量管理五大工具 1总体介绍 2 3 4 5 6 1总体介绍 质量管理五大工具,也称品管五大工具。包括:1.统计过程控制(,);2.测量系统分析(,);3.失效模式和效果分析(,& );4.产品质量先期策划(,);5. 生产件批准程序(,) 2 是一种制造控制方法,是将制造中的控制项目,依其特性所收集的数据,通过过程能力的分析与过程标准化,发掘过程中的异常,并立即采取改善措施,使过程恢复正常的方法。 利用统计的方法来监控制程的状态,确定生产过程在管制的状态下,以降低产品品质的变异能解决之问题1.经济性:有效的抽样管制,不用全数检验,不良率,得以控制成本。使制程稳定,能掌握品质、成本与交期。2.预警性:制程的异常趋势可即时对策,预防整批不良,以减少浪费。3.分辨特殊原因:作为局部问题对策或管理阶层系统改进之参考。4.善用机器设备:估计机器能力,可妥善安排适当机器生产适当零件。5.改善的评估:制程能力可作为改善前後比较之指标。 ·对过程做出可靠有效的评估; ·确定过程的统计控制界限,判断过程是否失控和过程是否有能力; ·为过程提供一个早期报警系统,及时监控过程的情况以防止废品的发生;

·减少对常规检验的依赖性,定时的观察以及系统的测量方法替代了大量的检测和验证工作[1]。 和不合格率 计算能力比值不合格(双边)不合格(单边) 0.50 133,620 133,620 0.60 71,860 71,860 0.70 35,730 35,730 0.80 16,396 16,396 0.90 6,934 6,934 1.00 2,700 2,700 1.10 966 966 1.20 318 318 1.30 96 96 1.40 26 26 1.50 7 7 1.60 2 2 1.70 0.340 0.340 1.80 0.060 0.060 1.90 0.012 0.012 2.00 0.002 0.002 是的缩写,是现代企业用于表示制程能力的指标。制程能力强才可能生产出质量、可靠性高的产品。而是中控制图中用来计算工序能力或叫过程能力的指数,是指考虑过程有偏差时,样本数据的过程性能。

品质五大工具

质量管理五大工具 编辑 质量管理五大工具,也称品管五大工具。包括:1.统计过程控制(SPC,Statistical Process Control);2.测量系统分析(MSA,Measure System Analyse);3.失效模式和效果分析(FMEA,Failure Mode & Effect Analyse);4.产品质量先期策划(APQP,Advanced Product Quality Planning);5.生产件批准程序(PPAP,Production Part Approval Process)。 1SPC 概念 SPC是一种制造控制方法,是将制造中的控制项目,依其特性所收集的数据,通过过程能力的分析与过程标准化,发掘过程中的异常,并立即采取改善措施,使过程恢复正常的方法[1]。利用统计的方法来监控制程的状态,确定生产过程在管制的状态下,以降低产品品质的变异SPC能解决之问题1.经济性:有效的抽样管制,不用全数检验,不良率,得以控制成本。使制程稳定,能掌握品质、成本与交期。 2.预警性:制程的异常趋势可即时对策,预防整批不良,以减少浪费。3.分辨特殊原因:作为局部问题对策或管理阶层系统改进之参考。4.善用机器设备:估计机器能力,可妥善安排适当机器生产适当零件。 5.改善的评估:制程能力可作为改善前後比较之指标。 目的 ·对过程做出可靠有效的评估; ·确定过程的统计控制界限,判断过程是否失控和过程是否有能力; ·为过程提供一个早期报警系统,及时监控过程的情况以防止废品的发生; ·减少对常规检验的依赖性,定时的观察以及系统的测量方法替代了大量的检测和验证工作[1]计算表 Pp 和Ppk不合格率 计算能力比值PP不合格(双边)Ppk不合格(单边) 0.50133,620133,620 0.6071,86071,860 0.7035,73035,730 0.8016,39616,396 0.906,9346,934 1.002,7002,700 1.10966966 1.20318318 1.309696 1.402626 1.5077 1.6022 1.700.3400.340 1.800.0600.060

iatf 16949质量管理体系五大工具版一本通附录 word版

质量管理办法 质量成本管理 为什么要进行质量成本管理道理很简单,企业建立的质量管理体系不仅应确保产品质量满足顾客的要求,更应减少质量损失\降低成本\增加盈利.如何用较合理的质量成本确保产品质量的提高,是每一个企业都必须面对的课题,质量成本管理为这一课题提供了全方位的解决之道. 附质量体系的财务表现 如何运用财务数据来分析和报告质量体系的有效性,一般有三个方法:过程成本法、质量损失法、质量成本法。 1、过程成本法 过程成本法是指用于分析产品生产或服务提供中任何过程所发生的符合性成本和非符合性成本。 (1)符合性成本 指为了满足拥护全部规定的和隐含的需要,现有过程不发生故障情况下而发生的费用。主 要指过程的预防、鉴定、外部保证等方面的投入。 (2)非符合性成本 由于现有过程的故障而发生的费用。主要指过程质量故障造成的损失。 过程成本法着重分析非符合性成本故障的产生原因,寻找降低的方法,为减少损失、降低 成本、提供信息、指出改进提供途径。 “过程成本法”一般在需要时进行,没必要定期报告。 2、质量损失法 质量损失法是针对由于质量差而产生的内部和外部损失,并按照企业提供产品或服务的具体情况,分别列出内部有形损失和无形损失类目。 典型的外部无形损失是指由于顾客不满意,以及造成抱怨、申诉或索赔等而造成影响今后销售的损失。 典型的内部无形损失是由于返工、人与机械控制不当、失去机会等而造成工作效率降低的后果。 有形损失是指内部和外部故障损失。 如果企业结构单一,有关活动简单或单纯,或质量管理体系不健全,最好采用质量损失法(只统计有形损失),而不必进行复杂的质量成本管理。 3、质量成本法 见下面附。 附质量成本法概论 1、质量成本的定义 质量成本(Quality-related Costs)是指为了确保和保证满意的质量而发生的费用以及没有达到满意的质量所造成的损失。 质量成本是体现产品质量经济性的一个重要方面。质量成本的高低可以衡量一个企业质量体系运行的有效性,也为质量改进提供依据。因此开展质量成本管理对改进产品质量、降低成本、提高管理水平具有重要意义。 2、质量成本的构成 质量成本由运行质量成本(Qperating Quality Costs)和外部保证质量成本(External

质量管理计划的五大工具和八大手法

01、五大工具 一,APQP APQP(AdvancedProductQualityPlanning)即产品质量先期策划,是一种结构化的方法,用来确定和制定确保某产品使顾客满意所需的步骤。 产品质量策划的目标是促进与所涉及的每一个人的联系,以确保所要求的步骤按时完成。有效的产品质量策划依赖于公司高层管理者对努力达到使顾客满意这一宗旨的承诺。 产品质量策划有如下的益处: 引导资源,使顾客满意; 促进对所需更改的早期识别; 避免晚期更改; 以最低的成本及时提供优质产品。 二,FMEA FMEA(PotentialFailureModeandEffectsAnalysis)即潜在的失效模式及后果分析,是在产品/过程/服务等的策划设计阶段,对构成产品的各子系统、零部件,对

构成过程,服务的各个程序逐一进行分析,找出潜在的失效模式,分析其可能的后果,评估其风险,从而预先采取措施,减少失效模式的严重程序,降低其可能发生的概率,以有效地提高质量与可靠性,确保顾客满意的系统化活动。 FMEA种类: 按其应用领域常见FMEA有设计FMEA(DFMEA)和过程FMEA(PFMEA),其它还有系统FMEA,应用FMEA,采购FMEA,服务FMEA。 三,MSA MSA(MeasurementSystemAnalysis)即MSA测量系统分析,它使用数理统计和图表的方法对测量系统的误差进行分析,以评估测量系统对于被测量的参数来说是否合适,并确定测量系统误差的主要成份。 四,PPAP

PPAP(Productionpartapprovalprocess)即生产件批准程序,是对生产件的控制程序,也是对质量的一种管理方法。 PPAP生产件提交保证书:主要有生产件尺寸检验报告、外观检验报告、功能检验报告,、材料检验报告、外加一些零件控制方法和供应商控制方法; 制造型企业要求供应商在提交产品时做PPAP文件及首件,只有当PPAP文件全部合格后才能提交;当工程变更后还须提交报告。 五,SPC SPC(StatisticalProcessControl)即统计过程控制,主要是指应用统计分析技术对生产过程进行适时监控,科学区分出生产过程中产品质量的随机波动与异常波动,从而对生产过程的异常趋势提出预警,以便生产管理人员及时采取措施,消除异常,恢复过程的稳定从而达到提高和控制质量的目的。

质量体系五大工具七大手法定义及详细解读

质量体系五大工具 APQP(Advanced Product Quality Planning)即产品质量先期策划,是一种结构化的方法,用来确定和制定确保某产品使顾客满意所需的步骤。产品质量策划的目标是促进与所涉及的每一个人的联系,以确保所要求的步骤按时完成。有效的产品质量策划依赖于公司高层管理者对努力达到使顾客满意这一宗旨的承诺。 产品质量策划有如下的益处: ◆ 引导资源,使顾客满意; ◆ 促进对所需更改的早期识别; ◆ 避免晚期更改; ◆ 以最低的成本及时提供优质产品。 SPC(Statistical Process Control)即统计过程控制,主要是指应用统计分析技术对生产过程进行适时监控,科学区分出生产过程中产品质量的随机波动与异常波动,从而对生产过程的异常趋势提出预警,以便生产管理人员及时采取措施,消除异常,恢复过程的稳定从而达到提高和控制质量的目的。 SPC非常适用于重复性的生产过程,它能够帮助组织对过程作出可靠的评估,确定过程的统计控制界限判断过程是否失控和过程是否有能力;为过程提供一个早期报警系统,及时监控过程的情况,以防止废品的产生,减少对常规检验的依赖性,定时以观察以及系统的测量方法替代大量检测和验证工作。 ⊙SPC实施意义 可以使企业: ◆ 降低成本 ◆ 降低不良率,减少返工和浪费 ◆ 提高劳动生产率 ◆ 提供核心竞争力 ◆ 赢得广泛客户 ⊙实施SPC两个阶段 分析阶段:运用控制图、直方图、过程能力分析等使过程处于统计稳态,使过程能力足够。 监控阶段:运用控制图等监控过程 ⊙SPC的产生:

工业革命以后,随着生产力的进一步发展,大规模生产的形成,如何控制大批量产品质量成为一个突出问题,单纯依靠事后检验的质量控制方法已不能适应当时经济发展的要求,必须改进质量管理方式。于是,英、美等国开始着手研究用统计方法代替事后检验的质量控制方法。 1924年,美国的休哈特博士提出将3Sigma原理运用于生产过程当中,并发表了著名的“控制图法”,对过程变量进行控制,为统计质量管理奠定了理论和方法基础。 ⊙SPC的作用: 1、确保制程持续稳定、可预测。 2、提高产品质量、生产能力、降低成本。 3、为制程分析提供依据。 4、区分变差的特殊原因和普通原因,作为采取局部措施或对系统采取措施的指南。 FMEA(Potential Failure Mode and Effects Analysis)即潜在的失效模式及后果分析,是在产品/过程/服务等的策划设计阶段,对构成产品的各子系统、零部件,对构成过程,服务的各个程序逐一进行分析,找出潜在的失效模式,分析其可能的后果,评估其风险,从而预先采取措施,减少失效模式的严重程序,降低其可能发生的概率,以有效地提高质量与可靠性,确保顾客满意的系统化活动。 ⊙FMEA种类: 按其应用领域常见FMEA有设计FMEA(DFMEA)和过程FMEA(PFMEA),其它还有系统FMEA,应用FMEA,采购FMEA,服务FMEA。 MSA:Measurement System Analysis的简称 MSA测量系统分析,它使用数理统计和图表的方法对测量系统的误差进行分析,以评估测量系统对于被测量的参数来说是否合适,并确定测量系统误差的主要成份。 PPAP:生产件批准程序(Production part approval process) ⊙PPAP生产件提交保证书:主要有生产件尺寸检验报告,外观检验报告,功能检验报告, 材料检验报告;外加一些零件控制方法和供应商控制方法; ⊙主要是制造型企业要求供应商在提交产品时做PPAP文件及首件,只有当PPAP文件全部合格后才能提交;当工程变更后还须提交报告。 PPAP是对生产件的控制程序,也是对质量的一种管理方法。

质量管理五大工具、七大手法知识点总结

质量管理五大工具、七大手法知识点总结 五大工具 APQP APQP(Advanced Product Quality Planning)即产品质量先期策划,是一种结构化的方法,用来确定和制定确保某产品使顾客满意所需的步骤。 产品质量策划的目标是促进与所涉及的每一个人的联系,以确保所要求的步骤按时完成。有效的产品质量策划依赖于公司高层管理者对努力达到使顾客满意这一宗旨的承诺。 产品质量策划有如下的益处: 引导资源,使顾客满意; 促进对所需更改的早期识别; 避免晚期更改; 以最低的成本及时提供优质产品。 FMEA FMEA(Potential Failure Mode and Effects Analysis)即潜在的失效模式及后果分析,是在产品/过程/服务等的策划设计阶段,对构成产品的各子系统、零部件,对构成过程,服务的各个程序逐一进行分析,找出潜在的失效模式,分析其可能

的后果,评估其风险,从而预先采取措施,减少失效模式的严重程序,降低其可能发生的概率,以有效地提高质量与可靠性,确保顾客满意的系统化活动。 FMEA种类: 按其应用领域常见FMEA有设计FMEA(DFMEA)和过程FMEA(PFMEA),其它还有系统FMEA,应用FMEA,采购FMEA,服务FMEA。 MSA MSA(Measurement System Analysis)即MSA测量系统分析,它使用数理统计和图表的方法对测量系统的误差进行分析,以评估测量系统对于被测量的参数来说是否合适,并确定测量系统误差的主要成份。 PPAP PPAP(Production part approval process) 即生产件批准程序,是对生产件的控制程序,也是对质量的一种管理方法。

质量管理五大工具介绍

质量管理五大工具简介 质量五大工具起初源于QS9000要求,QS9000是美国三大汽车公司通用、福特、克莱斯勒及一些货车制造公司所制定的供应商基本质量体系要求,后与德国汽车工业联合会VDA 、法国汽车工业质量体系EAQF 及意大利汽车工业质量体系AVSQ 进行整合,形成ISO/TS16949,一个国际标准化组织的技术规范,在全球汽车行业中统一现行的质量体系要求。质量五大工具为ISO/TS16949的顾客支持参考技术手册,主要为产品质量先期策划APQP (Advanced Product Quality Planning )、失效模式和效果分析FMEA (Failure Mode & Effects Analysis )、测量系统分析MSA (Measurement System Analysis )、统计过程控制SPC (Statistical Process Control )、生产件批准程序PPAP (Production Part Approval Process ),其相互关系见下图。 1. APQP 即产品质量先期策划,是一种结构化的方法,用来确定和制定确保某产品使顾客满意所需的步骤。产 品质量策划的目标是促进与所涉及的每一个人的联系,以确保所要求的步骤按时完成。有效的产品质 量策划依赖于公司高层管理者对努力达到使顾客满意这一宗旨的承诺。 产品质量先期策划的益处主要为引导资源,使顾客满意;促进对所需更改的早期识别;避免晚期更改;以最低的成本及时提供优质产品。 产品指令先期策划主要分五个过程: a.计划和定义 ·如何确定顾客的需要和期望,以计划和定义质量大纲; ·做一切工作必须把顾客牢记心上; ·确认顾客的需要和期望已经十分清楚。 b.产品的设计与开发 ·讨论将设计特征发展到最终形式的质量策划过程诸要素; ·小组应考虑所有的设计要素,即使设计是顾客所有或双方共有; ·步骤中包括样件制造以验证产品或服务满足“服务的呼声”的任务; ·一个可行的设计应能满足生产量和工期要求,也要考虑质量、可靠性、投资成本、重量、单件成本和时间目标; ●DFMEA 1 技术和定义 2 产品 设计和开发 3 过程 设计和开发 4 产品和过程 确认 5 反馈、评定和纠正措施 ● 1 ●0 ● 3 ● 2 ● 5 ● 4 ●PFMEA ●MSA ●SPC ●PPAP ●APQP

质量体系五大工具和七大手法图文【最新版】

质量体系五大工具和七大手法图文质量管理五大工具 APQP APQP(Advanced Product Quality Planning)即产品质量先期策划,是一种结构化的方法,用来确定和制定确保某产品使顾客满意所需的步骤。 产品质量策划的目标是促进与所涉及的每一个人的联系,以确保所要求的步骤按时完成。有效的产品质量策划依赖于公司高层管理者对努力达到使顾客满意这一宗旨的承诺。 产品质量策划有如下的益处:

引导资源,使顾客满意; 促进对所需更改的早期识别; 避免晚期更改; 以最低的成本及时提供优质产品。 FMEA FMEA(Potential Failure Mode and Effects Analysis)即潜在的失效模式及后果分析,是在产品/过程/服务等的策划设计阶段,对构成产品的各子系统、零部件,对构成过程,服务的各个程序逐一进行分析,找出潜在的失效模式,分析其可能的后果,评估其风险,从而预先采取措施,减少失效模式的严重程序,降低其可能发生的概率,以有效地提高质量与可靠性,确保顾客满意的系统化活动。

FMEA种类: 按其应用领域常见FMEA有设计FMEA(DFMEA)和过程FMEA(PFMEA),其它还有系统FMEA,应用FMEA,采购FMEA,服务FMEA。 MSA MSA(Measurement System Analysis)即MSA测量系统分析,它使用数理统计和图表的方法对测量系统的误差进行分析,以评估测量系统对于被测量的参数来说是否合适,并确定测量系统误差的主要成份。

PPAP PPAP(Production part approval process) 即生产件批准程序,是对生产件的控制程序,也是对质量的一种管理方法。 PPAP生产件提交保证书:主要有生产件尺寸检验报告、外观检验报告、功能检验报告,、材料检验报告、外加一些零件控制方法和供应商控制方法; 制造型企业要求供应商在提交产品时做PPAP文件及首件,只有当PPAP文件全部合格后才能提交;当工程变更后还须提交报告。

质量管理五大工具、七大手法知识点总结

干货 | 质量管理五大工具、七大手法知识点总结,非常全面! 2017-09-21 17:01 来源:增城质监AP/经验 原标题:干货| 质量管理五大工具、七大手法知识点总结,非常全面! 质量管理五大工具、七大手法知识点总结,非常全面! 五大工具 APQP APQP(Advanced Product Quality Planning)即产品质量先期策划,是一种结构化的方法,用来确定和制定确保某产品使顾客满意所需的步骤。 产品质量策划的目标是促进与所涉及的每一个人的联系,以确保所要求的步骤按时完成。有效的产品质量策划依赖于公司高层管理者对努力达到使顾客满意这一宗旨的承诺。 产品质量策划有如下的益处: 引导资源,使顾客满意; 促进对所需更改的早期识别; 避免晚期更改; 以最低的成本及时提供优质产品。 FMEA FMEA(Potential Failure Mode and Effects Analysis)即潜在的失效模式及后果分析, 是在产品/过程/服务等的策划设计阶段,对构成产品的各子系统、零部件,对构成过程,服务的各个程序逐一进行分析,找出潜在的失效模式,分析其可能的后果,

评估其风险,从而预先采取措施,减少失效模式的严重程序,降低其可能发生的概率,以有效地提高质量与可靠性,确保顾客满意的系统化活动。 FMEA种类: 按其应用领域常见FMEA有设计FMEA(DFMEA)和过程FMEA(PFMEA),其它还有系统FMEA,应用FMEA,采购FMEA,服务FMEA。 MSA MSA(Measurement System Analysis)即MSA测量系统分析,它使用数理统计和图表的方法对测量系统的误差进行分析,以评估测量系统对于被测量的参数来说是否合适,并确定测量系统误差的主要成份。 PPAP PPAP(Production part approval process) 即生产件批准程序,是对生产件的控制程序,也是对质量的一种管理方法。

质量管理体系及五大工具知识

质量管理体系及 ISO/TS16949五大工具知识 二〇一一年三月

质量管理体系及TS16949五大工具知识 1、我公司为什么要实施ISO/TS16949:2009《质量管理体系汽车 生产件及相关服务件组织执行ISO9001:2008的具体要求》? 1)贯彻、实施ISO/TS16949规范是汽车整车厂对供方的普遍要求。 2)ISO/TS16949:2009内容上增加了一些适合汽车行业特点的要求,如进行潜在失效模式及后果分析、防错等。 3)ISO9000标准中可能存在的一些薄弱环节得到加强,如采用APQP手册,帮助企业建立策划新产品设计和开发的步骤。 4)使企业的质量管理体系更加完善。引入持续改进的概念、采用潜 在失效模式和后果分析(FMEA)等。 5)引入了一些新的质量理念,如实行过程控制,而不是产品控制。 2、八项质量管理原则的内容是什么? 以顾客为关注焦点;领导作用;全员参与;过程方法;管理的系统方法;持续改进;基于事实的决策方法;与供方互利的关系。 3、我公司的质量方针是什么? 质量方针:以顾客满意为宗旨,全员参与持续改进,打造“潍柴”驰名品牌。 4、ISO/TS16949:2009的结构。 包含:ISO9001:2008的内容;增加了适合汽车及相关服务件组织的79个条款;先期产品质量策划和控制计划、潜在失效模式及后果分析、测量系统分析、统计过程控制、生产件批准程序等五本手册。 5、什么是APQP?(先期产品质量策划和控制计划Advanced Product Quality Planning and Control Plan)为什么进行APQP?APQP分几个阶段?各阶段主要任务是什么? APQP是一种系统的方法,用于确定并建立保证产品满足顾客需求 的必需步骤。 因为采用了多方论证的方式,利用不同职能人员的集体智慧,通过

质量管理体系及五大工具知识

质量管理体系及五大工具知识

质量管理体系及ISO/TS16949五大工具知识 二〇一一年三月 质量管理体系及TS16949五大工具知识 1、我公司为什么要实施ISO/TS16949:《质量管理体系汽车生产件及相关服务件组织执行ISO9001:的具体要求》?

1)贯彻、实施ISO/TS16949规范是汽车整车厂对供方的普遍要求。 2)ISO/TS16949:内容上增加了一些适合汽车行业特点的要求, 如进行潜在失效模式及后果分析、防错等。 3)ISO9000标准中可能存在的一些薄弱环节得到加强,如采用APQP手册,帮助企业建立策划新产品设计和开发的步骤。 4)使企业的质量管理体系更加完善。引入持续改进的概念、采用 潜在失效模式和后果分析(FMEA)等。 5)引入了一些新的质量理念,如实行过程控制,而不是产品控制。 2、八项质量管理原则的内容是什么? 以顾客为关注焦点;领导作用;全员参与;过程方法;管理的系统方法;持续改进;基于事实的决策方法;与供方互利的关系。 3、我公司的质量方针是什么? 质量方针:以顾客满意为宗旨,全员参与持续改进,打造“潍柴”驰名品牌。 4、ISO/TS16949:的结构。 包含:ISO9001:的内容;增加了适合汽车及相关服务件组织的79个条款;先期产品质量策划和控制计划、潜在失效模式及后果分析、测量系统分析、统计过程控制、生产件批准程序等五本手册。 5、什么是APQP?(先期产品质量策划和控制计划Advanced

Product Quality Planning and Control Plan)为什么进行APQP?APQP 分几个阶段?各阶段主要任务是什么? APQP是一种系统的方法,用于确定并建立保证产品满足顾客需求的必须步骤。 因为采用了多方论证的方式,利用不同职能人员的集体智慧,经过早期策划,找出以后可能出现的质量问题,并采取预防措施,最大限度的减少变差和浪费,以最经济、最合理的资源配置生产,满足顾客要求。 分为五个阶段:计划和项目的确定,产品设计和开发,过程设计和开发,产品和过程的验证和确认,过程评价管理和持续改进。 第一阶段:计划和确定项目,主要任务:确定顾客的需要和期望,以计划和规定质量项目。提供比竞争者更好的产品和服务。产品质量策划过程的早期阶段就是要确保对顾客的需要和期望有一个明确的了解。 第二阶段:产品设计和开发,主要任务:策划过程中设计特征和特性发展到接近最终形式时的要素。即使是在设计由顾客进行或部分由顾客进行的情况下产品质量策划小组也应考虑策划过程中的所有设计要素,包括从样件制造到验证产品和有关服务满足顾客呼声目标的所有环节。保证对工程要求和其它有关技术信息的全面和严格的评审。在这一过程阶段,要进行初始可行性分析,以评定在制造过程中可能发生的潜在问题。

相关文档
相关文档 最新文档