六西格玛过程中的实际问题解决方法doc 56页Word文件下载.docx

六西格玛过程中的实际问题解决方法doc 56页Word文件下载.docx

《六西格玛过程中的实际问题解决方法doc 56页Word文件下载.docx》由会员分享，可在线阅读，更多相关《六西格玛过程中的实际问题解决方法doc 56页Word文件下载.docx（27页珍藏版）》请在冰豆网上搜索。

维尔奇先生成为众多CEO学习的榜样，也让众多公司纷纷仿效GE运作的成功之道。

众所周知，6sigma是GE的取胜法宝。

6sigma为什么有这样的魔力？

与大多数国内的同行一样，我对6sigma也仅是略知一二。

而且我也对它很好奇，希望揭开它神秘的面纱。

幸运的是，目前我得到了一个

其实这是个相当浅显的道理：

保持我们成功的最好办法是帮助我们的客户成长和获利。

一家电信设备厂商发现今年合同额少了很多，原因是运营商的采购量大大减少；

为什么运营商的采购量减少了呢？

经过调查发现，宽带网络的服务建设遇到了困难，运营商没有钱赚。

于是这家电信厂商邀请多家运营商举行论坛，主题就是：

“设备商怎么帮助运营商赚钱？

”这是一个很好的以客户为中心的案例。

电信厂商看到合同额减少，并没有以自己为中心，一味抓住运营商，用尽一切手段增加合同额度；

而是站在运营商的角度分析原因，主动把自己和运营商放在一条船上，共同担负起开拓市场的任务。

这样的情况下，即使市场还没有开辟，运营商对这家厂商的满意度也会大大增加，这也正是设备商的目标之一啊！

上面是外部客户的例子，所谓外部与内部之分是以企业组织为界限的。

下面来谈谈谁是内部客户。

在稍大一些的企业，个人都不能够单打独斗做成事情的，必须与人合作，因此就有了流程。

那么我们每个人就会有上游和下游，上游流程为我们提供工作产品，可以说是我们的供应商；

工作产品经过我们的加工，传递到下游，那么下游就是我们的客户。

举例来说，假设我是研发团队的详细设计人员，我的工作是根据系统设计和模块划分，做出详细设计，在规定的时间内交付开发人员进行编码实现。

那么如何衡量我的详细设计文档质量呢？

就我个人而言，我认为那些复杂算法很能体现我的设计水平，我要把他们写得详细些；

而那些一般的接口方法，我就只定义其名称、参数、返回值域及其含义。

只要以上内容我写得详细清楚，而且遵守公司和项目的相关规范就可以了；

不必面面俱到，那写着多累啊。

这样行吗？

我有没有考虑过我的编码人员对系统是否熟悉？

那些没有设计方法体的接口，对他而言其实现方式是否已经了然于胸？

如果我的编码人员是第一次为我们的项目工作，应该会有很多约定俗成的不成文规则，如注释的内容和格式，我有没有给出提示？

如果我的编码人员是个高手，那么我写得那么详细的复杂和精巧算法，对他是否必要？

如果我对文档质量的认同标准与编码人员差距甚远，可想而知其后果必然是，他经常拿着文档要求我解释一下，再解释一下；

如果他忽略了，到后期再发现问题，那项目付出的成本可就更大了；

而且大概一转身，他就会讲：

“这个家伙，以为自己了不起，其实水平不怎么样，谁搞得懂他写的是什么！

”

有清晰流程的职位，还是比较容易区分客户的。

企业中还有一些职位比较难区分客户，或者说，容易让职位承担者忘记了谁是自己的客户，这些职位就是中层管理干部。

企业的中层经理，是企业的中流砥柱，因为所有的政策执行效果和产品实施质量都是由这一层来决定的。

谁是他们的客户呢？

这一定是第一个答案：

企业。

是的，完成企业的经营目标，企业有了利润，年底就会分红，这就决定了经理们的收入和职位升迁，这怎么可能忘记呢？

所以，项目延期时加班加点，验收时紧张如热锅蚂蚁的，也经常会是主管或者经理。

对于大多数从事技术出身的中层经理来说，对于产品或者项目的问题敏感得很，是很正常的事情。

