EOM核心经营能力：用SMP语言定义可校验的企业能力模型

EOM（Enterprise Operating Model，企业经营模型）七要素的界定走到第二篇，恰好也是SMP语言基础系列的第四十七篇。上一篇把“客户价值主张”这个要素讲完以后，不少人在SMP用户群里追问：价值主张讲清楚了，企业靠什么把价值稳定地交付出去？这个问题的答案，就是今天要界定的第二个要素：核心经营能力。SMP平台上的模型不是画几张架构图，它需要你把每一个经营要素落成一个可定义、可校验、可复用的对象。这篇的目的，就是结合SMP语言的基础知识，把“核心经营能力”到底怎么定义、怎么写进SMP、以及踩过的坑一次讲清楚。适合正在做企业架构、业务中台建模，以及刚把SMP语言基本语法学完的朋友往下看。

1. 从语言基础到EOM：这篇到底在解决什么问题

1.1 为什么把企业经营模型放进SMP讨论

很多同学学到第四十多篇，依然觉得SMP是一门“编程语言”，这其实是个误区。SMP的完整名称是软件制作平台，它自带一套业务建模语义。EOM模型放到SMP里讨论，不是因为平台闲得慌，而是因为企业经营模型本身需要被系统地表达和校验。

用文档写EOM有三个很现实的问题：第一，写完了没人看，Word里堆了一大堆概念，业务和IT各看各的；第二，改起来到处是碎片，今天改一段流程，明天加一个岗位，文档之间根本关联不上；第三，模型和系统实现完全脱节，架构图挂在墙上，代码里又是另一套逻辑。SMP语言做的，就是把文档变成对象，让模型可以被查询、比较、版本化，甚至被编译器校验。说的直白一点，SMP是让经营模型从“一个说法”变成“一个能运行的东西”。

这类建模语言和常见通用语言的关注点完全不同。每年网上都会有编程语言排行榜更新，也有人问我该怎么做编程语言推荐，我都会反问一句：你是要写业务模型，还是要写系统组件？榜单上的语言确实很强大，但EOM这种多层次、多对象、多关系的结构，用通用语言去表达，最后往往是一堆类和方法，业务的人看不懂，技术的人又嫌建模成本高。SMP语言在设计上就限制了表达范围，它只关心业务对象、业务关系、规则和指标，对象之间的关系是显式的，校验也是自动的。

1.2 EOM七大要素的全景坐标

整个EOM框架并不是从零发明的。我在实际项目中把它收敛为七个要素，七者之间不是平行罗列，而是一条从“价值判断”到“价值交付”到“价值评价”的闭环。今天只谈第二个要素，但必须把它放到全景里谈，否则边界会被带跑。

在这个全景里，“核心经营能力”处在非常关键的位置。价值主张定义了“为什么客户会买”，能力决定了“你凭什么能交付”。如果能力撑不住价值主张，前面说得再好也是空话。SMP建模时，能力对象可以直接关联到价值主张对象，这样模型层级不会散。上一篇里定义好的价值主张，在SMP里会有对应的valueProposition对象，能力里的valueLink字段就是引到那个对象的。

2. 要素二：核心经营能力，怎么界定才算清楚

2.1 先划清边界：能力不是流程，也不是组织架构

我见过最普遍的问题，就是把能力、流程、组织三者混在一起。三个对象在EOM里必须分开建模，因为它们的生命周期不一样。流程可以为了效率优化随时调整，组织架构会因为战略调整而重组，但能力的稳定性要强得多。能力回答的是“企业能做什么”，流程回答的是“企业怎么做”，组织回答的是“谁来做”。

举例来说，订单履约能力，不等于订单履约流程。订单履约流程是把订单接收、库存分配、拣货、打包、出库这些动作按时间串起来，而订单履约能力是企业在任何订单场景下都能稳定交付的那套本事。流程可以被流程引擎替换，ERP上线、规则调整都可能让流程变化，但企业依然需要具备“把订单按期送到客户手里”的能力。

这个边界如果划不清，后面SMP建模就会很混乱。我见过一个项目，把“开票”这种流程动作直接建成能力，结果能力目录里塞了上千个碎片化节点；同时也有人把“客户全生命周期管理”整体建成一个能力，大而空，根本无法评审和度量。合理的能力一定具备两个特征：它能独立产出一个业务结果，而且这个结果可以被衡量。开票动作的结果不是业务结果，它只是财务流程中的一个步骤，所以不适合作为独立能力。

