The following is a free excerpt from the book Real-Life BPMN. It can be used as study material in preparation for the training for certification according to OCEB.*
以下内容节选自《实战 BPMN》一书，可作为 OCEB*认证培训前的学习资料。

*Disclaimer: Please note that this excerpt does not represent the complete study material required in preparation for the training for certification according to OCEB.
*免责声明：请注意，此摘录不代表为准备 OCEB 认证培训所需的完整学习材料。

Real-Life BPMN  实战 BPMN

Real-Life BPMN   实战 BPMN

Contents  目录

Introduction  引言

1.1 Business process management
1.1 业务流程管理

1.1.1 Definition  1.1.1 定义

1.1.2 BPM in practice
1.1.2 实践中的业务流程管理

1. The client wants to improve a process using Information Technology (IT).
   客户希望利用信息技术（IT）改进流程。
2. The client wants current processes documented.
   客户希望现有流程得到文档记录。
3. The client wants to introduce entirely new processes.
   客户希望引入全新的流程。

1. There is an acute reason for using BPM. The project concerns essential processes that need to be created, improved, or documented.
   存在使用 BPM 的迫切需求。该项目涉及需要创建、改进或记录的核心流程。
2. The reason for BPM is strategic. There will be no direct or immediate benefit, and the project likely was initiated by some manager trying to advance his or her career.
   采用 BPM 是出于战略考量。虽不会产生直接或即时效益，这类项目往往由试图推进职业发展的管理者发起。
   As you can imagine, serious people don’t greet the second argument with enthusiasm. It is our own experience, however, which makes us advocate for this view strongly: BPM, process management, or whatever you want to call it, is not an end in itself.
   可想而知，务实者对这种理由难掩冷淡。但根据我们的实践经验，我们强烈主张：业务流程管理（或任何称谓）本身并非终极目标。
   We always recommend introducing BPM in steps. Each step should yield a practical, measurable benefit that justifies the time and effort that it took to accomplish. Once the justification of the first step is established, take the next step. You may think that this approach produces solutions isolated from each other, but what we mean to emphasize here is the controlled nature of the approach. Each step contributes to the big picture: the company’s process orientation. A hiker may use a map and a compass to guide his or her steps. Likewise, when you introduce BPM, you should use a good procedure model and common sense as your guides.
   我们始终建议分阶段引入 BPM。每一步都应带来实际、可衡量的效益，以证明所投入时间和精力的合理性。一旦第一步的合理性得到确认，便可继续下一步。您或许认为这种方法会导致解决方案彼此孤立，但我们在此强调的是该方法的可控性。每一步都对公司的大局——流程导向有所贡献。徒步者会借助地图和指南针指引方向。同样，在引入 BPM 时，您也应将完善的流程模型和常识作为行动指南。

1.1.3 Camunda BPM life cycle
1.1.3 Camunda BPM 生命周期

Procedure models always seem to be either too simple or too complex. The overly-simple ones contain only the most painfully obvious elements. They may be useful for marketing presentations, but not much else. On the other hand, overly complex models work so
流程模型似乎总是要么过于简单，要么过于复杂。过于简单的模型仅包含最显而易见的元素，可能只适用于营销演示，别无他用；而过于复杂的模型则往往...

• An existing process is to be documented or improved.
  需要记录或改进现有流程。
• A new process is to be introduced.
  需要引入新流程。

1.1.4 Process automation
1.1.4 流程自动化

• Process automation does not necessarily mean that the entire process is fully automated.
  流程自动化并不意味着整个流程必须完全自动化。
• The central component of process automation is the workflow engine, which executes an executable process model.
  流程自动化的核心组件是工作流引擎，它执行可执行的流程模型。
• The workflow engine controls the process by informing humans of tasks that they need to do, and it handles the result of what the people do. (This is human workflow management.) It also communicates with internal and external IT systems. (This is service orchestration.)
  工作流引擎通过向人员通知需执行的任务并处理其操作结果来控制流程（这是人工工作流管理）。同时，它还与内部及外部 IT 系统进行通信（这属于服务编排）。
• The workflow engine decides which tasks or service calls take place or not, under what conditions, and according to the result of the task execution or service call. Thus the people involved still can influence the operational sequence of an automated process.
  工作流引擎决定哪些任务或服务调用在何种条件下执行或跳过，并根据任务执行或服务调用的结果进行调整。因此，相关人员仍能影响自动化流程的实际运行顺序。

• The workflow engine specializes in representing process logic. The services it provides would have required extensive programming in the past; using a workflow engine now can make you considerably more productive than before. (Or perhaps productivity is not an issue for you, and so you develop your own spreadsheet, word-processing, and drawing programs!)
  工作流引擎专长于呈现流程逻辑。它所提供的服务在过去需要大量编程工作；如今使用工作流引擎能显著提升生产效率（当然，若您对生产力无要求，大可以自行开发电子表格、文字处理和绘图程序！）
• A workflow engine combines workflow management with application integration. This makes it a powerful tool for implementing all kinds of processes from start to end, regardless of other applications or the geography of people in the process. In some BPM software solutions, we can add a separate Enterprise Service Bus (ESB) or other components to the workflow engine to make the whole more versatile.
  工作流引擎将流程管理与应用集成相结合，成为从头到尾实施各类流程的强大工具，不受其他应用程序或流程参与者地域分布的限制。在某些 BPM 软件解决方案中，我们可为工作流引擎添加独立的企业服务总线（ESB）或其他组件，使整体功能更加多样化。
• As the workflow engine controls the process, it tracks everything. It always knows the current stage of the process and how long each task took to complete. Because the work-
  由于工作流引擎控制着流程，它会追踪所有细节。它始终清楚流程当前所处的阶段，以及每项任务完成所耗费的时间。因为工作-
  

  

1.2 The BPM standards
1.2 BPM 标准体系

1.2.1 Workflows with BPMN
1.2.1 使用 BPMN 的工作流程

• You become more independent from certain BPM tools when you do not have to learn a new notation every time you change tools. Today more than 100 BPMN tools exist; many of them are free.
  当你更换工具时不必每次都学习新的符号表示法，这样你对特定 BPM 工具的依赖性就降低了。如今已有超过 100 种 BPMN 工具，其中许多是免费的。
