艾伟也谈项目管理,话里话外:流程管理,其实可以做的更多

  在为企业做流程管理项目的时候,我们经常会反复的给企业流程经理灌输这样的一种思想:流程管理,并不仅仅是把流程图画出来,装订成册就结束了,流程管理其实可以做的更多。流程管理实际上是一种建立在流程基础上的管理体系,是从流程入手,借助流程这个平台将各种管理方法结合在一起的管理模式。

  之所以选择从流程入手,是因为流程是始终贯穿在所有的业务与管理活动当中的。通过流程的串联,可以很清晰的展示出业务逻辑和管理路径。但凡做过流程梳理工作的企业都会有一种认识,那就是通过流程的梳理,可以让企业发现原来自己以往做的事情其实是按照某种逻辑在执行的。

  一旦这种逻辑清晰了以后,企业对自己业务与管理的认识也就变得更为清晰了。 
选择流程入手的另一个理由是通过流程的梳理,可以很容易的发现瓶颈所在。让企业了解自己的流程,并不仅仅是让工作变得更为畅通,更多的时候是通过一些流程指标的设定来发现流程不畅的关键节点,发现流程的瓶颈;又或是通过对流程执行结果的分析发现管理上的瓶颈。这个时候再通过一些专项的管理方法导入,有的放矢的来解决这些瓶颈问题,往往会使得管理提升的效果更佳。

  对于这些专项的管理方法,有很多也是在利用流程管理的方法来实现其管理思想。例如在全员质量管理(TQM)和6sigma管理理论中,都会发现有着流程的影子。ISO9000的实质是将流程文档化,而6sigma则是提供了一套对流程中关键节点的判断、分析及改善的方法,并形成一种持续流程优化的体系;与信息化相关的管理方法从本质上来说是利用信息化的手段实现其某种管理思想,而信息化却离不开流程——无论是信息流还是业务流都不过是流程中的一部分。

  其实不仅仅是这些管理方法和流程有着千丝万缕的关系,绝大多数管理方法都需要建立在企业正常业务和管理活动的基础上进行提升和完善,而流程则是业务、管理活动的一种具有逻辑的表现形式,因此可以认为大多数的管理方法其实都是建立在流程之上的。流程越清晰,这些管理方法的效果越好。
正是基于这些原因,延展咨询的唐志明才提出了“一维切入,多维渗透”这个概念,强调企业的管理应该从流程入手,通过流程管理逐步引向进入其他方面的管理,在流程管理的基础上开展各种专项的管理活动。 
那么如何来实现“一维切入,多维渗透”呢?
  一维切入”指的是从流程切入,“多维渗透”则是通过流程进入到企业的各个管理层面寻求管理提升点。而实现“多维渗透”的方法可以被定义为D+PDCA。其中D表示为definition,即界定问题。企业首先需要的是建立一套较为完整的流程管理体系,从流程切入,通过流程的梳理将业务和管理活动显性化。

  在这个基础之上,再来考虑界定问题。界定问题有两种途径,一是从流程梳理的过程出发,通过对流程关键节点的过程性指标分析寻找到流程瓶颈,第二种则是考虑从流程梳理后的执行效果出发,通过对结果性指标的分析寻找整个管理体系中的管理瓶颈。通过界定问题,实现对企业的多角度分析,找到需要管理提升的需求点。
在界定清楚问题以后,接下来就是采用PDCA循环模型进行问题的解决。PDCA循环虽然最早是从质量管理中提出的一套管理提升模型,但实际上可以应用到各种管理活动当中。

  这种基于流程的PDCA模型依然是从流程入手,针对所界定的问题提出专项的管理方法,并形成完整的计划,通过修改某些业务流程或是设计新的流程来执行这些计划,通过对流程执行后的过程性指标以及结果性指标分析,将专项管理工作好的方面进行固化,对于不足的地方进行相应的调整,以此形成一个循环。而在完成专项管理工作的既定目标以后,才会进入到D+PDCA的另一个循环当中。

  这种方法的优势在于容易迅速的界定出问题并形成有效的解决方案,这点在一些企业当中也得到了证实。曾有一家企业在进行质量管理中一直发现不了引起质量问题的核心所在,而在经过顾问指导的流程梳理工作以后,通过对流程指标有针对性的分析,找到了前序工作中的关键节点并采取了改进措施,很快实现了质量的大幅提升,迅速降低了生产成本。

   由此可见,流程管理给予企业的管理提升绝对不仅仅是一些流程图而已,就像一位企业的流程经理所说:流程管理就像是土壤,其他的管理就像是种植在这个土壤上的各种作物,只有土壤有营养,这些作物才能生机盎然。

时间: 2024-08-23 08:24:52

艾伟也谈项目管理,话里话外:流程管理,其实可以做的更多的相关文章

艾伟也谈项目管理,动起来再调整 - 向项目经理推荐敏捷

要成为一个好的项目经理需要学会逆水行舟.虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方. "虽然很有道理,但我认为现实不允许,很多项目都有规定的期限.中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的." "写得不错,但是有些建议过于理想化了.毕竟说得很有道理,但实际中具体做起来又不是那么一回事了." 这是两位网友对<软件项目经理新手上路>的评论.这话很有道理,也是在现实生活中碰钉子碰出来的.在项目中确实存在

