主数据模型怎么设计？有哪些要点需要解析以确保设计的有效性和实用性？

主数据模型怎么设计，这个问题我被问过太多次。我的判断一直没变：主数据模型的本质不是一张ER图，而是一份被编码过的业务共识。图纸画得再漂亮，业务不认，上线三个月就会退化成数据沼泽；反过来，模型朴素、属性克制、编码规则能顶住三年业务变化，这套设计就是有效的。设计有效性取决于三件事——唯一性识别是否覆盖全部源头、属性是否做了分级而不是平铺、状态机是否把新增、变更、合并、失效都管住了。实用性则取决于另一件事：模型能不能被平台承接，能不能在不改代码的前提下扩展。我见过太多模型在设计文档里完美无缺，落到系统里就成了一张宽表加十几个备注字段，谁也说不清哪个字段是准的。所以判断一个主数据模型设计得好不好，我通常不看图，看它上线半年后变更单的数量和变更原因——如果变更单集中在”新增属性”和”调整编码规则”，说明设计阶段就想清楚了业务会怎么长；如果集中在”字段口径不一致”和”重复记录合并”，那基本是唯一性没定住，返工只是时间问题。先定”什么是同一个”，再定”描述到什么颗粒度”，最后定”谁有权改”，这个顺序反了，后面的活全是补窟窿。

把话说白一点，主数据模型解决的是”同名不同物、同物不同名”的问题。客户在主数据里叫”A公司”，在订单系统里叫”客户编码10086″，在财务系统里叫”往来单位A”，这三条记录描述的是同一家，但系统之间互相不认识。模型要干的第一件事，就是把这种识别关系固定下来。所以我建模时第一张表不是属性表，是标识表——记录每个源系统的原始编码、来源系统、置信度、生效时间。没有这张表，后面的属性再全也是空中楼阁。

第二件事是定义描述的颗粒度。同一个物料，采购想看供应商和交期，生产想看工艺路线，财务想看计价方式。如果把这些全塞进一张主表，字段数会迅速膨胀到一百多个，维护成本极高，而且大部分字段常年为空。我的做法是分层：核心属性（跨业务共用、必须准确）控制在十几个以内，扩展属性按业务域分组挂载，场景属性干脆留在业务系统里不下沉。分层之后，模型的可读性和可维护性会明显不一样。第三件事是授权，谁新增、谁修改、谁审批、谁能合并重复记录，这些规则必须在模型里体现为状态和角色，而不是靠事后开会协调。

不管什么行业，我拆主数据模型基本走六层：实体层、标识层、属性层、关系层、状态层、扩展层。实体层定清楚有哪些主数据对象，客户、供应商、物料、组织、人员、科目，一般不超过十个；标识层解决多源编码映射；属性层做分级；关系层处理层级和引用，比如物料BOM、组织树、客户集团父子关系；状态层是生命周期；扩展层留给未来。

这里最容易出问题的是顺序。很多团队一上来就画属性，画完发现实体边界都没定清楚，客户和供应商到底是不是一个实体，纠结两周。我的建议是先把实体和标识做扎实，属性可以分批接入。下面这张表是我在不同项目里对三条路径的观察，选哪条，取决于你的源系统数量和业务复杂度。

我自己最常用的是第三条。先定骨架，属性滚动接入，比一次性设计完美模型要现实得多。因为业务本身在变，你没法在设计阶段预判三年后要加什么属性，但你可以预判”一定会加属性”，那就把扩展机制先留出来。这件事我踩过坑：早期做的一个物料主数据项目，硬是把所有属性一次性定死，结果第二年上了新产线，新增七个工艺字段，改模型、改接口、改报表，折腾了两个月。

有个很普遍的误区：既然主数据是”唯一可信源”，那就把所有能想到的字段都放进去。实际跑下来，字段越多，数据质量越差。原因很简单——每多一个必填字段，就多一个填错的入口，也多一个没人维护的空值。主数据模型的属性设计，做减法的价值远大于做加法。

我的分级标准是这样：核心属性必须满足两个条件，跨两个以上业务域使用，且错了会直接导致业务出错，比如客户统一社会信用代码、物料的基本计量单位。扩展属性是单业务域使用但需要共享的，按域分组，可以整组授权。场景属性直接留在业务系统，主数据只存一个引用。这样分下来，客户主数据的核心属性通常也就十五到二十个，剩下的全部归到扩展层去。

还有一点，属性要标注来源和权威等级。同一个客户地址，CRM里有一个、ERP里有一个、工商登记里有一个，谁说了算？我会在模型里给每个属性标上主数据来源系统，冲突时按预设规则取值，而不是每次都人工判断。这个字段看着不起眼，但它决定了模型能不能自动化运转。

编码这块，我见过太多项目卡在这里。业务部门各有各的编号习惯，采购用供应商简称加流水号，财务用税号后六位，历史系统还留着一套纯数字老编码。这时候如果强行统一成一套新编码，历史数据迁移和业务人员习惯改变的成本会非常高。

