再谈6σ与研发（茹海燕）

两年前，我们怀疑在已经推行CMM的研发领域，6sigma是否应该进入；一年前，我们承认在硬件等研发部分，6sigma可以起作用，也有人在尝试做软件6sigma项目；而今天，人们考虑更多的是，如何将6sigma与CMM等已有的过程改进方式有机结合，共同促进研发过程的改进？企业的行为方式也随着时间在转变，更多的领导重视汇报中图表及信息的表述，重视基于数据和事实的决策；我们在分析时，也开始首先质疑数据的可靠性，之后用清晰的图表提供数据中的信息，用严密而合理的逻辑展示思路；过程能力、测量系统、柏拉图、试验设计等等术语经常听到，已经成为大家共同的语言，而这些并非局限于6sigma项目。

这一切都在说明，我们已经走出了体系之争的泥潭，越来越实际地选择使用最有效的工具，越来越清楚我们的工作目标，不是为了推进CMM或者6sigma，而是组织的进步，企业的业绩，即Voice of Business。看到这些悄然无声的变化，我们自然很欣慰，从最早的我们要求大家用，到现在大家自觉主动地要求学，这是对我们以往工作的肯定，也向我们提出了更高的要求：现在的形势下，黑带的作用在于敏锐地发现新的问题，前瞻性地思考，如何帮助研发领域的同事更好地使用6sigma改善业绩？

目前一些企业时时被一些疑问纠缠：对于一个普遍接受了CMM理念的软件企业，6sigma究竟应该发挥什么样的作用？勿庸置疑，“以事实为依据，以数据为基础”已然被接纳，一系列的6sigma工具也常常被使用，如鱼骨图、柏拉图、时间趋势图等等，还有一些工具正在尝试着嵌入研发流程，如QFD、FMEA等。6sigma的作用是否仅限于此？真正的一个工具箱？这与6sigma的理念不符，我们一再听到：6sigma是度量尺度、是工具箱、是思维方式、是管理哲学等等，在这些不同的维度上，它能够为研发过程改进做些什么呢？

一年以来，看到不少研发方面的6sigma项目，可是也时时会暴露出一些问题：有些研发过程的数据频率低，周期长，比较难达到统计分析的样本要求，这样如何使用6sigma工具？有些分析方法是受研发条件所限，如硬件单板有问题，已经分析出可能的原因，但是按照DOE的要求，需要对每个因子的不同水平的组合进行试验，以确认其是否关键因子，之后实施改进。这就需要拿不同组合的单板来试验，而对于研发中的项目，小数量的重新制板和生产优先级低，周期较长，这样就赶不及解决问题的期限。于是项目负责人采用了经验推断出几个因子，然后合在一起试验确认，即改进措施覆盖了所有的因子，当然也包括关键因子，最终确实也达到了改进目标。可是仍然说不出那个“罪魁祸首”究竟是谁，这给后续的控制造成了困难，而这样不确定的推理逻辑是否合适也在认证时引发了争论。

还有更多的人，在绿带培训之后跃跃欲试，努力地寻找“问题”，希望通过实战来提高对6sigma的理解。如同行评审过程，已经有好几个绿带项目在做这方面的改进，分别选择不一样的指标，如缺陷密度，如缺陷数量，如缺陷发现速率。项目本身是成功了，相应的指标有了提升，可是这样的改进在产品项目组并未得到认同。如缺陷密度如果过高就是评审对象质量太差；如果过低，就是本次评审活动不太有效；应该是在某个USL和LSL之间，评审的产品质量是合格的，于是在流程中设置了USL和LSL，如果越界，需要重新审核。很快就有项目经理不同意，说：“这个道理没错，可是在我们这里不适用，因为我们的工作产品目前的质量还很不稳定，多数是缺陷密度过高，如果按照这个要求，几乎每个产品都要重新评审了，而且也不一定能通过。”于是，项目的改进措施改成：“如果越界，提醒主持人注意。”这样的提醒能否达到效果呢？很难说啊。既然如此，费心费劲做了过程改进的项目，并未得到“客户”认同，又有什么意义呢？

所有这些都在提醒我们，研发领域有着自己的特点，6sigma如果希望能够有所帮助，必须根据这些特点来调整和适应，尤其与已经使用的CMM等方法体系如何兼收并蓄、相得益彰，是非常重要的。那么我们从不同方面来看看，6sigma能做些什么。

一、全局策划改进

多数QA选择的项目都是某个KPA的过程改进。这隐含着一个先天不足：CMM告诉我们，要达到哪个级别，需要实施哪些KPA，虽然它也说了要关注企业的战略目标，但是通常这总是被忽视。这样指导下的过程改进，更有为了过级而做的嫌疑，究竟是不是满足企业的需要？当然终极目标自然是企业能够受益，然而考虑到时间、成本、回报，我们做的是不是企业眼下最需要的？