艾伟也谈项目管理,DevOps,不是一个传说!

DevOps最近成了热词,望文生义,你也能猜个八九不离十,它就是在说"研发团队"与"运维团队"之间的那点事儿.那么,到底什么是"DevOps"呢? WikiPedia上说:"DevOps是软件开发.运维和质量保证三个部门之间的沟通.协作和集成所采用的流程.方法和体系的一个集合.它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解."这恰好体现了精益管理中的客户价值原则,即:以客户的

艾伟也谈项目管理,较大型项目的产品工作心得

最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目.从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享. 立项前 1.统一元素设计需考虑周全 也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲. 哪些元素应该做到统一? A.提示方面:统一的操作成功/失败提示:统一的弹窗形式:提示语言采用较统一的句型:为空情况的友好提醒:溢出情况的友好提

艾伟也谈项目管理,项目经理的思维批判

想做好项目经理,就一定要改变你的思维方式.这对于技术出身的朋友尤其重要. 清末人们自以为天朝,他国皆为蛮夷.结果如何呢?丧师辱国,自己沦为病夫.其根本莫非自己脑筋不对头?后来又搞洋务运动,以为洋人只是工具好,其他都不如我们,师夷长技以制夷就可了.而事实却告诉我们,感情我们又错了. 做技术出身的项目经理,就仿佛清末的国人.技术第一的概念已经深入骨髓,说是做管理,其实还是把自己的技术看做天朝上国,管理当做蛮夷丑类,或者只是把管理当做一种工具来学习学习.这么做,果真能做好项目管理吗? 从技术走向管理是

艾伟也谈项目管理,项目经理成长日记(4)——态度决定一切

超仔刚刚推门进来,屁股还没有碰到他的椅子上已经让人感觉到他欢喜轻飘的神色,我抬头望着他眼睛,神色中洋溢的满是欢快.我看着他那兴奋的样子,微微笑着问道:"签完了?结果还可以吗?" "还不错!" "能满意就可以,继续努力." "嗯." 我知道超仔刚刚和公司签了新的合同,在新合同里他的工资有了一定的提高,这些都是因为对于他去年的绩效考核成绩还不错应该得到的结果. 年底对于我来说,可真是多事之秋,因为我需要在年底前完成对我团队这些人的

艾伟也谈项目管理,学习腾讯的产品管理之道

马化腾带着一大批产品高管自上而下,持之以恒地推动产品本位的管理体制规范化,并不断地创新和优化这套体制,使得整个公司上上下下融入了"产品的基因",最终成就了"产品的腾讯". 1.设置一个质量监控小组,由经验非常丰富的高Level的产品人员构成,赋予他们很大的权力,去监控和规范所有的产品项目.并且用KPI来制约产品项目服从这些规范.为了不搞教条主义,很多规范都是在立项之初,由项目经理和这个小组共同确认的,未必是硬性指派,一经确认就受到严格监控.确保好的规范不流于空喊口号

艾伟也谈项目管理,编程习惯

文/Alexey Radul 译/程显峰 原文地址:http://web.mit.edu/~axch/www/programming_habits.html 近年来,我对编程艺术有很多体会.过后,我发现有些体会是错的:有些体会我遗忘了但又重新感受到:而另外有些则是必然会发现的.我还完善了一套项目管理的好习惯,这些习惯包括我自己的,或者小组的,抑或是更大的,公司内部的.一方面,这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算),另一方面,这些习惯也不是什么高深莫测的东西,较小的篇幅就可

艾伟也谈项目管理,敏捷的坏态度

虽然所有软件开发的专业人士都会对这篇文章感兴趣,但是经理.CIO以及软件架构师会对它最感兴趣.这个话题可能会引起许多争议,但我写这篇文章是为了让你了解在敏捷运动中看起来正在日益增长的问题. 你为什么在这?敏捷不需要经理. 以前听过这种说法吗? 想象一下,如果你听到开发人员认为你这个职位根本就不应该存在,你会感到多么震惊,就好像是你特意为自己搞出经理这么个职位似的.这个话最常应用在项目经理第一次与将要和他一起工作的开发团队碰面的时候.的确,最初的敏捷宣言绝对没有提到项目管理,并且后来的敏捷理论家更

艾伟也谈项目管理,《播客》项目总结——项目管理方面

引言:如果标题改成<被管理总结>的话,我可以滔滔不绝的说上个半天,但是如果是管理项目的话,我实在肚里的货有限,因为到至今做过的最高职位不过是个"班长"而已. 但是这次<播客>项目在管理方面的确出了问题,而且是满严重的问题,以至于到后来项目差点失控,而且最终的交付作品质量的确让人汗颜.如何避免下面程序员很累,但效率却很低:上面不停的催,产品却一个bug接一个bug,完全没法交付:项目经理累的要死,项目却仍然处于失控状态这样的问题和局面?在一个差点失控的项目刚刚结束