经常碰到这样的情况，你和他谈流程，他和你说工作流，你和他说职责，他和你说审批。你和他讨论业务结构，他却一直盯着待办列表。

多数情况下是口语的误用和概念的偏差，翻译翻译,可能更好理解。

业务流程=Business Process,  工作流=Workflow。

业务流程如下图:

工作流如下图：

表面上看，大家讨论的是同一件事；实际上，很多时候根本不是。多数争论，不是因为谁对谁错，而是因为概念层级没对齐。

流程和工作流这两个词关系很近，但不是一回事。把它们混为一谈，轻则讨论失焦，重则系统设计从一开始就歪了。

一、流程和工作流，到底差在哪

流程，解决的是“业务如何成立”。
工作流，解决的是“工作如何流转”。

流程是更高层的结构。它关心的是，为了完成某个业务目标，企业需要经历哪些关键活动、形成哪些结果、满足哪些约束。它讨论的是业务如何展开、责任如何承接、结果如何形成。

震惊！歪果仁吃个披萨也画业务流程图

工作流则更贴近系统执行。它关心的是，某项任务现在到谁手里了，下一步该谁处理，是否审批通过，是否超时，是否退回。它讨论的是任务如何在人和岗位之间流动。

理解工作流很容易，理解流程很困难。所以，工作流最适合什么？

适合审批。
适合工单流转。
适合任务编排。
适合人工协同。

因为在这些场景里，系统最关心的问题是：

• 现在在哪一步？

• 下一步该谁处理？

• 有没有走完？

• 卡在哪个节点？

  
  

这是一种非常典型的协调与推进视角。

但问题在于，企业经营里最关键的那些问题，很多并不属于这个视角。

二、ERP 的底层，不是“步骤视角”，而是“事件视角”

很多人理解企业系统，天然会先想到流程图。

订单之后是发货，发货之后是开票，开票之后是收款。仿佛系统的本质，就是沿着一条预设路线一步步往前走。

这种理解很直观，但它不是 ERP 交易建模最底层的哲学。

ERP里有没有流程？

ERP，尤其是 SAP 这类成熟 ERP，更接近另一种视角：

事件视角。

事件视角不先问“现在轮到谁处理”，而先问：

• 已经发生了什么？

• 这些发生过的事分别是什么类型？

• 它们之间有什么关系？

• 它们共同造成了什么状态？

  
  

这不是一个协调视角，而是一个事实与证明视角，这件事非常关键。

因为企业真正关心的问题，往往不是，“任务有没有流给下一个人？”

经营-为什么说流程优化，不是把流程缩短，而是把经营约束设计正确16

而是：

• 货到底发没发？

• 到底发了多少？

• 哪张发票对应了哪些交付？

• 哪笔款到底清了哪些应收？

• 这次成本确认究竟基于什么事件？

• 这个余额为什么还在？

  
  

这些问题，都不能靠“流程走到哪一步”来回答，只能靠“已经发生的事实，以及事实之间的关系”来回答。

也就是说：

流程节点可以告诉你事情推进到了哪里。
但只有事件关系，才能告诉你事情到底成立没有。

三、为什么流程图一旦进入真实业务，很快就不够用了

如果业务世界永远是标准直线，那流程图当然足够，但真实企业从来不是这样。

现实中的交易关系，几乎天然就是复杂的：

• 一张订单可能分多次交付

• 多张交付可能合并成一张发票

• 一张发票可能被部分收款、部分折扣、部分核销

• 之后还可能退货、补货、红冲、重开

• 同一前序结果，会被多个后续动作逐步消耗

  
  

这时候，问题就来了。

如果你还是用“先到 A，再到 B，再到 C”的线性流程去理解业务，你会发现系统越来越别扭。因为真实世界不是单线推进，而是多节点、多关系、可拆分、可合并、可部分消耗、可反向调整的。

所以，ERP真正强的地方，不是把东西“排成一条线”，而是把业务建成一张事实关系网。

你最终看到的流程，很多时候并不是先写死的脚本，而是从这张关系网里长出来的结果。

四、SAP 真正厉害的地方，不是“单据相连”，而是“关系可工程化”

很多人会说，SAP 不就是单据之间有关联吗？这句话不算错，但远远不够。

SAP 的厉害，不在于“有关联”，而在于它把“关系”做成了一个工程对象。这个关系，不是普通意义上的链接，而是同时具备至少四种属性。

1. 有方向

不是任意两个单据随便连一下就叫关系。

谁是前序，谁是后续；谁引用谁，谁由谁派生；谁为谁结算，谁对谁清算；这些都必须有方向。

方向一旦确定，业务语义就确定了。发票不是“碰巧关联”交付，而是“基于”交付形成；收款也不是“碰巧对上”发票，而是“对”应收进行清算。

方向，决定了因果。
因果，决定了追溯。

2. 有粒度

很多系统一谈关联，只会连单据头。但真实业务不是这么运作的。

关系往往要落到行项目，甚至落到部分数量、部分金额。不是整张订单都发掉了，也不是整张发票都收完了。系统必须知道，到底是哪一行、哪一部分，被后续动作消耗了。

没有这个粒度，所谓“部分交付”“部分开票”“部分收款”就都只能停留在嘴上，系统根本算不准。

3. 有消耗

后续不是“看过前序”就结束了，后续会真正消耗前序的可用范围。

交付会消耗订单中的可发数量；开票会消耗可开票范围；收款会消耗应收余额；退货、冲销、红字又会反向修正已经形成的结果。

这意味着，关系不是静态的“我认识你”，而是动态的“我占用了你多少”。

一旦进入企业交易世界，这一点极其重要。因为状态不是靠手工打标签得出的，而是靠前后关系与消耗计算推导出来的。

4. 有约束

不是任意节点都能相连，也不是任何连接方式都成立。

什么能引用什么，什么能派生什么，什么允许拆分，什么允许合并，什么必须一一对应，什么情况下允许冲销和重开，这些都受业务规则限制。

只有当关系是受约束的，这张网才不是“拼起来的数据”，而是“站得住的证据链”。

五、流程视角和事件视角，是两种完全不同的系统哲学

因为很多系统做着做着失败，不是因为功能少，而是因为底层哲学搞反了。

1）流程视角：它关注推进

流程视角问的是：

• 现在在哪一步？

• 下一步该谁处理？

• 有没有走完？

• 卡在哪个节点？

  
  

这是一个典型的协调与推进视角。

它特别适合审批、工单、人工协同、任务编排。因为在这些场景里，系统的使命就是推动事情往前走。

2）事件视角：它关注成立

事件视角问的是：

• 已经发生了什么？

• 这些事实是什么类型？

• 它们之间是什么关系？

• 它们共同造成了什么状态？

这是一个典型的事实与证明视角。

它不首先关心“谁还没点按钮”，而关心“什么事实已经被系统确认、记录、连接、清算和反映”。

阅读原文​