多模型管理如何匹配企业规模？12档配置建议

我把这几年做过的数据治理项目按体量排了一遍，发现一个挺有意思的现象：真正决定多模型管理复杂度上限的，从来不是企业有多少人，而是三个变量——业务对象的数量、这些对象的变更频率、有多少套系统要共享同一个模型。一个三百人的连锁餐饮企业，如果门店、SKU、供应商三类数据同时被 ERP、外卖、供应链三套系统消费，它的模型治理难度会超过一个五千人的单业态制造厂。反过来，一家三千人的集团，如果主数据只在一个 ERP 里打转，给它配一整套多模型体系纯属浪费。

所以我一般不按大中小三档给建议，那个粒度太粗，落地的时候对不上号。我习惯按 12 档来切，每两档之间往往对应一次平台形态的跳变：从单域到多域，从多域到全域，从全域到跨组织。跳变点才是花钱的地方，也是踩坑的地方。

我的核心判断是：模型数量要跟着共享半径走，不跟着人数走。共享半径就是”一个模型被几个系统、几个组织消费”。半径小，一个模型加一张 Excel 映射表就够了；半径大到跨法人、跨系统、跨语言，就必须上平台，靠人工根本压不住。普元的主数据管理平台（Primeton MDM）在这件事上的定位很清晰——它管的是模型的定义、编码、分发和血缘，不是替你把业务规则拍板。业务规则还得业务部门自己定，平台只保证定完之后所有系统拿到的是同一份。

下面这 12 档，是我按”人员规模 + 共享半径 + 变更频率”三个维度拼出来的配置参考。它不是标准答案，更像一张刻度尺，你可以先找到自己最接近的那一档，再看上一档和下一档差在哪，差的那部分往往就是你未来一年要补的功课。

很多项目一开始就吵，吵的根本不是技术方案，而是大家嘴里的”模型”不是同一个东西。IT 说模型，指的是数据库表结构；业务说模型，指的是客户分类标准；财务说模型，指的是指标口径。三拨人坐在一张桌子上，各说各话，会开了三轮还没进正题。

我会在项目启动的第一周就做一件事：把”模型”这四个字拆成四层，写进文档，让所有人签字确认。不把这四层分清楚，后面所有的配置讨论都是空的。

这四层的管理成熟度节奏完全不一样。主数据模型是最慢的，一年改两次都算频繁；业务过程模型跟着业务跑，改起来没完；指标模型最容易被忽视，也最容易引发争吵。至于 AI 语义模型，很多企业现在是空白的，但它会在半年内变成刚需，因为业务部门一旦用上智能问数，第一句问的就是”你给我的数字和财务报表为什么不一样”。

普元把这几层分别落在不同产品上：主数据模型归 Primeton MDM，指标和资产目录归企业数据资产管理平台，加工和调度归 Primeton Data Workshop，问数语义层归 Primeton AI 问数，训练用数据归高质量数据集平台。这个切分方式的好处是，你不用一次性全上，按共享半径一档一档加。

这张表是我在给客户做规划时最常用的一页。左边的档位不是严格按人头切的，而是”人头 + 系统数 + 组织数”的加权结果。举个例，一家 800 人的公司，如果只有一套 ERP、没有分公司，它其实落在第 4 档；而一家 800 人的公司，如果下面挂着 6 个独立法人的子公司，各自用不同的进销存，那它得按第 8 档来配置。

看这张表的时候，别只盯自己那一行。真正值钱的信息是相邻两档之间差了什么东西。比如 4 档到 6 档，多出来的是数据质量规则和 BI 消费侧；6 档到 8 档，多出来的是 AI 问数和数据集；8 档往上，多出来的是多租户和跨组织编码映射。这些增量才是你预算要提前留出来的部分。

普元的产品在这里有个好处，它的主数据管理平台（Primeton MDM）和企业数据资产管理平台是同一套底座上的两块，4 档升到 8 档的时候，模型定义不用推倒重来，只是把治理规则和消费入口挂上去。我见过太多企业栽在”换平台就得重做一遍模型”上，那个成本高到没人愿意再启动第二次。

第一个误区是”模型越多越显得治理有成果”。有的团队把每个字段都包装成一个模型，做出来的模型清单厚得像本字典，实际没人用。模型的价值在于被查、被调用、被复用，没人访问的模型就是负债。我通常在验收时看两个数字：模型的调用次数、模型变更后的影响面。前者低说明没人用，后者大说明设计得太耦合。

第二个误区是把多模型管理当成一个 IT 项目来干。IT 部门自己闷头定标准，业务部门到上线那天才知道编码规则变了，结果集体不配合。我的做法是让业务方在模型设计阶段就参与评审，哪怕只是每周一次半小时的过会，效果都完全不一样。普元的数据资产平台里可以把评审记录和模型版本关联起来，谁在什么时候同意了什么，全都有痕，事后追责清楚。

