2. 主数据模型与变更对象识别

主数据治理的第一道工程关口，不是审批流程本身，而是“变更对象识别”。如果连一次变更究竟改了什么、影响谁、是否属于主数据范围都判断不清，后续的审批层级、版本号规则、生效时间控制都会失去依据。本节围绕主数据模型的三层结构——实体、属性、关系，以及贯穿其中的编码体系，说明如何把一次业务动作翻译成可审批、可版本化的变更对象。

一、主数据模型的三层结构

主数据模型通常可以拆成三个层次来理解。最上层是实体，即业务上独立存在、需要被唯一标识和长期维护的对象，例如“客户”“物料”“供应商”“组织”“银行账户”。实体回答的是“我们管理哪些对象”。第二层是属性，描述实体的特征，例如客户实体下的客户名称、统一社会信用代码、注册地址、客户等级、结算币种。属性回答的是“这个对象有哪些信息”。第三层是关系，描述实体之间的连接，例如“客户—销售组织”的归属关系、“物料—工厂”的供应关系、“供应商—银行账户”的收款关系。关系回答的是“对象之间如何关联”。

这三层不是并列的，而是层层依赖：实体决定属性的归属，属性与关系共同决定一条主数据记录在业务系统中的可用性。识别变更对象时，必须同时判断变更落在哪一层，因为不同层次的变更，其影响面和审批要求差异很大。

二、编码体系：主数据的“身份证”

编码体系是主数据模型中最容易被低估、却最影响版本治理的部分。编码不是简单的流水号，它承担着唯一标识、跨系统对齐、历史追溯三重职责。一个可用的主数据编码通常要满足五个条件：唯一性（同一实体不重复）、稳定性（编码一旦分配不随属性变化而改变）、可扩展性（预留足够位段应对业务增长）、语义可读性（在合理范围内体现分类或来源）、跨系统一致性（同一实体在ERP、CRM、MDM中编码一致或可映射）。

以物料编码为例，一种常见设计是“分类码 + 流水码 + 校验位”，例如 M-03-001287-6：M 表示物料大类，03 表示子类，001287 为流水号，6 为校验位。这种结构下，分类调整会直接影响编码语义，因此“分类码变更”往往需要纳入审批；而流水号本身不承载业务含义，通常不单独审批。编码规则一旦确定，就应作为主数据模型的一部分冻结，任何规则级调整都属于高影响变更。

三、哪些变更需要纳入审批与版本管理

并非所有字段修改都值得走完整审批。判断标准可以归纳为三条：是否影响唯一标识、是否影响跨系统或跨组织使用、是否影响历史数据追溯与合规。满足任意一条，就应纳入审批与版本管理；三条都不满足的，可以走轻量变更或直接由数据 steward 处理。

具体到变更对象，可以分成四类：

• 实体级变更：新增实体类型、停用实体、合并重复实体。这类变更影响模型结构，必须审批并产生模型版本。
• 编码级变更：编码规则调整、编码段含义变化、编码映射关系修改。影响唯一标识与跨系统对齐，必须审批并版本化。
• 关键属性变更：如客户名称、统一社会信用代码、物料基本单位、供应商银行账号。影响业务执行与合规，需审批并保留变更前后版本。
• 关系变更：如客户归属销售组织调整、物料供应工厂增减、供应商收款账户替换。影响业务范围与结算路径，需审批并记录生效时间。

相对地，像联系电话格式修正、内部备注补充、非关键描述性字段的错别字修改，通常不纳入版本管理，只需保留操作日志即可。这里的关键是：版本管理针对的是“业务上可感知的状态变化”，而不是每一次数据库写入。

四、从变更请求到变更对象的识别方法

实际工作中，业务人员提交的往往是一句自然语言请求，例如“把华东区客户A的信用额度从100万调到300万”。要把它转成可审批的变更对象，需要做三步拆解：

1. 定位实体：客户A属于“客户”实体，主键为 CUST-100234。
2. 定位属性或关系：信用额度是客户实体下的属性，且通常与“销售组织—客户”关系上的信用控制范围绑定。
3. 判断变更类型：额度调整属于关键属性变更，影响财务风险与订单释放，应纳入审批，并生成新版本 V2，旧版本 V1 保留为历史。

如果同一请求还涉及“客户名称变更”，则名称属于合规关键属性，需要额外触发合规校验；如果涉及“客户编码变更”，则属于编码级变更，影响面更大，通常需要数据治理委员会审批。通过这种拆解，可以把模糊的业务请求稳定地映射到模型对象上，避免“同一类变更在不同人手里走不同流程”。

五、变更对象识别清单（示例）

下面给出一份可直接参考的识别清单，用于把变更请求快速归类。字段可根据企业实际模型增删，但判断逻辑保持一致。

这张表的价值不在于字段本身，而在于它把“审批”和“版本化”拆成了两个独立判断。有些变更需要审批但不一定产生新版本（例如临时冻结），有些变更需要版本化但审批可以简化（例如批量属性修正）。把两者分开，才能设计出既可控又不臃肿的治理机制。

六、常见识别误区

第一个误区是“只按字段名判断”。同一个字段在不同实体下影响不同，例如“状态”在客户实体上可能只是生命周期标记，在银行账户上却直接决定能否收款。第二个误区是“忽略关系变更”。很多数据问题不是属性错了，而是关系断了，例如客户与销售组织的归属关系失效，导致订单无法分配。第三个误区是“编码变更当普通属性处理”。编码一旦被下游系统引用，修改就会引发连锁映射问题，必须单独识别。第四个误区是“所有变更都走最高审批”。这会让治理流程失去弹性，最终被业务绕过。正确的做法是：先识别变更对象，再匹配审批层级，最后决定版本策略。

把主数据模型的三层结构、编码体系和变更识别方法连起来看，本节的核心结论可以概括为一句话：审批与版本管理的最小单位不是“一条记录”，而是“一个被识别出来的变更对象”。只有先准确识别对象，后续的流程、版本号、生效时间和回滚机制才有稳定的作用点。