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
4th edition 第 4 版
Real-Life BPMN 实战 BPMN
4th edition 第四版
Using BPMN and DMN to analyze, improve, and automate processes in your company 运用 BPMN 与 DMN 分析、优化并自动化企业流程
Jakob Freund, Bernd Rücker 雅各布·弗洛伊德,伯恩德·吕克尔Founders of Camunda Camunda 创始人www.camunda.com
This fourth edition in English is based on the successful sixth German edition. 英文第四版基于成功的德文第六版编写。
Also available in Spanish. 另有西班牙语版本可供选择。
Editing for the English-language edition of this book was provided by James Venis of Lakewood, Colorado, USA, with assistance from Kristen Hannum (1st edition), Jalynn Venis (2nd edition) and James Simmonds (3rd edition). 本书英文版的编辑工作由美国科罗拉多州莱克伍德的詹姆斯·维尼斯负责,并得到克里斯汀·汉纳姆(第一版)、贾琳·维尼斯(第二版)和詹姆斯·西蒙兹(第三版)的协助。 www.jvenis.net
Preface … XI 前言 … XI
1 Introduction … 1 1 引言 … 1
1.1 Business process management … 1 1.1 业务流程管理 … 1
1.1.1 Definition … 1 1.1.1 定义…1
1.1.2 BPM in practice … 2 1.1.2 实践中的业务流程管理…2
1.1.3 Camunda BPM life cycle … 2 1.1.3 Camunda BPM 生命周期…2
1.1.4 Process automation … 5 1.1.4 流程自动化…5
1.2 The BPM standards … 6 1.2 BPM 标准概述…6
1.2.1 Workflows with BPMN … 6 1.2.1 使用 BPMN 的工作流…6
1.2.2 DMN for rule-based decisions … 7 1.2.2 基于规则的决策与 DMN…7
1.2.3 Structured vs. unstructured workflows … 8 1.2.3 结构化与非结构化工作流对比…8
1.3 First example … 10 1.3 第一个示例…10
1.4 Can BPMN bridge the gap? … 13 1.4 BPMN 能否弥合差距?…13
1.4.1 The dilemma … 13 1.4.1 困境…13
1.4.2 The customers of a process model … 14 1.4.2 流程模型的客户…14
1.5 A method framework for BPMN … 16 1.5 BPMN 的方法框架… 16
1.5.1 The Camunda house … 16 1.5.1 Camunda 之家… 16
1.5.2 The great misunderstanding … 17 1.5.2 重大误解… 17
1.6 Domains, boundaries and the risk of BPMN monoliths … 19 1.6 领域、边界与 BPMN 巨石应用的风险… 19
2 The notation in detail. … 23 2 符号详解… 23
2.1 Understanding BPMN … 23 2.1 理解 BPMN… 23
2.1.1 Things BPMN does not do … 23 2.1.1 BPMN 不涉及的内容… 23
2.1.2 A map: The basic elements of BPMN … 24 2.1.2 一张地图:BPMN 的基本元素… 24
2.1.3 Perspectives in process analysis … 25 2.1.3 流程分析中的视角… 25
2.1.4 Models, instances, tokens, and correlations. … 26 2.1.4 模型、实例、令牌与关联… 26
2.1.5 Symbols and attributes … 26 2.1.5 符号与属性… 26
2.2 Simple tasks and none events … 27 2.2 简单任务与无事件… 27
2.3 Design process paths with gateways … 28 2.3 使用网关设计流程路径 … 28
2.3.1 Data-based exclusive gateway … 28 2.3.1 基于数据的排他网关 … 28
2.3.2 Parallel gateway … 30 2.3.2 并行网关 … 30
2.3.3 Data-based inclusive gateway … 33 2.3.3 基于数据的包容网关 … 33
2.3.4 Default flow and getting stuck … 36 2.3.4 默认流与流程停滞… 36
2.3.5 Complex gateway … 36 2.3.5 复杂网关… 36
2.4 Design process paths without gateways … 38 2.4 无需网关的流程路径设计… 38
2.5 Lanes … 40 2.5 泳道… 40
2.6 Events … 43 2.6 事件…43
2.6.1 Relevance in BPMN … 43 2.6.1 BPMN 中的重要性…43
2.6.2 Message events … 47 2.6.2 消息事件…47
2.6.3 Timer events … 49 2.6.3 定时器事件…49
2.6.4 Error events … 51 2.6.4 错误事件…51
2.6.5 Conditional … 51 2.6.5 条件事件…51
2.6.6 Signal events … 52 2.6.6 信号事件…52
2.6.7 Terminate events … 53 2.6.7 终止事件…53
2.6.8 Link events … 54 2.6.8 链接事件 … 54
2.6.9 Compensation events … 54 2.6.9 补偿事件 … 54
2.6.10 Multiple events … 56 2.6.10 多重事件 … 56
2.6.11 Parallel events … 57 2.6.11 并行事件 … 57
2.6.12 Escalation events … 58 2.6.12 升级事件…58
2.6.13 Cancel events … 58 2.6.13 取消事件…58
2.6.14 Event-based gateway … 58 2.6.14 基于事件的网关…58
2.6.15 Event-based parallel gateway … 61 2.6.15 基于事件的并行网关…61
2.7 Special tasks … 61 2.7 特殊任务…61
2.7.1 Typification … 61 2.7.1 类型化…61
2.7.2 Markers … 63 2.7.2 标记…63
2.7.3 Global tasks and call activity … 66 2.7.3 全局任务与调用活动…66
2.8 Subprocesses … 66 2.8 子流程 … 66
2.8.1 Encapsulate complexity … 66 2.8.1 封装复杂性 … 66
2.8.2 Modularization and reuse … 69 2.8.2 模块化与复用 … 69
2.8.3 Attached events … 71 2.8.3 附加事件 … 71
2.8.4 Markers … 73 2.8.4 标记…73
2.8.5 Transactions … 74 2.8.5 事务…74
2.8.6 Event subprocesses … 75 2.8.6 事件子流程…75
2.9 Pools and message flows … 78 2.9 池与消息流…78
2.9.1 The conductor and the orchestra … 78 2.9.1 指挥与乐团…78
2.9.2 Rules for application … 80 2.9.2 应用规则…80
2.9.3 The art of collaboration … 81 2.9.3 协作的艺术…81
2.9.4 Collapse pools … 83 2.9.4 合并池…83
2.9.5 Multiple instance pools … 84 2.9.5 多实例池…84
2.10 Data … 85 2.10 数据…85
2.11 Artifacts … 87 2.11 工件…87
2.11.1 Annotations and groups … 87 2.11.1 注释与分组…87
2.11.2 Custom artifacts … 88 2.11.2 自定义工件… 88
2.12 Comparison with other notations … 88 2.12 与其他符号表示法的比较… 88
2.12.1 Extended event-driven process chain (eEPC) … 89 2.12.1 扩展的事件驱动过程链(eEPC)… 89
2.12.2 UML activity diagram … 89 2.12.2 UML 活动图… 89
2.12.3 ibo sequence plan … 91 2.12.3 IBO 序列计划… 91
2.12.4 Key figures and probabilities … 91 2.12.4 关键指标与概率… 91
2.13 Choreographies and conversations … 94 2.13 编排与会话… 94
3 Strategic process models … 97 3 战略流程模型… 97
3.1 About this chapter … 97 3.1 关于本章节 … 97
3.1.1 Purpose and benefit … 97 3.1.1 目的与益处 … 97
3.1.2 Model requirements … 98 3.1.2 模型要求 … 98
3.1.3 Procedure … 99 3.1.3 流程 … 99
3.2 Case example: Recruiting process … 101 3.2 案例示例:招聘流程…101
3.3 Restricting the symbol set … 102 3.3 符号集限制…102
3.3.1 Pools and lanes … 102 3.3.1 池与泳道…102
3.3.2 Tasks and subprocesses … 105 3.3.2 任务与子流程…105
3.3.3 Gateways … 106 3.3.3 网关… 106
3.3.4 Events and event-based gateway … 106 3.3.4 事件与基于事件的网关… 106
3.3.5 Data and artifacts … 109 3.3.5 数据与工件… 109
3.3.6 Custom artifacts … 110 3.3.6 自定义工件… 110
3.3.7 Hide and reveal symbols … 111 3.3.7 隐藏与显示符号 … 111
3.4 Process analysis on the strategic level … 112 3.4 战略层面的流程分析 … 112
3.5 Conversations and choreographies … 114 3.5 会话与编排 … 114
4 Operational process models … 117 4 操作流程模型 … 117
4.1 About this chapter … 117 4.1 本章简介… 117
4.1.1 Purpose and benefit … 117 4.1.1 目的与益处… 117
4.1.2 Model requirements … 118 4.1.2 模型要求… 118
4.1.3 Procedure … 118 4.1.3 流程步骤… 118
4.2 From the strategic level to the operational level … 120 4.2 从战略层面到操作层面… 120
4.3 Processes of the participants … 122 4.3 参与者的流程… 122
4.4 Preparing for process automation … 125 4.4 为流程自动化做准备… 125
4.4.1 Designing for support by a workflow engine … 125 4.4.1 设计以支持工作流引擎… 125
4.4.2 Required processes of the workflow engine … 127 4.4.2 工作流引擎的必要流程…127
4.4.3 Further requirements … 129 4.4.3 其他需求…129
4.4.4 Technical implementation beyond the workflow engine … 130 4.4.4 工作流引擎之外的技术实现…130
4.4.5 Technical implementation without workflow engine … 132 4.4.5 无工作流引擎的技术实现…132
4.5 Hands-on tips for the operational level … 134 4.5 操作层面的实用技巧… 134
4.5.1 From the happy path to the bitter truth … 134 4.5.1 从理想路径到残酷现实… 134
4.5.2 The true benefit of subprocesses … 139 4.5.2 子流程的真正价值… 139
4.5.3 Slice processes according to your domain boundaries … 140 4.5.3 根据领域边界划分流程… 140
4.5.4 The limits of formalization … 141 4.5.4 形式化的局限性…141
4.5.5 Flexibility in BPMN models … 142 4.5.5 BPMN 模型的灵活性…142
4.5.6 Taking business decisions out of processes … 144 4.5.6 将业务决策从流程中剥离…144
5 DMN - Introduction and overview. … 149 5 DMN - 简介与概述…149
5.1 Understanding DMN … 149 5.1 理解 DMN…149
5.2 Notation elements … 151 5.2 符号元素…151
5.2.1 Decision tables … 151 5.2.1 决策表…151
5.2.2 Expressions in decision tables … 153 5.2.2 决策表中的表达式…153
5.2.3 Hit policy … 156 5.2.3 命中策略…156
5.2.4 Advanced FEEL … 159 5.2.4 高级 FEEL 表达式…159
5.2.5 Decision requirements … 162 5.2.5 决策需求…162
5.3 Practical tips … 163 5.3 实用技巧…163
5.3.1 Linking BPMN and DMN … 163 5.3.1 链接 BPMN 与 DMN … 163
5.3.2 Decisions with a decision flow … 164 5.3.2 决策流中的决策 … 164
5.3.3 The life cycle of decisions … 167 5.3.3 决策的生命周期 … 167
6 Workflow Automation … 169 6 工作流自动化 … 169
6.1 Purpose and benefit … 169 6.1 目的与益处 … 169
6.2 Basics … 170 6.2 基础知识 … 170
6.2.1 Model execution with workflow and decision engines … 170 6.2.1 使用工作流和决策引擎执行模型 … 170
6.2.2 Executing the BPMN and DMN standards … 172 6.2.2 执行 BPMN 与 DMN 标准 … 172
6.2.3 Alternative automation languages … 172 6.2.3 替代自动化语言… 172
6.2.4 When is it worth using a workflow engine? … 173 6.2.4 何时值得使用工作流引擎?… 173
6.2.5 When is it worth using a decision engine? … 174 6.2.5 何时值得使用决策引擎?… 174
6.2.6 Workflow and decision engines in interaction … 175 6.2.6 工作流与决策引擎的交互… 175
6.3 Automating technical process flows … 176 6.3 技术流程自动化… 176
6.3.1 Model requirements … 176 6.3.1 模型需求… 176
6.3.2 Procedure … 177 6.3.2 操作步骤… 177
6.3.3 The executable process model … 178 6.3.3 可执行流程模型… 178
6.4 Practical tips … 180 6.4 实用技巧 … 180
6.4.1 Embedded and decentralized workflow engines … 180 6.4.1 嵌入式与分布式工作流引擎 … 180
6.4.2 The low-code trap … 181 6.4.2 低代码陷阱 … 181
6.4.3 The myth of engine interchangeability … 183 6.4.3 引擎可互换性的迷思 … 183
6.4.4 Modeling or programming … 184 6.4.4 建模还是编程… 184
6.4.5 Overcoming technical challenges … 185 6.4.5 克服技术挑战… 185
6.4.6 Acceptance criteria when introducing a BPM platform … 187 6.4.6 引入 BPM 平台时的验收标准… 187
7 Introducing BPMN on a broad base … 191 7 广泛引入 BPMN… 191
7.1 Goals … 191 7.1 目标… 191
7.2 Roles … 193 7.2 角色… 193
7.2.1 Of gurus, followers, and unbelievers … 193 7.2.1 大师、追随者与怀疑者… 193
7.2.2 Anchoring in the organization … 194 7.2.2 在组织中的锚定… 194
7.2.3 Training of BPMN gurus … 195 7.2.3 BPMN 专家培训… 195
7.3 Methods … 196 7.3 方法论… 196
7.3.1 Range of symbols. … 197 7.3.1 符号范围… 197
7.3.2 Naming conventions … 198 7.3.2 命名规范… 198
7.3.3 Layout … 199 7.3.3 布局…199
7.3.4 Modeling alternatives … 199 7.3.4 建模替代方案…199
7.3.5 Design patterns. … 200 7.3.5 设计模式…200
7.4 Tools … 202 7.4 工具…202
7.4.1 Definition of your own BPM stack … 202 7.4.1 自定义 BPM 技术栈的定义… 202
7.4.2 The BPMN modeling tool … 204 7.4.2 BPMN 建模工具… 204
7.4.3 Camunda BPM: An open source BPM platform … 204 7.4.3 Camunda BPM:开源 BPM 平台… 204
7.4.4 It can’t always be software … 205 7.4.4 并非总能依赖软件… 205
7.5 Meta-processes … 208 7.5 元流程…208
8 Tips to get started … 211 8 入门技巧…211
8.1 Develop your own style … 211 8.1 形成个人风格…211
8.2 Find fellow sufferers … 212 8.2 寻找同行者…212
8.3 Get started … 212 8.3 开始使用… 212
Bibliography … 213 参考文献… 213
Introduction 引言
1.1 Business process management 1.1 业务流程管理
This book is about Business Process Model and Notation (BPMN 2.0). To understand why BPMN was invented, it is helpful to gain some understanding of business process management (BPM). 本书主要探讨业务流程模型与标记法(BPMN 2.0)。要理解 BPMN 诞生的缘由,需先对业务流程管理(BPM)有所了解。
1.1.1 Definition 1.1.1 定义
Experts use different definitions for business process management. We use the definition given by the European Association of BPM (EABPM) in its reference work, BPM Common Body of Knowledge [Eur09]: 专家们对业务流程管理的定义各有不同。我们采用欧洲业务流程管理协会(EABPM)在其参考著作《BPM 通用知识体系》[Eur09]中给出的定义:
Business process management (BPM) is a systemic approach for capturing, designing, executing, documenting, measuring, monitoring, and controlling both automated and non-automated processes to meet the objectives and business strategies of a company. BPM embraces the conscious, comprehensive, and increasingly technology-enabled definition, improvement, innovation, and maintenance of end-to-end processes. Through this systemic and conscious management of processes, companies achieve better results faster and more flexibly. 业务流程管理(BPM)是一种系统性方法,用于捕捉、设计、执行、记录、测量、监控并控制自动化和非自动化流程,以实现企业目标与商业战略。BPM 涵盖对端到端流程有意识、全面且日益技术驱动的定义、改进、创新和维护。通过这种系统且有意识的管理,企业能够更快、更灵活地取得更优成果。
Through BPM, processes can be aligned with the business strategy, and so help to improve company performance as a whole thanks to the optimization of processes within business divisions or even beyond company borders. 通过业务流程管理(BPM),流程可以与业务战略保持一致,从而通过优化业务部门内部甚至跨公司边界的流程,全面提升公司绩效。
What end-to-end process really means is from start to finish. The goal is to understand and thus to assess and improve an entire process -not just its components. We find the EABPM’s definition helpful because it treats automated and non-automated processes as both equally important and equally subject to the power of BPM. This understanding is essential to applying BPM successfully because it is rarely sufficient to improve only organizational procedures or the supporting technologies; most often we must improve both the procedures and the technology cooperatively. 端到端流程的真正含义是从头到尾。其目标是理解并进而评估和改进整个流程——而不仅仅是其组成部分。我们发现 EABPM 的定义很有帮助,因为它将自动化流程和非自动化流程视为同等重要,并同样受到 BPM 力量的影响。这种理解对于成功应用 BPM 至关重要,因为仅改进组织程序或支持技术往往是不够的;大多数情况下,我们必须协同改进程序和技术。
1.1.2 BPM in practice 1.1.2 实践中的业务流程管理
As consultants who specialize in BPM, our new projects almost always involve one of the following three scenarios: 作为专注于业务流程管理(BPM)的顾问,我们的新项目几乎总是涉及以下三种情况之一:
The client wants to improve a process using Information Technology (IT). 客户希望利用信息技术(IT)改进流程。
The client wants current processes documented. 客户希望现有流程得到文档记录。
The client wants to introduce entirely new processes. 客户希望引入全新的流程。
A vast majority of the time, we encounter the first scenario: the client seeks to improve a process with IT. The motivation often is a desire to improve efficiency, for example, to use software to eliminate manual keying or re-keying of data. A client may want to implement IT-based monitoring and analysis of routine processes based on key performance indicators (KPIs). 绝大多数情况下,我们遇到的是第一种场景:客户希望通过 IT 优化流程。其动机通常源于提升效率的需求,例如利用软件消除人工录入或重复输入数据。客户可能还希望基于关键绩效指标(KPI)对常规流程实施 IT 监控与分析。
The second scenario, documenting processes, usually comes about because the client needs the documentation to guide the work of the people involved. Another rationale is that the documentation is mandated by regulation or required to obtain certification such as ISO 9000. 第二种场景,即流程文档化,通常源于客户需要这些文档来指导相关人员的工作。另一个原因是文档化是法规要求或获取如 ISO 9000 等认证的必要条件。
The third scenario happens least often. We find that when companies want to introduce entirely new processes, it is usually because they are being forced to adapt to changed market conditions, develop new channels of distribution, or introduce new products. 第三种场景最为少见。我们发现,当企业希望引入全新流程时,通常是因为它们被迫适应市场环境变化、开发新的分销渠道或推出新产品。
In public announcements companies may speak in generalities: they have an interest in exploring BPM or they want to increase their process orientation. In practice, especially in large organizations, the argument for BPM is usually well-defined and specific, but it can take two forms: 在公开声明中,企业可能泛泛而谈:它们对探索业务流程管理(BPM)感兴趣,或希望提升流程导向性。但在实践中,尤其是大型组织里,采用 BPM 的理由通常具体而明确,且可能呈现两种形式:
There is an acute reason for using BPM. The project concerns essential processes that need to be created, improved, or documented. 存在使用 BPM 的迫切需求。该项目涉及需要创建、改进或记录的核心流程。
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 流程模型似乎总是要么过于简单,要么过于复杂。过于简单的模型仅包含最显而易见的元素,可能只适用于营销演示,别无他用;而过于复杂的模型则往往...
FIGURE 1.1 The Camunda BPM life cycle. 图 1.1 Camunda BPM 生命周期。
hard at anticipating every contingency that they trap the user like a fly in amber. They are unrealistically rigid. Still, without a model, we wouldn’t have our map to orient ourselves. 过于执着于预见所有意外情况,以至于像琥珀中的苍蝇般困住用户。它们不切实际地僵化。然而,若没有模型,我们将失去自我定位的地图。
After examining the simple BPM life cycle, which is the most well-established BPM procedure model, we refined it according to our experience. We wanted to create a relatively lightweight model without too many restrictions. We thought this would be more practical than the brightly colored marketing materials we see so often at conferences and in meetings. We call ours the Camunda BPM life cycle. See it in figure 1.1. 在研究了最成熟的 BPM 流程模型——简单 BPM 生命周期后,我们根据自身经验对其进行了优化。我们希望创建一个相对轻量级且限制较少的模型,认为这比在会议和研讨会上常见的那些色彩鲜艳的市场宣传材料更为实用。我们将其称为 Camunda BPM 生命周期,具体如图 1.1 所示。
We intend the Camunda BPM life cycle to describe one process at a time. Any process can run through the life cycle independently of any other process, and the process can be at a different stage each time it repeats. The cycle triggers when one of the following situations arises: 我们设计的 Camunda BPM 生命周期旨在一次描述一个流程。任何流程都可以独立于其他流程运行此生命周期,且每次循环时流程可能处于不同阶段。当以下任一情况出现时,该周期即被触发:
An existing process is to be documented or improved. 需要记录或改进现有流程。
A new process is to be introduced. 需要引入新流程。
We have to start by examining an existing process. The process discovery clearly differentiates the subject process from other processes both upstream and downstream. The discovery reveals the output generated by the subject process as well as the importance of that output for the client. We use e.g. workshops or one-on-one interviews to identify not only what needs to be accomplished, but also who needs to be involved, and which IT systems. 我们首先需要审视现有流程。流程发现阶段能清晰区分目标流程与其上下游其他流程,同时揭示该流程产生的输出及其对客户的重要性。我们通过研讨会或一对一访谈等方式,不仅明确需要完成的任务,还确定需参与的人员及相关 IT 系统。
We document the findings from the process discovery in a current state process model. This process documentation may include many different charts and descriptions; it usually has multiple flow charts. A systematic examination of the current state process clearly identifies weak points and their causes. 我们将流程发现阶段的成果记录在当前状态流程模型中。这类流程文档可能包含多种图表和说明,通常会有多张流程图。对当前流程的系统性审查能准确识别薄弱环节及其成因。
We conduct process analysis either because first-time documentation or continuous process control has revealed a weakness of a process that cannot be remedied easily. 开展流程分析的原因可能是:首次文档化时发现流程存在难以轻易修复的缺陷,或是持续流程监控中暴露出类似问题。
The causes of weak points identified by a process analysis become the starting point for another process design. If necessary, different process designs can be evaluated by means of 流程分析所识别的薄弱环节成因将成为新一轮流程设计的起点。必要时可通过多种方式评估不同的流程设计方案。
the process simulation. We also conduct a process design when introducing a new process. The result in either case is a target state process model. 流程模拟。在引入新流程时,我们也会进行流程设计。无论哪种情况,结果都是一个目标状态的流程模型。
In reality, we normally want to implement the target state process model as a change in business or organizational procedures as well as an IT project. Change management, especially process communication, plays a decisive role in successful organizational change. For the IT implementation, the process can be automated or software can be developed, adapted, or procured. The result of the process implementation is a current state process corresponding to the target state process model that, conveniently, has already been documented. 实际上,我们通常希望将目标状态的流程模型作为业务或组织程序的变更以及 IT 项目来实施。变革管理,尤其是流程沟通,在成功的组织变革中起着决定性作用。对于 IT 实施,流程可以自动化,也可以开发、调整或采购软件。流程实施的结果是一个与目标状态流程模型相对应的当前状态流程,幸运的是,该模型已经被记录在案。
In most cases, we find all the stages from process discovery to process implementation to be necessary. Because process monitoring takes place continuously, however, it reveals more about the ongoing operation of the process. 在大多数情况下,我们发现从流程发现到流程实施的所有阶段都是必要的。然而,由于流程监控是持续进行的,因此它更多地揭示了流程的持续运行情况。
The most important tasks of process control are the continuous monitoring of individual process instances and the analysis of key data so that weak points can be recognized as quickly as possible. Problems with individual entities require direct remedies, and so do structural problems if that’s possible. If necessary, the current state process model has to be adjusted. 流程控制最重要的任务是对各个流程实例进行持续监控,并分析关键数据,以便尽可能快速地识别薄弱环节。针对个别实体的问题需要直接采取补救措施,若存在结构性缺陷且条件允许,也需同样处理。必要时,必须对当前状态下的流程模型进行调整。
If the structural causes of the problems are unclear or complex, this calls for an improvement project that -once again -starts with a systematic process analysis of the weak points. The decision to initiate such a project lies with the process owner and anyone else who depends on the process. It is common to regard continuous process control as something that follows process implementation, though it may be better to have it follow the initial documentation. This is especially true when doubt exists about the necessity of the improvement. 若问题的结构性成因不明确或过于复杂,则需要启动改进项目——再次从对薄弱环节的系统性流程分析开始。启动此类项目的决策权在于流程所有者及其他依赖该流程的相关方。尽管通常认为持续流程控制应紧随流程实施之后开展,但在初始文档化完成后即跟进可能更为适宜,尤其是在对改进必要性存疑的情况下。
Given the importance of the process model within the BPM life cycle, you can imagine the importance of a modeling standard such as BPMN. Yet you may also notice that process modeling is not a stage in the Camunda BPM life cycle. That’s because process modeling is a method that affects all stages, especially process documentation and process design. As consultants, we constantly encounter people who try to insert process modeling as a stage at the same level as current state documentation. We think that’s a misconception. 鉴于流程模型在 BPM 生命周期中的重要性,您可以想象 BPMN 等建模标准的意义。但您可能也注意到,流程建模并非 Camunda BPM 生命周期中的一个独立阶段。这是因为流程建模是一种贯穿所有阶段的方法,尤其影响流程文档编制和流程设计环节。作为咨询顾问,我们经常遇到有人试图将流程建模与现状文档编制并列为一个层级阶段,我们认为这是认知误区。
The BPM life cycle describes a simple way to achieve continuous improvement. Applying it requires coordination of the triad: The responsible parties, the applied methods, and the supporting software tools. Getting the triad moving toward a common goal is the task of BPM governance, which has authority over all processes and all BPM projects in an organization. BPM 生命周期为实现持续改进提供了一套简明路径。其应用需要协调三大要素:责任主体、应用方法和支持性软件工具。推动这三者朝共同目标前进是 BPM 治理的职责所在,BPM 治理对组织内所有流程及 BPM 项目具有统辖权。
The EABPM’s definition of BPM used the term process automation, and we’ve also used that term in describing the Camunda BPM life cycle. BPMN was developed to automate processes better. Even if you are not an IT expert, you need to understand what process automation means because it will help you to grasp how BPMN builds bridges between business and technology. EABPM 对 BPM 的定义使用了“流程自动化”这一术语,我们在描述 Camunda BPM 生命周期时也采用了该术语。BPMN 的开发旨在更好地实现流程自动化。即使您不是 IT 专家,也需要理解流程自动化的含义,因为它将帮助您领会 BPMN 如何在业务与技术之间架起桥梁。
1.1.4 Process automation 1.1.4 流程自动化
Here’s a simple process: A potential bank customer mails a paper credit application, which ends up on the desk of a bank accountant. The accountant examines the application, then checks the potential customer’s creditworthiness through the web site of a credit rating agency. The results are positive, so the accountant records the application in a special software -let’s call it BankSoft -and then forwards the documents to a manager for approval. 这是一个简单的流程示例:一位潜在银行客户邮寄了一份纸质信用卡申请表,该表格最终送达银行会计的办公桌。会计审核申请表后,通过信用评级机构网站核查潜在客户的信用状况。结果良好,于是会计在专用软件(暂称为 BankSoft)中记录该申请,随后将文件转交给经理审批。
Here’s the same process automated: A potential bank customer mails a paper credit application. At the bank, a clerk scans the application into electronic form. Software known as a workflow engine takes over the document and routes it to the bank accountant’s virtual task list. The accountant accesses the task list, perhaps through the bank’s web site or an email program like Microsoft Outlook, examines the application on screen, then clicks a button. The workflow engine accesses the credit rating agency, transfers the pertinent details, and receives the report. Since the report is positive, the engine passes the information to BankSoft, and it creates an approval task in the manager’s task list. 以下是同一流程的自动化版本:一位潜在银行客户邮寄纸质信用卡申请表。银行内,职员将申请表扫描成电子版。被称为工作流引擎的软件接管该文档,并将其路由至银行会计师的虚拟任务列表。会计师通过银行网站或如 Microsoft Outlook 之类的电子邮件程序访问任务列表,在屏幕上审核申请表后点击按钮。工作流引擎连接信用评级机构,传输相关细节并接收报告。由于报告结果良好,引擎将信息传递给 BankSoft 系统,并在经理的任务列表中生成一项批准任务。
Whether this example represents optimal processing is not the point. It’s here only to illustrate the following principles of process automation: 此例是否代表最优处理流程并非重点,仅用于说明以下流程自动化原则:
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. 工作流引擎决定哪些任务或服务调用在何种条件下执行或跳过,并根据任务执行或服务调用的结果进行调整。因此,相关人员仍能影响自动化流程的实际运行顺序。
Figure 1.2 on the following page illustrates these principles. 下页图 1.2 展示了这些原理。
If you think that process automation is just a kind of software development, you are right. The workflow engine is the compiler or interpreter, and the executable process model is the program code. A workflow engine is the mechanism of choice where process automation is concerned. 若你认为流程自动化仅是软件开发的一种形式,那么你是正确的。工作流引擎相当于编译器或解释器,而可执行流程模型就是程序代码。在流程自动化领域,工作流引擎是首选的实现机制。
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- 由于工作流引擎控制着流程,它会追踪所有细节。它始终清楚流程当前所处的阶段,以及每项任务完成所耗费的时间。因为工作-
FIGURE 1.2 Process automation with a workflow engine. 图 1.2 使用工作流引擎实现流程自动化。
flow engine monitors key performance indicators directly, it provides a means to analyze performance as well. This offers huge potential for successful process control. 工作流引擎直接监控关键绩效指标,同时也提供了分析绩效的手段。这为成功的流程控制带来了巨大潜力。
The three features above would themselves justify using a workflow engine, but there is a fourth justification: The workflow engine works on the basis of an executable process model. In the best cases, this model can be developed -or at least understood -by someone who is not a technician. This promotes genuinely good communication between business and IT, and it can even result in process documentation that corresponds to reality. 上述三个特性本身已足以成为使用工作流引擎的理由,但还有第四个理由:工作流引擎基于可执行的流程模型运作。在最佳情况下,该模型可由非技术人员开发或至少理解。这极大促进了业务与 IT 之间的有效沟通,甚至能生成与现实相符的流程文档。
1.2 The BPM standards 1.2 BPM 标准体系
Our focus in this book is on BPMN as a standard for modeling and automating processes. But there is at least one standard that relates closely to BPMN, and complement BPMN well. This is Decision Model and Notation (DMN) for managing decisions. 本书聚焦于将 BPMN 作为流程建模与自动化的标准,但至少有一个与 BPMN 紧密关联并形成良好互补的标准——决策模型与标记法(DMN),专用于决策管理。
In this section, we provide an overview of the standards, and then we describe how they can be used in combination. 本节将概述这些标准,并阐述如何组合运用它们。
1.2.1 Workflows with BPMN 1.2.1 使用 BPMN 的工作流程
Initially, BPMN stood for Business Process Modeling Notation. The first version was developed predominantly by Stephen A. White from IBM before it was published in 2004 by Business Process Management Initiative (BPMI). From the outset, the aim was to provide a standardized graphical process notation that also could be used for process automation. 最初,BPMN 代表业务过程建模符号。第一版主要由 IBM 的 Stephen A. White 开发,后于 2004 年由业务流程管理倡议组织(BPMI)发布。从一开始,其目标就是提供一种标准化的图形化过程表示法,同时也能用于过程自动化。
In 2005, Object Management Group (OMG) took over BPMI along with the further development of BPMN. OMG is an important institution in the world of IT. It is known especially for its Unified Modeling Language (UML), a modeling standard for software design. The merger of BPMI with OMG was also the beginning of a global triumph for BPMN, as it provided incentive for many companies to switch. 2005 年,对象管理组织(OMG)接管了 BPMI 并继续推进 BPMN 的发展。OMG 是 IT 界的重要机构,尤其以其统一建模语言(UML)——一种软件设计建模标准——而闻名。BPMI 与 OMG 的合并也标志着 BPMN 全球性成功的开始,因为这激励了许多公司转而采用该标准。
In February 2011, OMG released the current version, BPMN version 2.0. We were able to play a part in that. Version 2.0 came with a new definition of BPMN: Business Process Model and Notation, because not only did version 2.0 define the notation but also the so-called formal metamodel. Then in September 2013, BPMN was published as an ISO standard by the International Organization for Standardization (ISO) under ISO/IEC 19510:2013. Since then, the notation has been deliberately kept stable, because a proliferation of versions would destroy many of the advantages, because then, for example, each tool would support a different version, or books would have to take account of many version differences. 2011 年 2 月,对象管理组织(OMG)发布了当前版本——BPMN 2.0 版,我们也有幸参与其中。2.0 版本为 BPMN 赋予了新的定义:业务流程模型与符号(Business Process Model and Notation),因为该版本不仅定义了符号系统,还引入了所谓的形式化元模型。随后在 2013 年 9 月,国际标准化组织(ISO)将 BPMN 作为 ISO/IEC 19510:2013 标准发布。自此,该符号体系被刻意保持稳定,因为版本泛滥会破坏其诸多优势——例如可能导致不同工具支持不同版本,或书籍需要处理大量版本差异问题。
By now you may be wondering what this mysterious BPMN is in a material sense. BPMN is a specification. It exists in the form of a PDF document that you can download free from the OMG [Obj09] website. Whereas the specification document for BPMN version 1.2 was about 320 pages, version 2.0 has expanded to 500 pages. The documents define all the BPMN symbols, their meanings, and the rules on combining them. 此刻您或许好奇这个神秘的 BPMN 具体是什么。BPMN 是一套规范,以 PDF 文档形式存在,您可以从 OMG 官网免费下载[Obj09]。BPMN 1.2 版的规范文档约 320 页,而 2.0 版已扩展到 500 页。这些文档定义了所有 BPMN 符号、其含义以及组合规则。
With version 1.2, BPMN had not yet defined all the technical attributes necessary for direct execution of BPMN models in workflow engines. This led to several unfortunate attempts to convert (“map”) BPMN models to BPEL models (see section 6.2.3 on page 172). BPMN version 2.0, however, made direct execution possible. That’s an important factor in terms of the use of BPMN models. Another important factor is standardization, which offers the following advantages: 在 1.2 版本中,BPMN 尚未定义所有必要的技术属性以实现 BPMN 模型在工作流引擎中的直接执行。这导致了几次不幸的尝试,即将 BPMN 模型转换(“映射”)为 BPEL 模型(参见第 172 页的 6.2.3 节)。然而,BPMN 2.0 版本使得直接执行成为可能。这对于 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
DMN is short for Decision Model and Notation. Like BPMN, it is administered by OMG. DMN is the newest of the three standards. Version 1.0 was released in September 2015. Version 1.2 is the current version when releasing this edition of the book. DMN 是决策模型与标记法的缩写。与 BPMN 一样,它由对象管理组织(OMG)管理。DMN 是三大标准中最新的一个,1.0 版发布于 2015 年 9 月。本书出版时,现行版本为 1.2 版。
A decision in the DMN sense means deriving a result (output) from given facts (input) on the basis of defined logic (decision logic). DMN 语境中的决策,意味着基于既定逻辑(决策逻辑)从给定事实(输入)推导出结果(输出)。
Unlike BPMN, DMN is not about activities or processes. DMN works in an operationally similar fashion: decisions can be modeled by a business user and then executed by a decision engine. Another similarity to BPMN is that the DMN standard specification contains both a written description of the notation and an XML-based formal metamodel. 与 BPMN 不同,DMN 并不关注活动或流程。DMN 在操作方式上与之类似:业务用户可以建模决策,然后由决策引擎执行。另一个与 BPMN 的相似之处在于,DMN 标准规范既包含了对该符号的文字描述,也包含了一个基于 XML 的形式化元模型。
The DMN standard offers different ways to model decisions. The most popular way is the decision table described in section 5.2.1 on page 151. Within decision tables you must define the specific conditions needed to determine a result. The definition has to be understandable and implementable on a technical level -BPMN users will recognize how this corresponds to BPMN -and it is why we use a formal language called Friendly Enough Expression Language (FEEL). FEEL is part of the DMN standard, and we introduce it in section 5.2.4 on page 159. DMN 标准提供了多种建模决策的方式。最流行的是第 151 页 5.2.1 节所述的决策表。在决策表中,您必须定义确定结果所需的具体条件。这些定义需在技术层面上可理解且可实施——BPMN 用户会认识到这与 BPMN 的对应关系——这也是我们使用一种名为“友好表达式语言”(FEEL)的形式化语言的原因。FEEL 是 DMN 标准的一部分,我们将在第 159 页 5.2.4 节介绍它。
Often, complex decisions are made up of comparatively simple decisions. The Decision Requirements Diagrams (DRDs) described in section 5.2 .5 on page 162 help us to dissect complex decisions into their components and make them clearer. 通常,复杂决策由相对简单的决策组成。第 162 页 5.2.5 节描述的决策需求图(DRD)帮助我们剖析复杂决策,将其分解为更清晰的组成部分。
Similar to BPMN, the value of DMN peaks when modeled decisions are executed by a compatible decision engine. This offers the following advantages: 与 BPMN 类似,当建模决策由兼容的决策引擎执行时,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 部门设计或调整软件解决方案。
Activities and decisions are closely entwined in business processes. BPMN version 2.0 defined a business rule task more than four years before the first version of DMN. Even then it was assumed that when completing processes, rules would be assessed constantly as part of making decisions. The term decision management was not common at that time, however; we spoke instead of business rule management, which explains the description of that task type in BPMN. 活动与决策在业务流程中紧密交织。BPMN 2.0 版本早在 DMN 首个版本问世前四年就已定义了业务规则任务。即便在当时,人们也认为在完成流程时,规则会作为决策的一部分被持续评估。不过那时"决策管理"这一术语尚未普及,我们更多使用"业务规则管理"的说法,这也解释了 BPMN 中对该任务类型的描述。
1.2.3 Structured vs. unstructured workflows 1.2.3 结构化与非结构化工作流
BPMN focuses on business processes, but there is an important limitation: There are some processes that are poorly suited to modeling or automation in BPMN. These are the unstructured processes - processes that do not always take place in a predictable and repeat- BPMN 专注于业务流程,但存在一个重要限制:某些流程并不适合用 BPMN 建模或自动化。这些就是非结构化流程——那些并非总是以可预测、可重复方式进行的流程。
able way. An example of an unstructured process is that of a doctor coming upon the scene of an accident with injuries. She is unlikely to work through a BPMN diagram but instead will quickly plunge in, making decisions based on her knowledge and experience, of course, but also in reaction to the chaos of the scene. We could draw other examples from practically every sector or industry, though many are less obvious. 非结构化流程的一个例子是医生遇到事故受伤现场时的处置。她不太可能按照 BPMN 流程图行事,而是会迅速投入急救,当然会基于专业知识和经验做决策,但也会根据现场混乱情况实时应对。我们几乎可以从每个行业领域举出类似例子,尽管许多案例不那么典型。
This is why the CMMN standard was invented alongside BPMN. CMMN is short for Case Management Model and Notation. OMG published CMMN version 1.0 in March 2014 and the current version when writing this edition is 1.1 . We introduced that notation in some detail in the 3rd edition of this book, used it a lot when working with customers and also added support for it in our software platform. We gave CMMN two years to take off, but, within that time, we experienced limited value from CMMN in our projects, especially if you compare it to BPMN or DMN. One observation was, for example, that most logic in CMMN models was hidden in complex rule-sets if certain activities are possible, impossible, mandatory or unnecessary. These rules were often expressed elsewhere and also not represented graphically. Exaggerating a bit, the CMMN model becomes kind of a graphical bullet point list. So we decided to remove CMMN from this book to not confuse anybody that just embarks on their BPM journey. Instead we want to emphasis how to tackle unstructured processes with BPMN in section 4.5.5 on page 142 and point out the limits of this approach. 这就是为什么 CMMN 标准与 BPMN 一同被发明。CMMN 是 Case Management Model and Notation 的缩写。OMG 于 2014 年 3 月发布了 CMMN 1.0 版本,而本书撰写时的最新版本为 1.1。我们在本书第三版中详细介绍了该符号,并在与客户合作时大量使用,还在我们的软件平台中增加了对它的支持。我们给了 CMMN 两年时间发展,但在此期间,我们在项目中体验到的 CMMN 价值有限,尤其是与 BPMN 或 DMN 相比。例如,我们观察到,CMMN 模型中的大部分逻辑隐藏在复杂的规则集中,这些规则决定了某些活动是可能、不可能、强制还是非必要的。这些规则通常在其他地方表达,且未以图形方式呈现。夸张地说,CMMN 模型变成了一种图形化的项目符号列表。因此,我们决定从本书中移除 CMMN,以免让刚接触 BPM 的人感到困惑。相反,我们将在第 142 页的 4.5.5 节中强调如何用 BPMN 处理非结构化流程,并指出这种方法的局限性。
Close your eyes (metaphorically speaking) and imagine that you are hosting a workshop to design a business process. You have a room full of people who have a stake in the process, and your mutual goal is to come up with a BPMN process model. You start with a manageable circle of participants, and you ask them what the first task should be. 闭上你的眼睛(打个比方),想象你正在主持一个设计业务流程的研讨会。房间里坐满了与流程利益相关的人,你们共同的目标是制定出一个 BPMN 流程模型。你从一个可控的参与者圈子开始,询问他们第一个任务应该是什么。
The answer to your question depends, they tell you, and they proceed to pepper you with an entire list of conditions. It seems that you will have to model the evaluation of conditions first, and you’ll use a gateway with many possible paths leading out of it. 他们告诉你,这个问题的答案取决于具体情况,接着便向你抛出一连串的条件。看来你得先建模评估这些条件,并且会使用一个带有多个可能路径的网关来表示。
During the course of the meeting, participants also point out the frequent need to jump back within the process and to repeat a previous task. While it is easy enough to represent such jumps in BPMN, if they have to be represented for more than half of the tasks, your model quickly starts to resemble a bowl of spaghetti. There are two ways out of this mess: 在会议过程中,参与者还指出经常需要在流程中跳回并重复之前的任务。虽然在 BPMN 中表示这种跳转很容易,但如果超过一半的任务都需要这样表示,你的模型很快就会变得像一碗意大利面一样混乱。摆脱这种混乱有两种方法:
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. 你解释说,他们将不得不开始以更有条理的方式工作,减少例外、偏差、回溯等情况。这会限制他们在流程中行动的灵活性,可能会让员工和客户都感到沮丧。另一方面,流程将变得可预测、可重复,并且减少对控制流程人员隐性知识的依赖。
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),需提供以下信息:
FIGURE 1.3 The Camundanzia website. 图 1.3 Camundanzia 保险公司网站界面。
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 兼容工作流引擎现在开始运行。
FIGURE 1.4 Request processing in BPMN. 图 1.4 BPMN 中的请求处理流程
The process starts with the determine risks business rule task. On the model side, this task is linked to the DMN decision table risk assessment (see figure 1.5) that is now carried out by the decision engine. The decision engine evaluates the input values for applicant age, vehicle manufacturer, and car model. The workflow model transferred these values to the decision engine when the business rule task was carried out. 流程从"风险评估"业务规则任务开始。在模型层面,该任务关联至 DMN 决策表"风险评估"(见图 1.5),此时由决策引擎执行。决策引擎会评估申请人年龄、车辆制造商和车型等输入值。当执行业务规则任务时,工作流模型已将这些值传递给决策引擎。
FIGURE 1.5 Risk assessment in DMN. 图 1.5 DMN 中的风险评估
Because you said you drive a BMW X3, rule number 5 applies regardless of your age. This rule states that any driver of a high-value vehicle gets a yellow risk rating. 由于您提到驾驶的是宝马 X3,无论年龄大小,第五条规则均适用。该规则规定,任何高价值车辆的驾驶者都将获得黄色风险评级。
The decision engine feeds two output values -one for the vehicle and one for the risk rating —back to the workflow engine, which continues to execute the process. In the following step we encounter an XOR gateway (see section 2.3 .1 on page 28 ), which decides how the process should continue based on the risk assessment. 决策引擎向工作流引擎反馈两个输出值——一个针对车辆,另一个针对风险评级——工作流引擎随后继续执行流程。在接下来的步骤中,我们会遇到一个异或网关(参见第 28 页 2.3.1 节),该网关根据风险评估结果决定流程的后续走向。
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 中,我们可以看到职员的任务表单样式。
FIGURE 1.6 Office clerk’s task form when deciding on the application. 图 1.6 办公室职员处理申请时的任务表单。
If the end result is to accept the application, the BPMN process continues, that is, the workflow engine reaches the XOR gateway decision and selects the path application accepted. Now the possibility described above becomes reality -the service task retrieves the insurance policy from the back-end system, and the send task sends it to the applicant by email. 若最终结果为接受申请,BPMN 流程将继续,即工作流引擎到达异或网关决策点并选择“申请已接受”路径。此时前述场景成为现实——服务任务从后端系统获取保险单,发送任务通过电子邮件将其寄送给申请人。
Perhaps only half an hour has elapsed since you sent your application for car insurance. You spent it idly snoozing at your desk, didn’t you? But your reverie ends when a new email arrives. You are thrilled at the speed with which Camundanzia was able to issue your insurance policy. 或许从您提交汽车保险申请至今仅过去半小时。这段时间您一直懒洋洋地在办公桌前打盹,不是吗?但当新邮件抵达时,您的遐想戛然而止。您会惊叹于 Camundanzia 签发保险单的神速。
This concludes our example. We hope it was enlightening. 示例到此结束,希望对你有所启发。
As you can see, each of the BPM standards has a role to play, but they also overlap. A question we get asked is why we need decision tables if business rules can also be represented in BPMN by gateways? We answer this question in section 4.5.6 on page 144. 如你所见,每个 BPM 标准都有其作用,但它们也存在重叠。常有人问:既然业务规则可以通过 BPMN 中的网关表示,为何还需要决策表?我们在第 144 页 4.5.6 节回答了这个问题。
- 1.4 Can BPMN bridge the gap? - 1.4 BPMN 能否弥合鸿沟?
1.4.1 The dilemma 1.4.1 两难困境
First, BPMN provides a set of symbols. Second, it implies a methodology that expresses itself as rules for combining the symbols graphically. Third, the symbol definitions and the rules for applying them is called syntax. Fourth, the meaning of the symbols and constructs that you can model with the symbols is called semantics. 首先,BPMN 提供了一套符号体系。其次,它蕴含了一种方法论,表现为将这些符号以图形方式组合的规则。第三,符号定义及其应用规则被称为语法。第四,这些符号及其可构建模型的意义被称为语义。
Unfortunately, just knowing the BPMN symbols is not enough for you to create useful process models. Since 2007, we have used BPMN extensively and often, and you can believe that we have suffered terribly! Mainly, we suffered because we always aimed for models with correct syntax and consistent semantics -in other words, unambiguous models. Others took the easy way out by saying: “Our process model is not really syntactically correct, and it’s not really unambiguous. But that doesn’t matter because the main thing is that the consumer understands it!” This attitude backfires because: 遗憾的是,仅了解 BPMN 符号并不足以创建有用的流程模型。自 2007 年以来,我们频繁且广泛地使用 BPMN,可以想见我们曾深受其苦!究其原因,主要是因为我们始终追求语法正确且语义一致的模型——换言之,即无歧义的模型。而其他人则选择走捷径,声称:“我们的流程模型在语法上并不完全正确,也不完全无歧义。但这没关系,关键是使用者能理解!”这种态度会适得其反,因为:
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 部门实施,这种风险尤其高。
If you want to supply your process model directly to the workflow engine, you must make your model correct, precise, and consistent. At that point, you still have to reconcile two contradictory objectives: 若想直接将流程模型提供给工作流引擎执行,必须确保模型正确、精确且一致。此时仍需调和两个相互矛盾的目标:
Different consumers must understand and accept the process model. Making the model easy to comprehend helps to reach agreement. 不同使用者必须理解并认可该流程模型。使模型易于理解有助于达成共识。
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. 由于流程模型需满足形式化建模的要求,通常不可避免地带有一定复杂性。这使得更难实现促成共识的理解程度。
Failure to reconcile the objectives, to bridge the gap in understanding between business and technology, is the main reason that process models have had limited success in the past. The really bad news is that BPMN alone also will not succeed! 未能调和目标,弥合业务与技术之间的理解鸿沟,是过去流程模型成效有限的主要原因。更糟糕的是,单靠 BPMN 同样无法取得成功!
Just as with spoken language, you can use BPMN and either succeed or fail. As with spoken language, successful use of BPMN depends on whom you want to communicate with and about what. You speak to your colleagues about the work you all know so well differently than you speak to your three-year-old about why the cat doesn’t like to be pulled by its tail. Similarly, you will need other BPMN process models for coordinating with your coworkers than for presenting the future process to upper management. Decide for yourself if the latter scenario is akin to the toddler-and-cat situation. 如同口语交流一样,使用 BPMN 既可能成功也可能失败。其成功与否取决于你想与谁沟通以及沟通的内容。向熟知工作的同事描述流程时,你会采用不同于向三岁孩童解释"为什么猫咪不喜欢被拽尾巴"的表达方式。同理,用于协调同事工作的 BPMN 流程模型,必然有别于向高层管理层展示未来流程的版本。至于后者是否类似"幼童与猫"的情景,不妨自行判断。
On the one hand, different BPMN process models are required for specific audiences and topics so that they can be understood. On the other hand, each model must contain all the detail necessary for the topic. BPMN may be a common language for business and IT, but the phrasing will remain different nevertheless. 一方面,需要针对不同受众和主题制定特定的 BPMN 流程模型以确保理解;另一方面,每个模型又必须包含该主题所需的全部细节。尽管 BPMN 堪称业务与 IT 的通用语言,但双方的表述方式始终存在差异。
The following understanding is therefore imperative for your work with BPMN: 因此,以下理解对于您使用 BPMN 至关重要:
The precision and formal correctness of the process model must vary depending on the modeling objective and the expected consumers. 流程模型的精确性和形式正确性必须根据建模目标和预期使用者的不同而变化。
1.4.2 The customers of a process model 1.4.2 流程模型的客户
Whenever we model processes, we have to work in a customer-focused way. We must always keep the consumer of our model in mind. We must put ourselves in his or her place. This sounds simple, but few process models actually support this orientation. 每当我们建模流程时,都必须以客户为中心的方式进行工作。我们必须始终牢记模型的最终使用者,设身处地为他们着想。这听起来简单,但实际上很少有流程模型真正支持这种导向。
As we have been saying, the knowledge, skills, and interests of the people who view our process models vary a great deal. In the following list, we have compiled the types we encounter in our BPM projects. These descriptions are for the roles played in relation to the project; they are not the titles of people in any organization. What we find is that the more experience an enterprise develops with BPM, the more consistently we see these roles fulfilled. We recommend that you become familiar with: 正如我们一直强调的,查看我们流程模型的人员其知识、技能和兴趣差异很大。在以下列表中,我们汇总了在 BPM 项目中常见的角色类型。这些描述针对的是项目中扮演的角色,而非任何组织中的职位头衔。我们发现,企业积累的 BPM 经验越多,这些角色的配置就越趋于稳定。我们建议您熟悉以下角色:
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 生命周期的实施阶段,但流程分析师也可能在其他阶段引入流程工程师参与。
FIGURE 1.7 The process matrix organization. 图 1.7 流程矩阵型组织架构
Now that we’ve outlined the potential customers of a process model, we can talk about what the models should look like to keep these customers happy. 既然我们已经勾勒出流程模型的潜在用户群体,接下来可以探讨如何设计模型才能让这些用户满意。
1.5 A method framework for BPMN 1.5 BPMN 方法论框架
In our consulting projects and workshops, we have introduced a great many people from all kinds of enterprises to BPMN. From that collected experience, we have developed a practical framework for applying BPMN. 在我们的咨询项目和研讨会中,我们向来自各类企业的众多人士介绍了 BPMN。基于这些积累的经验,我们开发了一套实用的 BPMN 应用框架。
This framework helps us decide which BPMN symbols and constructs to use in which situations -and also when to hold back in the interest of simplicity. The framework focuses on projects with processes that need improved technological support and in which it is the target state that needs to be modeled. In principle, what we show as modeling patterns can also be applied to other scenarios such as the discovery, documentation, and analysis of current-state processes. 该框架帮助我们判断在何种情境下使用哪些 BPMN 符号和结构——以及何时为了简洁性而有所保留。该框架主要针对那些需要改进技术支持的流程项目,且重点在于建模目标状态。原则上,我们所展示的建模模式也可应用于其他场景,如现状流程的发现、记录和分析。
For this edition of the book, we revamped the way we visualize the framework. The following section introduces the new visualization, and then we explain why we changed it. Basically, we now find fault with a widespread approach to process-focused IT projects, and we want to present an alternative that our experience suggests is better. 在本书此版中,我们改进了框架的可视化方式。接下来的章节将介绍新的可视化方案,并解释我们为何做出这一改变。简言之,我们现在发现以流程为核心的 IT 项目中普遍存在一种问题方法,而我们希望提出一种经验证更优的替代方案。
1.5.1 The Camunda house 1.5.1 卡蒙达之家
Content: Process overview 内容:流程概览
Goal: Fast comprehension 目标:快速理解
Semantics: Logically abstract 语义:逻辑抽象
Content: Operational processes 内容:运营流程
Goal: Coordinate details between 目标:协调
human process flow and technical process flow (automation) 人工流程与技术流程(自动化)之间的细节
Semantics: Physically specific 语义:物理层面具体化
The Camunda BPMN framework in figure 1.8, or Camunda house for short, distinguishes between strategic and operational process models: 图 1.8 中的 Camunda BPMN 框架,简称 Camunda 屋,区分了战略流程模型和操作流程模型:
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 工具支持
Abstract 摘要
We developed the Camunda house specifically to represent projects involving a lone process or a manageable group of related processes. For now, we won’t deal with modeling entire process landscapes. BPMN’s portfolio does not encompass process landscapes. We have modeled process landscapes at a customer’s request (we primarily used collapsed pools and message flows as described in section 2.9 on page 78), but we cannot recommend it. If you want a process landscape, you should use a more appropriate tool -perhaps a proprietary one that uses block arrows and rectangles and lots of colors. Of course, you can refine a process landscape with BPMN diagrams by linking the individual elements with flow charts. 我们专门开发了 Camunda house 模型,用以代表涉及单个流程或一组相关可管理流程的项目。目前,我们暂不处理整个流程景观的建模。BPMN 的功能范围并不涵盖流程景观。虽然我们应客户要求曾建模过流程景观(主要采用了第 78 页 2.9 节所述的折叠池和消息流),但我们不建议这样做。若需构建流程景观,应选用更合适的工具——或许是采用区块箭头、矩形框和丰富色彩的专有工具。当然,您可以通过流程图链接各个元素,用 BPMN 图表来细化流程景观。
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 项目都参考了这个金字塔框架示意图进行定位。某大型跨国软件供应商甚至将其纳入了营销资料。遗憾的是,这导致了一些误解。
FIGURE 1.9 From old to new: The Camunda BPMN framework. 图 1.9 从旧到新:Camunda BPMN 框架演变
In the pyramid, we distinguished between strategic, operational, and technical levels. It seems similar at first to the Camunda house, but the Camunda house defines the technical level as a component called technical process flows within the operational process model, and not as a level of its own. The pyramid put the operational level in a position equivalent to what we now call human process flows. 在金字塔结构中,我们区分了战略层、运营层和技术层。乍看之下与 Camunda 房屋模型相似,但 Camunda 房屋模型将技术层定义为运营流程模型内部的"技术流程流"组件,而非独立层级。金字塔模型将运营层定位为相当于我们现在所称的"人工流程流"。
This change was necessary because people too often assumed that the technical level was a refinement of the operational level, in other words, that the technical level merely added more detail. In reality, operational-level models (in the sense of the earlier framework) are often more detailed than their corresponding technical-level models. For example, think of a simple technical process flow -that triggers a complex manual task -which then requires a complex manual process. 这一变更是必要的,因为人们常常误以为技术层面是对操作层面的细化,换言之,技术层面仅仅是增加了更多细节。实际上,(按先前框架定义的)操作层面模型往往比对应的技术层面模型更为详细。例如,设想一个简单的技术流程——它触发了一项复杂的手工任务——而该任务又需要一套复杂的手工流程。
Two related misunderstandings came up. 出现了两个相关的误解。
The first was a perception that the modeling on three levels had to take place in a fixed sequence, that the target-state process must be created first on the strategic level, and then on the operational level, and finally on the technical level. There’s no need for that. It often makes more sense to create the operational or technical model first. Doing it this way allows you to develop a clearer understanding of the way process participants will have to do their work before you attempt to summarize or abstract it into a strategic process model. It is, in fact, common practice to conceive the technical and human flows of a process model concurrently, for example, in a workshop. 第一种误解是认为三个层面的建模必须按照固定顺序进行,即必须先创建战略层面的目标状态流程,然后是操作层面,最后才是技术层面。其实无需如此。通常先创建操作或技术模型反而更合理。这种方式能让你在尝试总结或抽象成战略流程模型之前,更清晰地理解流程参与者将如何开展工作。事实上,在研讨会等场景中,同时构思流程模型的技术流和人工流是常见做法。
The second misunderstanding related to a strict separation of responsibilities. It was assumed that only the business side would define the strategic and operational levels while only the IT Department would define the technical level. We found this assumption most frequently in enterprises with difficult political situations, where cooperation between IT, operations, and business departments was less than ideal. 第二种误解涉及严格的职责分离。人们认为只有业务部门才能定义战略和操作层面,而技术层面则专属于 IT 部门。我们发现这种假设最常见于政治环境复杂的企业中,这些企业的 IT、运营和业务部门之间的协作状况往往不尽如人意。
We should all understand that even a technical flow represents a business model. After all, it describes business requirements. It differs from a classic request document only in that the technical flow anticipates the executable source code -a major advantage of BPMN. The risk in such a strict segregation of responsibilities is that the technical model, while 我们都应明白,即便是技术流程也代表着一种业务模型。毕竟,它描述的是业务需求。它与传统的需求文档不同之处在于,技术流程预见了可执行的源代码——这是 BPMN 的一大优势。在这种严格职责划分中的风险在于,技术模型虽然
compliant with requirements, may become incomprehensible and unsatisfactory to the business. 符合需求,却可能变得难以理解且无法令业务方满意。
It is a similarly serious matter not to involve IT sufficiently in the design of human processes. To believe that you can define a process purely from an operational perspective and only then align the technical implementation with it is …naive. Experience shows us repeatedly that operational decisions can and should be influenced by technological realities, either because what the business wants is technologically impossible (or perhaps infeasible for cost reasons), or because the technology can offer solutions that are not on the radar for the people defining operational requirements. 同样严重的问题是未让 IT 充分参与人工流程的设计。认为可以纯粹从运营角度定义流程,之后再调整技术实现与之匹配的想法……太过天真。经验一再告诉我们,运营决策能够且应当受到技术现实的影响,要么因为业务期望在技术上无法实现(或出于成本考虑不可行),要么因为技术能提供那些制定运营需求者尚未想到的解决方案。
To summarize, you could say that the operational process model belongs both to the business and to IT. As a shared artifact, both parties should share in its development. 总结来说,可以认为操作流程模型既属于业务部门也属于 IT 部门。作为共享产物,双方都应参与其开发过程。
What does this thinking mean in terms of our approach to projects? Basically, it aligns with that of agile project organizations: The strict separation of concept from realization is as outmoded as the classic waterfall pattern of development. Most IT projects go better with iterative development, either in sprints within Scrum or otherwise, and it doesn’t matter if the project is about process improvement or automation. The business and IT shouldn’t work in isolation. 这种思维方式对我们的项目方法意味着什么?基本上,它与敏捷项目组织的理念一致:概念与实现的严格分离就像传统的瀑布式开发模式一样已经过时。大多数 IT 项目更适合采用迭代开发方式,无论是 Scrum 框架下的冲刺还是其他形式,且无论项目是关于流程改进还是自动化。业务部门与 IT 部门不应孤立工作。
To be abundantly clear: Project participants may need to be shaken out of their comfort zones and motivated sufficiently to work honestly with “the other side.” In our engagements during the last few years, the result of our strong encouragement for cooperation always has been the same: massive amazement at how productive a project can be. When IT and the business work side-by-side to define the target-state process at the strategic and operational levels, including technical flows, the technical flows can become executable within days or even hours. 需要明确强调的是:项目参与者可能需要被推出舒适区,并获得足够的动力来诚实地与“另一方”合作。在过去几年的实践中,我们大力倡导合作的结果始终如一:项目所能达到的高效程度令人惊叹。当 IT 与业务部门并肩工作,在战略和操作层面定义目标状态流程(包括技术流程)时,技术流程可在数日甚至数小时内变为可执行方案。
As Thorsten Schramm of LVM Versicherung (a large insurance firm) put it during one of our workshops: 正如 LVM 保险公司(一家大型保险企业)的 Thorsten Schramm 在我们某次研讨会上所言:
“It took only a few days to highly inspire the whole project team (consisting of people from both IT and business departments) for process modelling with BPMN, and right now the first improved processes are already emerging.” “仅用几天时间就极大地激发了整个项目团队(由 IT 和业务部门人员组成)对 BPMN 流程建模的热情,目前首批优化流程已经显现成效。”
Thorsten distills our message nicely. Sometimes, the cooperation experienced within a workshop is just as meaningful as learning the BPMN methodology. BPMN thus can operate synergistically to produce positive change within the enterprise. Thorsten 精炼地概括了我们的核心理念。有时,工作坊中实现的协作精神与学习 BPMN 方法论同等重要。因此,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%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%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 中的小例子。
FIGURE 1.10 Several microservices need to collaborate to implement an end-to-end business process. Every microservice has its own local process. 图 1.10 多个微服务需要协作以实现端到端业务流程。每个微服务都有其本地流程。
The microservice inbound application is responsible for end-to-end processing applications for an insurance policy. Therefore it includes a BPMN process, which we’ve already looked at. Now, however, the policy itself is an independent task and will probably be dealt with in a separate microservice. This is perhaps only a facade in front of an existing legacy system. The two microservices must now work together to process a new application. 微服务入站应用程序负责保险保单的端到端处理流程。因此,它包含一个我们已经研究过的 BPMN 流程。然而,现在保单本身是一个独立的任务,可能会在一个单独的微服务中处理。这可能只是现有遗留系统前面的一个门面。现在这两个微服务必须协同工作来处理新的申请。
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 巨石是指一个流程模型混杂了来自不同微服务的细节,从而未能尊重它们各自的职责与边界。这样的模型没有单一负责人,且由于过多利益相关方希望参与其中,通常协调起来极为繁琐。你无法直接自动化该模型,因为它需要分散到不同的微服务中实现。
FIGURE 1.11 Antipattern BPMN monolith: This model includes details about responsibilities from other microservices. 图 1.11 反模式 BPMN 巨石:该模型包含了其他微服务的职责细节。
Figure 1.11 shows an example of such a BPMN monolith. In addition to the processing of the application, there is business logic of the policy included, like the fact that policies only become valid if the first invoice is paid within a defined period. The application microservice should not know this detail - it only wants to know whether a policy was successful or not - and perhaps how long it has to wait at most. 图 1.11 展示了一个典型的 BPMN 巨石案例。除了申请处理流程外,该模型还包含了保单业务逻辑的细节,例如“只有首期保费在规定期限内支付后保单才生效”这样的规则。申请微服务本不应知晓此类细节——它只需知道保单是否成功生效,以及最多需要等待多长时间即可。
We know from our own experience that in the heat of a successful modeling workshop these monoliths can be created very quickly, as many details bubble out of the participants very naturally at this moment. Often it is even helpful to understand the overall situation and to allow these models. However, they may not be continued, let alone automated, so they are clearly an intermediate step before the process is sliced into individual parts. When doing so, the microservices boundaries must be taken into account. 根据我们的实践经验,在成功的建模研讨会热烈进行时,这些单体结构可能迅速形成,因为此时参与者会自然而然地涌现出许多细节。通常,这甚至有助于理解整体情况并允许此类模型存在。然而,它们可能不会被延续,更不用说实现自动化了,因此它们显然是流程被分解为独立部分前的中间步骤。在此过程中,必须考虑微服务的边界划分。
And, of course, it can still make sense to design a monolithic system. In this case you can model and execute a BPMN monolith accordingly. 当然,设计单体系统在某些情况下仍然合理。此时,你可以相应地建模并执行一个 BPMN 单体架构。
In chapter 4.5.3 on page 140 we will follow-up on this topic again with another example. 我们将在第 140 页的 4.5.3 章节中通过另一个案例继续探讨这一主题。
expressions. While this is a deliberate deviation from the standard, we are not violating it because the standard permits extensions. Overall, we find that the extensions make it much easier for Java developers to deal with process definition. Success depends on the individual customer’s situation. Most of our clients seem to think it is a worthwhile tradeoff. 表达式。虽然这是对标准的刻意偏离,但我们并未违反规范,因为标准允许扩展。总体而言,我们发现这些扩展显著降低了 Java 开发者处理流程定义的难度。实际成效取决于客户的具体情况。我们大多数客户似乎认为这是一种有价值的权衡。
User tasks 用户任务
Human interaction takes place in the form of a user task. The existence of user tasks in the process leads to tasks being placed in task management and tasks ending up on a user’s task list. Only after the user completes the task does the process continue. 人工交互以用户任务的形式进行。流程中存在用户任务会导致任务被分配到任务管理系统并出现在用户的任务列表中。只有当用户完成任务后,流程才会继续。
The exact technological connection is often a detail in the implementation of the particular workflow engine, making seamless integration possible. If it is essential for you to be independent of a specific engine, there is generally a standardized way using web services: WS-HumanTask (WS-HT). This comprehensive specification defines user tasks in a detailed and powerful way. Aspects such as responsibilities, delegation, escalation, or even meta information for the display can be defined. In real life, however, WS-HT is often too complex to be used easily. 具体的技术连接通常是特定工作流引擎实现中的一个细节,这使得无缝集成成为可能。如果您需要独立于特定引擎,通常可以通过 Web 服务采用标准化方式:WS-HumanTask(WS-HT)。这一全面的规范以详细且强大的方式定义了用户任务。职责、委派、升级甚至用于显示的元信息等方面都可以进行定义。然而在实际应用中,WS-HT 往往过于复杂而难以轻松使用。
Forms for tasks or other interface components, by the way, are completely left out by BPMN. This is where workflow engine vendors go off in different directions. 顺便提一下,BPMN 完全没有涉及任务表单或其他界面组件。这正是各工作流引擎供应商分道扬镳的地方。
- 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 套件不同,能够
FIGURE 6.6 In microservice architectures, the workflow engine is usually an implementation detail and not a central infrastructure. 图 6.6 在微服务架构中,工作流引擎通常是一个实现细节而非中心化基础设施。
operated very easily. In this book we don’t want to go further into these details and instead refer to relevant tutorials and how-tos on the Internet, for example about our open source platform Camunda BPM. 非常便捷地运行。本书不打算深入这些细节,而是推荐参考互联网上的相关教程和操作指南,例如关于我们的开源平台 Camunda BPM 的内容。
This view is essential in microservice architectures. We often find that BPMN tools are rejected by architects or developers because they automatically think of centralized or monolithic BPM systems. And in the world of microservices, which is characterized by decentralization and autonomy, such a tool has no place! So it is all the more important for us to spread the knowledge that a workflow engine can also be used decentrally in a microservice. Then it quickly becomes an essential building block in harmony with your microservices architecture. 这一观点在微服务架构中至关重要。我们经常发现,BPMN 工具会被架构师或开发者排斥,因为他们会自然而然地联想到集中式或单体式的 BPM 系统。而在以去中心化和自治为特点的微服务世界里,这样的工具似乎没有立足之地!因此,我们更有必要传播这样的认知:工作流引擎同样可以以去中心化的方式应用于微服务中。这样一来,它很快就能成为与微服务架构和谐共生的关键组件。
6.4.2 The low-code trap 6.4.2 低代码陷阱
Once people get familiar with the idea of a workflow engine, we often run into a problem: the expectation that the magical BPM suite will solve everything. Ideally, we feed the suite 当人们熟悉了工作流引擎的概念后,我们常会遇到一个问题:期望神奇的 BPM 套件能解决一切。理想情况下,我们向套件输入
on models developed by the business before IT systems are automatically integrated and human workflow management just works magically. Finally, we create a dashboard of key performance indicators. These enable the business to recognize process problems in real time and to resolve problems for themselves. 由业务部门在 IT 系统自动集成前开发的模型,人工工作流管理便能神奇般地自动运行。最后,我们创建关键绩效指标的仪表盘。这些指标使业务部门能够实时识别流程问题,并自行解决问题。
This scenario sounds too good to be true, and in practice, it is. Developing process applications is always a form of software development. The promise that this can be taken on by business users in the future is appealing, but it is a promise that cannot be kept. We have seen this over and over. At the end of the day, you need comprehensive wizards and forms to develop process applications in a model-driven way, and the wizards and forms are so complex that they overwhelm the average business user. 这个场景听起来好得不像真的,实际上也确实如此。开发流程应用始终是软件开发的一种形式。未来由业务用户承担这一工作的承诺很诱人,但这个承诺无法兑现。我们已反复见证这一点。归根结底,你需要全面的向导和表单以模型驱动的方式开发流程应用,而这些向导和表单复杂到让普通业务用户不堪重负。
What happens then? The company’s own IT department is called in to take over development. Unfortunately, the first thing the company’s software engineers have to do is figure out the BPM suite. After all, they can’t just apply their prior knowledge of programming languages because the technology has been hidden behind the wizards and forms. Ironically, the aim of making development faster and easier is completely thwarted. 接下来会发生什么?公司内部的 IT 部门会被调来接手开发工作。遗憾的是,软件工程师们首先要做的就是弄懂这套 BPM 套件。毕竟他们无法直接应用之前掌握的编程语言知识,因为技术细节已被隐藏在向导和表单背后。讽刺的是,让开发更快速、更简单的目标完全适得其反。
During our many years of BPM project experience, we have come to realize that this is exactly where the core problem with the classic BPM suite lies. It is especially pronounced in companies that already have been carrying out software development -in Java, for instance. The following disadvantages arise: 在我们多年的 BPM 项目实践中,我们逐渐认识到这正是传统 BPM 套件的核心问题所在。这一问题在那些已经进行软件开发(例如使用 Java)的公司中尤为突出。由此产生以下弊端:
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 引擎可互换性的迷思
We have indicated that some aspects may be solved differently in different products. The flexibility of the standards gives vendors latitude in selecting technology. Can a process model then be executable on different engines? Usually not. That is, we have not yet seen a model that covers real requirements and was able to do it completely without vendor extensions. 我们已指出,不同产品可能以不同方式解决某些问题。标准的灵活性为供应商选择技术提供了空间。那么,一个流程模型能否在不同引擎上执行?通常不能。也就是说,我们尚未见过一个覆盖真实需求且完全无需供应商扩展的模型。
We think that BPMN engine interchangeability is of limited concern. Consider how much time the SQL standard for databases has had to mature. Still, you often want to fall back on features of a product that you know. We find that legitimate. Any requirement for swapping around the workflow engine without having to touch your process solution should not be given too much weight. 我们认为 BPMN 引擎可互换性的关注度有限。试想 SQL 数据库标准经历了多长时间才趋于成熟。即便如此,您仍常会依赖熟悉产品的特性。我们认为这是合理的。对于无需修改流程解决方案即可随意更换工作流引擎的要求,不应给予过多重视。
Most projects end up buying a clearly simplified process execution, such as using Java shortcuts, while sacrificing interchangeability. This is further catalyzed by the fact that Webservices are not exactly touted as the technology of the future, and many projects prefer other technologies. 大多数项目最终都会购买明显简化过的流程执行方案,比如采用 Java 快捷方式,却牺牲了互操作性。这一现象进一步被 Web 服务并未被明确誉为未来技术的事实所催化,许多项目因此更倾向于其他技术。
In short: Don’t make complete interchangeability a sticking point. Just trust that the notation, meaning the BPMN model structures agreed upon with the business (without execution attributes), can survive a switch in engines. 简而言之:不必将完全互操作性作为难以妥协的痛点。只需相信与业务部门达成一致的 BPMN 模型结构(不含执行属性),能够在更换引擎时保持其效力。
6.4.4 Modeling or programming 6.4.4 建模还是编程
Okay, so you’re going to use a BPMN engine. The next questions are which aspects will be expressed through technical process models, and which requirements may it be better to continue addressing with classical software development? As is so often the case, there is no generally applicable answer to this question. Even if some of the following factors sound trivial to you, our experience shows that you will do well not to overlook: 好的,既然决定使用 BPMN 引擎,接下来的问题是:哪些方面应通过技术流程模型来表达,而哪些需求可能更适合继续用传统软件开发方式处理?和大多数情况一样,这个问题没有普遍适用的答案。即使以下部分因素对你而言显得基础,我们的经验表明,忽视它们绝非明智之举:
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 A bad example of modeling. It models too many aspects of the process. 图 6.7 展示了一个糟糕的建模示例,它过度建模了流程的多个方面。
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 展示了一个过度建模的例子。该模型明确展示了客户状态查询的环节。目前,我们是否用信号事件来建模这个流程并不重要。
FIGURE 6.8 The model improved by removing status inquiry from the process. 图 6.8 展示了改进后的模型,通过从流程中移除状态查询环节实现优化。
event (as shown), or with a condition event, or perhaps even with a terminating end event; you can see how complicated the process becomes. It probably isn’t such a good idea to integrate the inquiry into the actual order process. It would be better to model it in its own process or to use a simple service to query the state of the workflow engine’s instance. The only requirement on the engine is that the status must be retrievable. Now look at the modeling in figure 6.8. Whether the inquiry is carried out as a process or as a simple service depends on the architecture. 事件(如图所示)、条件事件,甚至终止结束事件;你可以看到流程变得多么复杂。将查询集成到实际订单流程中可能并不是一个好主意。最好将其建模为独立流程,或使用简单服务查询工作流引擎实例的状态。引擎的唯一要求是必须能够检索状态。现在看图 6.8 中的建模。查询是作为流程还是简单服务执行,取决于架构设计。
Hint: Business-IT-alignment 提示:业务与 IT 对齐
Business-IT alignment doesn’t mean that software can no longer be developed conventionally. It does mean introducing the workflow engine and graphical views of technical processes as additional tools. But beware of process models that are too finely granular! Use diagrams in a way that enables business users to understand the technically executable models. 业务与 IT 对齐并不意味着不能再以传统方式开发软件。它意味着引入工作流引擎和技术流程的图形视图作为额外工具。但要警惕过于细粒度的流程模型!使用图表时应确保业务用户能理解技术上可执行的模型。
In automation projects based around BPMN and DMN, there are some patterns and pitfalls that we would call typical. They depend on the technical environments and the tools used. Vendors address many problems with their features and extensions, so it is hardly worth going into too much detail in this book. Instead, let us give you some examples that will support your understanding of the kinds of problems you may encounter. 在基于 BPMN 和 DMN 的自动化项目中,存在一些我们称之为典型的模式和陷阱。这些取决于技术环境和所使用的工具。供应商通过其功能和扩展解决了许多问题,因此本书无需过多赘述。相反,我们将提供一些示例,帮助您理解可能遇到的各类问题。
Data in the process 流程中的数据
An exciting discussion always takes place in a project: How much data do we want to store in the process? Surely we’ll need all order data for an order process, won’t we? Our recommendation would be the opposite: Store as little as possible -but as much as necessary. It is usually a good idea to store order data in the preceding system for orders. Then, for the process itself, just reference the order number. If the process needs more information to 项目中总会引发一场激动人心的讨论:我们希望在流程中存储多少数据?订单流程当然需要所有订单数据,不是吗?我们的建议恰恰相反:尽可能少存——但存必要的量。通常,将订单数据存储在订单前置系统中是个好主意。然后,流程本身只需引用订单号。如果流程需要在网关处支持决策(例如),它可以通过服务调用加载订单数据。这样做有以下优势:
support a decision at a gateway, for example, it can load the order data using a service call. This has advantages: 支持网关处的决策时,例如,可以通过服务调用加载订单数据。这样做有以下优势:
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 页提到的“准备接收”状态的语义。严格来说,如果没有流程实例处于准备接收状态,传入的事件将会丢失。
FIGURE 6.9 Never miss a message, even if the process is not ready to receive. A feature of the workflow engine or explicit modeling? 图 6.9 即使流程未准备好接收,也绝不遗漏消息。这是工作流引擎的功能还是显式建模的结果?
to receive them. Looking at the example in the upper part of figure 6.9 on the facing page, a delivery order is sent to route planning, then the invoice goes out. If send invoice is a human task, it may take some time. The delivery sent message may come in before the invoice is ready, but we don’t want to lose the message. 接收它们。观察对页图 6.9 上半部分的示例,配送订单发送至路线规划后,发票随即发出。如果“发送发票”是人工任务,可能需要一些时间。配送发送的消息可能在发票准备就绪前到达,但我们不希望丢失该消息。
In technical modeling, pragmatism usually gains the upper hand -and modeling that is completely correct can seem unclear. In principle, workflow engines can solve the issue of an out-of-sequence message by buffering the message. This is an extension of the BPMN standard. If you have this functionality at your disposal, we recommend that you make your approach visible in the model with an annotation. 在技术建模中,实用主义往往占据上风——完全正确的建模可能反而显得不够清晰。原则上,工作流引擎可以通过缓冲消息来解决顺序错乱的消息问题。这是对 BPMN 标准的扩展。如果具备此功能,建议在模型中通过注释明确标注处理方式。
By the way, buffering a message in an engine usually raises an immediate question: What happens if a process never pulls the event out of the queue? The message sender can’t be informed. This means that sophisticated error handling needs to recognize when a process instance terminates the correlated event. As you can already tell, this is no mean feat. 顺便一提,引擎缓冲消息通常会立即引发一个问题:如果流程始终不从队列中提取事件会怎样?消息发送方无法获知此情况。这意味着需要建立完善的错误处理机制来识别流程实例何时终止了关联事件。正如你所见,这绝非易事。
You may have no choice but to restructure the model. You can wait for the event in parallel. As figure 6.9 on the preceding page shows in the lower part, a working alternative is not difficult. This restructuring shouldn’t cause a problem for IT, should it? At the very least, the diagram has become more complicated, and that’s a problem in terms of businessIT alignment. Even this modeling does not always have to be consistent because in some technical environments the answer may arrive before the process moves toward the receive event. Here, again, the devil is in the details. 你可能别无选择,只能重构模型。你可以并行等待事件的发生。正如前页图 6.9 下半部分所示,一个可行的替代方案并不难实现。这种重构对 IT 部门来说应该不会造成问题吧?至少,流程图变得更加复杂了,这在业务与 IT 对齐方面是个问题。即便是这样的建模也不必始终保持一致,因为在某些技术环境中,答案可能在流程到达接收事件之前就已返回。这里,细节决定成败。
Testing processes 测试流程
Testing processes and decisions is crucial. Executable models equate to source code, after all. They need testing in the same way and, as is now common in software development, the tests should be automated. Automated testing has the great advantage of being repeatable at any time at no additional cost. If you change the process, you can repeat the testing to confirm that you haven’t broken anything. Of course this approach means that when you change the model sufficiently, you also have to adapt the test cases. It may seem at first that testing comes at the price of agility, but our experience suggests that you have to take a longer view. Agility is preserved over time because otherwise, at some point, no changes will be possible. You will have become too worried about breaking something. 测试流程和决策至关重要。毕竟,可执行模型等同于源代码。它们需要以同样的方式进行测试,并且正如当今软件开发中的常见做法,测试应当自动化。自动化测试的一大优势在于可以随时重复执行且无需额外成本。若修改流程,可重复测试以确认未破坏任何功能。当然,这种方法意味着当模型改动较大时,测试用例也需相应调整。乍看之下,测试似乎以牺牲敏捷性为代价,但我们的经验表明需从长远角度考量。保持敏捷性是因为若不如此,终将导致无法进行任何修改——届时你会因担心破坏系统而束手束脚。
There are now exciting frameworks for automating tests that make the writing of tests easy to read or that allow test cases to use tables or languages readable by normal people. In addition, mocks make it possible for process tests that are not necessarily integration tests. In other words, during a test, services from the surrounding systems are not called up. This then makes unit tests possible that can be automated easily and without placing a burden on the environment -as long as the engine supports them. 如今已有令人兴奋的自动化测试框架,它们使得测试编写易于阅读,或允许测试用例使用表格或普通人可读的语言。此外,模拟技术使得非必须为集成测试的流程测试成为可能。换言之,在测试过程中不会调用周边系统的服务。这样一来,只要引擎支持,就能轻松实现可自动化且不增加环境负担的单元测试。
Processes are typically tested with specific scenarios that illustrate a run-through of the BPMN model. 流程通常通过特定场景进行测试,这些场景展示了 BPMN 模型的运行过程。
6.4.6 Acceptance criteria when introducing a BPM platform 6.4.6 引入 BPM 平台时的验收标准
If you want to introduce a BPM platform, there are more than technological challenges to overcome. Some aspects we have already addressed: 若想引入 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 所示的方法已被验证有效。
FIGURE 6.10 Best practice for introducing a BPM platform. 图 6.10 引入 BPM 平台的最佳实践。
It’s hard to carry out a sensible evaluation. We regularly see long tables with feature wishes sent to vendors of BPM platforms. The expected answers are yes, no, maybe -so that a score can be easily tallied. Of course, the following happens: The vendor who wants to obtain a high number of points replies yes as often as possible. That’s how he expects to get his foot in the door during an early evaluation phase. Features may hurriedly be introduced just to be able to have more yes answers. Whether or not the feature is really a good solution for the fundamental requirements is sometimes secondary. We had a revealing experience of this when an employee of a potential client called us up secretly and said: “You said no at some places where your competitors said yes. I know that your software is better than the competition’s in this area. Please don’t be too honest, otherwise we will end up having to choose the wrong tool!” 进行合理的评估并非易事。我们经常看到客户向 BPM 平台供应商发送包含功能需求的长表格,期望得到的回答是“是”、“否”或“可能”——以便轻松计算得分。然而实际情况往往是:想要获得高分的供应商会尽可能多地回答“是”,以此在早期评估阶段争取机会。有时甚至会仓促推出某些功能,只为增加“是”的答案数量,而该功能是否真正满足核心需求反而成了次要考量。我们曾有过一个发人深省的案例——某潜在客户的员工私下致电我们说:“在竞争对手都回答‘是’的地方,你们却说了‘不’。我清楚你们软件在这个领域更优秀,但请别太诚实,否则我们最终可能被迫选择错误的工具!”
As we keep saying, process automation projects are always software development projects. If you accept this, then you can see it is not necessary for every requirement to be covered by a zero-code tool. You will remain able to solve many requirements with conventional 正如我们一直强调的,流程自动化项目本质上都是软件开发项目。若能认同这一点,你就会明白并非所有需求都必须通过零代码工具来实现。许多需求仍可通过传统软件开发方式解决,且不必苛求愿望清单上的每一项都得到肯定答复。当“可能”意味着能在项目中实现时,这个答案就已足够。
software development, and you won’t necessarily need to hear yes to every item on your wish list. A maybe may suffice when it means it can be implemented in the project. 什么是恰如其分的决断力?我们会反问:该平台是否提供扩展机制,让你在必要时能自行实现需求?当然,实施成本问题依然存在,厂商的预制方案也仍是理想选择。但最糟糕的情况莫过于平台封闭僵化,让你陷入死胡同。潜在客户往往鲜少深入探究 BPM 供应商的理念或愿景是否与自身相符。
What is appropriately decisive? We would ask: Does the platform offer extensions so that you can implement requirements yourself if needed? Questions of implementation effort remain, of course, and of course, prefabrication by the vendor remains desirable. But the worst thing is a boarded-up platform that leaves you at a dead end. Too rarely do prospective clients inspect the BPM vendor’s philosophy or vision deeply enough to understand if there is consonance with their own. 平台是否具备适当的扩展性?我们更应关注:当需要时,该平台是否允许你自行实现某些需求?实施难度的问题固然存在,厂商预制方案的优势也不言而喻。但最令人束手无策的,莫过于遭遇一个封闭的平台,将你逼入绝境。遗憾的是,潜在客户往往未能深入审视 BPM 供应商的核心理念是否与自身需求契合。
Once you have determined a suitable candidate, we recommend a proof of concept (POC) that implements one of your processes in the planned target environment. By all means, let the vendor assist with this; it will be quicker. In any event, make certain you are present to truly experience how process applications are generated, what effort goes into them, and what kind of know-how is required. Also be alert to tricks that the vendor’s consultants may have up their sleeves, tricks they may be applying secretly to hide shortcomings in their own products. 一旦确定了合适的候选方案,我们建议实施一个概念验证(POC),在计划的目标环境中实现您的一个流程。务必让供应商协助完成这一过程,这样会更快。无论如何,确保您亲自参与,真正体验流程应用程序是如何生成的,投入了多少努力,以及需要什么样的专业知识。同时,要警惕供应商顾问可能暗中使用的技巧,这些技巧可能是为了掩盖他们产品中的缺陷。
Prior to the POC, you have to be absolutely clear about your goals. Are you seeking to verify if the tool will fit into your architecture and is able, for example, to call up your specific services correctly? Do you have a whole catalog of questions you are seeking to put to the vendor? Are you looking to showcase a wide variety of choices as a way of selling BPM or a particular tool to decision makers within your own company? The POC will be designed differently for different goals. It’s therefore essential for all parties to be clear on what the goal is. 在进行概念验证之前,您必须非常清楚自己的目标。您是想验证该工具是否能融入您的架构,并能够正确调用您的特定服务吗?您是否有一系列问题要向供应商提出?您是否希望通过展示多种选择来向公司内部的决策者推销 BPM 或特定工具?不同的目标将设计出不同的概念验证方案。因此,所有参与方都必须明确目标是什么。
Once you decide on a tool, you should move quickly to implement a suitable process. Put this process into live operation! Suitable processes should be: 一旦选定工具,就应迅速实施合适的流程。将该流程投入实际运营!合适的流程应具备以下特点:
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 平台任务录入其中或许是明智之举。这意味着终端用户(流程参与者)既无需使用新界面,也无需操作两个不同任务列表。若正在替换现有工作流管理工具,终端用户可能完全感知不到变更。
In your first project, you should move forward as quickly as possible and not spend too much time on conventions, patterns, or setting up your own process-application blueprint. You will learn so much during the first project that you will be better off to plan time after 在你的第一个项目中,应该尽快推进,不要在约定、模式或建立自己的流程应用蓝图上花费太多时间。你会在第一个项目中学到很多,之后安排时间会更明智。
the project for analysis and documentation of lessons learned and best practices. Best of all will be to review your process once more after the fact. It will surely have a spotlight on it, and you can hope that many others will seek to copy what you did. To summarize: Revising your first project afterwards will cost you a lot less than trying to get it completely right the first time. In principle, this is us recommending an agile approach. 用于分析和记录经验教训及最佳实践的项目。最好的做法是在事后再次审查你的流程。它肯定会受到关注,你可以期待许多人会试图复制你所做的事情。总结来说:事后修订你的第一个项目将比第一次就试图完全做对花费少得多。原则上,这是我们推荐的一种敏捷方法。
Armed with this, you can venture out confidently to meet your next projects. We hope you have lots of fun automating your business processes! Further information on BPM tools can be found in section 7.4.1 on page 202. 有了这些知识,你就可以自信地迎接下一个项目了。希望你在业务流程自动化中找到许多乐趣!更多关于 BPM 工具的信息可以在第 202 页的 7.4.1 节找到。