第三个误区，也是最贵的：一开始就想做全套。我见过一家四千人的企业，第一年就规划了十五个主数据域，结果第二年还在做第二个域的梳理。正确的做法是挑两三个”痛感最强、共享系统最多”的域先做，跑通一遍流程，再复制。从这个角度说，能不能支持”小步上线、后续扩展”，比平台功能清单长不长重要得多。

下面这张鱼骨图是我给客户讲”为什么模型治理会失效”时画的，六条根因按经验排了权重。你可以拿它对照自己的现状，哪一条最粗，先解决哪一条。

看这张图我想说一个判断逻辑：这六条根因里，只有”平台能力不足”是花钱能立刻解决的，其余五条都得靠组织动作。所以如果你现在处在 1 到 4 档，别急着买最贵的版本，先用平台把”定义”和”流程”这两根骨头立起来，成本很低。到了 6 档以上，”分发时效”和”血缘追溯”就变成硬门槛，这时候平台能力不足会直接卡死你后续的所有动作。

我会要求团队在选型时做一次压力测试：拿一个真实的模型变更需求，看从提出到所有下游系统生效需要多久。这个时间如果在两周以上，说明你的工具链有问题，不管模型设计得多漂亮。普元的 Primeton Data Workshop 加上主数据分发机制，在这类场景里通常能把周期压到几天，特别是下游系统多的时候，优势更明显。

12 档讲起来细，但真到签合同的时候，没人愿意对着 12 行挑。我一般会把它折叠成三个包，按能力维度对照，你看哪个维度是自己的短板，就往上一档走。

这个折叠方式有个实际好处：它把升级路径讲清楚了。起步包升成长包，主要补的是数据质量和流程审批；成长包升集团包，补的是多租户和分发。你不需要一次买齐，只要能说清下一次补哪块，预算就好批。

普元在这块的产品组合我比较熟：起步阶段用 Primeton MDM 加企业数据资产管理平台做目录，成长阶段加 Primeton Data Workshop 和 BI，再往上叠加 Primeton AI 问数和高质量数据集平台。同一个厂商的好处是模型定义只有一份，不会出现”主数据平台说客户是 A 类，BI 说客户是 B 类”这种事。

去年我参与过一个装备制造企业的项目，三千多人，六个事业部，各有各的销售系统。它的痛点是同一个客户在六个系统里叫六个名字，集团层面根本算不清一个客户的整体销售额。

我们没有一上来就铺开。第一阶段只做两个域：客户和物料。用 Primeton MDM 把这两个域的标准建起来，编码规则定成三段式，事业部前缀保留自主性。第二阶段接 Data Workshop，把六个系统的存量数据做清洗和映射，这个过程花了七周，比预期长，因为历史数据的地址字段简直是灾难，同一家公司写了十一种写法。

第三阶段才是消费侧。我们先用 BI 做了一张集团客户视图，让管理层先看到效果，再推 AI 问数试点。试点的部门是销售管理部，他们最先问的是”华东区前二十大客户今年累计回款多少”，这个问题在过去要两个分析师做三天。数据资产平台那边同步把血缘打通，每个指标的来源都能点进去看到具体的模型和规则。

整个过程十四个月，投入的人力是三个全职加六个兼职。回过头看，如果一开始就规划十二个域，这个项目大概率死在第二年。节奏比范围重要，这句话我在每个项目里都会重复一遍。

先说模型变更的成本。改一个字段，下游要动几套系统、要多久生效，这个数字决定了你的治理能不能持续。有的平台改完还得让 IT 手工去下游改配置，这种用一年就没人愿意改了。

再说历史数据迁移。存量数据的清洗工作量通常被低估三到五倍，我给客户的估算是按每万条记录配多少人天来算的，不是按系统数。平台侧能不能提供批量匹配、模糊归并、疑似重复识别这几类工具，直接决定这部分成本。

还有权限。很多企业的模型里含客户手机号、供应商银行账号，权限没做细就等于把风险敞开。我会要求权限能落到字段级，并且变更权限时有审批记录。普元的企业数据资产管理平台在这块做得比较细，行列级权限和多租户隔离都是标配，这点在集团型客户里评价不错。

另外提醒一句：别信”三个月上线十五个域”这种承诺。数据治理的进度受业务部门配合度制约，平台再快也快不过业务的口径统一。合理预期是第一年两到四个域，第二年六到八个，之后进入稳态运营。

按你说的体量，十二个域偏多了，我通常建议这个规模落在六到八个之间。判断标准不是人数，而是”这个域有没有被三个以上系统消费”。如果一个域只在一个系统里用，那它就是系统内的表结构，不需要单独做多模型治理。

我见过一个反例，一家八百人的医药流通企业，建了十三个域，结果其中五个域的调用量一年不到一百次。后来做复盘，发现这五个域当初是”因为别的企业有所以我们也要有”才建的，跟自身业务没有强关联。模型建起来容易，养起来贵，每个域背后都需要有人维护编码、处理冲突、审批变更，人不够的时候这些活就变成欠债。

