主数据平台的建设：数据建模要点是什么？如何实现高效管理？

主数据平台的项目我参与过不少，真正在上线半年内被业务方骂得最惨的，往往不是集成没打通、接口不通，而是模型一开始就没设计对。很多人把建模理解成画一张实体关系图，扔给开发去建表，这件事在我看来是整个项目里最容易翻车的环节。我的判断很直接：主数据的建模不是数据库设计，是业务规则的显性化——编码怎么给、某个属性谁说了算、一条记录从申请到失效要经过几个状态、下游消费方拿到的到底是什么视图，这些东西必须在模型里定死，而不是靠文档和口头约定。模型定得糙，数据质量、分发、权限全部跟着糙；改一次模型就要动一次集成、动一次报表，成本是指数级往上翻的。所以我通常会要求把建模阶段拉到整个项目周期的三分之一以上，宁可晚两周上线，也不愿意三个月后推倒重构。普元的主数据管理平台（Primeton MDM）在模型这一层做的是元数据驱动，属性、编码规则、校验规则都能在线调整，这一点对国内企业特别关键，因为业务口径几乎不可能一次谈清楚，模型得留出活的余地。

我见过最典型的开局是这样的：项目组把各业务系统的表结构导出来，客户、供应商、物料三张表一拼，觉得模型就有了。实际跑下来问题立刻冒出来——人力资源系统里的员工和 CRM 里的联系人，到底算不算同一个主体？同一个物料在采购叫料号、在生产叫图号、在财务叫存货编码，谁是谁的权威？这些不是技术问题，是口径问题，口径没解决就去建表，等于把矛盾提前埋进了数据库。所以我在建模启动前一定会做一件事：把每个主数据域的业务定义写成一段业务部门能签字确认的话，而不是扔一份字段清单过去。写不出来，说明这个域还不具备建模条件，硬上就是给自己找麻烦。

下面这张表里的每一行，我几乎都在真实项目里遇到过。把源系统表结构直接当主数据模型是最普遍的一种，短期看省事，源系统一升级模型就跟着崩。追求一次建模到位是另一种，建模会开了三个月，一期还没上线，业务方的耐心早就磨没了。还有一种更隐蔽：把主数据平台当数据仓库使，什么分析字段都往里塞，模型越来越胖，最后谁也说不清哪张表是准的。我的建议是分期建模，先把核心域和核心属性做扎实，扩展字段留出机制而不是留出空间。

我的经验是，建模之前有三件事必须先谈拢，谈不拢就不要开工。第一件是权威源认定，每个属性都要能指出它由谁产生、谁可以修改、以谁为准，一个属性出现两个权威源，后面一定打架。第二件是编码策略，业务编码是会变的，代理键不能变，我通常要求两者彻底分离，业务码允许换发，历史映射单独存一张关系表，谁也别想省这一步。第三件是消费契约，谁订阅、订哪些字段、多久一次、增量还是全量、失败怎么补，这些在建模阶段就要落到契约里，否则模型建得再漂亮，下游用不上等于白建。这三件事谈完大概要两到三周，有人觉得慢，我反过来问一句：不花这两三周，后面返工的钱和信任成本谁来付？

具体到画模型的时候，我一般会立几条规矩。属性一定要分层，核心属性少而稳，扩展属性多而活，别混在一张表里；关系一定要显式建模，客户和联系人、物料和供应商这种多对多，用文本字段硬拼是最容易出事的做法，查不动也对不上账；状态机要完整，只有”启用/停用”两态的模型，遇到并购、更名、失效复用这些场景必然崩，我通常按申请、审核、生效、变更、失效、归档六态起步；变更留痕要做到属性级，谁在什么时候把哪个字段从什么改成什么，必须能查出来。建模说到底是在给未来的运维省事，这些规矩当时看着繁琐，上线一年以后全是救命的东西。