• There’s a good chance that your partners in other companies (customers, suppliers, consultants, and so on) are familiar with BPMN and can therefore understand your process models quickly.
  其他公司中的合作伙伴（如客户、供应商、顾问等）很可能已经熟悉 BPMN，因此能快速理解你的流程模型。
• When hiring new staff, it’s likelier that more of them already can read or generate your BPMN process models.
  在招聘新员工时，更多人已经能够阅读或生成你的 BPMN 流程模型的可能性更高。
• When universities and private companies invest time and money to develop additional solutions based on BPMN, this is to your benefit as well. Our BPMN framework, which we present later, is an example of this commitment -we never would have developed it if BPMN were not a standard.
  当大学和私营企业投入时间和资金基于 BPMN 开发额外解决方案时，这同样对你有利。我们后续介绍的 BPMN 框架正是这种投入的例证——若非 BPMN 成为标准，我们绝不会开发它。

1.2.2 DMN for rule-based decisions
1.2.2 基于规则的决策之 DMN

• Transparency: Everyone can easily understand how decisions are being made. This knowledge is no longer buried either in the heads of certain employees nor in barely intelligible application source code.
  透明度：每个人都能轻松理解决策是如何做出的。这些知识不再埋藏在某些员工的头脑中，也不再隐藏在难以理解的应用程序源代码里。
• Traceability: Every decision can be logged automatically by the decision engine. It is possible to trace why certain decisions were made.
  可追溯性：每个决策都可以由决策引擎自动记录。可以追溯某些决策为何被做出。
• Flexibility: The decision logic can be adapted more readily. It does not have to be rolled out accompanied by lengthy training or documentation; it can just be deployed. In this regard, DMN is slightly superior to BPMN because changing BPMN diagrams intended for execution by a process engine can be too risky for a non-programmer. (This may be hard to appreciate -after all, how hard can it be to add, move, or delete a few symbols? True, but the technical process is only one part of an entire application architecture that can be affected by the unintended consequences of small changes.) Something similar can happen with a DMN decision table, but the consequences are more easily recognizable and, unlike in BPMN, there are no technical attributes behind the symbols that have to be maintained. It is thus more easily possible for the business department to design or adapt software solutions independently of IT.
  灵活性：决策逻辑可以更容易地进行调整。它无需伴随冗长的培训或文档即可部署；直接投入使用即可。在这方面，DMN 略优于 BPMN，因为对于非程序员来说，修改由流程引擎执行的 BPMN 图表可能风险过高（这一点可能难以理解——毕竟，添加、移动或删除几个符号能有多难？确实如此，但技术流程只是整个应用架构的一部分，微小的改动可能引发意想不到的连锁反应）。DMN 决策表也可能出现类似情况，但其后果更容易识别，且与 BPMN 不同，符号背后没有需要维护的技术属性。因此，业务部门更有可能独立于 IT 部门设计或调整软件解决方案。

1.2.3 Structured vs. unstructured workflows
1.2.3 结构化与非结构化工作流

1. You explain that they will have to start working in a more structured manner, with fewer exceptions, deviations, backtracks and the like. This will limit their flexibility when acting within the process, which may frustrate employees and customers alike. On the other hand, the process will become predictable, repeatable, and less dependent on the implicit knowledge of the humans controlling the process.
   你解释说，他们将不得不开始以更有条理的方式工作，减少例外、偏差、回溯等情况。这会限制他们在流程中行动的灵活性，可能会让员工和客户都感到沮丧。另一方面，流程将变得可预测、可重复，并且减少对控制流程人员隐性知识的依赖。
2. You accept that every case may be different, and that this process cannot be structured homogeneously. You need to ensure that the people working on cases have enough latitude to make use of all their knowledge and experience. BPMN might be at its limit here and you need to find another way of approaching a solution. CMMN might be an option, but proprietary products might be as well. Very often these problems boil down to individual software, groupware, Trello- or IFTTT-alike tools or case management solutions.
   你承认每个案例可能都不同，这个流程无法以统一的方式结构化。你需要确保处理案例的人员有足够的自由度来运用他们所有的知识和经验。BPMN 在这里可能已经达到极限，你需要寻找其他解决方案的途径。CMMN 可能是一个选择，但专有产品也可能是。通常这些问题最终会归结为个别软件、群件、类似 Trello 或 IFTTT 的工具或案例管理解决方案。
   BPMN assumes a clear order, a basic sequence in which the tasks are expected to be carried out. But of course there are possibilities to define branches, backflows, and reactions to events. In our projects, these possibilities are often sufficient to properly model partly
   BPMN 假设了一个明确的顺序，即任务预期执行的基本序列。但当然也有定义分支、回流和对事件反应的可能性。在我们的项目中，这些可能性通常足以正确建模部分
   unstructured models. We will further examine this in section 4.5.5 on page 142. In the real world, an entire process seldom fits a completely structured or unstructured pattern. More commonly, there are some structured parts within a process - and these can be captured in BPMN -as well as some unstructured parts for which you will need other possibilities.
   非结构化模型。我们将在第 142 页的 4.5.5 节进一步探讨这一点。在现实世界中，整个流程很少完全符合结构化或非结构化模式。更常见的是，流程中既有可以用 BPMN 捕捉的结构化部分，也存在需要其他方法处理的非结构化部分。
   So let’s get going and look at our first example, including some flexibility for human intervention.
   那么，让我们开始行动，看看我们的第一个例子，包括为人工干预预留的灵活性。

1.3 First example  1.3 第一个示例

