十三 · 组织、角色与预算
三个角色、人月预算、KPI 与失败信号
前十二章讲的是「怎么做对」。这一章讲一个更容易被忽略的问题：这件事由谁负责、花多少钱、怎么向上证明它值得。
本体项目最常见的死法不是技术失败，是有支持、没资源——领导口头认可，但没人被明确指派，预算挂在「数字化专项」里，第一个季度结束就没人提了。这一章给一个可操作的最小组织形态与预算口径。
三个角色，不是三个部门
本体项目只需要三个角色。它们可以是兼职的，但必须有人明确承担，且不能都由同一个人兼。
| 角色 | 对什么负责 | 现实中该由谁兼 | 不该给谁 |
|---|---|---|---|
| 模型所有者（Model Owner） | 「模型是否正确表达了业务」——类的划分、关系的方向、约束的内容 | 数据架构师 / 资深数据工程师 | 刚毕业的建模新人（没有裁决权，也没有业务信任） |
| 领域裁决者（Domain Arbiter） | 争议拍板：「准时率到底按哪个口径算」 | 业务侧有签字权的人（如供应链总监、财务 BP） | IT 部门（IT 拍不了业务口径） |
| 工程维护者（Steward） | CI、发布、豁免处理、违规工单分派 | 平台组的一名工程师，0.5–1 FTE | 外包（三个月后就没人能改了） |
三者的关系可以用一句话概括：模型所有者提方案，领域裁决者签字，工程维护者保证它每天真的在跑。
RACI
| 事项 | 模型所有者 | 领域裁决者 | 工程维护者 | 业务方 |
|---|---|---|---|---|
| 新增/修改类与关系 | A/R | C | C | I |
| 新增/修改约束 | R | A | C | I |
| 口径变更 | R | A | I | C |
| 豁免审批 | C | A | R | I |
| 违规处理 | I | C | R | A（业务侧整改） |
| CI 与发布 | I | I | A/R | — |
（A = 最终负责，R = 执行，C = 需咨询，I = 需告知）
这张表里最容易出错的一格是「违规处理」：工程维护者负责把违规清单分派出去，但整改必须由业务方负责。如果整改也落在数据团队身上，他们就会倾向于放宽规则——这是校验体系退化的最常见机制。
为什么不建议建「本体团队」
三个理由：
一、规模不支撑。 一个 18–40 个类的模型，稳态维护不需要专职团队。设一个 5 人的「知识工程部」，实际工作量会在 0.5–1 FTE 左右，剩下的人会开始做「更有产出感」的事——通常是写文档和画图，也就是退化成文档组。
二、容易与业务脱节。 独立团队会形成自己的语言与节奏，然后开始「向业务收集需求」，而不是「和业务一起定义」。本体是业务概念的形式化，脱离日常业务讨论就很难做对。
三、汇报线决定生死。 挂在 IT 下的本体团队，KPI 往往是「系统上线」「模型数量」；挂在业务下的，KPI 天然是「口径统一」「坏数据下降」。后者才活得久。
推荐编制：平台/数据架构组内 1.5–2 FTE（一名所有者 + 半名维护者），加业务侧兼职裁决者 2–4 人（每人每月 2–4 小时）。这个规模能支撑到 B 形态（第 10 章），再往上才需要考虑专职。
预算：用人月算，不用钱算
软件许可可以谈，人力不能。所以预算口径统一折成人月：
| 形态 | 首年 | 稳态（第 2 年起） | 用途 |
|---|---|---|---|
| A 小团队、无新存储、纯生成物 + 校验 | 6–10 人月 | 3–5 人月/年 | 1 个域、20 个类、5–15 条约束 |
| B 编译器为核心、多域共享一份源 | 20–30 人月 | 12–20 人月/年 | 3–5 个域、40–80 个类、生成多目标产物 |
| C 受监管、动作网关 + 审计 | 50–80 人月 | 40–60 人月/年 | 全公司域、动作门控、审计与回放 |
这张表最该被记住的是「稳态」那一列。 立项时几乎所有人只看首年，而失败几乎都发生在第 12–18 个月——那时首年预算花完，稳态预算没批。
一个粗略的经验比例：稳态维护成本约等于首年建设成本的 35%–50%。如果一个方案声称「建完就不用管了」，它不是方案，是采购话术。
买还是自建
| 维度 | 开源 + 自建 | 商业平台 |
|---|---|---|
| 软件成本 | 0（或极低） | 30–80 万元/年起（按席位或数据量） |
| 首年人力 | 6–30 人月 | 4–12 人月（实施方承担一部分） |
| 三年 TCO | 人力为主，可预测 | 许可 + 实施 + 升级，通常更高 |
| 得到什么 | 完全可控、可嵌进现有 CI、无锁定 | 图形化建模、协作与评审 UI、厂商支持 |
| 主要风险 | 版本演进靠自己、缺 UI 导致业务方不参与 | 锁定、升级成本、定制靠厂商排期 |
建议路径：先用开源把 A 形态跑通（6–10 人月），在真实数据上验证「拒绝写入」这件事对你的组织是否有价值。如果答案是「有价值但没 UI 业务方不用」，再买；如果答案是「业务方根本不看」，买了也没用。
反过来做（先买平台再找场景）的失败率极高，因为平台的能力边界会反过来塑造需求——你会开始做「平台擅长的事」，而不是「业务疼的事」。
哪些能外包，哪些不能
可以外包：工具链搭建、迁移脚本、CI 集成、可视化看板、一次性数据清洗。
不能外包：
- 模型本身。 外包方交付的模型，在合同结束后的第一次业务变更时就会变成黑盒。三个月后没人敢改。
- 裁决。 口径争议的拍板权无法外包，也不该外包给咨询方。
- 豁免审批。 这是治理动作，必须留在组织内。
一个可用的判据：凡是「三年后还会被修改」的东西，都不能外包。 本体恰好全部属于这一类（第 12 章判据第 6 条）。
三个月内证明价值：三个 KPI，选一个
不要用「模型类数量」「覆盖表数量」「问答准确率」当 KPI——前两个是产出量不是价值，第三个会把项目拖进 AI 叙事（第 12 章死法五）。
三个可测、可归因、三个月内能出数的 KPI：
| KPI | 怎么测 | 三个月后的合理值 |
|---|---|---|
| 坏数据拦截数 | 校验闸门在 CI 与写入路径上拦下的条数（按类型分） | 从 0 到每周 10–50 条，且 60% 以上被真正修复 |
| 口径争议关闭时间 | 从提出到裁决的平均天数 | 从 3 周降到 3–5 天 |
| 变更引发的事故数 | 因模型/口径变更导致的下游错误 | 目标 0；对照基线是过去 6 个月的实际次数 |
第一个 KPI 最有说服力，因为它能当场演示；第三个最容易被管理层记住，因为它对应「省下的损失」。
反例 KPI（看起来合理，实际有害）：模型类数量（鼓励过度建模）、覆盖表数量（鼓励做宽不做深）、图谱节点数（纯粹的虚荣指标）。
组织失败的四个信号
按出现频率排序：
一、委员会化。 变成「每月开一次会、每次没有决议」。判断标准：最近三次会议的产出里，有没有一次改变了模型或裁决了争议？ 没有，就是委员会化。
二、汇报线在 IT，且没有业务 KPI。 症状是项目汇报全是技术指标，业务方只在验收时出现。
三、只有一个人在维护。 单点即风险。这个人休假两周，流水线就红着没人管——这种情况在调研中非常普遍。
四、豁免没有到期日。 这是治理失效最早的信号：一旦出现「永久豁免」，约束体系就开始名存实亡。第 7 章案例里那条「豁免到期后有人把日期改到下季度」，正是这个信号的典型形态。
招聘：三道题就够
不需要「本体专家」，需要「能把业务概念形式化、并且愿意写测试的人」。三道面试题：
- 给一个业务场景，让候选人写 5 条约束，并说明每条对应什么错误。看的是「能不能从错误倒推约束」，而不是会不会 Turtle。
- 给一份有冲突的口径定义，问他怎么推进裁决。 看的是组织能力，不是技术能力。
- 问：如果校验报出 100% 违规，你的第一反应是什么？ 正确答案是「规则写错了」，不是「数据太差」。这一题能筛掉一大批只会跑工具的人。
一句话
本体项目的组织问题，本质是「谁有权说这条数据是错的」。 技术选型可以慢慢改，这个权力归属定错了，项目从第一天起就只是在生产文档。