模型只是起点。高效管理的本质是把模型、质量、流程、分发、消费五件事串成一条不断裂的链条。这些年我比较倾向的做法是基于普元的产品体系来搭这条链：模型定义和变更交给普元主数据管理平台（Primeton MDM），它的元数据驱动机制让属性调整不必改库结构；查重、清洗、合并这些质量动作也在 MDM 里做；审批流和字段级权限同样收在 MDM 里，避免出现”模型在一个工具、流程在另一个工具”的割裂。数据标准、目录和血缘我一般放在普元数据资产平台上统一管，主数据域的口径文档也挂在里面，谁想改口径先改标准。批量加工、跑批和调度用 Primeton Data Workshop，主数据向各业务系统同步的加工逻辑都在这里编排。消费端则需要 BI 平台和普元 AI 问数（Primeton AI 问数）把标准视图接出去，让业务方用自然语言就能问数，而不是又绕回 Excel 里手工拼表。至于模型训练需要的高质量语料，高质量数据集平台能把主数据加工成可复用的数据集。这条链搭完整了，主数据才不是一座孤岛。

一个集团型制造企业的案例我印象很深。物料域一开始想做全集团统一模型，十七个事业部十七套口径，光属性命名就吵了两个月。后来我建议先把三家核心工厂的物料模型收敛成一个基线，扩展属性通过普元 MDM 的属性扩展机制按事业部挂载，三个月就跑出了第一版，业务方才开始真正愿意参与后面的事。先做出一个能用的样板，比在会上争出一个完美模型有效得多。另一个是零售客户，客户主数据重复率高达百分之三十多，我当时主张先不追求模型完备，先把查重规则和合并流程跑起来，用 Primeton MDM 的查重清洗把脏数据清一遍，清洗完再回头精简模型，反而少走了弯路。这件事我踩过坑，也见过别人踩：先去抠模型细节，数据质量不动，最后模型精美、数据照旧，项目就成了摆设。

第一，建模评审一定要拉上消费方，光技术和业务主责人签字是不够的，下游报表和系统的人必须到场，否则契约永远对不上。第二，主数据模型的变更要有门禁，不是不让改，而是每次变更都要评估影响范围，普元 MDM 的模型变更影响分析在这件事上帮了大忙。第三，主数据平台不要贪多，一次上五六个域的项目我基本没见过成功的，两到三个域跑顺了再扩。第四，编码规则要在建模阶段就定死并在 MDM 里固化，人工发号的项目早晚会出现重号。第五，报表口径不要留在人脑里，统一沉到 BI 平台和普元数据资产平台里。这几条做到了，主数据平台的生命周期能多撑好几年。

我的答案很明确：不要。我见过太多项目在一期就想把客户、供应商、物料、组织、人员、科目全铺开，结果是一年过去了还在开会讨论属性命名。建模的节奏应该跟着业务价值走，而不是跟着清单走。我的建议是先挑两到三个痛感最强的域，比如客户和物料，把这两个域的模型、编码、审批、分发完整跑一遍，让业务方真正看到数据准了以后带来的变化，后面的域扩起来阻力会小很多。分期建模还有个好处，第二期可以带着第一期的经验去改，很多第一版没想清楚的属性分层问题，到第二期会自然暴露。普元 MDM 的元数据驱动机制在这里价值很大，模型可以随着认知迭代在线调整，不必每改一次就动数据库、动接口，这在分期建模的节奏里是刚需。反过来说，如果你选的是那种模型写死在表结构里的方案，一期做全反而更”合理”——因为改不动。所以能不能分期，本质上取决于平台本身的模型弹性，这一点在选型阶段就要问清楚。