Our scenario comes from the insurance industry. It is simplified, but it represents the kinds of real-life situations we have encountered repeatedly. Note that the models used here are more than theoretical constructs or documentation; they are executable by engines, one of which is our own product, Camunda BPM. Camunda BPM allows you both to model and execute models in BPMN as well as DMN.
我们的场景来自保险行业。虽然经过简化，但它代表了我们反复遇到的现实情况类型。请注意，这里使用的模型不仅仅是理论构建或文档；它们可由引擎执行，其中之一就是我们自己的产品 Camunda BPM。Camunda BPM 允许您以 BPMN 和 DMN 两种方式建模并执行模型。
If you have no experience with BPMN, or DMN, the following may seem like a forced march through notational language you don’t yet know. To help, we have added cross references to the sections of the book in which we detail the notational elements.
若您对 BPMN 或 DMN 尚无经验，接下来的内容可能会像一场对陌生符号语言的强制行军。为此，我们添加了书中详细讲解符号元素的章节交叉引用以助理解。
Let’s get started.  让我们开始吧。
Suppose you want to take out car insurance. Nowadays your first stop is the Internet, where you compare offers and decide on a provider. You visit the website of your chosen insurance company -in this case, the fictitious Camundanzia Insurance. You complete an application form (see figure 1.3) with the following data:
假设您想办理汽车保险。如今第一步通常是上网比较不同报价并选定一家保险公司——本例中我们虚构了 Camundanzia 保险公司。您在其官网填写申请表（见图 1.3），需提供以下信息：

• Your date of birth is January 1, 1980. At the time we wrote this, you were 39.
  您的出生日期是 1980 年 1 月 1 日。在我们撰写此文时，您 39 岁。
• The manufacturer of your vehicle is BMW.
  您的车辆制造商是宝马。
• The vehicle model is an X3.
  车型为 X3。

You click to submit the form and lean back, eagerly awaiting your insurance policy.
您点击提交表格，身体后仰，热切期待您的保险单。
The data from the form immediately creates an instance of a business process at Camundanzia, which has been modeled in BPMN and is technically implemented in Camunda BPM (see figure 1.4). We can tell this from looking at the start event application received. The BPMN-compatible workflow engine first mentioned in section 1.1.4 on page 5 now goes to work.
表单数据会立即在 Camundanzia 创建一个业务流程实例，该流程已用 BPMN 建模并在 Camunda BPM 中技术实现（见图 1.4）。通过查看接收到的申请启动事件可以确认这一点。1.1.4 节第 5 页首次提到的 BPMN 兼容工作流引擎现在开始运行。

If no risks had been recognized, the gateway would have selected the path labeled none. This would have led to the issue policy service task (see section 2.7 on page 61 ). The workflow engine would have called Camundanzia’s backend system through an interface, and the backend system would have generated a document. In turn, the document would have been fed back to the workflow engine. The next step would have been the send policy task, which would have forwarded the document to you.
如果未识别到任何风险，网关会选择标记为“无”的路径。这将导向签发保单服务任务（参见第 61 页 2.7 节）。工作流引擎会通过接口调用 Camundanzia 的后台系统，由后台系统生成文档。随后，文档将反馈至工作流引擎。下一步是发送保单任务，该任务会将文档转发给您。
Your risk, however, fell into the yellow category because you drive a BMW X3. The XOR gateway activates the Decide on application user task (see section 2.7 on page 61) and waits for some clerk to decide manually, because he got some task in his inbox. The workflow engine is patient, but because of the attached time event (see section 2.6.3 on page 49), after two days of waiting it will launch an escalation. It will initiate another user task called accelerate application assessment. The user task could be assigned, for instance, to the team leader of the worker who was responsible for this application assessment.
然而，由于您驾驶的是宝马 X3，您的风险等级被归入黄色类别。异或网关（XOR gateway）会触发“决定申请”用户任务（参见第 61 页 2.7 节），并等待某位职员手动处理，因为其收件箱中收到了该任务。工作流引擎具备耐心，但由于附加的时间事件（参见第 49 页 2.6.3 节），若等待超过两天，系统将启动升级流程——发起另一个名为“加速申请评估”的用户任务。该任务可能被分配给负责此申请评估的员工的团队领导。
Let’s assume that the office clerk with the expert knowledge processes the application immediately. He asks himself: “Should this applicant be insured despite the high value of this vehicle?” Maybe he needs to be flexible in handling the application, so in our example he can request further documents. This leads to a call activity (see section 2.8 . 2 on page 69) which is linked to a separate BPMN process model.
假设掌握专业知识的办公室职员立即处理了该申请。他自问：“尽管这辆车价值较高，是否仍应为该申请人承保？”或许他需要在处理申请时保持灵活性，因此在我们的案例中，他可能会要求补充材料。这将引发一个调用活动（call activity，参见第 69 页 2.8.2 节），该活动关联到另一个独立的 BPMN 流程模型。
Requesting additional documents (or other activities you model accordingly) above can be carried out or skipped, that decision is up to the office clerk. In figure 1.6, we see what the clerk’s task form looks like.
请求额外文件（或您相应建模的其他活动）可由办公室职员决定是否执行或跳过。在图 1.6 中，我们可以看到职员的任务表单样式。

- 1.4 Can BPMN bridge the gap?
- 1.4 BPMN 能否弥合鸿沟？

1.4.1 The dilemma  1.4.1 两难困境

• When you apply BPMN in a syntactically incorrect way, you lose all benefits of standardization. After all, what do you need a standard for if the models all look different in the end? Many BPMN tools won’t even enable syntactically incorrect modeling.
  当你以语法错误的方式应用 BPMN 时，你将丧失标准化的所有优势。毕竟，如果最终模型看起来各不相同，还需要标准做什么？许多 BPMN 工具甚至不允许语法错误的建模。
• Semantic inaccuracies or inconsistencies always create the risk that your model will be misinterpreted. This risk is particularly high if you create an inconsistent target state process model and then send it to IT to implement.
  语义上的不准确或不一致始终存在模型被误解的风险。若你创建了一个不一致的目标状态流程模型并交给 IT 部门实施，这种风险尤其高。

1. Different consumers must understand and accept the process model. Making the model easy to comprehend helps to reach agreement.
   不同使用者必须理解并认可该流程模型。使模型易于理解有助于达成共识。
2. Because the process model has to meet the requirements of formal modeling, there’s usually an unavoidable level of complexity to it. This makes it harder to achieve the comprehension that leads to agreement.
   由于流程模型需满足形式化建模的要求，通常不可避免地带有一定复杂性。这使得更难实现促成共识的理解程度。

