呵呵,既然大家这么关心,我贴出来好了。 我们这个项目是一个IT基础运维的项目。大家都知道,在一个非软件行业的集团中,IT部门几乎是不盈利的服务性组织,所有的经费是要靠上面划拨,而不是自己出去包工。而6Sigma的方法主要是通过流程找出改善因子,然后将改善后的效果数字化(这里最头疼,后面说),达到精减开支,节约成本的目的。我们这个项目可以定义为IT的服务类项目。 我们集团现在的分销系统(DRP)主要由三部分构成:物流、商流(CRM)和财务。由于财务软件是用的外包成品,所以故障率不高,软件的整体水平还是可以的。但偏偏物流和商流软件是我们部门以前自己做的(呵呵,在我来部门之前),系统的运转效率很低,而且故障不断。经常是每个月都要宕掉50个小时左右,这就害苦了下面计划和物流的人,也使整个销售业务收到影响,下面的几百个经营部肯定开不出单,造成销售损失。所以实施这个6Sigma项目的初衷,是要把系统不稳定时间由50个小时缩短到12个小时左右,而且要将时间基本都控制在晚间没有销售行为的时候。 部长牵头,找了一个基础运维组组长(孙悟空)当项目经理,下面三个兵:一个运维组的成员(负责物流系统维护)和我们项目管理组两个人(俺刚毕业,进公司两个礼拜,呵呵)。项目算是正式立项了。前期很顺利,现状分析、RD和PP(我的强项,呵呵)都做完了。结果到了项目收益估算这里卡了:IT运维并不产生实际效益,而6Sigma必须要将结果数据化。这下我们可是费尽了脑筋,和财务部来的FEA开始一场惊心动魄的拉据战(哈哈,不夸张)。具体的过程就不说了,总之前后花了两周的时间,总算把这个FEA给搞定了(唉,财务强势啊,下辈子也作财务)。后来想想,这段时间完全荒废了,后期的项目进度其实可以正常进行的,这就是经验的积累了。这里可以透漏个小MM,服务类项目显形收益是没法做得,大家可以想想其他方法…嘿嘿。具体的收益我就不说了,反正是上百万了(才是一个GB项目,亏啊!至少是BB了)这里提一下,以前没有做过6Sigma项目的兄弟姐妹们要注意了,在我们的项目风险报告里面一定要把收益评估风险和时间风险写进去,一定要!不然项目在这个阶段肯定要耗费时间,我们作项目计划的时候也要把时间稍微给得充裕一些。 下面作SIPOC、VOB/VOC、CTQ、大小Y通通搞定,D阶段算是完成了,进入M阶段,先找出所有可能影响系统稳定性的因子(鱼骨图等),然后通过以前的记录,将因子一一找出。将所有的东西数据化(这里学习MINI TAB又花掉一周),然后利用工具将统计结果做出来(呵呵,又是俺的活),在找出因子的同时,逐一做出及时改善。注意,这个时候我们已经将项目管理在平常的实践中贯穿实施了。该提交的文档一个都不能少。在项目管理阶段,这里属于项目实施了。不过说句实话,实施起来是要实力的,呵呵。 后期的A阶段主要是把主要因子找出(矩阵分析),然后找出解决办法,为I阶段做铺垫准备。这里要注意,项目周报和月报在这个阶段就开始更总要了,因为要具体开始干活了。I阶段是最累的,要将找出来的因子一一进行改善……(呵呵大家不要找太多啊)。这里没有我的活,主要是运维组的两个人负责。项目管理在这里就主要是项目监控的问题了。通过改善,我们建立了一套流程,通过这个流程确实可以减少系统宕机的时间,还有一些突发事件的处理机制,这里都是不可少的。硬件的维护比较简单,主要是机器重启的时间,学习硬件的朋友有很多方法何以保证系统的稳定,我这里就不班门弄斧了。主要是软件方面的故障,这有的时候还是需要一些方法的,呵呵,又是商业MM。到此,项目实施阶段算是完成了。 C阶段就更简单了,主要是一个后期控制。这个时候只要按照前面制定的流程和方法就能够保证最后的效果。项目管理在这个时候可以进入最后的阶段了(注意,不是结束)。由于6Sigma项目的成败是要数据支撑,所以后面一定要坚持下去,至少要一年…(呵呵,不是我说的) 整个项目从4月份开始,到8月份结束。最后的项目汇报,我们的项目在几乎没有投入的情况下(就是这样,我们人力是不算的资源的,在Project2003里面大家的成本为0,5555555),达到了上百万的效益。和目标相比,最终的结果差不多是4.5个Sigma左右,把下面听报告的老总们乐得啊~~~~~呵呵,奖金到手了 总结一下,其实项目管理和6Sigma的DMAIC流程并不冲突,关键是我们对流程的把握。6Sigma的各个流程在项目管理里面究竟是哪个阶段,每个阶段提交的文档究竟有哪些,这些东西只要我们在前期PP里面做好,其实都很简单。大家看看CMMI的实施,和项目管理有多大的区别呢?下次有机会再把CMMI的案例写出来,还是那句话:还真要点实力。再废话一句:刚毕业来公司就给我这样的实践机会,真的很幸运…
|