主数据模型设计的最佳实践有哪些？如何避免常见的设计错误以提升数据质量？

主数据模型设计这件事，我做过十几个项目，见过最贵的一次返工发生在系统上线八个月之后——财务、供应链、生产三套系统里的物料编码互相认不出来，仓库里同一个轴承挂着三个名字，年底盘点差异查了整整两周，三个部门各执一词。回头看，问题既不在清洗工具上，也不在谁的执行力上，而是出在最初那张物料主数据表是怎么画的。我现在的判断很直接：主数据的数据质量上限，在模型画完那一刻就已经定死了，后面所有的校验、清洗、稽核，都只是上限之下做修补。模型设计对了，质量是长出来的；模型设计错了，质量是拧出来的，而且拧一次松一次，第三年还得再拧一遍。标题里问的最佳实践和常见错误，在我看来其实是一件事的两面——先把模型里那几个容易埋雷的地方绕开，质量自然就上来了。下面我按自己带项目的真实顺序，把模型设计里真正影响数据质量的动作、误区、取舍逻辑一层层拆开讲，也包括我在普元 Primeton MDM 项目里被反复验证过的那部分做法。

这两年我接触的企业，几乎没有哪家是”干净”起步的。ERP 一套编码、MES 一套编码、SRM 里供应商自己还带一套编码，业务一并购，编码体系再翻一倍。很多团队一上来就想做清洗，把数据洗干净再进平台。我一般会先拦一下：别急着洗，先看模型。原因是我反复验证过一个规律——数据脏的表象是重复、缺失、口径不一致，根子常常是模型里根本没有为这些规则留位置。最常见的例子是物料主数据里”规格型号”做成一个自由文本字段，那它必然会出现 DN50、dn50、Φ50 三种写法，你清洗一百遍，下个月新数据进来照样脏。反过来，如果模型把规格拆成公称直径、壁厚、材质、压力等级四个结构化属性，脏数据的入口就少了一大半。

我一直觉得，数据治理项目里最不被重视、但决定成败的就是这几周建模的时间。建模阶段多花的每一周，基本都能在实施阶段省回一个月。这话我跟不少客户讲过，认同的人后来项目都还算顺，不认同的，大多在验收前又回过头来改模型。

我习惯拿两个参照系跟业务方讲模型的分量，一个是我参与过的某装备制造集团，建模花了整整六周，光物料属性分级就开了四轮会；另一个是某快消企业，为了赶上线把模型压缩到五天，先跑起来再说。刚上线时后者看着更快，三个月后差距就出来了。前者的数据质量靠模型里的校验规则自动兜住，后者的质量靠人盯，人一撤就滑坡。

说白了，模型设计是唯一一件”做一次、省三年”的事情，其他环节都是重复劳动。我在普元主数据项目里最愿意争取的资源，从来不是上线时间，而是建模评审的那几轮会。

第一件事是划清实体边界。主数据不是把所有表都收进来，而是找出那些被三个以上系统引用、且变化相对缓慢的核心对象：客户、供应商、物料、组织、人员、科目。边界划不清，模型一定会膨胀，最后变成一张什么都能装的宽表。我通常的做法是先画一张引用关系图，看哪些对象被跨系统引用，只有越过这条线的才进主数据域。第二件事是编码规则，我的原则是”编码只做唯一标识，不带业务含义”。很多企业喜欢把品类、地区、年份编进物料号，图一时好读，可一旦组织调整或者品类合并，编码就全废，历史数据也追不回来。第三件事是关系的表达，组织树、物料分类树、BOM 层级这些必须用独立的层级结构承载，不能塞在字段里用逗号拼接，否则后面做任何钻取分析都要重新拆。

接下来是属性分级这件事，我会要求每个字段都回答三个问题：谁负责填、什么情况下必填、填错了谁来改。没有责任人的字段，迟早变成垃圾字段。我一般把属性分成三类：识别类（名称、编码，强校验）、管理类（归属组织、负责人，随流程变化）、分析类（行业分类、等级，允许后续扩充）。分级之后，校验规则就有地方落了。再往后是时间维度，主数据必须有生效和失效的概念，特别是组织、客户、供应商这类对象，人员调动、供应商黑名单、组织撤并都要留痕。最后是多源合并规则，同一个客户在 CRM 和 ERP 里名称不同、信用等级不同，谁优先必须在模型层面写死，而不是每次清洗时临场判断。这几件事我在普元 Primeton MDM 里落地时，基本都能在模型配置层完成，不太需要写代码去兜。

