Six Sigma journey of lenovo

降低系统原因导致的制程降低系统原因导致的制程批量问题发生率批量问题发生率

20042004 年年 22 月月

Six Sigma 五步法

1.0（ D）定义范围了解过程

2.0（M）测量评估确定目标

3.0（ A）分析过程确定重点

4.0（ I）制定措施实施改进

5.0（ C）效果控制持续改善

定义问题范围

明确客户需求

确认业务流程

成立高效团队

• 项目范围确定：解决什么问题

• 团队建设（成员、章程）• 项目推进计划

• 业务主流程图 SIPOC• 细化的关键业务流程图

• 客户关心的关键质量 CTQ

可使用的工具• 头脑风暴、因果图• 柏拉图等• 客户调查、抽样统计• QFD 、矩阵表、雷达图等• KPI

• 流程图• 项目管理

每一步工作每一步工作输出

定义问题范围定义问题范围

（ D ）定义范围、了解过程

项目衡量指标 01 实际 02 实际 03 目标

项目按时完成率 - - *% *%

制程批量问题发生率 - - 5.85% 3%售后批量问题发生次数严重程度 >=B 的次

数 - * *

质量管理能力一次开箱合格率 *% *% *%

3个月返修率 *% *% *%

6个月返修率 *% *% *%

公司 QMM评估级别 - * *

资料来源： 03CDB 规划

1.1. 内容：阐述从部门或处规划的哪部分导出项目；内容：阐述从部门或处规划的哪部分导出项目；



制程批量问题发生率趋势图

数据来源：质量管理部规划监控处（南北方厂）

5.38%

6.37%

5.00%

6.11%

7.22%

0.0%1.0%2.0%3.0%4.0%5.0%6.0%7.0%8.0%9.0%

10.0%

2003.3 2003.4 2003.5 2003.6 2003.7

现状

目标

22 、、内容：内容：量化阐述问题的存在（不改进的严重程度）量化阐述问题的存在（不改进的严重程度）



制程批量问题原因柏拉图

系统来料生产说明书0

25

50

75

100

N= 205

0

25

50

75

100

其他数据来源： ****数据收集区间： ***

41.5%

21.5%18% 14.1%

4.9%

项目范围

系统问题

定义：由于研发设计或评测不充分，引起机器随机部件之间（包括：硬件、 BIOS、 Driver 、随机系统软件、应用程序，不包括说明书和机械配合）的配合不当。

33 、、内容：内容：用一个或多个连续的用一个或多个连续的 PARETOPARETO 将问题进行分解，并明确本项目的将问题进行分解，并明确本项目的范围范围

明确客户及客户需求明确客户及客户需求


客户名称

对本项目的需求 / 期望 CTQ

事业部降低系统原因造成的停线次数；

系统问题导致的制程（批次）停线率

不希望用系统原因问题占总制程批量问题的比率来衡量项目

。

同上

制造厂降低系统原因造成的返线次数系统问题导致的制程（批次）返线率

11 、、内容：内容：针对该项目范围，明确客户及客户需求针对该项目范围，明确客户及客户需求 ------ 即客户即客户希望本项目能达到什么效果；希望本项目能达到什么效果；

11 、内容：阐述、内容：阐述 CTQCTQ 与流程的关系，并确定项目名称与流程的关系，并确定项目名称确认业务流程确认业务流程


流程

CTQ CTQ1 ：系统问题导致的制程（批次）停线率

CTQ2 ：系统问题导致的制程（批次）返

线率

合计

权重 6 4

BIOS 导入 /变更流程

9 9 90

部件导入技术评测流程

8 8 80

批量评测流程

2 2 20

项目名称：降低系统原因导致的制程批量问题发生率

11 、、内容：内容：阐述初步确定的项目团队阐述初步确定的项目团队及团队章程及团队章程

成立高效团队成立高效团队


章程见附件：章程见附件： ********

项目 Sponsor ：卢旭LEADER ：王英仙指导老师：傅革新项目核心成员：

龚仲涛、欧余海、何卫峰、宋万峰、彭桃芳、贾子江、李仕润、余锦荣