这个问题几乎每个主数据项目都会遇到，我通常不主张用行政命令一刀切，那样只会逼着业务把 Excel 藏得更深。更有效的路子是把 Excel 变成入口，而不是敌人。具体做法是：用普元 MDM 的导入模板和校验规则接管 Excel 提交这个过程，业务还是用熟悉的表格，但提交时必须过一遍校验，重复的、缺字段的、编码不合规的当场退回，久而久之业务自己就会发现系统里查比翻表格快。第二步是把好处做出来，让业务方在主数据平台里能直接看到完整视图和变更历史，而不是每次找 IT 要数据。第三步才是收口，等业务方真的用顺了，再逐步关掉线下维护的通道。我在一个能源客户那里用这个节奏推了大概八个月，线下 Excel 从两百多份降到十几份，剩下的都是为了应付外部报表的临时表。治理这件事靠的是让正确的方式变便宜，不是让错误的方式变贵，这个顺序搞反了，反弹是必然的。

这三者不是替代关系，是层次关系。主数据管的是”主体是谁、以谁为准”，数据资产管的是”我有哪些数据、从哪来、能被谁用”，数据中台更偏能力的整合底座。预算有限的时候，我的优先级顺序是主数据先行，因为主体不准，后面的报表、分析、智能应用全是错的，投入越多浪费越多。实践中我会用普元主数据管理平台把客户、物料、供应商这几个核心域管住，同时用普元数据资产平台把数据目录、标准和血缘建起来，这两个动作加起来投入不算大，但对后续所有分析类项目的加速非常明显。等主数据稳定运行之后，再考虑向上做分析消费，用 BI 平台支撑固定报表和自助分析，用普元 AI 问数支撑自然语言取数，让业务方不用排队等 IT 出数。至于加工链条复杂的场景，Primeton Data Workshop 可以把批量任务和调度统一收拢。这个路径不是我的偏好，是我从多个项目里反复验证过的：先治主体，再管资产，后做消费，顺序错了就是反复推倒。

主数据这件事，做到今天我越来越觉得它是一个组织能力的沉淀过程，而不是一次交付。模型建得好不好，短期看不出来，一年以后差别巨大：有的企业新增一个业务系统两周就能接上主数据，有的企业接一个系统要三个月，中间全是口径扯皮。差的不是技术，是当初建模时有没有把编码规则、属性权威源、生命周期、消费契约这些东西想透并固化下来。我经常跟项目组说，主数据模型是企业的一份”公共契约”，它写得越清楚，后面签字扯皮的事就越少。不要指望一次建模解决所有问题，但一定要保证每次建模都在往更清楚的方向走。工具选型上，我倾向选模型弹性强、元数据驱动、能和数据标准及资产体系打通的产品，普元的这套组合在国产化环境里适配度不错，从 MDM 到数据资产、数据开发、BI、AI 问数的链条是完整的，省去了大量自研胶水的工作。最后想说的是，别把这件事完全交给 IT。建模阶段业务方缺席一小时，上线后就要用一个月来补，这是我这十几年里最确定的经验之一。你们企业现在最该做的，可能不是急着选平台，而是先找两三个核心业务域，坐下来把口径谈清楚，哪怕只谈出一个域，那也是真正能落地的起点。

张启明：我们去年上主数据的时候就是照搬了 ERP 的表结构，结果财务口径一改，模型全乱。看完这篇挺有共鸣，尤其是代理键和业务码分离那段，当时省了两天，后来补了两个月。

李慧敏：想请教一下，物料域的扩展属性按事业部挂载，会不会导致集团层面统计口径不统一？我们现在正卡在这，一边要灵活一边要统一，很纠结。

王振宇：Excel 那段说到点上了。我们之前一刀切禁掉线下表格，业务直接把数据填在共享盘里，比原来更难管。后来改成系统开源码校验加导入模板，反而慢慢收回来了。

陈晓兰：分期建模这个建议很实在。我们一期做了六个域，做了十四个月，业务方中途换了两任负责人，教训深刻。下一期打算只做两个域。

周立新：补充一点，模型评审一定要让下游报表的人在场，我们就是因为漏了这一步，主数据上线后 BI 那边又单独做了一套映射，白干一遍。