组织架构也同理。能力可以有负责人，但负责人不等于组织部门。一个能力可能是跨部门协作的结果，比如“供应链风险应对能力”同时涉及采购、生产、物流、财务四个部门；而一个部门也可能支撑多个能力。把能力绑定到某个部门，等于给模型加了错误的约束，将来组织一调整，整个模型就得返工。

2.2 能力的三层结构：输入、动作组合、输出

为了在SMP里把能力定义得可操作，我把每个能力拆成三层：稳定输入、动作组合、可测输出。这个结构很像一个“黑盒”，但比黑盒多了一层要求：输入要明确，动作要可组合，输出要能量化。

稳定输入指的是能力启动时需要的对象或事件，比如“已确认订单”“库存可用量”“支付成功通知”。这些输入在SMP里可以被定义为事件或快照，它们的类型、来源、状态都要有唯一标识。动作组合不等同于流程，它更接近能力内部的一组“子能力”或“策略”。比如订单履约能力的动作组合包括库存锁定、波次调度、承运商匹配、异常处理策略。这里不需要写“先做A再做B”，而是声明能力内部依赖哪些支撑性子能力。

可测输出是这个能力存在的意义。输出到外部世界的必须是明确的对象，比如“履约承诺”“发货通知”“更新后的风险台账”。如果一项能力定义不出可测输出，那它大概率不是一个独立能力，而是一个辅助动作。SMP编译的时候会对输出做一致性检查，如果你在指标里定义了“订单准时交付率”，但能力输出里没有“发货时间”这个对象，编译器就会提示你：指标的度量对象缺失。

下面是SMP里一个订单履约能力的完整结构示例。我在字段上故意省去太多语法修饰，保留实际项目中最常用的部分，你可以直接照着写：

capability OrderFulfilment { id: "cap.fulfilment" name: "订单履约能力" type: "core" owner: "运营负责人" valueLink: ["value.proposition.rapidDelivery"] inputs: [ { id: "order.confirmed", name: "已确认订单", type: "event" }, { id: "stock.available", name: "库存可用量", type: "snapshot" } ] outputs: [ { id: "promise.shipping", name: "履约承诺", type: "contract" }, { id: "order.shipped", name: "发货通知", type: "event" } ] capabilitiesUsed: ["cap.availableInventory", "cap.routeOptimization"] metrics: ["metric.order.otd", "metric.order.cycleTime"] systems: ["OMS", "WMS", "TMS"] }

这里我使用了capabilitiesUsed来表示这个能力依赖哪些更底层的能力，而不是直接写流程顺序。这样模型能保留“组合”的语义。比如cap.availableInventory是库存可见能力，它负责提供可卖库存；cap.routeOptimization是路径优化能力，它负责计算最优配送路线。订单履约能力组合了这两个能力，但它们之间不一定是严格先后关系。

2.3 怎么用能力地图铺开企业的经营底盘

有了单个能力的定义之后，还要把能力组织成一张地图。能力地图不是流程图，它更像企业能力的“完整清单+层级结构”。我在项目里一般分三层：战略层、运营层、支撑层。

战略层能力决定了企业的独特性，比如“客户需求洞察能力”“生态伙伴整合能力”，这类能力数量不多，但直接构成竞争力。运营层能力是每天产生实际业务结果的核心能力，比如订单履约、生产制造、渠道分销、计划预测。支撑层能力为上面两层提供保障，比如人力资源服务能力、财务核算能力、数据治理能力。这种分层不是简单的金字塔，而是一种依赖关系：运营层能力依赖支撑层能力，战略层能力又依赖运营层能力。

SMP里可以用capabilityGroup把相关能力组合成一个能力域。如下：

capabilityGroup FullfilmentSuite { name: "履约能力域" capabilities: [ "cap.fulfilment", "cap.availableInventory", "cap.routeOptimization", "cap.returnHandle" ] }

能力地图的价值在于，它可以和IT建设规划直接映射。企业规划明年要建设一套智慧供应链，那就先在能力地图里找到需要提升的能力，看这些能力当前由哪些系统支撑，哪些能力还完全没有系统支撑，哪些能力被多个系统重复支撑。这个分析在SMP里可以通过对象关系查询直接生成，不需要手工画表格。这也是我强调在SMP里做EOM的原因：能力地图不是一张静态图，而是一个可以被分析的数据结构。