D、M 阶段 6 月 15 日完成

A 阶段 7 月 30 日完成

I 阶段 9 月 30 日完成

C 阶段 10 月 27 日完成

22 、、内容：内容：项目项目 DMAICDMAIC 各阶段初步计各阶段初步计划划

Six Sigma 五步法

2.0（M）测量性能评估现状









明确测量对象

明确测量标准

现状水平分析

确定项目目标

• 确定衡量项目指标、参数

• 项目计划书 ( 目标、收益预算 )

• 目前的绩效水平

• 测量系统、 Defect 的定义• 测量系统分析 / 改进报告

每一步工作可使用的工具

• 检查表• 抽样统计 • minitab 统计软件• 测量基础• 测量系统分析 --MSA

• 项目管理

每一步工作输出

1 、内容：内容：项目的衡量或监控指标 /参数及其定义、数据来源；明确测量对象明确测量对象

（M ）测量评估、确定目标

项目衡量指标：

系统问题导致的制程批量问题发生率：由于系统问题造成的返、停线批数

总生产线批数％

何为系统问题造成的返、停线批：由于研发设计或评测不充分，引起机器随机部件之间（包括：硬件、 BIOS、 Driver 、随机系统软件、应用程序，但不包括说明书和机械配合）的配合不当，使 >=3% 的系统无法正常运行，造成生产线返线或停线， 100 台（含）以上的生产批。

1 、内容：内容：阐述与衡量或参考指标 /参数相对应的缺陷如何定义；明确测量标准明确测量标准

制程中可能出现的问题现象判断人A 判断人B 判断人C Y/NSAMPLE 1 2 3 1 2 3 1 2 3 Agree?

1 AA Y Y Y Y Y Y Y Y Y Y Y2 AB Y Y Y Y Y Y Y Y Y Y Y3 AC Y Y Y Y Y Y Y Y Y Y Y4 AD Y Y Y Y Y Y Y Y Y Y Y5 AE Y Y Y Y Y Y Y Y Y Y Y6 AF Y Y Y Y Y Y Y Y Y Y Y7 AG N N N N N N N N N N Y8 AH N N N N N N N N N N Y9 AI N N N N N N N N N N Y10 AJ Y Y Y Y Y Y Y Y Y Y Y11 AK N N N N N N N N N N Y12 AL Y Y Y Y Y Y Y Y Y Y Y13 AL Y Y Y Y Y Y Y Y Y Y Y14 AM Y Y Y Y Y Y Y Y Y Y Y15 AN N N N N N N N N N N Y16 AO N N N N N N N N N N Y17 AP Y Y Y Y Y Y Y Y Y Y Y18 AQ N N N N N N N N N N Y19 AR Y Y Y Y Y Y Y Y Y Y Y20 AS N N N N N N N N N N Y

Repeatability 100%Repeatability 100%Repeatability 100%

% EffectivenessReproduciblity 100%

是否应判断为系统问题造成的批量问题（标准判定）

2 、内容：内容：对相关测量系统进行分析；（如果不合格则进行改善并重新评价直至合格）

明确测量标准明确测量标准


•按照系统问题造成的制程批量问题的定义，挑选北京厂 / 惠阳厂负责的机型工程师对发生的批次问题进行判定。

•结论：测量系统符合要求。报告见附件。

