5S现场管理6sigma过程解决实际问题Word格式文档下载.docx
《5S现场管理6sigma过程解决实际问题Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《5S现场管理6sigma过程解决实际问题Word格式文档下载.docx（31页珍藏版）》请在冰豆网上搜索。
6sigma为什么有这样的魔力？
与大多数国内的同行一样，我对6sigma也仅是略知一二。
而且我也对它很好奇，希望揭开它神秘的面纱。
幸运的是，目前我得到了一个机会，全面进行6sigma的完整系列培训，并直接参与相关项目的组织和实施，能够以亲身经历来深入领会6sigma的思想。
一旦打开这扇门，我发现它的确魅力无穷：
原本在学校中枯燥的统计分析，能够揭示出我们自己无法发现的问题根源；
多种多样的支持工具象变戏法一样，展示给我们过程的原始能力。
我越发入了迷，深信正象6sigma在国外掀起的过程改进狂飚一样，它必定也要在中国推波助澜，助我们的民族企业进入世界行业前列！
这个系列是我在学习和实践过程中的所思和所为的记录，它不是6sigma的内容介绍，关于这些有相关书籍讲解得更加全面和深入。
我关注的是对我个人很有启发意义的思想亮点，尤其是具有实践指导意义的关键过程和工具。
希望它能够推动6sigma在国内的发展，也为同样关注流程改进的同行们提供一些实际经验，或者教训。
进入正题
6sigma的中心思想就是“以客户为中心”和“追求卓越”。
就是这么简单，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天。
在分析数据和项目现状之后，大家提出了两条措施：
一是将系统平台的升级与网元管理模块的升级错
升级会员 