Nimbus Control 2007讲座听后感

  今天和公司同仁一起在北京酒仙桥丽都酒店听了来自英国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 个

不同的版本，到最后领导一发话全都得改，才发现他们都不是能最后拍板的，及其没有效率，看来以后我们的

业务需求调研就得用此方法了。