3. 在SMP语言里，把核心经营能力变成可执行对象

3.1 一个能力定义的SMP代码长什么样

上面那段capability OrderFulfilment已经展示了基本形态。现在我们逐个字段说清楚，否则你只知道语法，不知道建模意图。

id是对象的全局唯一标识。SMP里所有业务对象都遵循域.对象类型.名称的命名习惯，比如cap.fulfilment就是能力域的履约能力。这个ID一旦发布，最好不要轻易修改，因为其他对象会引用它。name是给人看的显示名，可以随时改。type标记能力类型，目前项目里常用的有core（核心）、supporting（支撑）、emerging（新兴）三类。owner是这个能力的第一责任人，人和组织字段在SMP里也有独立对象，这里先填 ID 或名称。

valueLink是能力跟客户价值主张之间的关联。上篇我们已经在SMP里定义了价值主张对象，比如value.proposition.rapidDelivery，能力通过这个引用告诉所有人：我为什么存在？没有价值主张关联的能力，会被SMP校验器标记为“孤儿能力”，提醒你可能不需要它。

inputs和outputs是能力的输入输出契约。每个输入输出必须明确类型，event表示事件流，snapshot表示存量快照，contract表示多方约定的契约对象。这个类型差别很重要：事件流会触发能力，快照为决策提供背景，契约是能力对外做出的承诺。定义错了，后面的数据映射和接口对接都会跟着错。

metrics是能力的量化评价。SMP自己不负责算指标，它是把指标对象的ID挂在能力上，具体计算规则放在指标定义里。之所以要显式关联，是为了让人一眼看到“该项能力健康状况看哪些数”。systems是支撑能力的系统清单。这部分不要求全部填完，但至少要填能识别的IT系统对象。系统对象在SMP里可能来自CMDB导入，也可能在建模时手工创建。

3.2 能力目录、能力组合与依赖关系的建模

单个能力定义完，下一步就要考虑能力之间的组合和依赖。SMP语言里有两个关系：capabilitiesUsed表示子能力依赖，capabilityGroup表示逻辑分组。这两个关系语义不同。

capabilitiesUsed偏硬，意味着被依赖能力不可缺失，如果我删掉cap.availableInventory，所有引用它的能力都会因为依赖断裂而校验失败。这种刚性用于保证模型的完整性。capabilityGroup偏软，它更多是组织视图，不参与运行逻辑。履约能力域可以包含订单履约、库存可见、路径优化和退货处理，但这个分组不意味着四个能力之间一定存在数据流。

依赖关系很容易被画成一张网。我的建议是：不要过度依赖。如果你发现自己画出的能力依赖图有几十个节点互相交叉，大概率是把流程的先后关系混进去了。真正的能力依赖应该相对稀疏，比如“订单履约”依赖“库存可见”和“路径优化”，路径优化又可能依赖“地理编码能力”，这就足够了。依赖关系一旦成环，SMP会直接报错，我会在第五部分详细讲这个坑。

3.3 为什么不用C#、Rust直接写EOM对象

每次编程语言排行榜更新，都会有人把榜单截图发到群里，问SMP为什么不直接使用榜单上的热门语言来写模型。我理解这个疑问，但答案其实很简单：你要建模的是企业经营模型，不是算法、不是驱动、不是Web服务。C#编程语言手册背得再熟，也不解决“能力与流程边界”这个建模问题；Rust性能再好，把它安装在E盘还是D盘也不会让模型语义更清晰。模型语言的价值在于精准表达业务概念，而不是图灵完备。

SMP语言是一种小颗粒的领域特定语言，它故意去掉通用语言里的分支、循环、指针、内存管理，就是为了逼你把注意力放到业务对象和关系上。你用C#也能写一个Capability类，写上几个属性，但你能获得的只是代码，而不是模型。SMP除了语法，还提供了模型校验、影响分析、版本对比、权限控制等能力，这些都不是一段代码能替代的。

当然，SMP不是封闭的。它允许用通用语言编写扩展函数。比如深度学习所需要的Python代码，可以封装成SMP的扩展插件，在指标计算或预测性能力里调用。Rust、C#也可以用来编写核心计算插件。但这种嵌入是“脚本插件”，不是主模型。主模型的唯一表达方式就是SMP语言。这样划分之后，业务团队可以独立维护模型，技术团队只用关心扩展点，两边边界清楚。

4. 实操：在SMP平台上完成能力要素建模的完整过程

