六西格玛管理有一个很鲜明的特点，就是把改善工作当成正式项目来做，而不是把问题交给某一个部门自行处理。
一个质量问题可能涉及生产、工程、采购、设备、供应商和客户，如果只由质量部门单独负责，很容易出现信息不完整或部门之间互相推卸的问题。六西格玛通常会建立跨部门项目团队，由项目负责人协调资源，并沿着DMAIC方法推进。
传统六西格玛组织中，黑带往往承担较复杂项目的领导角色，部分企业甚至安排黑带全职负责改善。但今天很多公司已经采用更灵活的方式，黑带和绿带可能同时保留原岗位，只在需要时承担项目责任。
无论组织形式怎样变化，一个成熟的六西格玛项目仍然有一个共同特点：问题要明确，数据要可靠，原因要验证，改善要有结果，而且成果要能够长期保持。
六西格玛项目和一般改善活动有什么不同？
企业每天都在改善，但并不是所有改善都需要变成六西格玛项目。
例如操作台灯坏了，直接更换即可；SOP中出现错字，修改文件即可。这些问题原因明确，不需要DMAIC。
六西格玛更适合那些原因不清楚、问题持续存在、涉及多个部门，而且对质量、成本、交付或客户有明显影响的问题。
例如某产品半年内不良率一直维持在6%，不同班次和设备表现又不一致，过去已经尝试多种措施但效果不稳定，这就比较适合正式立项。
所以六西格玛项目的第一原则不是「所有问题都用DMAIC」，而是把DMAIC用在真正需要系统分析的问题上。
成功项目的第一条件：问题定义必须清楚
很多项目从一开始就已经埋下失败种子。
例如项目名称写成：
「提高生产效率」
这个范围太大。生产效率可能涉及几十台设备、多个产品、排产、人员、换线和材料。
更好的定义可能是：
「将A产品在3号装配线的首次通过率，由过去三个月平均82%提高至95%，并在四个月内完成。」
这样团队才知道要研究哪条线、哪个产品、哪个指标，以及什么时候算完成。
项目不是靠工具数量判断水平
有些项目报告为了显得专业，会放入大量鱼骨图、Pareto、控制图、Cpk、假设检验、DOE和FMEA。
但工具多，不代表项目好。
真正成熟的项目，是每一个工具都有明确目的。
例如MSA是为了确认测量数据可靠，控制图是为了判断过程是否稳定，假设检验是为了验证某个因素是否真的影响Y，DOE则是为了研究多个因子及交互作用。
正确的工具用在正确的问题上，比使用很多复杂工具更重要。
图表也必须能够独立说明问题
六西格玛项目经常使用大量图表，因此图表质量非常重要。
一个好的图表应该让没有参加项目的人也能大致看懂。
例如控制图和趋势图应说明指标是什么、时间范围是什么；散点图要标明X轴和Y轴；改善前后图表最好使用一致口径，避免因为坐标或样本范围不同而制造视觉差异。
图表不是装饰，它本身就是证据的一部分。
Define：先说明为什么这个项目值得做
Define阶段的重点不是马上分析原因，而是确认项目方向。
团队通常需要完成项目章程，说明问题、业务影响、目标、范围、项目成员和时间计划。
同时还要确认客户是谁，以及客户真正重视什么。
VOC（Voice of Customer）可以帮助理解客户声音，再进一步转换成可测量的CTQ。
例如客户说「交货总是太慢」，这句话本身不能直接成为项目指标。团队可能进一步把它定义为：
「订单确认至出货的平均Lead Time」
或者：
「按期交付率」
Define阶段还经常使用SIPOC，从高层次了解供应商、输入、过程、输出和客户之间的关系。
Measure：先证明你的数据值得相信
很多项目最危险的问题，不是分析错误，而是数据本身就不可靠。
所以Measure阶段首先要确认怎样收集数据，以及数据定义是否一致。
例如什么叫「缺陷」？返工以后合格算不算一次缺陷？不同检验员是不是使用同一标准？
如果是测量型数据，还可能需要进行MSA或Gage R&R，判断量具和人员造成的测量变异是否可以接受。
只有确认数据可靠以后，团队才适合建立基线。
Measure阶段真正要回答的是「现在到底有多差？」
建立基线以后，团队需要清楚说明改善前的过程表现。
根据数据类型和问题，可以使用运行图、控制图、直方图、箱线图、缺陷率、DPMO、Cpk或其他指标。
但也不要机械使用所有工具。
如果Y是交付周期，可能更适合看Lead Time分布和趋势；如果Y是尺寸，则可能适合控制图和过程能力。
工具应该跟随问题，而不是反过来。
Analyze：潜在原因不等于根本原因
分析阶段经常会先通过鱼骨图、5 Why、流程分析和头脑风暴产生很多可能原因。
例如产品尺寸超差，团队可能列出刀具磨损、夹具定位、材料硬度、操作员、设备温度等因素。
但这些只能叫做「潜在原因」。
真正进入六西格玛分析以后，还需要用数据验证哪些原因真的与结果Y有关。
这一步是DMAIC和普通头脑风暴最大的差别之一。
Pareto图能够排序问题，但不能证明根因
这是项目中一个常见误区。
Pareto可以告诉团队哪一种缺陷出现最多，但不能直接证明为什么发生。
例如Pareto显示「焊点虚焊」占全部不良的55%，这只能说明应该优先研究虚焊。
后续仍然需要分析温度、锡膏、设备、材料和操作等因素。
必要时可以利用假设检验、ANOVA、相关回归或DOE等方法进行进一步验证。
Improve：解决方案必须对应已验证的原因
进入Improve阶段以后，团队才真正开始决定应该改变什么。
如果Analyze已经确认某个关键参数影响缺陷率，那么改善措施就应该围绕这个参数展开，而不是突然提出一个和原因没有关系的方案。
团队可以通过方案评估矩阵、影响／付出矩阵等方法比较不同选择。
如果需要寻找最佳参数组合，可以使用DOE。
但DOE并不是「实施计划」，而是一种用来研究因素影响和优化过程的统计实验方法。
改善措施实施以后，还需要再次收集数据验证结果，而不是因为新方案已经上线就宣布项目成功。
FMEA在Improve阶段可以帮助评估新风险
一个改善方案解决旧问题以后，也可能引入新问题。
例如提高设备速度可以增加产量，但可能增加磨损或缺陷风险。
因此，在实施重要变更前，可以利用FMEA重新评估潜在失效模式和风险。
这能避免项目只看到改善收益，却忽略副作用。
Control：真正困难的是半年以后还有效
六西格玛项目最容易在Control阶段被低估。
很多项目改善后一个月表现很好，但三个月、六个月以后又逐渐回到原点。
原因通常不是分析错，而是成果没有被制度化。
Control阶段需要明确哪些关键参数要持续监控、谁负责、监控频率是多少、异常发生以后怎样处理。
常见工具包括Control Plan、SPC、SOP、培训、反应计划和管理看板。
如果过程需要持续统计监控，就可以使用控制图观察新的Y是否保持稳定。
项目关闭不能只写「达到目标」
一个完整项目在关闭时，还应该总结：
项目最终改善多少？财务收益是多少？哪些方法有效？哪些假设被推翻？有没有其他产品线可以复制？谁负责后续监控？
这些经验可以减少其他团队重新走相同弯路。
如果项目产生了节省金额，最好由财务部门使用统一口径确认，而不是项目团队自己估一个很漂亮的数字。
项目阶段审核，比机械「过关」更重要
DMAIC五个阶段确实应该有基本交付物，但不必把它理解成完全僵硬的关卡。
实际项目中，有时团队在Analyze阶段发现数据不足，就需要回到Measure补收数据；Improve试验结果不好，也可能重新分析原因。
DMAIC本身允许这种迭代。
所以阶段审核的目的不是为了盖章，而是确认：
目前掌握的证据是否足够支持进入下一步？
绿带和黑带的项目差异在哪里？
绿带和黑带都使用DMAIC，因此并不是绿带只做前三步、黑带才做完整五步。
两者更大的区别通常在项目复杂度、影响范围和所需分析深度。
绿带项目可能集中在单一部门或较明确的问题，使用基础统计和质量工具已经足够。
黑带项目则更常涉及跨部门问题、更大的财务影响，以及较深入的统计分析，例如回归、ANOVA和DOE等。
同时，黑带通常也需要更强的项目领导、利益相关者沟通和团队管理能力。
六西格玛和项目管理确实有大量共同能力
DMAIC本质上具有明确的项目结构，所以学习六西格玛确实会训练很多项目管理能力。
例如项目范围、目标、时间计划、资源协调、团队沟通、风险管理和项目关闭。
但六西格玛黑带并不等同于一般项目经理。
传统项目管理更多关注项目是否按时间、预算和范围完成，而六西格玛还特别强调过程表现、数据分析、根因验证和统计改善。
两者能力高度互补，但重点并不完全一样。
真正优秀的六西格玛项目，是一条完整证据链
一个成熟项目读下来，应该能够清楚看到：
企业为什么要做这个项目，问题有多严重，数据是否可信，潜在原因有哪些，哪些原因被数据验证，为什么选择这个改善方案，结果改善多少，以及怎样确保成果不会反弹。
每一步都应该和前一步连接。
如果分析出来的原因和最终措施完全无关，或者项目收益没有任何前后数据支持，即使报告做得再漂亮，也很难称为高质量的六西格玛项目。
结语
六西格玛项目真正重要的，不是把DMAIC五个阶段填满，也不是展示用了多少统计工具。
它是一种有纪律的项目改善方法，把一个模糊的业务问题逐步转化成可以测量、分析、验证和控制的问题。
优思学院认为，一个好的六西格玛项目应该做到四件事：问题定义清楚，数据能够相信，原因经过验证，成果可以持续。
做到这四点以后，鱼骨图、Cpk、假设检验、DOE和控制图才真正有意义。
这也是为什么六西格玛绿带和黑带学习的不只是统计工具，而是一套完整的问题解决和项目管理思维。