系统原因导致制程批量问题趋势图 ( 比率）

1 、内容：内容：指标现状呈现（用趋势图，建议使用一段时间的数据进行说明，如： 6个月）

现状水平分析现状水平分析


数据来源：批量问题发生率月报

1.36%1.00%0.57%

0.88%

6.51%

0.00%1.00%2.00%3.00%4.00%5.00%6.00%7.00%

03.3 03.4 03.5 03.6 03.7

1.14%去除异常点的影响

不去除异常点的影响

2.12%sigma 水平 3.78

1 、内容：内容：用柱状图呈现依据现状水平确定项目目标（明确完成时间）确定项目目标确定项目目标


由系统问题导致的制程批量问题发生率均值从 03年 4-7 月的 1.14% （含异常点则 2.12% ）下降到 0.57% （ 03 年 9-12

月）。

1.14%

0.57%

0.00%

0.20%

0.40%

0.60%

0.80%

1.00%

1.20%

1.40%

现状目标baseline

0.43%

2 、内容：内容：项目收益预计（项目财务收益预计报告，见附件）•项目投入： *** 项目产出： ***

•项目净收益： **** 其他： ****

3 、内容：内容：对业务指标的贡献

确定项目目标确定项目目标


系统问题导致的制程批量问题发生率均值：

2.12% 下降到 0.57%

系统问题导致的制程批量问题占总批量问题：

41.5%

对制程批量问题发生率的贡献：

降低 1.55%

对财年目标 --- 制程批量问题发生率降低的贡献：

54.3%

DMDMAAICIC

Six Sigma 五步法






细化流程

分析影响因素

找关键因子

• 流程分析结果

•关键因素 X 确定

• 影响项目 Y值的输入因素 X


• 头脑风暴、因果图、原因筛选• 相关性分析• 对比实验• 多变异分析 --ANOVA

• 失效模式和后果分析 --FMEA

• 柏拉图、 MINITAB 统计软件


系统问题 Pareto Analysis

0BIOS 应用硬件其他 driver

0

25

50

75

100

N=52

25

50

75

100

数据来源：批量问题发生率月报数据区间： 2003.4-2003.7

38.46% 38.46%

15.38%

5.77%1.32%

问题进一步细分问题进一步细分

三部分占总系统问题 92.3%

（ A ）分析过程、确定重点

1、 BIOS 问题

2 、硬件配合问题

3 、应用配合


从三个方向进行深入分析：

细化流程细化流程

供应商

变更 BIOS 新发BIOS

系统开发工程师（ DE)

变更 BIOS 验证

新发 BIOS 验证

BIOS 下发

产线生产

问题

交付用户Yes

No

变更B

IOS

工作流

新发B

IOS

工作流


测量测量人人

环境环境材料材料

BIOS问题

技评环境和产线差异

特配 BIOS 修改质量不可靠

新引入 BIOS 更改频繁版本没有控制 vvv

应用 BIOS 修改质量不可靠

标配 BIOS 修改质量不可靠

现象在特定环境下才能复现

技评、生产评测方法差异

概率性问题

BIOS 规格不完善

BIOS刷新工具变更

工程师认知能力有限

供应商 BIOS 质量低vvv

测试员工作疏忽

BIOS下发信息错误

EN没有及时下发

三厂执行不一致vvv

变更评测不充分 vvv

主板开发工程师重视度不够

工程师向供应商反映问题不准确

BIOS工程师

主板开发工程师

BIOS 变更频繁 vvv

（ A ）分析过程、确定重点分析影响因素分析影响因素

新引入主板B

IOS

流程图

因素一：新引入 BIOS （新主板）更改频繁，版本无控制

通过

Yes

BUG

问题验证

No

Yes 问题验证

兼容性及个性化测试

1功能测试

2功能测试

N功能测试

BIOS功能测试

BUG解决

PCB确认测试

BUG解决No

BIOS功能简单验证

主板样品 BIOS首版

BIOS 2版本

BIOS 3版本

BIOS M版本

BIOS功能测试

BIOS修改

BIOS功能问题验证

BIOS M P版本＋

样品评测通过

BUG

问题验证

BUG解决

No

Yes

BIOS全面验证BIOS技评结束

批量评测

BIOS修改

BUG 批量验证

BUG解决

No

批量评测通过Yes

结束

BIOS下发

BI OS修改

影响了主板功能 /性能测试的质量

正式下发的 BIOS没经过严格技评


找出关键因子找出关键因子

BIOS 、硬件配合问题和 BIOS切换次数相关分析

查检验相关系数的临界值表：

N-2=3 置信区间 95% 临界值 :0.878

0.9325>0.878

故判定 BIOS 、硬件配合问题比率和BIOS切换次数相关。

因素二： BIOS 变更频繁