但是因此而忽略了对下属的服务，却是不应该的。

注意，我用了“服务”一词而不是“管理”，因为我认为对于经理来说，除了为企业服务，他应该时刻牢记，自己的客户还有所有的下属员工！

然而，我们见到的经理们，多数管得多而服务得少，突出表现在平时以领导自居，深陷于企业经营事务，不注重与员工的沟通。

只有到了考核时候，才想起来要听一听员工的声音。

一旦企业遇到难处，开口闭口要求员工体谅企业；

相反，却从不为员工的收益考虑，更不要提什么成长和成功了。

在大量的调查中发现，不是企业高层领导制定决策的失误，而是那些执行不力，以自身的不良行为歪曲了企业意图，和阻塞了员工发展的中层经理，导致IT行业员工的流失率居高不下。

这是多么让企业高层痛心疾首的事情！

企业耗费巨资谋求利润，和保留优秀员工，却被一些人漫不经心地将所有努力付诸东流。

正如拿自己的左手去砍右手的手指，即使过一段时间可以恢复，然而长此以往，企业总作别人的培训班，为此付出的代价不可计数！

古语有云：

“千军易得，一将难求”，中层经理对企业的重要和贡献无人可以否认；

然而一旦这一关没有把握好，造成的损失也将非比寻常。

为什么中层经理象得了流行病一样，会习惯性地拒绝为员工服务？

首先是没有认真分析职位要求，企业是自己的客户，下属也是自己的客户，而且下属的成长决定着企业长期发展的水平。

其次，与通常的观点不同，我相信中层经理宁愿身陷于技术，而较少顾及人员，也是因为后者的工作较前者更虚，更难。

有些经理担心自己不擅长处理人员管理问题，投入过多精力，而结果事倍功半。

如果同时业务上也没有突出贡献，就会影响个人业绩。

的确，处理人员管理问题复杂得多，然而经理们身处企业中层，有责任保障企业上下通道顺畅，为企业的长期利益考虑。

做为企业的感应器，及时反馈员工的声音，调整相应的措施行为，鼓励和帮助员工成长，为企业培养长期稳定的优秀员工，这是经理们不可推卸的职责。

所以，经理的管理就是服务，为企业服务包括贯彻执行企业经营战略和政策，也包括在自己的组织内创造良好的环境，维持和谐的气氛，让员工们能够专心做自己的事情。

如果在完成企业经营目标的同时，能够主动和有效地帮助员工成长，那就是一个百分百的优秀领导！

总结一下，6sigma强调以客户为中心，将自己的成功定义为客户的成长和获利。

无论是做什么工作，都需要先搞清楚：

“谁是我的客户？

”然后经常自问：

“我能为客户做什么，来让客户获得成功？

”只有客户成功了，我们才能获得收益，才能提高客户满意度，我们自己也会获得成功。

软件业已经有了CMM，还需要6sigma吗——“和我一起学6sigma”之二

关键字：

6sigma——一种基于统计的管理法

CMM——软件成熟度模型

DMAIC——6sigma的主要模式之一，五个字母分别表示定义、测量、分析、改进和控制

在6sigma绿带的培训过程中，不绝于耳的是软件从业人员的一个困惑：

“软件业已经实施了CMM，我们还需要6sigma吗？

这个消息对于不论是CMM推进组，还是6sigma推进组，确实是个好消息，这证明软件部门终于接受了CMM。

两年前，CMM对于我们来说还是个“洋物事”，当时没有人相信可以在我们的企业中成功推行，深入人心。

而在今天，它已经溶入我们的日常工作，证明了企业推广CMM的成就不容置疑。

同样，6sigma对于现在的我们还是个有些陌生的事情，但是有CMM的成功推进经验在先，我们有信心让6sigma成为企业持续经营发展的思想方法、实践方式和企业文化。

即使这样，我们还是首先要解释：

软件为什么需要6sigma？

有两个原因，其一，软件行业的目标与6sigma的核心思想完全一致：

以客户为中心，追求卓越。

其二，软件行业在产业划分中，属于服务行业的一部分，6sigma已经在服务行业大获成功，因此有理由相信它也能够帮助软件行业得到大幅度的发展。