1.4.2 The customers of a process model
1.4.2 流程模型的客户

• Process owner: Process owners have strategic responsibilities for their processes. They are vitally interested in optimizing performance. They often have budget authority, but before they sign off, they need to be convinced that your improvement plan will work. In most companies, process owners inhabit the first or second tier of management. They may be members of management committees or heads of major divisions.
  流程负责人：流程负责人对其负责的流程具有战略层面的职责。他们高度关注流程性能的优化，通常拥有预算审批权，但在签字批准前，他们需要确信改进方案切实可行。在多数企业中，流程负责人属于第一或第二管理层级，可能是管理委员会成员或主要部门负责人。
• Process manager: Process managers have operational responsibility for their processes. They report directly or indirectly to the process owners. They apply for improvement projects, acting as the ordering party for external services. Process managers are often low- or middle-level managers.
  流程经理：流程经理对其负责的流程负有运营责任。他们直接或间接向流程所有者汇报。他们申请改进项目，作为外部服务的订购方。流程经理通常是中低层管理者。
• Process participant: Process participants work with the processes and actually create value. Their relationship to the process manager varies greatly. In companies organized by functional divisions -sales, logistics, and so on -a process manager is a functional executive for the division in which the process is carried out. Process participants report directly to that functional executive. If the process is carried out across departments, which is common, especially in process matrix organizations (see figure 1.7) conflicts
  流程参与者：流程参与者与流程协同工作并实际创造价值。他们与流程经理的关系差异很大。在按职能部门（如销售、物流等）组织的公司中，流程经理是执行该流程的职能部门的主管。流程参与者直接向该职能主管汇报。如果流程跨部门执行（这种情况很常见，尤其是在流程矩阵组织中，参见图 1.7），则会产生冲突
  can arise between department executives. Process modeling alone cannot resolve such issues, which is why we do not examine them further in this book.
  部门高管之间可能会出现分歧。仅靠流程建模无法解决此类问题，因此本书不再进一步探讨。
• Process analyst: The core competencies of process analysts are BPM in general and BPMN in particular. They support process managers as internal or external service providers through all stages of the BPM life cycle. A process analyst may be the contact for external service providers or may act as the process manager’s representative. Within the company, process analysts usually have either their own sphere of competence in BPM, such as the business organization, or they are part of their IT divisions. It is rare, however, for a process analyst to be responsible for technical implementation.
  流程分析师：流程分析师的核心能力在于广义上的业务流程管理（BPM），尤其是业务流程建模与标注（BPMN）。他们作为内部或外部服务提供商，在业务流程管理生命周期的各个阶段为流程经理提供支持。流程分析师可能是外部服务提供商的对接人，也可能担任流程经理的代表。在企业内部，流程分析师通常拥有自己在业务流程管理中的专业领域，例如业务组织，或者他们属于信息技术部门的一部分。然而，流程分析师很少负责技术实施工作。
  The analyst may like technical work, may know BPMN from back to front, but his or her strengths are as an organizer and communicator. As the builder of bridges between business and IT, the process analyst is the center of every BPM project. About 70 percent of the people who claim or are assigned to this role, in our experience, are poorly qualified because they lack the proper analytic predisposition. The most important qualification of a process analyst is not a facility for sending out information, but a facility for receiving it. Good process analysts naturally want to understand everything thoroughly. At the same time, they have plenty of empathy in relating to the other people involved, and they can tailor their communication for every group. They remember every detail, but they also sensibly shield details from those for whom the details would just be a distraction.
  分析师可能喜欢技术工作，可能对 BPMN 了如指掌，但他或她的优势在于组织和沟通能力。作为业务与 IT 之间的桥梁构建者，流程分析师是每个 BPM 项目的核心。根据我们的经验，约 70%自称或被指派担任这一角色的人并不称职，因为他们缺乏适当的分析倾向。流程分析师最重要的资质不是发送信息的能力，而是接收信息的能力。优秀的流程分析师天生希望彻底理解一切。同时，他们在与相关人员互动时表现出极大的同理心，并能针对每个群体调整沟通方式。他们记得每一个细节，但也会明智地对那些会被细节分散注意力的人屏蔽这些细节。
  Do project managers make good process analysts? No, nor should the project manager be the same person as the process analyst. Most project managers see themselves as “dynamic, action-oriented individuals” who constantly have to “get someone on board” or “pull chestnuts out of the fire.” They may be extremely skilled at delegating responsibility although, to be honest, some are clueless windbags. It may seem ideal to have a good process analyst also manage a BPM project, but it rarely works.
  项目经理能成为优秀的流程分析师吗？不能，项目经理也不应与流程分析师由同一人担任。多数项目经理自视为“充满活力、行动导向的人”，总需要“拉人入伙”或“火中取栗”。他们或许极其擅长分配责任，不过老实说，有些不过是夸夸其谈的门外汉。让优秀的流程分析师同时管理 BPM 项目看似理想，但实际效果往往不佳。
• Process engineer: Process engineers use technology to implement the target state process modeled by process analysts. In the best cases, they do so in the workflow engine, which automates the process. You can call a programmer who programs the process logic in Java, C#, or another language a process engineer. The programmer’s major work takes place during the implementation stage of the BPM life cycle, though the process analyst may get the process engineer involved at other stages as well.
  流程工程师：流程工程师运用技术实现由流程分析师建模的目标流程。最佳情况下，他们通过工作流引擎实现流程自动化。用 Java、C#等语言编写流程逻辑的程序员也可称为流程工程师。程序员的主要工作集中在 BPM 生命周期的实施阶段，但流程分析师也可能在其他阶段引入流程工程师参与。
  

  

1.5 A method framework for BPMN
1.5 BPMN 方法论框架

1.5.1 The Camunda house
1.5.1 卡蒙达之家