Correlations

VariableColumn 1Column 2

Column 1 1.0000 0.9325

Column 2 0.9325 1.0000

数据出处：批量问题发生率月报数据区间： 2003.4-2003.8

结论：频繁的 BIOS切换将导致高的 BIOS和硬件配合问题

BIOS及硬件问题比率 By BIOS切换次数

0.004

0.005

0.006

0.007

0.008

0.009

10 15 20 25 30 35BIOS切换次数

Linear Fit

Linear Fit

BIOS 、硬件问题比率 = 0.00037 + 0.00025 BIOS切换次数

BIO

S

及硬件问题比率



简单技评可以发现

针对性验证可发现

概率问题

技术认知

下发问题

0

25

50

75

100

N= 71

0

25

50

75

100

60.56%

21.13%11.27%

5.63%1.41%

BIOS 变更问题柏拉图

技评可以屏蔽的问题高达 81.69%

因素三： BIOS 变更评测不充分

数据出处：批量问题发生率月报数据区间： 2003.4-2003.8



a 、发生问题的BIOS 100％都是没有经过评测

b、 1-8 月下发的BIOS 有 79.63%没有经过评测

C、 1-8 月经过平台评测的 BIOS 出现问题为 0

为什么不经过标准化、全面的测试

a 、供应商修改时间长，测试时间少，通用测试流程无法进行全面 /全部测试；

b 、工程师时常直接认可供应商修改 BIOS；

c 、主板 BIOS 没有统一管控，要针对性验证，工程师和测试员沟通不顺畅；

为什么变更评测不充

分？

因素三： BIOS 变更评测不充分



下一层原因： a 、各供应商对 BIOS 的控制和管理、供应商工程师的素质参差不齐

b 、事业部研发对供应商的控制力度有限，并且工程师和供应商都更加关注项目进度

c 、供应商为减少投入而不验证就提供 BIOS,直接使用问题较多

对 9 月 1 日－ 9 月 15日 BIOS进行跟踪

供应商提供的 BIOS60% 有问题

因素四：供应商 BIOS 质量不高



45. 71%

14. 29%

40. 00% BI OS引发新问题的比率

针对的问题没完全解决BI OS的比率

BI OS修改好的比率

BIOS传递表中内容简单，没有直接和机型对应，导致生产厂使用 BIOS 时效率低，易产生错误；

因素五：三厂执行不一致



小结小结

BIOS 变更评测不充分

BIOS 变更频繁

供应商

变更 BIOS 新发BIOS

系统开发工程师（ DE)

变更 BIOS 验证

新发 BIOS 验证

BIOS 下发

产线生产

问题

供应商BIOS 质量不高

新引入 BIOS 版本无控制

三厂执行不一致

交付用户Yes

No

变更B

IOS

工作流

新发B

IOS

工作流

12

3

5

4


1、 BIOS 问题


3 、应用配合


Six Sigma 五步法






找出改进方案 • 针对每一个关键因素 X找出尽可能多的改进方案

评估方案 • 选择的方案

方案实施

效果验证

• 行动计划表并实施

• 改善效果分析报告

每一步工作输出每一步工作可使用的工具• 头脑风暴、方案评估• 实验设计 --DOE

• 回归分析、对比分析• 责任矩阵、甘特图• 项目管理• 客户满意度调查• 统计基础、 minitab 软件

DMADMAIICC

1、 BIOS 问题


3 、应用配合

（ I ）制定措施、实施改进

BIOS及硬件配合问题————————— BIOS切换次数

通过来衡量系统开发处下发 BIOS 的水平

因子 2 ： BIOS 变更频繁

因子 1 ：新引入 BIOS 更改频繁，版本没有控制

改进措施：在主板评测过程中按照主板的测试节奏单独按 BIOS 划线，将版本控制在 4 版左右，便于对主板及 BIOS 问题进行合理有效评估；

并落入处考核中；

计划完成时间： 2003.9.15 负责人：龚仲涛

计划完成时间： 2003.9.15 负责人：欧余海


改进措施：

目前分别执行的几种方式