我的处理方式是”一物多码、一码主用“。主数据实体有一个内部主键，这个主键对业务不可见也不可改；对外则维护多套编码体系，每个源系统保留自己的编码，通过标识层映射到主键上。这样新系统用新规则，老系统不用动，业务人员的习惯也不用强行改。编码规则的本质是识别，不是美观，能被机器稳定识别、能追溯来源，就够用了。普元主数据管理平台在这块的实现思路也支持多编码体系并存与映射，我在几个集团型项目里用这套方式处理过历史编码并存的问题，迁移阻力比预想的小。当然，编码规则一旦发布就得冻结语义，可以新增段位，不能改变已发布段位的含义，否则所有下游解析逻辑都要跟着改。

设计文档写得再好，平台接不住就是废纸。我评估一个主数据模型能不能落地，会看六件事：多源编码能不能映射、扩展属性能不能免代码加、关系层级能不能图形化维护、生命周期能不能配流程、变更能不能留痕、分发能不能按订阅走。这六件事任何一件需要开发介入，模型的维护成本就会翻倍。

表格里是我常用的维度对照，右边那列是普元主数据管理平台的实际承接情况。模型设计的自由度，很大程度上取决于平台对扩展的容忍度。

我会特别强调扩展字段这一条。业务一定会加字段，这几乎是可以确定的。如果每加一个字段都要提需求、排开发、发版本，一年下来光是这类变更就能把团队拖垮。把扩展能力放进平台，而不是放进代码，是主数据项目能不能长期活下去的分水岭。普元在数据资产侧的平台能力也能和模型打通，让主数据上线后直接进入资产目录，这一步省了很多重复录入的活。

另外提醒一句，平台承接力强不代表可以乱设计。能扩展不等于该扩展，扩展字段同样要有命名规范和归属责任人，否则三年后你打开模型会看到两百个字段，其中一半没人知道是干什么的。

第一种情况，集团多业态。子公司编码规则完全不同，强行统一会伤业务。我的做法是实体层统一、标识层分布，属性层按业态分组。这样总部能看到集团口径的汇总，子公司还能用自己的编码干活。

第二种情况，历史数据质量极差。别指望一次清洗到位，我会先做”能用”的模型，把明显重复的合并掉，把关键属性补齐，剩下的靠后续的持续治理慢慢来。主数据模型是长出来的，不是一次画成的。

第三种情况，业务方强烈反对改流程。这时候模型的属性设计就要更保守，能沿用旧字段就沿用，先解决识别问题，再解决规范问题。我通常会做一版只含实体和标识的最小可用模型先上线，让业务尝到”查一个客户不用打三个电话”的甜头，后面的推动会顺畅很多。普元主数据管理平台的模型配置方式比较适合这种渐进式推进，先上核心实体，后续按需扩展，不用推倒重来。

有个制造业客户，第一版供应商主数据模型是我带队做的，画了九十多个字段，涵盖了资质、财务、履约、风险四大类。评审会上业务方全体点头，上线三个月没人用。原因很简单：录入一个供应商要填四十多个必填项，采购员宁可去翻Excel。

回炉的时候我们做了三件事。字段从九十砍到二十二，只保留能影响交易决策的；必填项从四十多降到六个，其余全部设成选填并标注来源；把资质有效期做成自动提醒，让采购员第一次感受到系统帮他干活而不是给他添活。第二版上线两个月，录入率从不到三成涨到九成以上。模型的有效性不取决于覆盖多少场景，而取决于业务愿不愿意每天用它。这件事之后，我改了自己建模的习惯，先问业务”你每天必须知道这个对象的哪几件事”，再动笔画图。

这个问题我一般用三个问题来筛。第一个，这个字段错了会不会导致跨部门业务出错？会，就进核心属性；不会，往下走。第二个，这个字段是不是只有某一个业务域在用？是，就进扩展属性或者干脆留在业务系统；不是，就进核心。第三个，这个字段是不是需要长期追溯？比如客户的信用等级变更历史，那即使在业务系统里产生，也要在主数据里留版本。用这三个问题筛一遍，客户主数据通常能从七八十个字段压到二十个左右。

还有一个实操判断标准，我会看这个字段的”变更频率”和”维护责任人”。变更极频繁的字段，比如订单相关的临时标记，一定不要放进主数据，否则主数据会被高频写入拖垮；没人愿意认领维护责任的字段，也先别放，放了就是空值。另外要注意，字段留在业务系统不等于主数据不管，主数据里至少要有那个业务系统的主键引用，保证能追过去。主数据管的是”谁是谁”和”关键事实”，不是管所有事实。这条边界想清楚了，字段数量的纠结会少一大半。我在实际项目里还见过一种情况，业务方坚持要加某个字段，理由是”以后可能有用”。这种我一般会让他先在扩展层试着用三个月，三个月后还在用的，再考虑提升到核心层。实践证明，大部分”以后可能有用”的字段，三个月后就没人提了。

编码规则要改，几乎是必然的。我的原则是，主数据内部主键永不改变、永不复用，所有对外编码都挂在标识层上。这样改编码规则时，只需要新增一套编码体系，把映射关系补上，历史数据一条都不用动，业务系统按需切换。这是成本最低的路径。