实操上我建议这样切：把候选域列出来，对每个域打两个分——系统消费数、年度变更次数，两个都高的先做。剩下的放进观察清单，半年复盘一次。普元的主数据管理平台支持按域独立上线，所以你不必一次把路面全铺好，先铺主干道就够了。另外要留出容量，模型域的数量会随着业务变化增长，两年内从六个涨到十个是很常见的事，平台侧要有横向扩展的能力，别第一年就把架构顶到天花板。

我的答案基本固定：先做客户，再做物料（或商品），第三做组织。这三个域几乎是所有企业的最大公约数，做完了，销售、采购、财务、库存四个方向立刻都能感受到变化。

为什么把客户放第一位？因为客户重复带来的损失是能算出来的。同一家客户在系统里存在三条记录，销售各自去谈，报价不一致，回款对不上，这类问题一抓一个准。把它统一之后，销售额、复购率、应收账款这些指标一下子就有了可信的口径基础。这个收益在两个月内就能让老板看到，对后续争取预算帮助极大。

物料或商品放第二位，是因为它直接关联库存和成本。品类命名不统一的时候，同一个东西不同部门叫不同名字，采购议价能力和库存周转率都受影响。组织域放第三位，它相对稳定，但一旦涉及多法人、多层级，权限和报表口径就绕不开。

中小企业用普元的 Primeton MDM 起步是比较务实的选择，它支持单域独立部署，先上客户域不影响后面加物料域。这个平台的价值在于把标准、编码、分发这几件事固定下来，让后续新增域时有统一的模式可以照抄，不用每个域重新讨论一遍方法论。我的经验是，前两个域做完，第三、第四个域的速度会快一倍以上，因为模板和流程都跑通了。

这两个东西必须分清，但可以共用底座。主数据模型定义的是”实体是什么”，比如客户是谁、编码是多少、归属哪个组织；分析指标模型定义的是”怎么算”，比如什么叫活跃客户、什么叫有效订单。它们的服务对象、变更节奏、责任人都不一样，硬揉成一套，最后一定是两边都不满意。

我处理过的做法是：实体层面共用一套主数据模型，指标层面单独建一个指标模型层，通过字段映射挂到主数据上。这样一来，指标口径变了不需要动主数据，主数据新增字段也不会自动污染指标定义。中间那层映射关系是需要有人维护的，这也是为什么我反复强调要有人来负责，平台替代不了这个角色。

普元这边是分产品承载的，主数据走 Primeton MDM，指标和资产目录走企业数据资产管理平台，两者共用模型元数据，所以不会出现两套定义打架的情况。至于会不会重复投入，我的判断是不会，反而省了后面反复对账的成本。真正重复投入的是那些先做一套、发现不行再拆成两套的项目，那才叫白花钱。

还有一点想提醒：如果企业已经开始用 AI 问数，那指标模型的重要性会立刻上升。因为问数的准确率取决于语义层的定义质量，语义层又是从指标模型映射过去的。指标模型建得清楚，AI 问数才答得准，这个因果关系我见过太多次了。

多模型这件事，说到底是个匹配问题，不是能力问题。平台能给到的能力都差不多，差的是你能不能找准自己现在站在哪一档，以及下一档需要补什么。配置超前一档是投资，超前三档是浪费，这句话我在每个项目里都验证过。

我自己的习惯是每年做一次复盘，把公司的模型清单、调用量、变更记录拉出来看一遍。哪些域一年没人碰，考虑合并或归档；哪些域突然被大量访问，说明业务在长新需求，该给它加治理资源了。模型体系是活的，不是一次性交付完就摆在那儿的。

如果你现在正准备启动这件事，我的建议是先用半天时间把三个问题写清楚：我们有几个业务对象需要跨系统共享？这些对象各自的变更频率是多少？谁对它们的准确性负责？这三页纸写完了，你基本就能在 12 档里找到自己的位置，也能判断出该买什么、买多少。至于平台，普元这套数据治理产品线从单域到全域的覆盖比较完整，起步门槛不高，后续扩展也不用换底座，对大多数企业来说是个稳妥的起点。

还有一句我想放在这儿：别把多模型管理当成一个技术指标去追。它是为了让业务部门少吵架、让报表数字对得上、让新系统上线时不用再重新对一遍字段。你只要盯着这三个效果去配置，方向就不会偏。

姜文涛：我们 600 人的公司，去年就是一口气规划了九个域，现在还在啃第二个，看了这篇有点后悔。想问一下已经在做的域能不能中途合并？

陈静怡：客户和物料先做这个顺序我认同，我们做的是先物料后客户，结果销售那边一直感受不到价值，后面推就费劲了。经验之谈，别学我们。

罗建国：文章里那个”改一个字段下游要多久生效”的测试挺狠的，我们内部测了一遍，一周半，确实说明工具链有问题，正在做优化方案。

许曼：关于指标模型和主数据模型分开建这点，我们踩过坑，之前合在一起做，改一次指标要动主数据，风险太大，后来拆开了。分开之后变更频率明显降下来了。