• Strategic process model: The primary target group for strategic process models are process owners and process managers. A secondary group early in the project may include process participants and process analysts. We provide the strategic model as a general,
  战略流程模型：战略流程模型的主要目标群体是流程所有者和流程经理。项目早期可能包括流程参与者和流程分析师在内的次要群体。我们将战略模型作为一个通用的、结果导向的流程表示提供，因为我们希望为没有特殊 BPMN 知识的受众创造最快的理解。我们用几个步骤勾勒出流程，但不显示错误或变化。更多关于创建战略流程模型的详细信息，请参见第 3 章。
  results-oriented representation of the process because we want to create the quickest possible understanding for an audience that has no special BPMN knowledge. We sketch the process in a few steps, but we don’t show errors or variations. See chapter 3 for more detailed information on creating strategic process models.
  结果导向的流程表示，因为我们希望为不具备专业 BPMN 知识的受众提供最快速的理解。我们仅用少量步骤勾勒流程概貌，不展示错误或变体。关于创建战略流程模型的更多细节，请参阅第 3 章。
• Operational process model: At this level, we investigate operational details of the actual process. It may contain human or technical process flows, and we model them accordingly. A human flow is handled by a participant while a technical flow is handled by software - preferably a workflow engine. Of course, the human and technical flows can interact. A human may trigger a technical flow in the course of doing his or her work, as in the case of calling a software function. Equally, a technical flow may require a participant to send an email, assign a task, and so on. The human flow thus is triggered by the technical flow. We handle developing human and technical process flows in chapter 4 and chapter 6.
  操作流程模型：在这一层面，我们探究实际流程的操作细节。它可能包含人工或技术流程，我们会相应地进行建模。人工流程由参与者处理，而技术流程则由软件（最好是工作流引擎）处理。当然，人工流程与技术流程可以交互。例如，工作人员在执行工作时可能触发技术流程，如调用软件功能。同样，技术流程也可能要求参与者发送电子邮件、分配任务等。因此，人工流程由技术流程触发。我们将在第 4 章和第 6 章中探讨人工流程与技术流程的开发。
  The Camunda house is a purely methodological framework. In other words, it works independently of particular software tools, although certain tool functions may make it easier to apply. We deal with this in section 7.4.2 on page 204.
  Camunda 框架是一个纯粹的方法论框架。换句话说，它可以独立于特定的软件工具使用，尽管某些工具功能可能使其应用更为便捷。我们将在第 204 页的 7.4.2 节中对此进行详细讨论。
  About half of this book is a detailed description of this framework. Because those chapters offer so much practical information, we encourage you to read them even if you are unconvinced of our framework’s utility. If that’s the case, just think of our framework as a classification system for our advice on applying BPMN practically.
  本书约有一半篇幅是对该框架的详细阐述。由于这些章节提供了大量实用信息，我们鼓励您即使对该框架的实用性存疑也坚持阅读。若您确实如此，不妨将我们的框架视为一套分类体系，用以实际应用 BPMN 时参考我们的建议。
  Either way, we look forward to your comments and feedback, not just on this book, but also on the framework itself. By nature it’s not a perfect approach, and it is subject to constant change and development. With your help, perhaps we can make it better for everyone!
  无论哪种情况，我们都期待您的评论与反馈，不仅针对本书，更针对框架本身。本质上它并非完美方案，会持续经历变化与发展。在您的帮助下，或许我们能共同完善它，惠及更多人！

Tooling  工具支持

1.5.2 The great misunderstanding
1.5.2 重大误解

This is a confession. We declare ourselves guilty of spreading a deceptive image. The Camunda BPMN framework shown in figure 1.9 on the following page was used in a previous edition of this book. Released in German in 2009 and in English in 2012, it was a huge success. Hundreds of BPMN projects used the pyramid depiction of the framework for orientation. A large, international software vendor even included the pyramid in its marketing material. Unfortunately, it resulted in some misunderstandings.
这是一份坦白声明。我们承认自己传播了具有误导性的图示。本书前一版本中使用了图 1.9 展示的 Camunda BPMN 框架。该框架德文版于 2009 年发布，英文版于 2012 年问世，取得了巨大成功。数百个 BPMN 项目都参考了这个金字塔框架示意图进行定位。某大型跨国软件供应商甚至将其纳入了营销资料。遗憾的是，这导致了一些误解。

- 1.6 Domains, boundaries and the risk of BPMN monoliths
- 1.6 领域、边界与 BPMN 巨石应用的风险

The microservice architectural style is currently on the rise. For example, in a 2018 survey ([Cam18]) $63\mathrm{\%}$$63\mathrm{\%}$63%63 \% of participating companies had already adopted microservices architectures. The idea is that software is no longer built as large monolithic applications, but rather as a bunch of smaller microservices that focus on exactly one business capability each. Every services is owned by one team that cares about design, development, deployment, operations and maintenance. A microservice has a clear responsibility and API, and
微服务架构风格当前正日益流行。例如，在 2018 年的一项调查（[Cam18]）中，参与公司中已有 $63\mathrm{\%}$$63\mathrm{\%}$63%63 \% 采用了微服务架构。其核心理念是软件不再构建为庞大的单体应用，而是由多个专注于单一业务能力的小型微服务组成。每个服务由一个团队负责，涵盖设计、开发、部署、运维及维护全流程。微服务具有明确的职责和 API 接口，且
only these are known to the rest of the company Without implementation details. This is contrary to horizontal teams you see so often, like the business analysts, the software developers, the database admins and operation folks. Instead, you will have the “customer onboarding” team, that bundles all these roles and can act on its own.
公司内部其他部门仅知晓这些接口而非实现细节。这与常见的横向团队（如业务分析师、软件开发人员、数据库管理员和运维人员）形成鲜明对比。取而代之的是“客户注册”团队，这类团队整合了所有角色，能够独立运作。
Splitting up logic into microservices influences business processes and their models in BPMN. There are only rare cases where a business process will be handled completely by one microservice, instead you will see microservices that need to collaborate to implement end-to-end business processes.
将业务逻辑拆分为微服务会影响业务流程及其在 BPMN 中的建模。很少有业务流程会完全由一个微服务处理，相反，你会看到多个微服务需要协作以实现端到端的业务流程。
If you now think of the Camunda house, this means that several operational processes (in the respective microservices) interact to achieve the overall goal. If we wanted to drive the metaphor further, it would probably be a village consisting of different Camunda houses. The end-to-end process from the customers’ point of view would probably be the gate in the city wall and… But let’s drop that and look at a small example in figure 1.10.
如果你现在联想到 Camunda 房屋的比喻，这意味着多个操作流程（在各自的微服务中）相互作用以实现整体目标。如果我们进一步延伸这个比喻，它可能是一个由不同 Camunda 房屋组成的村庄。从客户角度来看，端到端流程可能是城墙的大门……不过让我们放下这个比喻，直接看图 1.10 中的小例子。

