1. 为什么EOM最终要落成一种“语言”而不是一套“方案”1.1 方案会过时语言不会我做企业管理软件项目这么多年最怕的不是需求复杂而是老板在系统上线之后忽然问一句“我们企业的经营逻辑到底是什么样的”按理说系统里什么都有订单、审批、报表、库存、合同可大家只能说出“哪里有个按钮”说不清“企业是靠哪些对象、哪些动作、哪些规则在运转”。这就是EOMEnterprise Operating Model企业经营模型想要回答的问题也是SMP软件制作平台语言把“经营模型”这种听起来很上层的东西硬塞进“语言基础知识”系列里的原因。这篇是系列第四十六篇。上篇《EOM的由来上》已经讲过EOM不是商学院哪本教材里突然蹦出来的概念而是企业信息化从记账、流程、数据报表一路摩擦之后被大家共同意识到的一套结构化共识。这篇下篇我打算把视角完全转到工程侧EOM在SMP语言里到底由哪些基础构件组成、为什么是这些构件、以及实际建模时最容易在哪几个地方翻车。没看过上篇的朋友也不用着急关键前提我会简单重述不影响往下读。我一直想用一个词来形容EOM和传统软件方案的区别方案会过时语言不会。企业数字化最难的不是“上系统”而是系统跑起来之后业务逻辑就被冻结在某一个版本里。两年前某制造企业上了一套成熟的进销存采购、库存、应付全都跑通了今年管理层决定改成“以销定产”模式结果发现改起来比重新买一套还痛苦。为什么因为当初的规则散落在几十个事务脚本里订单、计划、领料之间的联动关系没有任何一处能一眼看全。所以我在项目里越来越坚持一个判断如果交付物是一堆页面和报表那这套应用三年之后基本就是遗物如果交付物是一组可读、可解释、可调整的经营模型那业务再怎么变模型跟着改页面、按钮、表结构都会自动跟着调整。EOM之所以必须长成“语言”而不是“方案”就是因为它要跨越具体业务版本继续存活就像自然语言比某一套契约文本更能承载思想的演化——契约有可能失效语言却可以不断长出新句子。1.2 EOM的三个层次经营认知、模型表达、系统实现为了让EOM不变成那种人人都在说、却没人知道怎么落地的黑话我习惯把它拆成三个可以动手操作的层次。第一层是经营认知回答的是“企业到底靠什么赚钱、主要有哪些经营循环”。这一层通常发生在顾问和老板的对话里产出可能只是一张手绘的循环图市场线索进来变成商机商机变成合同合同变成订单订单变成交付交付变成回款回款又变成新市场的投入。别小看这张图很多企业连这一层都没对齐老板说“我们是项目型销售”销售总监却说“我们也有不少标准产品订单”。第二层是模型表达把经营认知变成一组结构化对象比如客户、商机、合同、订单、发票、回款以及它们之间的关系、状态、规则。这是EOM真正的核心地带也是SMP语言最能施展开拳脚的地方。第三层是系统实现把这些模型落到具体的界面、数据库表、接口、权限和报表上。传统开发方式里这三层是完全割裂的业务文档归顾问管数据库设计归架构师管页面交互归前端管。SMP的核心思路是用第二层“模型表达”直接驱动第三层“系统实现”让模型不只是文档而是可运行的东西。我常打一个比方经营认知是剧本模型表达是分镜脚本系统实现是电影成品。绝大多数项目缺的从来不是创意而是中间那层分镜脚本。EOM真正值钱的部分恰恰就在“模型表达”这一层因为它要求把口头上的业务理解变成没有歧义、可以校验、可以被平台执行的语句。1.3 SMP语言要回答的四个问题在SMP语言里一段文章也好、一份模型设计也好想证明自己建立了EOM必须连续回答四个问题。第一个问题有哪些经营对象比如“订单”是一个对象“订单行”是另一个对象“客户”和“物料”同样是对象。第二个问题对象之间是什么关系客户“拥有”订单订单“引用”物料发票“关联”订单销售组“负责”客户。第三个问题对象经历哪些动作创建、提交、审核、发货、开票、核销这些动作不是普通按钮而是带有经营语义的状态变更。第四个问题动作受什么规则约束金额超过某个阈值要二次审批库存不足时自动触发采购建议信用额度超额时订货方式自动改成款到发货。四个问题全部答完才可以说这个项目的EOM建好了。只要还有一个问题答不上来我就建议先别急着设计数据库表。因为表结构只是模型某一部分的物理投影业务语义没定义清楚投影一定是歪的。我见过太多项目一上来就开表、建索引结果业务规则只能靠后端的 if 语句一块一块补补到最后连写代码的人都说不清完整链路——那不是EOM那只是把数据库暴露成了一个没人能读懂的线团。2. EOM由来的真实路径从科目、流程到经营对象2.1 第一代记账系统里的科目思维要讲EOM的由来不能只看理论得看企业管理软件背后的思维是怎么一步步演变的。第一代典型系统本质上就是“记账系统”。它的核心思维是会计科目借方、贷方、应收、应付、库存成本。那时候一个企业的“模型”其实就是一套科目表所有业务最终都被折算成金额进入某个科目。科目思维的长处是极其严谨银行、审计、税务都喜欢它但短处也很致命它只能描述“钱去了哪里”很难描述“是谁做的、因为什么触发、下一步会怎么样”。老牌财务系统可以几十年稳定运行但想让它跑通销售、交付、回款这整条经营链路几乎不可能。早年我接手过一个基于科目逻辑改的进销存项目光“订单来源”这个字段就争论了三个月。原因就是科目思维里根本没有“订单”这种非货币对象的位置可业务上又确实需要它于是只能硬塞塞完之后整个报表逻辑全乱了。2.2 第二代流程引擎里的动作思维第二代管理软件把重心从“钱”挪到了“事”上于是工作流、审批流大行其道。这一代的核心词汇是“动作”提单、审批、转交、会签、归档。到这一步系统开始有了一点点动态色彩。一个合同可以从草稿变成审批中再变成已生效责任人、时间点、审批意见都记录得清清楚楚比记账时代前进了一大步。但流程引擎也把一批项目带进了沟里。问题出在它把“动作”当成了第一公民“对象”反而被降级成表单上一堆字段。同一个合同对象在销售流程里是一套字段在财务流程里是另一套字段两个系统之间只靠一个合同编号做弱关联。结果就是流程越画越多数据越拆越碎。后来数据中台、主数据管理这些概念火起来本质上都是在给流程时代拆碎的对象“还债”。我在项目里见过一个极端案例同一家客户的“收货地址”在销售系统、物流系统、开票系统里各存一份客户改了个门牌号三个系统各改各的最后没人知道哪份是真的。2.3 第三代对象、关系、规则组成的经营思维直到大家把注意力从“流程”挪回“对象”本身事情才出现转折。所谓对象就是企业运行里真正要紧的那些东西商机、报价、订单、计划、物料、产品、合同、发票、回款。EOM的雏形正是从这里冒出来的先定义对象以及对象之间的关系再把动作挂在对象上把规则写在动作前后最后才把这一切呈现为界面、列表和报表。这个顺序非常关键相当于把流程降级了。流程只是“某个对象在特定角色手中被转交、并在状态机上发生变更”的外在表现。以订单对象为例订单有草稿、已提交、已审核、已发货、已关闭这些状态每一次状态变更就是一次动作谁有权限执行这个动作就是权限控制金额达到多少要送回上级复核就是规则。把这些定义清楚之后哪怕不画一条流程图业务过程也已经成立了。流程引擎只是在运行时把模型里已经存在的状态迁移可视化而已。2.4 为什么说EOM是被逼出来的EOM不是某个人灵光一现创造的新词。它是三代信息化思路反复摩擦之后形成的共识。记账系统回答了“钱怎么记”流程系统回答了“事怎么走”中台和数据仓库回答了“数据怎么聚”却始终没人能好好回答那个老板最常问的问题我们完整的经营链路到底是什么这时候能兜住所有碎片的方法只有一个以经营对象为骨架、以关系为连接、以动作和规则为活组织、以指标为反馈信号构建一套可运行、可观察、可调整的模型。这就是EOM的由来也解释了为什么它天生和SMP这类软件制作平台绑定在一起——因为它需要的不是一张写满方针的战略地图而是一套能把“模型”直接变成“系统”的语言。我做得越多越确认数据治理之所以常常失败是因为只敢在残缺模型上做表面清洁真正该建设的是从业务语义出发的模型基座。3. SMP语言中EOM的六个基础构件3.1 经营对象把订单、物料、商机当成同一类公民如果把EOM比作一栋房子经营对象就是承重墙。在SMP语言里一个对象不只是数据库表也不只是页面上的一个列表它是一组语义的集合。它包含三样东西。一是属性比如订单有编号、日期、金额、负责人二是分类要区分主数据对象和事务对象客户、物料是主数据订单、发票是事务三是生命周期也就是这个对象允许存在哪些状态。定义对象时我会先问一句这个东西在真实经营中会不会被单独追溯、单独审批、单独统计如果会它就有资格成为独立对象如果它只是另一个对象的明细行那就老老实实定义为子表不要升级成对象。曾有一个团队把“订单行”建成了独立对象于是订单行的状态、权限、审批都要单独挂一套结果逻辑层级全乱返工了大半个月。这个教训让我一直坚持经营对象必须对应大家日常挂在嘴边的经营词汇而不是数据库范式的物理拆分。还有团队用数据库逆向工程工具把表结构自动生成对象省事是省事但生成出来的是“表对象”不是“经营对象”。比如一个状态字段存的是 0 和 1可业务语义其实是“草稿、待审、已审、作废”四种状态。如果建模时没把枚举语义补进去后面所有规则写起来都会又丑又脆。3.2 经营关系让对象之间长出明确的挂接方式对象之间如果没有关系就只是一份名词清单。EOM里常见的关系类型有四类引用、归属、追溯、汇总。引用就是订单引用了客户、订单行引用了物料归属是合同归属于某个销售组、项目归属于某个交付团队追溯是发票能追到对应订单和发货单回款能追到对应发票汇总则是订单汇总到月度销售统计、成本中心汇总到部门损益。在SMP语言里这些关系最好显式声明而不是靠“外键字段长得像”去猜测。显式声明以后很多麻烦会自动消失做数据权限时按归属过滤做报表时按汇总聚合做审计时按追溯穿行。我见过一些项目组为了“灵活”把所有关系都做成一张通用关联表字段A关联字段B类型用另一个字段表示。结果查询性能一路暴跌业务规则也写不进去。关系一旦脱离语义灵活就变成了混乱。EOM的关系必须是可在模型里被看见、被校验、被解释的否则它无法承担“企业经营模型”这个身份。3.3 经营动作从增删改查升级到事务语义对象定义完了下一步是定义动作。传统低代码平台喜欢给每个对象自动生成一堆增删改查按钮但在EOM语境下这远远不够。订单审核不是一个简单的“把状态改成已审核”它往往还意味着库存预留、价格锁定、联动生成生产计划、给商务负责人推一条待办消息。所以SMP里的经营动作至少包含三个部分前置条件判断什么情况下可以执行核心操作描述对象和关联对象发生的数据变化后置效果列出执行后会触发什么联动、生成什么待办、更新什么指标。我习惯把这种设计叫“服务化动作”。建模型时一旦把审核订单、撤销审核、变更发货地址都当成独立动作来看待而不是给状态字段写一堆 if权限、审计、二次开发都会清楚得多。更重要的是动作应该有语义名称。在代码里写“order.updateStatus(3)”没人知道是干嘛写成“submitOrderForApproval”所有人一看就懂。EOM是组织对自身运行逻辑的成文记忆动作命名就是这份记忆的目录。3.4 业务规则给模型装上判断与决策业务规则是六个构件里最能体现企业差异的部分。同样是销售订单不同行业的玩法完全不同订货超过信用额度要转款到发货特种物料必须经过质量放行金额超过一定级别要总裁办会签。SMP语言里的规则最好是声明式的例如RULE Order_Audit_Level WHEN order.totalAmount 1000000 THEN action.auditRoute VP_SALES, CFO这种写法可测试、可追溯也不容易被事务代码绕过去。规则必须能回答“什么条件下、执行什么路径”。我在项目里坚持一个习惯每条规则都有唯一编号和业务解释字段否则三个月后没人记得当初为什么要写这条。尤其是一些反直觉的例外规则比如“重点客户的订单可以免预付款”如果只留下代码逻辑后面的人一定会觉得那是 bug。3.5 经营指标让模型输出可用数字EOM如果没有指标就像人没有神经反馈。模型里的对象、动作、规则都数字化了指标才能从中“长”出来。常见指标模式有三种统计型比如本月新签合同金额状态型比如当前待发货订单数量质量型比如订单一次审核通过率。指标定义最容易出问题的是口径。同样叫“回款金额”一个报表用含税口径一个报表用不含税口径结果必然对不上同样叫“新签合同”一个按审核通过时点算一个按创建时点算结果也差很多。EOM里指标一定要挂到明确的动作和状态上并写明口径。我习惯把所有统计口径做成一页说明书同时把关键解释写进模型注释里。这样一来就算将来和财务、运营扯皮至少有一个权威依据可以拿出来对齐。3.6 权限与协同回答谁能看、谁能做、怎么交接EOM天生是多人协作的产物权限不能被当成界面配置的附属品。在SMP语言里权限通常跟着组织和角色走销售人员只能看到自己名下的客户销售总监能看到整个大区财务人员可以查看订单金额但不能修改订单内容。协同则表现为待办、通知、会签状态谁审核、谁记录、谁被超时提醒。这些都不是写死在某个按钮上的而是由经营动作和规则自动推导出来的。我吃过一次亏某个订单模块做到后期才加数据权限结果发现“归属部门”跟“组织架构”是两套维度当初的对象关系里根本没有设计这个维度最后只能大幅返工。现在我的建议很直接权限设计者从建模第一天就参与哪怕一开始只定对象归属关系不给具体角色分配也比最后硬加一套权限过滤要好得多。构件一句话本质经营对象企业里要被追溯、审批、统计的名词经营关系对象之间的引用、归属、追溯、汇总经营动作对象沿生命周期发生的受控变化业务规则动作是否允许发生的判断条件经营指标以统一口径衡量对象的输出结果权限与协同在组织边界内允许谁操作、如何交接4. 用一个主价值链场景说明EOM如何落地到SMP4.1 场景预设与建模起点理论讲多了容易飘我拿一个实际做过的场景来拆。某制造企业做定制机械设备典型的项目型销售模式。他们的核心痛点有三个报价之后经常在合同阶段变成本签了合同又没人跟踪交付节点最后发货运费对不上账单。进场之后我们没有先画流程图而是拉上销售、财务、生产计划、仓库的人坐到一起先列经营对象清单。列出来的东西不复杂客户、商机、报价、合同、订单、生产任务、出库单、发票、回款。然后补关系商机属于客户报价引用商机合同引用报价订单引用合同发票引用订单。到这一步整条主价值链其实已经能从对象清单里读出来了不需要什么高深工具。4.2 用经营对象语言拆解“从报价到回款”第二步是给每个对象定义生命周期。以“报价”为例它的状态集合是草稿、已确认、已提交客户、已中标、已失效。对应的动作有编辑、提交、审批、中标登记、变更价格、失效。规则层面则是一些带着客户企业味道的条件报价金额超过200万要销售总监审批同一个客户三个月内重复提交类似报价系统要预警中标之后报价自动生成合同草稿。这个过程中最让我触动的一点是所有业务上的动词一旦被收编到对象状态机里管理层的“概要描述”和研发侧的“细节实现”就开始重叠了。老板说“报价中标后要自动转合同”这句话已经可以直接变成SMP里的一条状态迁移规则不需要再经过需求文档翻译。这就是EOM在语言层面的意义。4.3 在SMP中编排动作和规则接下来是编排动作把它们串成一条协作链路。商机阶段一旦推进到“方案确认”就允许创建报价报价被“中标登记”之后系统自动生成合同草稿合同“审核通过”后生成订单和生产任务生产任务“完工入库”后出库单才能被引用去开票发票“核销”完成后这条链路上的回款状态随之更新。这些在传统项目里可能要写一堆业务代码在SMP语言里则是对象状态机的迁移与联动定义。我用一段简化写法示意STATE_MACHINE PX_Quote STATES: draft, submitted, won, lost, expired EVENT: markWon WHEN quote.result win THEN create PX_Contract from quote不要小看这段示意它背后意味着“报价”和“合同”两个对象之间已经具备了一条明确的、由业务结果触发的创造路径。业务规则不再藏在某个按钮点击事件里而是长在模型本身上谁都能读谁都能审。4.4 界面、权限和指标如何从模型派生最后一步才是把模型暴露给用户。SMP里列表页、表单页、看板都可以从模型声明推导出来订单列表可以定义成“最近三个月、我的销售组、未关闭”的视图报价表单可以根据状态字段决定金额是否可编辑合同台账可以实时汇总当前执行中合同的应收余额。权限一旦按对象的归属关系过滤每个业务员看到的自然只有属于自己客户那些单据。整个项目跑下来之后一个感受特别强烈EOM不是某个系统里的新模块而是决定所有模块边界的基础底座。没有这张底座后续加再多的页面、报表、对接接口都是往沙地上垒墙。5. 建立EOM最容易踩的四个坑5.1 把数据库表当成经营模型这是最最常见的坑。数据库第三范式导出的表对存储友好跟业务语义的距离却很遥远。表里一个“外键”字段根本无法回答“这个对象归属谁、经历哪些状态、允许谁操作”这些问题。EOM建模应该从业务名词出发先定义对象和规则再让平台反推表结构而不是顺着表结构往上建模型。我见过一个“合同明细表”合同ID关联订单ID订单ID又关联客户ID数据关系看起来全对可业务规则一个也挂不上。原因就是一张表里混了两个状态机合同的状态演进规则和订单的状态演进规则完全不同。表结构没错错的是建模思维。5.2 流程画得很漂亮对象却定义得很稀烂不少顾问特别迷恋画流程图一讨论业务就铺开一张泳道图角色、节点、条件分支密密麻麻。可你只要追问一句“订单和合同到底是什么关系”立马支支吾吾。这是典型的本末倒置。EOM的骨架是对象和关系流程只是骨架之上的一条路径。先把对象关系经得起追问再谈流程优化否则流程图只会给人留下“运行良好”的错觉一到落表、写规则、配权限的环节照样寸步难行。5.3 指标算完没人认账建模时如果没有和财务、运营把指标口径定死后面一定扯皮。销售说回款已经完成了财务说没有运营说订单准时交付率98%销售说客户签收率只有85%。原因往往是一个按“出库单生成日期”算一个按“客户签收日期”算。EOM里指标如果挂在动作或状态上就要把动作的时点定义清楚。我习惯把所有统计指标写成一张口径表在模型里用注释字段保存至少将来发生争论有一个大家可以共同核对的基础。5.4 模型“大而全”但根本不可执行另一种失败的团队是恨不得一张模型装下整个集团客户主数据、供应商协同、生产排程、商业智能全部塞进来对象关系像蜘蛛网一样密集规则之间互相打架结果谁都不敢碰这个模型。做EOM务必要沿着主价值链先切第一刀先打穿一条完整链路跑起来、用起来再向旁边扩展。我复盘过好几个失败项目死因几乎一致第一张模型图就想包罗万象。6. EOM根在语言语言根在业务常识6.1 为什么说语言基础决定建模上限在这个系列里我反复强调过一件事SMP语言所能表达的东西决定了企业模型能走多远。如果语言只支持“表单加流程”企业的复杂度就只会表现为成百上千条纠缠不清的流程如果语言支持“对象、关系、动作、规则、指标、权限”这组完整构件企业才有机会把复杂度收敛成一份可以持续演化的模型。这不是工具崇拜而是表达边界的现实约束。语言里没有“关系”这个词你就永远只能靠外键字段名去偷偷摸摸地表达关系。6.2 这个系列前四十五篇到底在铺什么有人可能会问既然是“语言基础知识”系列怎么突然讲起企业经营模型来了因为前面四十五篇铺的全是元能力主子表关系怎么拆、权限模型里数据范围怎么算、事务回滚要带哪些关联对象、报表引擎的指标粒度怎么选。单独看都只是技术点合在一起才是EOM完整的表达底座。没有那些基础本篇里的六个构件就是悬在半空的概念有了它们EOM才真正从一张思想地图变成一台可以运转的机器。6.3 给做平台和做顾问的朋友一句实在话我越来越觉得做这套东西的上限不在代码而在能不能尊重业务常识。技术人员一上来就问“有没有现成插件”业务顾问一上来就画流程图两边都对但中间缺一层共同语言。EOM就是那个中间层它把业务语言翻译成平台可执行的模型语言。与其焦虑选哪个平台、用哪套技术栈不如先找一张白纸把公司的客户、订单、合同、回款、质量、成本这些对象的关系写清楚。这一张纸往往比几十个系统建设规划都值钱。我自己的体会很朴素先别急着写代码也别急着买工具。能认认真真把经营对象写全、把关系连对后面系统怎么建都是水到渠成。这话我在多少个项目里重复了多少遍但它从来没有失灵过。