CLCA 定义
CLCA表示Close Loop Corrective Action(闭环纠正措施) ,这是DELL公司使用的一种处理问题的方法,也是DELL专用的名词,其他公司很少用,CLCA是对已经发生的质量问题,进行有效的改善追踪,直到问题不在发生为止,表现的形式就是一份改善报告的格式。它确保所有纠正和预防措施都及时方式得到处理,进行所有跟踪活动,采取的措施是有效的,并且是有计划地进行跟踪,以保证纠正措施的持续有效性。
当一个质量问题出现时,由质量部门发出一份问题追踪表,由责任单位提出解决措施,当纠正措施执行后,追踪其有效性,措施有效就可关闭此问题点,若无效相关责任单位须再次提出对策,直到问题得到根本的解决。有时后我们在执行PDCA (Plan-Do-Check-Act)后,容易形成一个开环(Open Loop)的持续改善过程;而CLCA则更强调纠正措施要形成一个封闭环圈,至少对短期改进不了的问题,实施对策后还要回到最好的质量状态。
CLCA实施步骤
完整的CLCA要包括以下 5 个阶段性步骤:
(1) 问题发生;
(2) 分析问题发生的原因,确立根本原因;
(3) 拟订消除根本原因的改善计划,并验证其可行性;
(4) 实施改善措施,并多次追踪措施的效果;
(5) 验证改善效果,确认问题发生的根源已经解决。
常犯的一些误解
CLCA = CA(纠正措施)
对CLCA而言,仅实施CAR(corrective action request)就足够了
对问题而言,只要能反应迅速就行了
对CLCA应由QA部门负全责
在规定时间内,只要问题没有再发生,CA就是有效的
基本知识
CLCA 表示Close Loop Corrective Action(纠正行动的一个闭环)
真正的根本原因
采取纠正行动
采取预防措施
监视采取行动后的效果
应用SMART原则来满足Dell/AOC的 CLCA 要求
重点 – 找出问题的真正的根本原因
诀窍 I – 5W1H
何事
何时
何处
谁
为什么
如何
诀窍 II – 问 5 个问题
基于不良的信息,问第一个问题, 得到答案后针对不良和第一个问题提第二个问题, … . 如此重复5次.
CLCA的基本报告 — 8D 报告
8D报告样本
SUPPLIER: | ||||
---|---|---|---|---|
Part #: | Description: | |||
STEP 1 | INTERNAL / EXTERNAL TEAM | DATE: | ||
Team Leader: | Dell Lead: | Team Members: | ||
STEP 2 | DESCRIBE THE ISSUE | DATE: | ||
STEP 3 | CONTAINMENT PLAN (What, Who, When, Where) | DATE: | ||
Is a purge necessary_____ Does this affect other product families/types_____________________ | ||||
STEP 4 | ROOT CAUSE ANALYSIS (Use problem solving tools) | DATE: | ||
STEP 5 | CORRECTIVE ACTION PLAN | DATE | ||
Responsibility:_______________________ Date to be implemented:_____________ | ||||
STEP 6 | PREVENTIVE ACTION | DATE: | ||
Responsibility:_______________________ Date to be implemented:_____________ | ||||
STEP 7 | VERIFICATION (Follow-up to Corrective/Preventive actions) | DATE: | ||
CLCA #: | Status: | Target Closure Date: | Customer Ref #: |
8 DISCIPLINE
D1. Use the Team Approach(组成成员)
选择并记录内部/外部成员
D2. Problem Description(问题描述)
描述引起问题的状态变化
用量化的术语来表示状态
D3. Short-term action(执行临时措施)
描述现在由谁,什么, 何时及怎样来发现及控制不良, 并且怎样防止其流到顾客
D4. Define Root Cause(定义根本原因)
描述为什么变化会发生, 或识别系统中允许问题存在并不能发现的”漏洞”
根本原因分类,如:
– 材料, 机器, 方法, 人员, 环境
原因描述要尽量具体详细
D5. Permanent Corrective Action(执行永久改善对策)
描述将来由谁,什么, 何时及怎样实施在材料,人员,方法等方面的变化来完全消除问题的根本原因
D6. Action Effectiveness Verification(效果确认)
用量化的术语描述确认的结果
持续实施临时措施直到永久改善对策已被证明有效
D7. Prevent Recurrence(防止再发生)
描述内部/外部文化或系统的变化,此变化必须可以防止问题的发生
标准化
D8. Closure
表示到目前已完成一闭环
SUPPLIER(供应商): | ||
Part #(料号): | Description(现象描述): | |
STEP 1(第一步) | INTERNAL / EXTERNAL TEAM(内部/外部团队) | DATE(时间): |
Team Leader(团队领导): | Dell Lead(DELL/AOC领导): | Team Members(团队成员): |
CLCA – 第一步
SUPPLIER(供应商): | ||
---|---|---|
Part #(料号): | Description(现象描述): | |
STEP 1(第一步) | INTERNAL / EXTERNAL TEAM(内部/外部团队) | DATE(时间): |
Team Leader(团队领导): | Dell Lead(DELL/AOC领导): | Team Members(团队成员): |
CLCA #(CLCA编号): | Status(现状): | Target Closure Date(目标完成日期): | Customer Ref #(客户参考): |
写下公司名称
辨别失效产品料号
描述失效信息,如:失效率,失效地点,批号等…
组成团队
第一步完成日期
给出一个CLCA #编号和/或客户参考号以便追踪
目标完成日期应给出
STEP 2 | DESCRIBE THE ISSUE | DATE: | ||
---|---|---|---|---|
描述失效现象,报告地点,报告失效率,相关的批号或辨别号,受影响的品质,受影响的客户等详细细节
第二步完成日期
STEP 3 | CONTAINMENT PLAN (What, Who, When, Where) | DATE: | ||
---|---|---|---|---|
Is a purge necessary_____ Does this affect other product families/types_____________________ |
估计对品质/客户的影响有多大
这种失效会影响其它产品类/型号吗
有多少可疑产品已被生产 这些产品在哪
在港口/客户处有多少可疑产品 如何处理
有多少可疑产品在路上/供应商仓库 处理
是否有良品可以替代 是否需要清除
第三步的完成日期
STEP 4 | ROOT CAUSE ANALYSIS (Use problem solving tools) | DATE: | ||
---|---|---|---|---|
描述问题的根本原因
如果失效是由于元器件的失效,该元件失效的根本原因也需要描述
使用问题解决工具,如鱼骨图,制程图等来找出根本原因
第四步完成日期
STEP 5 | CORRECTIVE ACTION PLAN | DATE | ||
---|---|---|---|---|
Responsibility:_______________________ Date to be implemented:_____________ |
提供短期对策,包括:
在制程/OQA作特别检验
在制程/OQA作特别测试
其他短期对策以过滤或消除问题
也许需要DELL对相关的ECR进行批准
对策的有效性需要有证据进行验证
第五步完成日期
STEP 6 | PREVENTIVE ACTION | DATE: | ||
---|---|---|---|---|
Responsibility:_______________________ Date to be implemented:_____________ |
提供长期的预防对策,包括:
针对根本原因的预防对策
进行总的检查以消除任何潜在的相似问题
更改有关部门的指导书/程序
对相关人员提供必要的培训
对相关的ECR需要DELL的批准
第六步完成日期
STEP 7 | VERIFICATION (Follow-up to Corrective/Preventive actions) | DATE: | ||
---|---|---|---|---|
提供证据表明对策的有效性,包括:
短期对策的有效性
effectiveness of long term preventive actions
若对策由分供应商进行,需要有分供应商/供应商制程/OQA数据进行验证
需要对整个制程进行追踪验证,包括:
文件/培训的完成
对策导入日期/良品的批号及performance
第七步完成日期
CLCA 实例 — Step 1 ~ 7
分为4 ~ 5个团队
每一个团队应包括有不同部门人员
每一个团队配备纸/笔(白板等最好)
每一个团队有队名和团队领导
每一个团队应解决一个同样的问题实例
一些失效样品可以提供作为参考
每一个团队从第三步开始至第七步结束
每一个团队用30分钟完成每一步
每一步完成时,应选一个团队作展示
应评估该团队的优点/缺点
应解释实例中的每一个内容
CLCA 实例 — Step 1 ~ 2
Model | E551c | CLCA # | DAO IFIR CLCA#012 | |
STEP 1 | INTERNAL / EXTERNAL TEAM | DATE: Jan-28-02 | ||
Team Leader: | Leader: L M.Yan | Team Members: | ||
STEP 2 | DESCRIBE THE ISSUE | DATE: Jan-28-02 | ||
2.1 S/N: 07G076-64180-1AT-00F4 2.2 Fail area(失效模式): DAO 2.3 Defect Symptom(失效现象): no video(无画), led on(灯亮) 2.4 Invoice (sold) date(出货日期): 2001-12-7 2.5 Complaint issue date(失效日期): 2001-12-30 2.6 IFIR/FIR IFIR |
||||
STEP 3 | DESCRIBE THE PROBLEM | DATE: Jan-28-02 | ||
FAE(失效分析工程师)分析结果: No video ,LED on; L906 1.0mH; L906 open , No B+ output. Inductor wire broken near foot. |
CLCA 实例 — Step 3
STEP 3 | CONTAINMENT PLAN (What, Who, When, Where) | DATE: | ||
---|---|---|---|---|
Is a purge necessary_____ Does this affect other product families/types_____________________ |
利用失效率/报告数量判断如何采取相应行动
对不同的问题采取不同的部署
针对元器件失效,第三步也许不需要
对部件的缺少,也许需要对港口/仓库进行检查
CLCA 实例 — Step 4
STEP 4 | ROOT CAUSE ANALYSIS (Use problem solving tools) | DATE: | ||
---|---|---|---|---|
也许需要结合多种分析工具,如制程图/鱼骨图
可以利用鱼骨图作第一层的原因分析
进行到下一层时,也可以利用它作原因分析
在找到根本原因之前消除其它所有可能
有时仅有潜在的提高可以确认
CLCA 实例 — Step 5
STEP 5 | CORRECTIVE ACTION PLAN | DATE | ||
---|---|---|---|---|
Responsibility:_______________________ Date to be implemented:_____________ |
CLCA 实例 — Step 6
STEP 6 | PREVENTIVE ACTION | DATE: | ||
---|---|---|---|---|
Responsibility:_______________________ Date to be implemented:_____________ |
CLCA 实例 — Step 7
STEP 7 | VERIFICATION (Follow-up to Corrective/Preventive actions) | DATE: | ||
---|---|---|---|---|
CLCA #: | Status: | Target Closure Date: | Customer Ref #: |
D1. Use the Team Approach(组成成员)
选择并记录内部/外部成员
D2. Problem Description(问题描述)
描述引起问题的状态变化* 用量化的术语来表示状态
D3. Short-term action(执行临时措施)
描述现在由谁,什么, 何时及怎样来发现及控制不良, 并且怎样防止其流到顾客
D4. Define Root Cause(定义根本原因)
描述为什么变化会发生, 或识别系统中允许问题存在并不能发现的”漏洞”
根本原因分类,如:- 材料, 机器, 方法, 人员, 环境
原因描述要尽量具体详细
D5. Permanent Corrective Action(执行永久改善对策)
描述将来由谁,什么, 何时及怎样实施在材料,人员,方法等方面的变化来完全消除问题的根本原因
D6. Action Effectiveness Verification(效果确认)
用量化的术语描述确认的结果
持续实施临时措施直到永久改善对策已被证明有效
D7. Prevent Recurrence(防止再发生)
描述内部/外部文化或系统的变化,此变化必须可以防止问题的发生
标准化
D8. Closure
表示到目前已完成一闭环
CLCA的时效性/成本/有效性
运用头脑风暴法找出根本原因
日常数据的收集/保持对CLCA非常有用
元器件/WIP/制成品的可追溯性对确认原因非常有用
由分供应商提供的日常失效元器件的FA/CA对参考非常重要
各部门之间的包括分供应商的团队精神非常重要
提高日常检验并保留记录对过滤可以原因及预防问题发生非常有用
QSA–不符合的控制
Review并处理不符合品
Material Review Board (MRB)(核检表)
设计工程,制造工程,采购,和品质工程
Disposition(处理)
返工,暂用,维修,废弃,选用
Note: “暂用” 需DELL SQE最后批准
纠正行动程序
使用8D原则来追踪并完成CA
调查根本原因,确认纠正行动
消除不符合品的潜在原因
确保纠正行动有效
实施并记录制程的改变
8-D: 定义失效,技术调查/分析,根本原因,短期对策,纠正行动计划,预防措施防止再犯,验证行动的有效性
纠正行动应在30天内完成,除非有DELL SQE的指示
Some Common Misunderstanding:
CLCA = CA(纠正措施)
对CLCA而言,仅实施CAR(corrective action request)就足够了
对问题而言,只要能反应迅速就行了
对CLCA应由QA部门负全责
在规定时间内,只要问题没有再发生,CA就是有效的
WHY
You should have known all the answers now.
稽核中发现的典型问题
1.对RMA针对文件中的主要问题,没有很好的实施 CLCA以解决问题.
纠正行动:所有市场上的主要不良应实施FA/CA,应定义程序使专注于市场反馈的数据,以及对相关部门及分供应商回馈分析结果及纠正措施.
2.很多CAR并没有有效实施以防止再发生.
纠正行动: 运用CLCA原则,定义寻找根本原因以及实施批准/验证CAR的基本程序
3. 不合格材料的控制程序没有很好定义.
纠正行动: 重新定义CLCA程序,使其包含MRB,市场失效,ORT,安全测试等…中的失效
4.在MRB程序中没有很好定义材料的处理标准/指引(UAI,RTV,废弃,返工,挑选).
纠正行动: 定义MRB处理的标准及责任部门,同时需定义受影响的品质/功能/安全的评估标准以及相应措施后可允许的失效率也应被定义.
5.MRB中针对不同处理的材料核检人员及其职责没有很好定义(UAI, RTV, Scrap, Rework, Sorting). UAI仅由当地QA和PE工程师批准而没有回复原始设计人员进行Review.
纠正行动: 针对不同的处理定义人员职责,定义UAI的批准程序指明在何种情况下需要原始设计人员的批准.
6.一些有关元件失效的CLCA报告由不能稽核的部门签署.
纠正行动: 建立委托元件的反馈和追踪程序.
7.当发现分供应商的改善计划无效时没有合适的行动.
纠正行动:当发现分供应商的改善计划无效时,应拒绝其CAR报告,并反馈IQC和采购部门做进一步的行动.
8.对塑料件的相同的分供应商,因制程控制缺陷和原材料缺陷造成的问题重复发生,在日常稽核时却没有对这些问题进行重点检查.
纠正行动: 改善VCAR发布者与现场稽核工程师的沟通.
9.对有关分供应商的失效,问题应反馈给分供应商做提高,但仅限于一些关键的部件,如CRT.
纠正行动: 针对主要失效元件,向分供应商发布VCAR,建立元件performance 追踪系统以提供预警.
10. 用CAR代替8D报告,失效信息(批号,样本大小,失效数量/失效率)没有存档.
纠正行动: 使用类似8D的方法,对可以得到的失效信息进行存档.
DELL:CLCA – Training