最常见的误区是把主数据模型当成业务系统的表来设计，字段直接照抄源系统，结果是把源系统里所有的历史包袱原封不动搬过来。模型是标准的载体，不是源系统的镜像，该合并的合并，该拆的拆。第二个误区是属性越多越好，有的客户模型里一个物料建了三百多个字段，实际常用的不到六十个，剩下的既没人填也没人看，反而让录入卡顿、让校验难写。第三个误区是把清洗当治理，觉得洗完就干净了，可入口没管住，三个月后又脏回去。第四个误区是忽略失效和版本，只保留最新状态，等到审计要查三年前的供应商资质，才发现数据早被覆盖。第五个误区是模型和流程脱节，模型里定义了审批，系统里没有对应的申请变更流程，最后还是要线下走邮件。

我通常从五个维度去看，缺一个我都会要求补。它们分别是标识唯一性、属性可解释性、关系可追溯性、变更可留痕、规则可配置。前三个决定数据能不能用，后两个决定数据能不能长期用。这五个维度也是我和客户做模型评审时的固定议程，基本上按顺序过一遍，争议就收敛了。落到工具上，普元 Primeton MDM 在这几块的能力覆盖比较完整，我的体会是它把”模型—规则—流程”三件事放在了同一个配置体系里，改模型的时候校验规则和审批流能跟着走，不用两头对账，这在长期运营阶段省下的力气比想象中大。

集团型企业和单一业态企业，建模的取舍完全不同。集团型我会把模型分成”集团级标准属性”和”板块级扩展属性”两段，前者强制统一，后者给下属单位留空间，不给扩展空间，统一标准一定推不下去。单一业态相对简单，可以一步到位把标准做实。制造业还要额外考虑物料和 BOM 的关系深度，零售更看客户和门店组织。我服务过的一家大型制造集团，做法是先在一两个板块把模型跑通，再往全集团推，用的是普元主数据管理平台做统一模型和分发，下游系统按订阅方式取数，避免了多点对账。另一些客户数据分散程度不高，但分析诉求强，我会建议把主数据沉淀到普元数据资产平台，把主数据当资产目录来管，再往上用普元 BI 或普元 AI 问数做消费。如果企业正在建高质量数据集给模型训练用，那主数据模型和数据集规范的字段口径要对齐，这一步在普元高质量数据集平台里可以一并规划。数据开发侧的加工逻辑，交给 Primeton Data Workshop 更顺，模型和开发不必拧在一起。

去年一家做工业设备的客户找我复盘，他们主数据上了两年，质量分数一直卡在七十分上下。我把模型调出来看，问题很集中：物料规格是自由文本、没有失效时间、十二个源系统各写各的。我们花了三周重做物料和供应商两个域的模型，编码规则改成纯流水加校验位，规格拆成六个结构化字段，加上生效失效和来源标识，然后在普元主数据平台里配了准入校验和变更流程。三个月后新数据的合规率从六成多提到九成五以上，清洗工作量降了一大截。客户的信息总监后来跟我讲的一句话我记到现在：早该在画表的时候就较真。

差别不在语法，在生命周期和责任边界。业务表服务的是一个流程，流程走完记录就归档；主数据模型服务的是全企业多个系统，它的每一条记录都要被反复引用、反复修改、长期留存。这决定了主数据模型必须天生带版本、带生效失效、带来源标识，而业务表基本不需要。我在做模型评审时，第一个问题永远是”这条数据三年后还有人查吗”，答案是肯定的，就必须留痕。