Must Better测试周期短

可应付高频度评测

投入少

测试全面规范

验证问题充分

安排方便

沟通顺畅

测试效率

合计

批量评测 N N

工程师自测 Y Y 4 2 5 5 5 3 24

测试平台测试 Y Y 4.5 5 4 4 4 4.5 26

结论：测试平台测试的方式最优。但在某些方面可通过工程师自测灵活操作：

1 ）问题验证：建议平台全面测试，问题验证由工程师指导并确认；

2 ）安排方便性：对于简单的 BIOS 修改，可以采取工程师自测的《免评原则》，对时间紧张的测试开通《 BIOS紧急验证流程》；

3 ）沟通顺畅：通过 BIOS realease 和 BIOS Buglist 使测试员也能很容易地了解该BIOS 发展全貌，不遗漏可能发生的问题。

因子 3 ： BIOS 变更评测不充分：测试时间问题、针对性测试问题…


选择、评估方案


因子 3 ： BIOS 变更评测不充分：测试时间问题、针对性测试问题… 变更评测改进 FMEA优化 / 完善改进方案，并实施


因子 3 ： BIOS 变更评测不充分：测试时间问题、针对性测试问题…

实施改进BIOS 下发免测试流程标准

适用范围：此标准仅适合商用台式相关 BIOS下发岗，在紧急情况下自已通过标准 BIOS 修改工具进行修改的 BIOS文件。

原则：

1．但凡经过供应商修改、升级并传递给联想的BIOS ，无论 BIOS 修改了哪些地方，都需要进行测试验证。

2．由 BIOS下发岗在按下行要求自行修改的 BIOS ，虽可不经过现有测试流程，但必须保证使用修改后的 BIOS自行验证，以保证修改的可靠与稳定。

自修改工具：MODBIN.EXE（ VER6）、 CBROM.EXE

免测试流程标准：

1 、对于新引入的主板，经过主板样品评测的 BIOS只能用于质评下发，后通过批量评测的 BIOS 可免相关测试流程下发；

2、 BIOS 开机画面更改（含特配开机画面）；

3 、使用 MODBIN6工具，对 ACPI默认值进行的修改，如 S3 修改为 S1 ，反之亦然；

紧急B

ios

验证规范

充实 BIOS传递表的内容


因子 4 ：三厂执行不一致研发维护机型 BIOS 对应表

短期：通过加强自测验证来弥补 BIOS 修改错误带来的问题，增加一个测试岗位。

长期：加强供应商管控，充分开展联合测试，辅以自测验证。

Must Better

总分改进方案在现有体制下

可行

不影响研发效

率

不增加研发投入

见效快

有长期效应

2个月内完

成

加强研发对供应商的管理力度

N Y

加强供应商联合测试

Y Y 4 2 4 2 12

加强自测验证 Y Y 3 4.5 2 5 14.5


因子 5 ：供应商 BIOS 质量不高选择、评估方案

实施：

1、 BIOS 问题


3 、应用配合


0. 56%

0. 37%

0. 00%

0. 10%

0. 20%

0. 30%

0. 40%

0. 50%

0. 60%

0. 70%

BIOS 问题改善效果

改善前03.4-03.7

改善后03.9-04.1


效果验证

系统问题改善效果

1.14%

0.57%0.42%

0.00%

0.20%

0.40%

0.60%

0.80%

1.00%

1.20%

改善前03.4-03.7

目标改善后 03.9-04.1

超额完成目标

效果验证


Six Sigma 五步法






控制跟踪

固化改进 • 文件、制度、体系的形成

• 改善效果监控• 关键因素监控

持续改进 •再次寻找改善机会，持续改善


• 抽样统计• SPC 、对比实验• 控制图、趋势图 • 客户满意度调查• minitab 统计软件


DMAIDMAICC

系统问题改善后趋势

注 1 ：在找到解决方案后，对 9 月份前下发的在用但没进行过评测的 BIOS 分批进行了补测，在 11 月份补测中发现了几个对用户严重影响的问题，于是对相关的已入库 12 批机器进行了返线，若去除该影响，当月系统问题水平为 0.38%<0.57%, 在控制范围内；