4.1 准备步骤：先梳理能力清单，别急着敲代码

我在刚接触SMP时也犯过一上来就写模型的错误。结果写了一个月，发现能力对象跟上下游关系完全理不清，只好推倒重来。正确做法是先离线梳理能力清单。

你可以用一张Excel表，强制填以下几列：能力名称、所属能力域、类型（核心/支撑）、负责人、输出来自哪个上游、输出给哪个下游、依赖哪些能力、建议指标、支撑系统。这张表不要追求一次完美，第一版目标是把企业里大家公认的“大事”列出来，比如订单履约、客户管理、产品研发、供应链计划，先给五个到十个，不要超过二十个。

梳理时有一个建议：每个能力必须能回答“没有这个能力，企业的哪个价值主张会直接受影响”。如果回答不出来，就先放到观察列表，不要急着建模。这个动作能过滤掉大部分伪能力。

4.2 从Excel清单到SMP对象的落地过程

当Excel清单评审得差不多之后，再开始SMP建模。我自己的操作流程如下，总共六步：

1. 在SMP里新建能力域capabilityGroup，名称尽量跟业务域一致，比如“履约域”“营销域”“供应链域”。
2. 通过导入功能把Excel清单批量导入，系统会为每个名称生成带临时ID的capability对象。
3. 逐项补全owner、valueLink、inputs、outputs。这一步最费时间，建议按能力域组织评审，而不是一个人闷头填。
4. 如果SMP的数据资产模块还没有对应对象，先创建占位对象。先保证能力对象引用不缺失，等后续再细化数据结构。
5. 运行模型校验。SMP会把孤儿能力、缺依赖、输出不匹配、指标对象缺失都标出来。
6. 发布版本，并邀请业务负责人做线上评审。评审通过后，把这个版本设为“当前基线”。

这套流程我在多个项目里跑过，从Excel到可评审版本，一般需要三到四次集中工作坊，而不是一次完成。在SMP里调整比在文档里调整快很多，因为你能直观看到依赖关系，改一个输入输出，马上会显示哪些上游、下游受影响。

4.3 能力重要度怎么算：一个可落地的评分模型

能力清单出来以后，往往面临一个问题：先建设哪个能力？这时候我们需要给能力排优先级。虽然SMP没有内置“优先级”字段，但可以通过score字段自定义评分。

我在项目里用的评分模型是：

能力重要度 = 业务影响 × 0.4 + 客户可见度 × 0.3 + 不可替代性 × 0.3

三个维度都是1到5分，最终得分是1到5分。业务影响指该能力若失效，对收入、成本或合规的影响程度；客户可见度指客户能否直接感知到这个能力的表现；不可替代性指这个能力被外部采购或临时替代的困难程度。

我拿一个实际例子说明，订单履约能力在电商公司里通常评为：业务影响5分，因为它直接决定客户是否复购；客户可见度5分，客户感知最强；不可替代性4分，因为有第三方仓储物流可以部分替代，但体验很难完全对齐。最终得分：5×0.4 + 5×0.3 + 4×0.3 = 4.7。而一个“内部报销能力”，业务影响可能3分，客户可见度1分，不可替代性2分，最终是 3×0.4 + 1×0.3 + 2×0.3 = 2.1。这样排序下来，资源投入的方向就清楚了。

评分完成以后，我会把分数写到SMP的score字段，生成一个简易视图，直接把所有能力按分数倒序排出来。这个视图在预算评审会上非常好用，它能回答“为什么先建这个能力”的质疑。

5. 常见问题与排查实录

5.1 能力粒度忽粗忽细，模型没法用

这是最让人头疼的问题，没有之一。同一个项目里，有人把“开票”单独建一个能力，也有人把“客户全生命周期管理”整体建一个能力，结果能力地图成为一张两边对不上的饼状图。

我的判断标准有三个：能不能独立产出一个业务结果？有没有明确的输入输出对象？有没有可量化的指标？不符合这三个标准的，一律降级为流程动作或支撑性规则。开票动作不满足“独立业务结果”要求，它只是开票流程的一步；客户全生命周期管理如果囊括了获客、留存、复购、推荐，那它不是一个能力，而是一个能力域，需要拆成多个能力。

操作上，SMP里如果发现粒度问题，不要手工去改十几个对象，而是要利用“合并”或“拆分”功能。合并时保留拆分时的通用输入输出，拆开时把大对象里的输入输出按子能力重新分配。