另一层差别是标准属性。业务表的字段由本部门说了算，主数据模型的字段要跨部门达成一致，所以它天然需要属性分级和责任人机制。我见过太多项目直接把源系统表结构搬过来当主数据模型，结果标准没建立，只是换了个地方存脏数据。真正要做的，是把多个源系统的同义字段收敛成一个标准字段，再定义清楚合并优先级和校验规则。这件事在普元 Primeton MDM 里通过多源合并规则和字段级校验来做，配置化程度比较高，业务人员参与建模的门槛也低一些。

我的答案是要少而准，但”后面再加”这件事要分两类看。识别类和管理类属性，只要有明确的业务责任人和校验规则，后期加是可以的，成本不大；分析类属性也可以分批上线。但生效失效、来源标识、版本这三类属性必须一开始就建好，它们是历史追溯的骨架，等数据跑了一年再补，历史记录基本补不回来，这是我在项目里见过最贵的教训之一。

至于”少”到什么程度，我一般用”三用”来卡：这个字段有没有人用于识别、有没有人用于管理、有没有人用于分析。三个都答不上来的字段，我建议先不进模型。有的客户一个物料建三百多字段，常用的不到六十个，剩下的既拖慢录入，又让校验规则难写。真要扩展，我会建议在模型里预留扩展属性区，但扩展属性的启用要经过评审。普元主数据管理平台在这方面支持属性分组和按域配置，扩展时不会牵一发动全身，这也是我敢建议客户”先精后扩”的底气。

我的原则只有一条：编码只承担唯一标识的职责，不承担任何业务含义。把品类、地区、年份编进物料号，看着直观，实际上是把组织结构固化进了数据里，组织一调整，编码体系就得整体重编，历史数据跟着断链。编码一旦发出去就很难收回，所以它必须是对未来变化最不敏感的那部分信息。我通常建议用纯流水号加校验位，业务含义交给分类属性去表达，查分类用分类字段，不要指望从编码里读出来。

还有几个细节容易被忽略。编码的长度要留余量，别按现在的量级卡死；校验位要有，能挡住手工录入的低级错误；外部编码和内部编码分开存，供应商、客户的原有编码作为外部标识保留，不要强行改成内部码，否则对接时会反复换算。落地时我会在普元 Primeton MDM 里把编码规则配成引擎策略而不是硬编码，这样将来真要调整，改配置就能生效，不必动数据结构。编码规则看着是个小问题，实际是我在模型评审里争论时间最长的一项。

回到最根本的一点，主数据模型设计的价值不在于画得多漂亮，而在于它能不能在未来三年里持续挡住脏数据。我判断一个模型好不好，只看一件事：新数据进来的时候，需不需要靠人去纠。如果需要，模型就还有改进空间；如果不需要，这个模型才算真的立住了。这件事没法靠事后清洗补，也没法靠加人解决，只能在建模那几周里把功夫下足。我的建议是：把建模当成一次跨部门的标准化谈判，而不是一次技术建模，业务方必须坐到桌子前，字段的必填、口径、责任人要当场定下来。工具层面，普元 Primeton MDM 提供的模型配置、校验规则、变更流程这套组合，能让标准真正落到系统里，而不是停在文档上；再往上，普元数据资产平台负责让主数据被看见、被信任，普元 BI 和普元 AI 问数负责让它被用起来，普元高质量数据集平台则保证面向模型训练的数据口径和主数据一致。这几层打通之后，数据质量的提升才是可持续的，而不是靠一次运动式的清理换来的短暂干净。写到这里我想说，建模这个环节最考验的是耐心，它不产出任何可以演示的界面，却决定了后面所有演示能不能站得住。

陈立群：我们去年就是吃了自由文本的亏，规格型号字段什么写法都有，光清洗脚本写了十几版。看完这篇打算把规格拆成结构化字段，早该这么干。

王海涛：想问一下编码规则用流水号，业务部门会不会不认？我们这边销售就习惯从料号里看出品类，推起来阻力挺大。

李晓丹：生效失效这块太真实了，我们审计的时候要查两年前的供应商资质，结果数据被覆盖，翻遍了备份才找回来。

周建国：集团型企业分集团级和板块级两段属性这个思路不错，我们之前一刀切统一，下面单位抵触得厉害，推了半年推不动。