BPM建模
看清流程图与可执行模型的分界，掌握BPMN元素的语义边界与常见误读
按 空格/→ 演示下一步
全部页面点击任意一页，跳回舞台从这页播放
BPM建模
看清流程图与可执行模型的分界，掌握BPMN元素的语义边界与常见误读
A of ARM
BPM建模把业务流程拆解到可执行层级。在ARM框架中，A代表Activity（活动），是流程的最小执行单元，每个活动都有明确的开始和结束。
工位接收半成品、完成单一加工、传给下个工位，对应活动的输入—处理—输出
R of ARM：物理对象相关性
上一页 A of ARM 讲了活动节点。但每个活动都会处理或产出「看得见、摸得着」的东西——表单、合同、报表、原材料。这些物理对象之间存在的关联关系，就是 R 要回答的核心。
面粉→面团→面包，每步产出即下步输入，活动通过共享对象相连
R of ARM：同步器回顾
R of ARM：同步器回顾：定义、要点与典型应用
R+M of ARM：业务逻辑
前页同步器控制了流程的『时间节奏』，物理对象相关性理清了『实体依赖』。但流程为什么走A分支而不是B？这取决于规则（R）和消息（M）的组合——这就是本节要拆的业务逻辑。
R是『超过3天需HR介入』这类条件规则，M是『请假单内容』这样的传递信息
M of ARM：化简规则
上页堆叠起来的业务逻辑，往往会让一张流程图变成上百节点的毛线团。化简规则就是告诉你：哪些节点可以合并、哪些结构能折叠，让模型重新可读。
地图不会画每扇门，化简不会画每个网关；忠实反映主干路径即够用
R+M of ARM：案例语义
上一页把 R 与 M 的业务逻辑拼出来了，那是模型层面的事。现在落到一次具体的执行——也就是一个案例——它到底是怎么跑起来的？
一个病历夹装一位患者的所有检查、处方、缴费；一个案例装同一实例的全部资源和消息
R+M of ARM：管理逻辑
上一页我们讲了业务逻辑——流程里每一步「做什么」的规则。但流程真跑起来，谁来接收？超时了交给谁？这类「谁来处理、怎么流转」的问题，正是管理逻辑要回答的。
分拣中心自己不送件，但读地址、看优先级，决定包裹上哪辆车——管理逻辑也不干业务活，只决定任务怎么流转
M of ARM：BPMA
前面看过化简规则和管理逻辑——它们要成立，都得跑在一个能被数学化讨论的『流程模型』上。这个模型，就是 ARM 里 M 层所依托的 BPMA。
A 是承重结构、R 是机电管线，BPMA 把整套工程变成可审查、可计算、可施工的总图
本节要点
- ✓ARM 把流程拆成 A/R/M：谁触发、按什么规则、模型结构是什么
- ✓同一物理对象的不同实例，是流程分支的天然切分点
- ✓同步器＝多输入汇聚触发，是规则层的两类基本算子之一
- ✓化简规则保证：敢画复杂图，必能等价压缩回最小表达
- ✓业务逻辑讲"做什么"，管理逻辑讲"谁做、能否做"——别混
课后思考
先自己想，再对照参考答案，体会思考路径。
参考答案A 承担「谁来做」的意图，R 承担「借助什么做」的能力。拆开后改派工或换工具时各层独立变化，模型更稳。
参考答案两个 A：客户与客服；同一 R：业务系统。自助路径调 R 完成订单，异常分支由客服接管，M 决定何时转人工。
参考答案可揪出隐含 A（谁实际在做）、错位 R（把流程节点当资源）、漏掉的同步器（谁等谁）、可合并的多余环节。