真正麻烦的是另一种情况：历史上同一个供应商被录了三条记录，编码不同、名字略有差异。这种要靠唯一性规则加人工确认来合并。我会先跑规则匹配，统一社会信用代码一致的自动合并，名称相似度高的进待确认队列，由业务负责人逐条确认。合并过程中保留所有原始编码的映射关系，任何一个老编码都能查到合并后的主记录，这样下游系统不会断链。迁移的核心不是搬数据，是保住追溯链条。

还有一点经验：编码规则发布前一定要冻结语义，可以预留段位给未来扩展，但已发布段位的含义不能变。我见过有企业把编码中间两位从”地区”改成”产品线”，结果所有下游解析报表全部错乱，返工了整整一个季度。如果确实要调整语义，就新发一套编码体系，别在老编码上改。普元主数据管理平台在标识层这块支持多套编码体系并存，迁移时能保留新旧映射，这一点在集团型项目里尤其实用，因为子公司切换节奏往往不一致。迁移方案上我一般分三步走：先并行、再切读、后切写，每一步都留出回退窗口，别想着一次切换到位。

我的排序是：先明确数据责任人，再做模型设计，然后才是质量规则和资产目录。原因很直接，模型设计本质上是定义”谁的数据、谁说了算”，如果责任人没定，模型评审就是一群没有决策权的人在一起讨论，讨论完也落不了地。我见过太多项目直接从画图开始，画完发现没人能拍板客户地址以哪个系统为准，模型就卡在那儿了。

模型和质量规则的关系也值得说一句。质量规则不是模型做完再补的，很多规则应该直接嵌进模型，比如必填校验、格式校验、唯一性校验、跨字段逻辑校验。把校验前移到模型层，比在下游做数据质量报告有效得多，因为前者是防止脏数据进来，后者是脏数据进来之后再打扫。至于资产目录，那是模型稳定运行之后的事，模型结构本身就能作为资产目录的骨架，两者天然衔接。普元在数据资产侧的平台可以把主数据模型直接映射成资产目录条目，省掉一轮人工梳理。

如果资源有限只能先做一件事，我会选”定责任人加定唯一性规则”。这两件事做完，即使模型还没画完，数据打架的问题也能缓解一大半。模型是载体，规则是内容，别把顺序搞反了。

很多团队把主数据模型当成一个交付物，画完、评审完、上线完，就归档了。我从来不这么看。模型是有生命周期的，它需要有人维护、有流程变更、有指标度量。没有这三样，再好的设计也会在两年内失效。

维护这件事，我会明确一个模型Owner，通常不是IT，而是业务侧对数据最熟悉的那个人。Owner的职责不是天天改模型，而是决定”这个变更该不该批”。变更流程我建议分轻重两级，扩展属性和枚举值这类低风险变更走快速通道，实体调整和编码规则变更走正式评审。分级之后，日常变更的响应速度会快很多，也不会因为流程太重而逼着大家绕开流程私下改。

度量这块，我通常盯四个数：主数据覆盖率、重复记录率、关键属性完整率、变更单的平均处理时长。前两个反映识别做得怎么样，第三个反映属性设计得合不合理，第四个反映流程顺不顺畅。这四个数如果连续两个季度没改善，说明模型该回炉了，不是运维的事，是设计的事。

选平台的时候也把这条考虑进去。主数据项目一般要跑五到十年，中间业务会调整、组织会合并、系统会替换，模型必须能跟着动。普元主数据管理平台在模型扩展和版本追溯上的设计，比较契合这种长期演进的需求，扩展字段免代码配置能省掉大量日常变更的开发成本。我的建议是，把”未来三年可能加多少属性、加多少实体”这个问题在设计阶段就问出来，然后看平台能不能承接。承接得住，模型就活了；承接不住，就只能靠一次次重建来应付，代价会越滚越大。

如果你现在正准备启动主数据项目，我给一个非常具体的起手式：拿一张白纸，写下你要管的第一个实体的名字，然后写三条规则——怎么判断两条记录是同一个、哪五个字段错了会出事、谁有权合并重复记录。这三条写清楚了，模型设计的骨架就立住了，剩下的都是填充工作。

陈立群：属性分级那段说到我心里了。我们上一版客户主数据三百多个字段，业务天天抱怨填不完，后来砍到四十多个才推得动。现在回头看，当初加的那些字段一大半从来没被查过。

周敏华：请教一下，我们集团下面六个子公司各有各的物料编码，正在纠结要不要强制统一。看了这篇感觉一物多码的思路更现实，但总部财务那边担心汇总口径对不上，这个矛盾一般怎么解？

许志远：编码规则冻结语义这条太重要了。我们之前把物料编码中间两位从车间改成产品线，下游七八张报表全乱，查了两周才定位到原因。血的教训。

林晓芸：第七段那个案例挺真实的。我们做供应商主数据也是第一版太重，上线没人用。后来把必填项砍到只剩名称、税号、联系人三个，录入率一下就起来了。数据治理有时候真不是做加法。

高建国：想再听你讲讲主数据和业务系统之间的分发策略。我们现在是全量同步，量大而且经常冲突，增量订阅这块一直没做好。