1. 主数据变更治理全景
主数据是企业范围内被多个业务系统共享、用于描述核心业务实体的基准数据，例如客户、物料、供应商、组织、科目、员工等。它不像交易数据那样高频变化，但一旦发生变化，影响面往往横跨采购、生产、销售、财务、供应链等多个系统。因此，主数据变更治理的核心命题不是“能不能改”，而是“谁在什么条件下、以什么证据、通过什么路径改，改完之后如何被追溯、被回滚、被验证”。本章从典型变更场景出发，梳理审批与版本治理的核心挑战，并界定工程化治理的目标与边界，为后续章节建立整体坐标系。
一、主数据变更的典型场景
主数据变更并非单一动作，而是由不同触发源、不同影响范围、不同紧急程度构成的一组场景。理解场景分类，是设计审批策略和版本策略的前提。常见场景可以归纳为以下几类：
- 属性修正型变更：例如物料描述拼写错误、客户联系人电话更新、供应商银行账号变更。这类变更通常影响范围小，但银行账号、税号等字段涉及资金安全，必须走强校验与双人复核。
- 结构扩展型变更：例如新增物料分类层级、为客户主数据增加“ESG评级”字段、组织架构新增法人主体。这类变更会改变数据模型或编码规则，需要评估下游系统兼容性。
- 合并与拆分型变更：例如两个客户因集团重组合并为一个、一个供应商拆分为多个结算主体。这类变更涉及历史交易归属、未清订单、信用额度迁移，是版本治理中最复杂的场景。
- 状态生命周期变更：例如物料从“启用”转为“冻结”、供应商从“合格”转为“黑名单”、客户从“活跃”转为“归档”。状态变更往往不修改属性值，但会改变业务可用性，必须与业务流程联动。
- 批量治理型变更：例如数据质量专项中批量补全缺失的税号、统一国家代码格式、清理重复客户。这类变更数量大、来源集中，需要批次化审批与灰度发布能力。
这些场景在审批粒度、版本保留策略、生效时间要求上差异显著。例如属性修正可以走轻量审批、即时生效；而合并拆分往往需要冻结窗口、制定迁移方案、保留旧版本可查询。工程化治理的第一步，就是建立场景分类矩阵，把“变更类型—影响等级—审批路径—版本策略”对应起来，而不是用一套流程覆盖所有变更。
二、审批与版本治理的核心挑战
从工程视角看，主数据变更治理的困难并不在于“写一个审批流”，而在于五个相互纠缠的问题。
第一，审批权责不清。主数据通常由多个部门共同维护：物料由研发和采购共同定义，客户由销售和财务共同维护，供应商由采购和质检共同评估。如果审批矩阵没有明确到“字段级”或“变更类型级”，就会出现两种极端：要么所有变更都堆到数据管理部，形成瓶颈；要么各部门自行其是，数据质量失控。工程化做法是建立“数据域—字段组—变更类型—审批角色”的四级映射，并允许按金额、影响系统数、是否涉及资金字段等条件动态升级审批层级。
第二，版本追溯困难。很多企业的变更记录只保留“最后修改人和修改时间”，无法回答“这个客户在2024年3月时的信用额度是多少”“这个物料在变更前属于哪个分类”。版本治理要求每次变更生成一个不可变的版本快照，记录变更前后值、变更原因、审批链、生效时间、失效时间。版本不是简单备份，而是带有语义的时间轴：同一主数据对象在不同时间点有不同有效版本，查询时必须能按业务时间点还原。
第三，下游影响失控。主数据变更后，需要同步到ERP、CRM、SRM、WMS、财务共享等多个系统。如果同步是异步的、无确认的，就会出现“主数据已改、下游未改”的不一致窗口。更严重的是合并拆分场景：客户A合并到客户B后，历史订单、应收账款、信用额度需要迁移，未清业务需要冻结或重挂。工程化治理必须把“变更影响评估”作为审批的前置步骤，明确受影响系统、受影响数据量、迁移方案和回滚方案。
第四，紧急变更与合规冲突。业务现场经常出现“产线等着物料放行”“客户等着开户”的紧急情况。如果坚持先批后改，业务会绕过系统直接改数据库；如果允许先改后补，又可能留下合规缺口。合理的工程做法是设置“紧急变更通道”：允许特定角色在限定字段范围内先执行、后补审批，但系统自动记录操作人、时间、前后值，并在规定时限内未补审批时自动冻结该记录或触发告警。
第五，批量变更风险放大。一次批量更新可能影响数万条记录。如果脚本条件写错，可能把“国家=CN”误写成“国家=CN1”，导致所有中国客户地址异常。批量变更必须支持试运行、影响行数预览、分批提交、逐批确认和快速回滚。版本治理在这里的作用是：每一批生成一个批次版本，可以按批次整体回滚，而不是逐条恢复。
三、工程化治理的目标与边界
工程化治理的目标可以概括为三个“可”：可审批、可追溯、可回滚。可审批意味着任何变更都有明确的发起、校验、审批、执行、确认路径，且路径可按场景配置；可追溯意味着任何时间点的数据状态都能还原，任何一次变更都能回答“谁、何时、为什么、改了什么、经过谁批准”；可回滚意味着错误变更可以在可控时间内恢复到已知正确版本，且回滚本身也被记录为一个新版本。
但治理必须有边界。第一条边界是不替代业务决策：治理系统负责流程、权限、版本和审计，不负责判断“这个客户信用额度应该定多少”。业务规则仍由业务部门定义，治理系统只保证规则被正确执行和记录。第二条边界是不追求零变更：主数据必须随业务变化而更新，治理的目标是让变更可控、可见、可逆，而不是禁止变更。第三条边界是不追求一次性完美：治理能力应分阶段建设，先覆盖高风险字段和高频场景，再逐步扩展。