The challenge, by the way, is usually to determine the boundaries of the services and the exact responsibility of individual services. There is no right or wrong, only more or less suitable. In our example, there are different variants that can all make sense. For example, the policy microservice could send out documents itself to the customer, but that could also be part of the application microservice. However, there may also be a separate service for sending documents. It is important to make a conscious decision and then design the processes accordingly. For this topic we can recommend the literature around domaindriven design. And if you are in need of a distraction anyway, please take a look on the Internet and search for the “bounded context”.
顺便说一句，挑战通常在于确定服务的边界以及各个服务的具体职责。没有对错之分，只有适合与否。在我们的例子中，存在多种可能合理的变体。例如，保单微服务可以自行向客户发送文件，但这也可以是应用微服务的一部分。然而，也可能有一个专门用于发送文件的独立服务。重要的是做出有意识的决策，然后相应地设计流程。针对这一主题，我们可以推荐围绕领域驱动设计的文献。如果你需要转换一下注意力，不妨上网搜索一下“有界上下文”。
At this point we just want to explicitly warn against, as we call it, “BPMN monoliths”. A BPMN monolith is a process model that mixes details from different microservices, thus not respecting their responsibilities and boundaries. Such a model does not have a single person responsible for the process and is usually very cumbersome to coordinate because too many stakeholders want to participate. You cannot automate this model directly because it has to be distributed among different microservices.
在此，我们想明确警告一种我们称之为“BPMN 巨石”的现象。BPMN 巨石是指一个流程模型混杂了来自不同微服务的细节，从而未能尊重它们各自的职责与边界。这样的模型没有单一负责人，且由于过多利益相关方希望参与其中，通常协调起来极为繁琐。你无法直接自动化该模型，因为它需要分散到不同的微服务中实现。

User tasks  用户任务

- 6.4 Practical tips
- 6.4 实用技巧

6.4.1 Embedded and decentralized workflow engines
6.4.1 嵌入式与分布式工作流引擎

If you want to run your BPMN models on a workflow engine, the question immediately arises: how to run this engine? In the past, the image of the central workflow engine or BPM suite dominated. Various operational processes were operated on this central platform. The main advantage was that the platform only had to be operated once, so that fewer people had to be familiar with it and perhaps licensing costs could be saved.
若要在工作流引擎上运行 BPMN 模型，首要问题便是：如何部署该引擎？过去，中央工作流引擎或 BPM 套件的概念占据主导地位，各类业务流程均在这一中央平台上运行。其主要优势在于只需维护单一平台，从而减少人员培训需求，并可能节省许可成本。
However, this view does not fit into modern architectures around microservices. In section 1.6 on page 19 and section 4.5.3 on page 140, we talked about BPMN monoliths and showed that an operative business process also has to consider system boundaries.
然而这种架构理念已不适应现代微服务体系。在第 19 页 1.6 节及第 140 页 4.5.3 节中，我们探讨过 BPMN 单体架构，并指出实际业务流程设计必须考虑系统边界问题。
This also runs through the technical infrastructure, because one wants to grant the individual microservice teams as much autonomy as possible. A microservice is actually defined only by its responsibility and the API. The use of a workflow engine and the selection of the concrete product is an implementation detail that should be left to the team itself. Of course, autonomy in practice usually has its limits, since companies want to avoid a proliferation of technologies and often form competence centers for key technologies such as workflow engines.
这也贯穿于技术基础设施之中，因为人们希望赋予各个微服务团队尽可能多的自主权。微服务实际上仅由其职责和 API 定义。工作流引擎的使用及具体产品的选择属于实现细节，应当交由团队自行决定。当然，实践中自主权通常有其界限，因为企业希望避免技术泛滥，并常为工作流引擎等关键技术设立能力中心。
But nevertheless the workflow engine is logically part of a microservice as shown in figure 6.6. It is not a central infrastructure or a microservice in itself. This view becomes possible because lightweight workflow engines today, unlike complex BPM suites in the past, can be
但即便如此，如图 6.6 所示，工作流引擎在逻辑上仍是微服务的一部分。它既非中心化基础设施，本身也不是一个独立的微服务。这种视角之所以成立，是因为如今的轻量级工作流引擎与过去复杂的 BPM 套件不同，能够

6.4.2 The low-code trap
6.4.2 低代码陷阱

• High programming effort: Because software development is vendor specific, in-house developers need to learn and practice the vendor’s specific platform. The related expense is not a one-off but instead continuous, with retraining required to maintain knowledge. Existing knowledge (in Java, for example) cannot be applied. In addition, existing tools, techniques, and best practices of software development (unit testing, for example) can be applied partially or not at all. This severely limits the developers’ productivity, and as a result, technical implementation is much more complex than it at first appears.
  高昂的编程成本：由于软件开发是厂商特定的，内部开发人员需要学习并实践该厂商的特定平台。相关支出并非一次性投入，而是持续性的，需要不断进行再培训以保持知识更新。现有知识（例如 Java）无法直接应用。此外，现有的软件开发工具、技术和最佳实践（例如单元测试）只能部分应用或完全无法应用。这严重限制了开发人员的工作效率，导致技术实现远比最初看起来复杂得多。
