今天和公司同仁一起在北京酒仙桥丽都酒店听了来自英国Nimbus公司的John Allen 的Control2007
的讲座,Control 2007用的不多可以说是第一此接触,但对于老外的讲解和整个产品的的理念,听完
后还是受益良多,写下来大家分享也是自己的回顾提高的记录。
1:对企业的业务流程分析。control最大的卖点不在于它是如何处理电子化的工作流,正如John所
说,一个公司中它所见过最大的电子化流程占总的业务流程比例为35%,其它的业务处理还是要依靠人
工,我想整个数值应该是很高了,实质上国内很多企业做到20%就已经相当不错了。所以Control最大的
贡献是在对企业所有的业务梳理的过程中,让所有的管理者或者叫业务参与者明白和发现企业的业务流
程中的不足或不够清晰的地方,明确who do it。
2:control中的业务描述中有明确的层级关系和资源的参与。用John的话讲,没有明确的目标和资源
参与的流程是不够完善的。也就是说在每个业务流程的节点上都要有明确的输入输出点,进入流程节点
前的 When:什么时机启动此节点,节点中的Who + What,干什么工作和谁做(职责),节点完成后所要
达到的目标以及为什么做成这样Why。通过对业务节点的剖析能够深度的挖掘出企业内部的薄弱环节和流
程不畅的地方。持续改进。
3:Workshops的工作流设计模式。整个是比较吸引我的地方。大体上可以这样描述,在我们向业务客户
实施Control产品时,因为要对客户的业务进行梳理和构建。我们可以现现与管理层沟通,让他指派出需
要构建的业务都需要那些相关职能人员的参与,那我们就把这些相关的人员都聚集在一个Office room 里
,大家开始对业务开始描述,由产品人员先确定好此客户的战略目标,也就是先由个大方向的输入和输出
。输出就是我们要达成的最后结果,John把他叫做 cash in bank,很形象。然后让业务单位的人员充分发
言和讨论用Who+what的方式画出其中的业务节点。在构建的过程中,实施人员更多的是引导,而不要参与
讨论,因为你对客户的业务模式是没有人家本身更加了解的。其中我们就会碰到几个问题:可能他们对自己
的业务模式也不是很清晰,ok由问题就说明此方法找到了他们存在问题的地方,按照此方法我们就会完整的
构建出客户企业的业务模型。我觉得这样的方法可以拿来运用在Ultimus上,以前我们的需求人员都是拿着
笔记本和笔去找相关人员去调研可是效果能,跑了很多部门,出来的流程描述都不是一个样,10个人由10 个
不同的版本,到最后领导一发话全都得改,才发现他们都不是能最后拍板的,及其没有效率,看来以后我们的
业务需求调研就得用此方法了。