很多六西格玛项目在Improve阶段看到指标改善后，团队很容易产生一种感觉：问题已经解决，项目可以结束了。
实际上，这往往是改善最危险的时候。
过程今天变好了，并不代表三个月后仍然会保持。人员会更换，设备会磨损，原材料会变化，生产压力会上升，新的操作方法也可能慢慢被员工放弃。如果没有建立控制机制，项目辛苦取得的成果很可能逐渐消失。
所以，DMAIC最后一个阶段Control，并不是简单地「观察一下结果」，而是要把经过验证的改善方法真正转化成日常管理。
Improve解决的是「怎样把过程变好」，Control解决的则是「怎样让它一直保持这么好」。
为什么DMAIC一定要有Control阶段？
六西格玛项目通常针对长期存在的流程问题。如果原来的过程能够自己维持良好表现，也就没有必要开展改善项目。
因此，一旦团队改变了设备参数、作业方法、检验方式或工作流程，就需要考虑这些新条件是否能够长期执行。
例如某项目通过调整温度和压力，把不良率从8%降低到2%。如果项目结束后没有把新参数写入工艺标准，也没有监控设备参数是否发生漂移，那么几个月以后，不良率完全可能重新上升。
Control的作用，就是把一个依赖项目团队维持的改善，转化成一个能够由日常系统自行维持的过程。
先理解DMAIC五个阶段之间的逻辑
Control并不是独立存在的。它实际上是前面四个阶段的最后落地。
Define阶段回答「我们究竟要解决什么问题」；Measure建立现状基线并确认数据可靠；Analyze利用数据验证真正原因；Improve针对关键原因设计并验证解决方案；到了Control，团队才需要决定这些新方法如何长期保持。
所以，如果前面的根因没有验证清楚，Control阶段也很难建立有效控制。
例如团队误以为人员培训就是根因，最后建立了一套非常完整的培训制度，但真正造成缺陷的是设备温度漂移，那么控制得再严格也没有用。
Control第一项工作：明确到底要控制什么
控制阶段不是把所有数据都纳入监控。
真正需要控制的，是那些已经证明会影响关键结果Y的重要因素。
例如DOE已经验证：
- 温度是关键X；
- 压力是关键X；
- 操作人员不是显著因素。
那么控制计划应该重点监控温度和压力，而不是为了完整而加入大量没有意义的指标。
六西格玛项目在Control阶段一个非常重要的原则就是：
控制关键X，同时监控关键Y。
X告诉我们过程条件有没有发生变化，Y则告诉我们最终结果是否仍然保持改善后的水平。
控制计划是Control阶段最重要的工具之一
Control Plan，也就是控制计划，是制造业中非常常见的过程管理工具。
一份有效的控制计划通常需要明确：
- 需要控制的过程或工序；
- 需要监控的关键特性或参数；
- 规格或目标是什么；
- 使用什么测量方法；
- 多久测量一次；
- 由谁负责；
- 出现异常以后应该采取什么行动。
其中最后一项特别重要。
很多企业建立了大量监控指标，却没有Reaction Plan，也就是异常反应计划。
结果员工看到控制图出现异常，只知道「这个点超限了」，却不知道下一步应该停机、隔离产品、通知工程人员，还是重新测量。
真正成熟的控制系统，不能只发现问题，还必须明确发现问题以后怎样处理。
SOP的作用，是把改善方法变成标准工作
如果Improve阶段改变了工作方法，Control阶段通常需要更新SOP、WI、工艺参数或相关操作文件。
例如项目发现，产品装配错误主要来自三个不同版本的作业方法。团队通过试验确认了一个更可靠的新流程。
如果只是培训现有员工，却没有更新SOP，那么半年以后新员工加入时，很可能又回到旧方法。
因此，改善措施需要进入正式标准。
但也要注意，Control阶段不是「写一份SOP就结束」。
文件只是控制机制的一部分，还必须确认现场真的按照新标准执行。
SPC可以帮助判断过程是否开始反弹
对于需要连续监控的关键过程，SPC控制图是Control阶段非常有价值的工具。
假设项目已经把某个关键尺寸稳定下来，控制图可以继续观察过程平均值和波动是否出现异常。
如果控制图出现超出控制限的点、连续偏向中心线一侧或明显趋势，就可能表示过程产生新的特殊原因。
这比等到产品大量超出规格以后才处理，更具有预警作用。
因此，Control阶段的重点不是天天重新计算项目收益，而是尽早识别过程是否正在偏离新的稳定状态。
Cpk高了，也不代表可以停止监控
有些项目完成后发现Cpk从0.85提高到1.50，于是认为过程能力已经很好，不需要继续关注。
这个想法有风险。
Cpk描述的是一定条件下过程满足规格的能力。如果设备磨损、人员方法或原料发生变化，过程均值和标准差同样可能改变。
所以Cpk是结果指标之一，并不能代替过程控制。
更合理的做法是同时关注：
过程是否稳定？关键X有没有保持？最终Y和过程能力有没有下降？
培训不是一次活动，而是一项控制机制
如果改善涉及人员操作，培训必须进入Control阶段。
但培训不能只是项目结束前安排一次课堂，然后在项目报告里写「全部人员培训完成」。
真正需要考虑的是：
新员工怎样接受培训？多久需要复核能力？员工忘记关键步骤以后怎样发现？不同班次是否使用同一操作方法？
必要时可以通过技能矩阵、资格确认、现场审核和周期性复训来维持人员能力。
这样培训才真正成为控制系统，而不是项目关闭前的一张签到表。
把控制责任移交给Process Owner
六西格玛项目团队通常只是临时存在。
项目结束以后，黑带和项目成员会进入其他工作，因此不可能永远负责每天监控这个过程。
Control阶段必须完成一个重要动作：把过程正式移交给Process Owner，也就是过程负责人。
过程负责人需要清楚知道：
哪些指标要看？多久看一次？哪些变化算异常？出现问题以后联系谁？什么时候需要重新启动改善？
如果这些责任没有明确，项目结束后控制机制很容易无人维护。
一个简单案例：为什么改善后还是会反弹？
假设一家箱包制造企业长期出现锁扣装配错误。
项目团队通过DMAIC分析发现，主要原因不是员工粗心，而是装配治具定位不稳定，以及不同班次使用的作业步骤不一致。
Improve阶段更换了定位装置，并重新设计操作方法，错误率明显下降。
如果项目到这里结束，风险仍然存在。
新的治具会磨损，员工会更换，新的操作标准也可能慢慢被简化。
所以Control阶段可以建立以下机制：
- 明确治具点检和更换周期；
- 更新标准作业指导书；
- 对新员工进行资格确认；
- 每周监控锁扣错误率；
- 当错误率超过预警水平时启动异常调查；
- 由生产主管负责日常过程控制。
这些机制比单纯写一句「加强员工责任心」可靠得多。
Control阶段还需要验证改善效果能否持续
改善前后出现差异，并不代表改善已经稳定。
例如项目实施后一周，缺陷率从10%下降到3%，当然是好消息。
但如果第二个月升到5%，第三个月又回到8%，那么项目显然没有真正完成。
因此，控制阶段通常需要经过一段适当的观察期，确认指标能够在正常业务条件下保持。
观察多久并没有统一规定，应该根据生产频率、业务周期和风险决定。
高产量制造过程可能几周就能获得大量数据；某些低频服务过程可能需要更长时间。
所以不能简单规定「Control阶段一定需要三个月」或「一定需要一年」。
项目收益也需要在Control阶段重新确认
六西格玛项目经常会计算财务收益，例如减少报废、降低返工、减少工时或释放产能。
Improve阶段根据初步结果估算的收益，并不一定等于最终实际收益。
如果改善不能长期保持，原来计算的全年节省金额也可能无法实现。
所以在Control阶段，可以让财务人员重新确认实际收益。
这能回答一个非常实际的问题：
项目报告说节省了100万元，企业最后真的少花了100万元吗？
Control阶段不只是防止回到原点，也可以发现新的改善机会
控制并不等于把过程冻结。
随着监控数据积累，团队可能发现新的问题。
例如改善后的平均交付时间已经从7天降到4天，但数据显示某一种客户订单仍然需要8天。
这就可能成为下一轮改善项目。
所以Control实际上也是持续改善的入口。
它一方面维持当前成果，另一方面不断向组织提供新的过程信息。
Control阶段最常见的几个错误
第一，把控制理解成「写SOP」。SOP重要，但不能代替数据监控和异常反应机制。
第二，只监控Y，不监控关键X。等Y变差时才发现问题，通常已经太晚。
第三，项目团队长期自己负责控制，没有正式移交给过程负责人。
第四，所有数据都纳入控制，导致现场需要维护大量没有实际意义的指标。
第五，项目刚看到一次好结果就宣布成功，没有确认长期稳定性。
一个完整的Control阶段应该留下什么？
项目关闭以前，至少应该能够留下清楚的控制逻辑。
改善后的标准是什么？关键X和Y是什么？谁负责监控？使用什么方式监控？多久检查一次？什么情况算异常？出现异常以后怎样处理？改善措施有没有进入SOP和培训？项目成果是否已经验证并移交？
这些问题如果都能回答，项目才真正具有持续性。
结语
DMAIC的Control阶段看起来没有Analyze和Improve那么精彩，因为它通常没有复杂的统计发现，也没有明显的改善突破。
但从企业角度来看，Control很可能决定整个项目最终有没有价值。
如果一个六西格玛项目花了几个月，把不良率从10%降到2%，半年以后又回到10%，前面所有分析和改善几乎等于白做。
优思学院认为，Control阶段真正要完成的，是让改善不再依赖某几个项目成员，而是进入公司的流程、标准和日常管理。
只有做到这一点，DMAIC才算真正完成闭环。
六西格玛项目的终点，不是「我们曾经把指标改善过」，而应该是：
即使项目团队已经离开，这个过程仍然能够维持改善后的表现。