• Inability to model distinctive parts of a process: Because the development approach is model-driven, the possibilities for technical implementation are limited. Compare this to a painter: On a blank canvas, an artist can paint a picture exactly the way she imagines. Another artist paints by numbers. He can create stunning images, but only by daubing predetermined colors onto predetermined places. This second artist can create only what was predesigned.
  无法建模流程的独特部分：由于采用模型驱动的开发方法，技术实现的可能性受到限制。可以类比画家：在空白画布上，艺术家能完全按照自己的想象作画。而另一位画家则按数字填色，虽然也能创作出惊艳的作品，但仅限于在预设区域涂抹预设颜色。后者只能复现预先设计好的内容。
  Painting by numbers in BPM suites is like using off-the-shelf application software. Often it is sufficiently flexible for standard support processes (vacation requests, for example, or invoicing), but the limited possibilities for technical implementation remain insufficient for capturing and implementing core business processes.
  在 BPM 套件中按数字填色，就如同使用现成的应用软件。对于标准化支持流程（如休假申请或开具发票），通常具备足够的灵活性，但技术实现的局限性仍无法满足核心业务流程的捕捉与实施需求。
• Inability to integrate into existing IT: On an operational level, the drawbacks of off-the-shelf applications also apply to traditional BPM suites: they cannot be incorporated easily into existing IT structures.
  无法与现有 IT 系统集成：在操作层面，传统 BPM 套件同样存在现成应用的缺陷——难以无缝融入现有 IT 架构。
• Specialized developers needed: As we mentioned, a model-driven development approach is inevitably vendor specific, so there’s no escaping the fact that you will need developers trained in a particular BPM suite. Such developers are scarce, and if they are not available, it is much easier to find developers for popular programming languages such as Java.
  需要专业开发人员：正如我们提到的，模型驱动开发方法不可避免地依赖于特定供应商，因此无法回避一个事实——您将需要受过特定 BPM 套件培训的开发人员。这类开发人员稀缺，如果无法找到他们，招聘掌握 Java 等流行编程语言的开发人员会容易得多。
• Vendor lock-in: Consequently, there is a strong vendor dependency as the vendor and its partners are usually the only ones with developers with the required level of expertise. This is acceptable in the context of support processes (invoicing, vacation requests, and so on), but it represents unacceptable risk when capturing and implementing core business processes.
  供应商锁定：因此存在强烈的供应商依赖性，因为通常只有该供应商及其合作伙伴拥有具备所需专业水平的开发人员。这对于支持性流程（如发票处理、休假申请等）尚可接受，但在捕获和实现核心业务流程时，这种依赖性意味着不可接受的风险。
  To us, it seems that traditional BPM suites are . . . stuck in the middle . . . neither fish nor fowl. They are as unsuitable, compared to existing software development, as off-the-shelf application products, and they don’t even offer an out-of-the-box solution for process automation. This dilemma has resulted from an unsuccessful search for compromise between the two extremes and also, to a large extent, to a more academic flow during the last decade: model-driven software development. The modest growth of BPM suite vendors during the same decade seems to confirm our assessment.
  在我们看来，传统的 BPM 套件似乎……卡在中间……不伦不类。与现有软件开发相比，它们如同现成的应用产品一样不适用，甚至无法为流程自动化提供开箱即用的解决方案。这一困境源于对两个极端之间妥协的失败尝试，也在很大程度上源于过去十年中更为学术化的潮流：模型驱动软件开发。同期 BPM 套件供应商的缓慢增长似乎印证了我们的评估。
  Does this mean that using BPM software for process automation is a bad idea? Of course not, but it does mean that the right approach is not as simple as we might wish. In practice, it is a hybrid approach that proves best, where certain parts - the process itself -are model-driven while other parts -complex user interfaces for instance -are developed through classic programming. You therefore have to accept that software development will require software developers in the future. Sounds fairly logical, doesn’t it?
  这是否意味着使用 BPM 软件进行流程自动化是个坏主意？当然不是，但这确实意味着正确的方法并不像我们希望的那么简单。实际上，实践证明最佳方案是混合方法——流程本身等部分采用模型驱动，而其他部分（例如复杂的用户界面）则通过经典编程开发。因此你必须接受一个事实：未来软件开发仍需要软件开发者。听起来相当合理，不是吗？
  In section 7.4.3 on page 204, we present the Camunda BPM platform as an example that supports the hybrid approach and is available as an open source project.
  在第 204 页的 7.4.3 节中，我们以支持混合方法并作为开源项目提供的 Camunda BPM 平台为例进行介绍。

6.4.3 The myth of engine interchangeability
6.4.3 引擎可互换性的迷思

6.4.4 Modeling or programming
6.4.4 建模还是编程

• Technology and architecture: Depending on the workflow engine and the overall architecture to be used, it can be either simple or difficult to execute certain requirements within a process. Some engines, for example, make it possible directly to integrate Java code, connectors, or script language. Others restrict the possibilities to web services.
  技术与架构：根据所使用的工作流引擎及整体架构的不同，执行流程中的某些需求可能简单或困难。例如，某些引擎允许直接集成 Java 代码、连接器或脚本语言，而其他引擎则限制为仅能使用 Web 服务。
• Existing infrastructure: Few projects start from scratch. Existing systems and services should be reused or integrated. Processes can be triggered using an existing scheduler, for example, and not the workflow engine itself. These peripheral conditions need to be taken into account.
  现有基础设施：很少有项目是从零开始的。应重用或整合现有系统和服务。例如，流程可以通过现有调度器而非工作流引擎本身触发。这些周边条件需要被纳入考量。
• Roles within the project: It is important to account for existing roles and know-how within the project. Often, there are developers involved who can implement certain functionalities quickly with classical programming but who will need a long time to do so with the workflow engine. On the other hand, there are also projects involving trained process engineers, and they work better with process models than with programming languages.
  项目中的角色：必须考虑项目中现有的角色和专业知识。通常会有开发人员参与，他们能用传统编程快速实现某些功能，但使用工作流引擎则耗时较长。另一方面，也有项目配备经过培训的流程工程师，他们更擅长处理流程模型而非编程语言。
  We often see that once a workflow engine has been procured, there is impetus to use it come hell or high water, and process models quickly follow that are so detailed that you can’t see the forest for all the trees. These models do not help when communicating with the business, and they are no easier to maintain than classical programming code. Besides, the IT department will hate the more detailed models, and that’s no good to anyone. Success is all about finding the right granularity. Modeled processes are a piece of the puzzle, but they are only one piece.
  我们常常看到，一旦采购了工作流引擎，就会不顾一切地推动其使用，随之而来的流程模型往往过于详细，以至于只见树木不见森林。这些模型在与业务部门沟通时毫无帮助，维护起来也不比传统编程代码轻松。此外，IT 部门会厌恶这些过于细致的模型，这对任何人都没有好处。成功的关键在于找到合适的颗粒度。建模的流程只是拼图的一部分，而非全部。
  

  