这就是CMM与6sigma的不同，6sigma强调“以客户为中心”，自顶向下，从VOC/VOB逐步分解而得改进方向，而衡量改进效果是依据财务收益，更让组织和个人都能够清楚看到其效果。所以，按照6sigma的思路，首先要清晰描述企业的业务目标，之后按照领域逐层分解为子业务目标，分解到过程可得KPA，分解到团队、个人可得KRA。这自上而下的分解图，就是企业的“需求下行”，我们需要做的就是改善自己对应的性能指标，以保障“能力上行”。从这个角度看，其实我们可以把企业的改进看做一个大项目来作，这个项目也需要策划，DFSS的思路可用于此，倡导者与MBB合作将不同领域的项目分为不同的项目集合，由MBB或者BB负责；之后，BB继续分解，由BB或者GB来具体负责实施改进项目。这样整个企业的改进就是有计划、有组织，所有的改进活动共享同样的愿景目标，又能够互相支持，协调发展。

这是6sigma思路得出的建议，无独有偶，CMMI与CMM相比，也强调了企业应该根据业务目标的需要，选择自己的改进路径，如连续表示法就是为了适应这种路径而创造。在这种表示法中，企业根据业务目标可以选择最优先需要改进的过程区域，可以将这些PA从能力级别0一直改进到能力级别5。如何划分过程域？CMM/CMMI帮助我们将研发过程可视化；如何选择PA？6sigma可以帮助我们。

二、选择合适的思路和工具

CMM告诉我们要做到哪些事情，但是如何做到呢？6sigma可以帮助确定思路。这个其实不用多讲，逐步改进型的选择DMAIC，需要突破原有流程束缚，或者新创造流程的选择DFSS。

需要用哪些工具？这要视需而定。需要注意的是：

1．这些工具并不局限于6sigma的工具箱，如果研发过程中的传统方法已经很有效，就可以沿用。不要忘记，6sigma的生命力就在于它是个开放的系统。

2．根据研发的特点来使用工具。如鱼骨图，一般我们是5M1E作为六大分支，而在软件系统的分析中，就可以按照模块来组织。又例如有的研发过程数据的测量系统分析，没有重复性可言，那么就只关心再现性即可。

3．始终记住：使用工具的目的是什么？是为了加强沟通，让自己和别人都更加了解彼此的想法，所以工具的使用关键在于合适，而不在于繁复或花哨。很多初学者喜欢使用的FMEA，其实是个比较复杂的工具，用的人多但是用得好的案例不多。相比而言，PUGH MATRIX是个简单的选择方案的工具，能够很方便地在研发的方案设计阶段使用，很快就受到了系统工程师的青睐。

三、选择合适的人

在过程改进中，应该有哪些人参加？6sigma说得很清楚，包括倡导者（高层领导）、发起人（直接领导）、客户（内部、外部）、相关流程、领域的代表（利益相关者和执行者），以及黑带、绿带（技术和工具的支持者）等等。在研发过程改进的项目中，最好加上有实践经验的CMM/CMMI专家，这基本上就够了。

 
四、寻求支持

6sigma一再强调 “以客户为中心”，而领导是我们最重要的内部客户。在这方面，6sigma似乎是在暗示一种“领导文化”：去思考你的领导最关注的问题。如果我们选择的改进方向，是组织重要的业绩相关领域，是领导日里夜里想的问题列表的前几位，那么得到领导的支持和协调资源是比较容易的。相反，项目很容易夭折，或者即使完成也默默无闻，影响力有限。最近这句话似乎成了流行语，有篇文章题目就是“今天你‘以客户为中心’了吗”，足见其影响程度。

CMM其实也有这方面的要求，不过它表现得明显温文尔雅得多，因为它的目标是建立“法治文化”。在CMMI的共性实践中，包括流程的支持、领导的定期检验、提供受过培训的资源等等，不过在我看来，这些都不如6sigma简单直接、而且有效啊。建立法治社会永远是我们的目标，6sigma管理法也是致力于挖掘和复制成功的因素，将以前只有10％优秀员工能够做到的事情，教给所有人，让90％的员工都能做到，而且持续达到成功，这唯有通过建立流程、优化流程才能做到。只是在实际操作中，面面俱到往往会落得什么也顾不到，反而需要有所侧重才好。

以上所说的四点，也恰好是6sigma元老，Steve Zinkbraf从大量6sigma实施实践中，总结出的成功实施6sigma的四个KPIV：合适的项目、合适的人、合适的思路与工具、合适的支持。 在研发领域里，6sigma如果能够进行相应的调整和适应，并与已经使用的CMM等方法体系成功结合，将带来意想不到的效果。

再谈研发过程改进与6sigma之二（茹海燕）

本文由作者向AMT提供

茹海燕 专栏