大误会

    这是一种忏悔。我们宣称自己因传播虚假形象而有罪。下图所示的camunda bpmn框架在本书的前一个版本中使用过。2009年在德国投入使用，2012年在英国投入使用，获得了巨大的成功。数百个bpmn项目使用框架的金字塔描述来进行定向。一家大型的国际软件供应商甚至将金字塔列入其营销材料。不幸的是，这导致了一些误解。

6.16.png

    上图:从旧到新:camunda bpmn框架。

    在金字塔中，我们区分了战略、操作和技术层面。乍一看，它与camunda house类似，但是camunda house将技术级别定义为操作流程模型中称为技术流程流的组件，而不是自己的级别。金字塔把操作层放在一个相当于我们现在所说的人类流程流的位置。

    这种改变是必要的，因为人们经常认为技术级别是操作级别的细化，换句话说，技术级别只是增加了更多的细节。实际上，操作级模型(在早期框架的意义上)通常比相应的技术级模型更详细。例如，考虑一个简单的技术流程流，它触发一个复杂的手动任务，然后需要一个复杂的手动流程。

    **出现了两个相关的误解。**

    第一种看法是，三个级别上的建模必须按照固定的顺序进行，目标状态流程必须首先在战略级别创建，然后在操作级别创建，最后在技术级别创建。没有必要这样做。首先创建操作模型或技术模型通常更有意义。这样做可以让您在尝试将其总结或抽象为战略过程模型之前，对过程参与者必须进行的工作方式有更清晰的理解。实际上，通常的做法是同时设想流程模型的技术流和人员流，例如在研讨会中。

    第二个误解与严格的责任分离有关。我们假设只有业务方面定义战略和操作级别，而只有it部门定义技术级别。我们发现这种假设在政治环境困难的企业中最常见，在这些企业中，it、运营和业务部门之间的合作并不理想。

    我们都应该明白，即使是技术流也代表了业务模型。毕竟，它描述的是业务需求。它与经典请求文档的区别仅仅在于技术流程预期可执行源代码——这是bpmn的一个主要优势。如此严格的责任分离的风险是，技术模型虽然符合需求，但可能对业务变得难以理解并不能令人满意。

    同样，在人类流程的设计中不充分地使用it也是一个严重的问题。如果认为您可以纯粹从操作的角度定义流程，并且只有在此之后才能使技术实现与流程保持一致，那就太天真了。经验告诉我们反复操作决策可以而且应该受到技术现实,要么因为业务需要什么技术上是不可能的(或者不可行,原因成本),或因为技术可以提供解决方案而不是雷达定义业务需求。

    总而言之，您可以说操作流程模型既属于业务，也属于it。作为共享的工件，双方应该共享其开发。

    就我们处理项目的方法而言，这种想法意味着什么?基本上，它与敏捷项目组织一致:概念与实现的严格分离就像经典的瀑布式开发模式一样过时。大多数it项目在迭代开发中表现得更好，无论是在scrum中的sprint中还是在其他情况下，项目是关于过程改进还是自动化并不重要。企业和it不应该孤立地工作。

    非常清楚的是:项目参与者可能需要从他们的舒适区中摆脱出来，并充分地激励他们诚实地与“对方”一起工作。“在过去的几年里，我们强烈鼓励合作的结果总是一样的:巨大的惊讶于一个项目是多么富有成效。”当it和业务肩并肩地在战略和操作级别(包括技术流程)定义目标状态流程时，技术流程可以在几天甚至几个小时内变为可执行的。

    正如大型保险公司lvm versicherung的thorsten schramm在我们的一次研讨会上所说:

    “用BPMN进行过程建模只花了几天时间就极大地鼓舞了整个项目团队(包括来自it和业务部门的人员)，现在第一个改进的过程已经出现了。”

    托尔斯滕很好地提炼了我们的信息。有时候，研讨会中的合作经验与学习bpmn方法论一样有意义。因此，bpmn可以协同运作，在企业内部产生积极的变化。

下篇文章我们会详细阐述bpmn符号，欢迎关注~~~

• 本文会持续更新，欢迎关注，技术支持：盘古BPM *