5.2 把流程步骤写进了能力定义

新手最容易犯的第二个错误，是把能力内部的动作组合写成“第一步做什么，第二步做什么”。比如在订单履约能力的定义里写“先对订单进行支付校验，然后锁定库存，然后生成运单”。这个写法不是错，但它把能力定义和流程定义混在了一个对象里，将来流程要优化，能力对象也得跟着改，违背了能力稳定的初衷。

正确做法是：能力内部只声明“依赖哪些子能力”，不写顺序。顺序留给后续的业务流程网络元素去表达。SMP语言里也有process对象，它专门承载流程逻辑。能力对象和流程对象之间通过“能力被流程使用”的关系关联，而不是把流程内容写进能力里。

5.3 输入输出对不上，能力链断裂

多个能力模型连起来之后，经常出现这种情况：上游能力输出的是“发货通知”，下游能力的输入需要的是“订单状态快照”，两边对不上。SMP校验器不会无所不能，如果你输入输出都定义成字符串类型，它只能提示“对象类型不匹配”，不会帮你判断业务语义是否一致。

所以我建议所有输入输出尽量引用已有的业务对象，而不是随手填一个字符串。比如输出order.shipped这个事件对象，它的数据结构在SMP里是全局定义的，下游能力如果确实需要接收这个事件，就必须引用同一个对象ID。这样虽然前期建模多花一点时间，但后期联调会顺畅得多。

如果确实遇到语义相同、结构不同的输入输出，不要硬在能力建模层转换，而是建立一个“适配对象”或者“数据映射关系”。SMP支持定义映射规则，把上游输出转换成下游输入，但这应该是个显式对象，不能让下游能力去“猜”。

5.4 依赖环出现，SMP校验不通过

依赖环的一个典型案例是：A能力依赖B能力，B能力依赖C能力，C能力又依赖A能力。发生这种情况，SMP的依赖分析会提示“存在循环依赖”，此时强行发布是过不去的。

处理办法不是把依赖去掉，而是要看这个环的涵义到底是什么。大多数情况下，环意味着两个能力之间应该是“资源提供”关系，而不是“调用”关系。比如订单履约能力依赖库存可见能力，库存可见能力又依赖订单履约能力来更新库存占用，表面看是环，实际上库存可见能力依赖的不是“订单履约”，而是“订单占用数据”这份数据资源。这时候应该把依赖对象改成数据资产对象，而不是另一个能力对象。

如果环还很复杂，建议把相关能力拉到一个工作坊里，逐个问“你到底需要对面给你什么”，然后把依赖改成具体输入对象。我这个经验对付大多数环状依赖都有效。

5.5 能力没有owner，发布之后没人维护

SMP模型发布后，最怕的不是模型写得不对，而是没有负责人。很多项目刚开始建模时热情高涨，模型发布后却没人持续更新，三个月后模型和业务对不上，最终沦为文档垃圾。所以我从第一次做EOM建模就立了一个规矩：owner字段不允许为空。

这不仅是流程问题，还涉及到权限。SMP里没有owner的能力对象默认只有只读权限，想修改必须先指派owner。这样一来，如果某个能力已经半年没有任何人修改，你自然就会去问这个owner还在不在职，能力还重要不重要。这个“物理手段”比任何约定都管用。

另外，owner不一定是组织部门负责人，他可以是某个关键用户、流程Owner或者产品经理。关键是这个人要对能力的业务结果负责，而不是对建模格式负责。我在项目里一般把负责人放在能力对象里，同时把协作成员放在一个单独的关联列表里，避免把责任和参与搞混。

6. 几句实在话：能力模型后续还能怎么用

最后分享一个我自己的操作心得：不要一上来就试图把整个企业的能力目录全部搬进SMP，那会让团队在建模阶段就疲惫不堪。我们最成功的做法是先挑一个端到端场景，比如订单履约，把相关五到八个能力定义清楚，跑通一个可评审、可校验、可查询的版本，再复制到其他业务域。这样SMP语言的学习曲线会平缓很多，业务人员也能在短时间内看到模型带来的确定性。

另外，能力模型建好之后不要停在“看”的阶段，可以借着它去做系统规划、流程优化、组织设计。能力是稳定的骨干，其他要素在它上面长。等到后续系列把业务流程网络、数据资产、技术架构都串起来，你会看到当初花的建模时间，最后都会以模型复用度还回来。