BPMN 记录流程。
memodya 驱动流程。
BPMN 图通常只为手册或审计绘制一次，随后便逐渐过时。memodya 将同样的工作建模为方法，包含真实的输入、输出、工具和人员，您的团队每天都在这个模型中工作。
并排对比
同一流程， 两种模型。
同样是架构定义的四个步骤，分别用 BPMN 2.0 绘制和在 memodya 中建模。
用 BPMN 2.0 绘制
- 1 文档挂在跨越泳道和流程的虚线上，没有任何校验。
- 2 角色变成了泳道。Clemens 既是架构师又是审核人，所以他的任务要画两次。
- 3 BPMN 没有表示工具的符号，最终只能写进自由文本注释里。
- 4 为审计而绘制，上次打开已是几个月前，内容早已过时。
在 memodya 中建模1234
收集需求
需求工程师 定义
已完成第 38 周
起草架构
架构师 设计
已完成第 41 周
审核架构
审核人 验证
进行中62%
发布接口规格
架构师 发布
已计划第 44 周
需求
用户故事
架构
已批准 架构
审核发现
接口规格
Jira
Draw.io
Modeler
ModDoc
Confluence
Anna
Stefan
Clemens
Clemens
审核智能体
Stefan
- 1 每个方法的输出就是下一个方法的输入。需求一变，“起草架构”立刻知晓。
- 2 Clemens 被关联到他参与的两个方法上。没有泳道，没有重复。
- 3 工具直接挂在使用它的方法上。
- 4 每个方法都显示实时状态和排期，团队每天都在其中工作。
深入对比
BPMN 的短板 在工程团队中暴露无遗。
1. 输入与输出
BPMN
松散的数据关联
数据对象通过可选的虚线关联附加。没有任何信息说明某个任务使用了哪个版本的需求，也无法得知需求变更时哪些步骤会受影响。
memodya
明确声明、相互连接的依赖
每个方法都声明了自己的输入和输出。这些连接是真实的依赖关系，因此需求一旦变更，所有受影响的下游方法都会清晰呈现。
2. 角色
BPMN
泳道把人挤到了一边
每个任务只能位于一条泳道中。真实的协作会让流程在泳道间来回穿梭，或导致任务重复；每次组织调整都意味着要重新绘图。
memodya
人员关联到工作，而非困在泳道里
人员、角色和 AI 智能体直接关联到方法本身。一个步骤可以有多位参与者，团队变动时布局保持不变。
3. 工具
BPMN
数百个符号，却没有一个代表您的工具
BPMN 2.0 拥有庞大的符号集，但没有任何符号可表示 CAD、仿真、测试台架或工程师实际使用的建模工具。
memodya
五个基本构件
方法、输入、输出、工具和角色。团队中的任何人无需学习建模符号即可阅读和编辑模型。
4. 文档记录 vs. 日常使用
BPMN
流程的一张快照
BPMN 模型是为手册、流程门户和审计而制作的。工作进行时很少有人打开它们，因此它们与团队的实际工作方式渐行渐远。
memodya
模型即工作区
状态、排期和负责人都记录在每个方法上。团队在模型中规划和跟踪工作，模型因被使用而始终保持最新。
如何选择
合适的工具， 用在合适的地方。
BPMN 仍然适用的场景
当由工作流引擎执行流程图时，或用于采购审批、员工入职等稳定的业务流程时，BPMN 是一个可靠的标准。如果您的流程很少变化且由机器执行，请继续使用 BPMN；如果由工程师执行且每隔几周就会变化，请在 memodya 中建模。
- 由工作流引擎执行流程图
- 采购审批、员工入职等稳定的业务流程
- 审计方或合同要求使用 BPMN 2.0
memodya 更胜一筹的场景
当工作由人而非引擎完成、且流程持续变化时。memodya 将模型与日常工作放在同一处，团队在使用中让地图始终真实准确。
- 每隔几周就会变化的工程与研发工作
- 有多位参与者的步骤：人员、角色和 AI 智能体
- 需要看清某个步骤依赖什么、一项变更会影响什么
- 团队在模型中规划和跟踪工作，而不只是记录文档