例如，一个软件项目遇到这样的问题：

远程客户端和服务器同步所有数据总是花费时间很长；

而且在此期间，客户端不对用户的任何操作做响应，用户感觉就是客户端死机。

可是，如果不理它，过了半个小时之后，它自动返回消息，说同步成功了。

你认为这是一个好的软件吗？

不，实时性差，交互信息少，用户的反馈很不好。

项目组收到用户抱怨之后，就开始定位原因，发现是服务器端的处理方式有问题，同步数据操作完全是串行操作，而且全部数据量又很大，导致这个操作的完成时间长达37、38分钟。

这个问题在调试过程中就已经发现，测试组也在测试报告中特别指出其实时性差，但是在发布版本中为什么没有解决呢？

因为在项目划分中，客户端的开发是一个项目，而服务器的开发是借用另一个项目的人员。

对于这个操作耗时太长的问题，尽管客户端开发人员早就提出不满足用户的要求，但是服务器端的人员认为完成功能就可以了，实时性并不重要。

双方的沟通没有效果，就造成问题一直摆到了用户的面前。

为了解决这个问题，相关的软件部门成立了一个6sigma项目，抽专人寻找原因。

在大家的协同工作下，一周之后，就将同步时间降为1.5分钟。

这是个不对原有系统伤筋动骨的最好结果，如果希望进一步减少同步时间，只有调整系统架构。

由此引发的风险和成本太大，在经过项目组和6sigma黑带的权衡后，同意此项目到此成功结束。

这是个成功地应用DMAIC来解决问题的软件项目，从中体现了6sigma的几个主题：

对客户的真正关注；

由数据和事实驱动的管理；

跨越组织的无界限合作；

对完美的渴望。

在这个案例中，没有CMM的介入，单纯利用6sigma的方法解决了软件的问题。

有人会讲：

“这只是证明了6sigma确实可以应用于软件行业，但是我们的软件行业已经有了CMM，也能取得成功，又何必花费这么多资源推广6sigma呢？

我们另外举一个案例，网络管理系统项目组发现，一年以来系统发布的时间总是推迟，而这个项目已经实施CMM一年有余，而且其实施方法中关于高效召开CCB会议还受到了表扬，其他的同行评审、设计先行等都是做得比较好的。

那么问题出在哪里呢？

在成立了一个绿带项目之后，统计一年以来的计划数据和测试故障数据发现，每当设备系统升级，从而引发的网元管理模块升级，与系统平台本身的升级同时进行的时候，网元管理模块出的故障占到了66.6%；

而由于这些故障，测试由平常的两次，增加到平均7.25次，因此系统发布时间平均延误29天。

在分析数据和项目现状之后，大家提出了两条措施：

一是将系统平台的升级与网元管理模块的升级错开，系统版本发布以平台的升级为主；

而为了解决网元管理模块的故障太多的问题，大家继续研究其解决方案。

在与许多开发人员和一线经理的讨论后，大家一致认为是由于自测不够充分造成的。

按照CMM流程，这家企业要求软件项目在提交系统测试之前，需要提供功能清单和相应的自测报告。

这个项目的自测报告每次都提供，它的一个片断是这样的形式：

模块

功能

功能模块描述

系统配置

系统信息配置

功能正常

板位信息

协议管理

用户访问控制

访问控制列表配置

这有什么问题呢？

自测的粒度难以控制，每个功能给出一个“功能正常”的结论，但是达到什么样的标准可以给出这个结论呢？

大家的看法并不一致，有的开发人员认为功能很重要，只要设备管理功能正常就可以了；

有的认为，性能也很重要，要看操作的响应时间是否在用户需求的规格范围之内；

还有的人说，语言的本地化也很重要，因此这个系统提供的几种语言都需要自测；

相反其他的人认为其他语言的环境很难搭建，算了，还是让测试部去查吧。

这些情况反映出以下问题：

1．在设计中没有明确用户需求规格，大家不清楚这些需求中哪些是基本需求，一定要满足的，哪些是可以可变需求，或者潜在需求，作为锦上添花可以选择满足的；