Figure 6.7 shows an example of going too far. The model shows a customer status inquiry explicitly. At the moment, it doesn’t matter if we’re modeling this process with a signal
图 6.7 展示了一个过度建模的例子。该模型明确展示了客户状态查询的环节。目前，我们是否用信号事件来建模这个流程并不重要。

Hint: Business-IT-alignment
提示：业务与 IT 对齐

6.4.5 Overcoming technical challenges
6.4.5 克服技术挑战

Data in the process
流程中的数据

• The data is always up-to-date and there is no risk of divergence.
  数据始终保持最新，不存在分歧风险。
• You do not need to store data redundantly in the process where it may persist in different versions -meaning multiple times.
  您无需在流程中冗余存储可能以不同版本（即多次）持久化的数据。
  Exceptions confirm the rule, however, and our experience shows that there are times to keep data in the process:
  然而例外恰恰印证了规则的存在，根据我们的经验，确实存在需要在流程中保留数据的情况：
• The preceding system is too slow. Constant loading leads to a performance issue. In this case, you could use a cache, or you could abuse the engine as a cache.
  前置系统响应过慢。频繁加载导致性能问题。此时可采用缓存方案，或退而求其次将流程引擎充当缓存使用。
• You want to keep a copy of the data as it existed at a particular moment in the process and to use it for the duration of the process run.
  您希望在流程运行的整个期间保留数据在某一特定时刻的状态副本并使用它。
• Your BPM platform does not make it possible to load data in the background. If this means you have to model a service task over and over just to load the order, your model quickly will become unreadable. As we said, it’s about finding the right balance between graphical modeling and programming behind the scene.
  您的 BPM 平台不支持在后台加载数据。如果这意味着您不得不反复建模服务任务仅为了加载订单，您的模型很快就会变得难以阅读。正如我们所说，关键在于找到图形化建模与幕后编程之间的适当平衡。
• You only store data needed for controlling the process flow, for example, decisions in user tasks not available from other systems.
  您仅存储用于控制流程流向所需的数据，例如用户任务中无法从其他系统获取的决策信息。
• Often it may be desirable to store messages in an as transmitted form. This can make it easier to repeat service calls or to identify errors.
  通常，以原始传输形式存储消息可能是可取的。这可以更容易地重复服务调用或识别错误。

Being ready-to-receive to receive events
处于准备接收事件的状态

From an automation point of view, intermediate events deserve a closer look. First, consider the semantics of the ready-to-receive state we mentioned in section 2.6 on page 43 . Remember that, strictly speaking, incoming events are lost if no process instance is ready
从自动化角度来看，中间事件值得深入研究。首先，考虑我们在第 2.6 节第 43 页提到的“准备接收”状态的语义。严格来说，如果没有流程实例处于准备接收状态，传入的事件将会丢失。

Testing processes  测试流程

6.4.6 Acceptance criteria when introducing a BPM platform
6.4.6 引入 BPM 平台时的验收标准

• The relevance of business-IT alignment through a suitable methodology as suggested in this book.
  本书所建议的通过合适方法论实现业务与 IT 对齐的重要性。
• The roundtrip, so that all stakeholders understand the executed models that represent the truth.
  确保所有利益相关者理解代表实际情况的执行模型的往返过程。
• The right granularity of models, so that they contain only business-motivated issues.
  模型的适当粒度，使其仅包含业务驱动的问题。

The approach taken when introducing a BPM platform also is important, in particular the choice of tool and the first steps undertaken with the platform. In our experience with projects, the approach shown in figure 6.10 has proved itself.
引入 BPM 平台时采取的方法同样重要，尤其是工具的选择和平台初期实施步骤。根据我们的项目经验，图 6.10 所示的方法已被验证有效。

• Relevant, preferably close to the core processes of the business.
  相关性高，最好贴近业务核心流程。
• Not too small, otherwise it will seem too easy, and it will make it difficult to show off the project as a BPM success story.
  规模不宜过小，否则会显得过于简单，难以作为 BPM 成功案例展示。
• Not too big, or you risk taking too long to deliver results.
  规模不宜过大，否则可能耗时过长才能交付成果。
• Not a political minefield. Unfortunately, this often is the case with business processes.
  并非政治雷区。不幸的是，业务流程往往如此。
• Suitable for displaying the advantages of BPM. Remember that the first project will be used to decide on how to proceed.
  适合展示 BPM 的优势。请记住，首个项目将用于决定后续推进方式。
• Not too demanding on organizational change. Suggesting too much change only generates resistance that can be overcome only with a lot of willpower and endurance. It isn’t helpful to expect much change while also introducing a new technological platform. On the other hand, organizational change cannot be completely avoided - and a desire for change is usually what triggers the introduction of the BPM platform in the first place.
  对组织变革要求不宜过高。建议过多变革只会引发阻力，需极大意志力与耐力才能克服。在引入新技术平台时期望大幅变革并无助益。另一方面，组织变革无法完全避免——而寻求变革的意愿通常正是引入 BPM 平台的初衷。
  In the context of that final point, by the way, it may be a good idea to keep an existing task list and to enter tasks for the new BPM platform into it. This implies that end users (process participants) do not need to use either a new interface nor two different task lists. If you are replacing an existing workflow management tool, the change could be transparent to end users.
  顺带一提，针对最后一点，保留现有任务列表并将新 BPM 平台任务录入其中或许是明智之举。这意味着终端用户（流程参与者）既无需使用新界面，也无需操作两个不同任务列表。若正在替换现有工作流管理工具，终端用户可能完全感知不到变更。