[点晴模切ERP]流程不是工作流：为什么很多企业一开始就理解错了
经常碰到这样的情况，你和他谈流程，他和你说工作流，你和他说职责，他和你说审批。你和他讨论业务结构，他却一直盯着待办列表。
多数情况下是口语的误用和概念的偏差，翻译翻译,可能更好理解。
业务流程=Business Process, 工作流=Workflow。
业务流程如下图:
工作流如下图：
表面上看，大家讨论的是同一件事；实际上，很多时候根本不是。多数争论，不是因为谁对谁错，而是因为概念层级没对齐。
流程和工作流这两个词关系很近，但不是一回事。把它们混为一谈，轻则讨论失焦，重则系统设计从一开始就歪了。
流程，解决的是“业务如何成立”。
工作流，解决的是“工作如何流转”。
流程是更高层的结构。它关心的是，为了完成某个业务目标，企业需要经历哪些关键活动、形成哪些结果、满足哪些约束。它讨论的是业务如何展开、责任如何承接、结果如何形成。
工作流则更贴近系统执行。它关心的是，某项任务现在到谁手里了，下一步该谁处理，是否审批通过，是否超时，是否退回。它讨论的是任务如何在人和岗位之间流动。
理解工作流很容易，理解流程很困难。所以，工作流最适合什么？
适合审批。
适合工单流转。
适合任务编排。
适合人工协同。
因为在这些场景里，系统最关心的问题是：
现在在哪一步？
下一步该谁处理？
有没有走完？
卡在哪个节点？
这是一种非常典型的协调与推进视角。
但问题在于，企业经营里最关键的那些问题，很多并不属于这个视角。
很多人理解企业系统，天然会先想到流程图。
订单之后是发货，发货之后是开票，开票之后是收款。仿佛系统的本质，就是沿着一条预设路线一步步往前走。
这种理解很直观，但它不是 ERP 交易建模最底层的哲学。
ERP，尤其是 SAP 这类成熟 ERP，更接近另一种视角：
事件视角。
事件视角不先问“现在轮到谁处理”，而先问：
已经发生了什么？
这些发生过的事分别是什么类型？
它们之间有什么关系？
它们共同造成了什么状态？
这不是一个协调视角，而是一个事实与证明视角，这件事非常关键。
因为企业真正关心的问题，往往不是，“任务有没有流给下一个人？”
经营-为什么说流程优化，不是把流程缩短，而是把经营约束设计正确16
而是：
货到底发没发？
到底发了多少？
哪张发票对应了哪些交付？
哪笔款到底清了哪些应收？
这次成本确认究竟基于什么事件？
这个余额为什么还在？
这些问题，都不能靠“流程走到哪一步”来回答，只能靠“已经发生的事实，以及事实之间的关系”来回答。
也就是说：
流程节点可以告诉你事情推进到了哪里。
但只有事件关系，才能告诉你事情到底成立没有。
如果业务世界永远是标准直线，那流程图当然足够，但真实企业从来不是这样。
现实中的交易关系，几乎天然就是复杂的：
一张订单可能分多次交付
多张交付可能合并成一张发票
一张发票可能被部分收款、部分折扣、部分核销
之后还可能退货、补货、红冲、重开
同一前序结果，会被多个后续动作逐步消耗
这时候，问题就来了。
如果你还是用“先到 A，再到 B，再到 C”的线性流程去理解业务，你会发现系统越来越别扭。因为真实世界不是单线推进，而是多节点、多关系、可拆分、可合并、可部分消耗、可反向调整的。
所以，ERP真正强的地方，不是把东西“排成一条线”，而是把业务建成一张事实关系网。
你最终看到的流程，很多时候并不是先写死的脚本，而是从这张关系网里长出来的结果。
很多人会说，SAP 不就是单据之间有关联吗？这句话不算错，但远远不够。
SAP 的厉害，不在于“有关联”，而在于它把“关系”做成了一个工程对象。这个关系，不是普通意义上的链接，而是同时具备至少四种属性。
不是任意两个单据随便连一下就叫关系。
谁是前序，谁是后续；谁引用谁，谁由谁派生；谁为谁结算，谁对谁清算；这些都必须有方向。
方向一旦确定，业务语义就确定了。发票不是“碰巧关联”交付，而是“基于”交付形成；收款也不是“碰巧对上”发票，而是“对”应收进行清算。
方向，决定了因果。
因果，决定了追溯。
很多系统一谈关联，只会连单据头。但真实业务不是这么运作的。
关系往往要落到行项目，甚至落到部分数量、部分金额。不是整张订单都发掉了，也不是整张发票都收完了。系统必须知道，到底是哪一行、哪一部分，被后续动作消耗了。
没有这个粒度，所谓“部分交付”“部分开票”“部分收款”就都只能停留在嘴上，系统根本算不准。
后续不是“看过前序”就结束了，后续会真正消耗前序的可用范围。
交付会消耗订单中的可发数量；开票会消耗可开票范围；收款会消耗应收余额；退货、冲销、红字又会反向修正已经形成的结果。
这意味着，关系不是静态的“我认识你”，而是动态的“我占用了你多少”。
一旦进入企业交易世界，这一点极其重要。因为状态不是靠手工打标签得出的，而是靠前后关系与消耗计算推导出来的。
不是任意节点都能相连，也不是任何连接方式都成立。
什么能引用什么，什么能派生什么，什么允许拆分，什么允许合并，什么必须一一对应，什么情况下允许冲销和重开，这些都受业务规则限制。
只有当关系是受约束的，这张网才不是“拼起来的数据”，而是“站得住的证据链”。
因为很多系统做着做着失败，不是因为功能少，而是因为底层哲学搞反了。
流程视角问的是：
现在在哪一步？
下一步该谁处理？
有没有走完？
卡在哪个节点？
这是一个典型的协调与推进视角。
它特别适合审批、工单、人工协同、任务编排。因为在这些场景里，系统的使命就是推动事情往前走。
事件视角问的是：
已经发生了什么？
这些事实是什么类型？
它们之间是什么关系？
它们共同造成了什么状态？
这是一个典型的事实与证明视角。
它不首先关心“谁还没点按钮”，而关心“什么事实已经被系统确认、记录、连接、清算和反映”。
阅读原文