注 2 ： 9 月份陆续开始实施部分措施，且设计端控制效果对产线有一定滞后，故 9 月份状况略差

（ C ）效果控制、持续改善

0. 88%0. 57%

1. 00%0. 51% 0. 60%

0. 06%0. 53%

0. 84%

0. 10%

6. 51%

1. 36%

0. 00%

1. 00%

2. 00%

3. 00%

4. 00%

5. 00%

6. 00%

7. 00%

03. 3 03. 4 03. 5 03. 6 03. 7 03. 8 03. 9 03. 10 03. 11 03. 12 03. 1

注 1注 2

实施前实施后

控制跟踪

sigma 水平 3.78sigma 水平 4.13

　

由系统问题引起的返停

线批数生产批数返停线

率

改善前 52 4579 P1

改善后 50 11792 P2

对由系统问题引起的返停线发生的概率进行统计验证：

H0： P1＝ P2 H1： P1≠P2 （ 95 ％的置信度）

验证的结果如上， P<0.05 ，所以我们放弃归零假设采用对立假设，认为：

P1和 P2在统计上存在显著性的差异，即改善是有效的！

系统问题改善对比实验


控制跟踪

< >测试工程师 < >测试助理 < >下发审核< >系统开发工程师

BIOS变更

测试启动原则

紧急

BIOS紧急验证

针对销量最大的配置进行全面

BIOS测试

是否有测试报告

是否遗留问题

遗留问题是否体现

Yes

启动全面验证

No

No

BIOS下发

紧急测试

形成测试记录

Yes

Yes

发放

不测原则

Yes

No

NoYesNo

Yes

全面测试

测试记录

会签

通过

通过

YesBug解决

No

Yes

No

BIOS评测原则 Rel easnotes Bugl i st

BIOS评测报告

变更B

IOS

评测流程

图

固化改进


主板开发流程图

—— 3 -4商用台式主板引入流程开发阶段（个月个月）

验证评审阶段

验证评审阶段

PCB确认阶段

(-5

WD)

技评测试阶段

-10W

D

相关输入输出文档PE测试方案工程师测试方案工程师主板开发工程师

常规电性能、通用测试BIOS软件、全面测试

PCB遗留问题跟踪和验证

PCB确认

PCB确认报告EMI、环境、信号

PCB等专项确认测试

兼容性测试

功能／性能／稳定性测试

系统评测报告

批量设计验证

批量评测报告

样品评测报告

系统批量评测报告

系统批量验证

系统设计验证

批量问题验证解决BIOS等重点模块验证批量问题分析与验证

小批量采购申请

开发验证评审批量评测通过

系统批量评测通过系统评测通过样品评测通过

Owner提交DE解决

VE提交DE解决

DE提交DE解决VE验证 VE提交

DE解决

BIOS下发

BIOS第二版全面功能测试

Bug解决

Bug解决

BIOS第四版BIOS各种应用

样品、系统问题验证及收关测试

BIOS第三版BIOS各种应用

样品问题验证及相关功能测试

BIOS样品基本功能测试

Bug解决 PCB遗留问题跟踪

功能遗留问题跟踪

系统测试遗留问题跟踪

批量问题遗留跟踪

固化改进


硬件配合问题固化改进措施

应用配合问题固化改进措施


项目收益

1 ）计算方法及原则收益：由于批次问题减少，减少返工损失产生收益 1

由于返停线可能造成延期供货罚款，该项减少产生收益 2

投入： a) 系统测试：通过优化部件测试及采用自动测试的方式抵消增加的测试，无投

入 b) BIOS 测试的增加需要增加 1 个测试员及 TEAM 成员工时费用总收益 = 收益 1+ 收益 2-投入

2 ）收益核算收益 1＝ 236574元收益 2=173721元投入 =55000元

净收益＝ 236574＋ 173721－ 55000＝ 325295元

谢谢大家！谢谢大家！谢谢大家！谢谢大家！

Documents

Six Sigma journey of lenovo