3. 变更类型与风险分级

主数据变更审批的第一道关口，不是“谁来批”，而是“这次变更到底属于哪一类、风险有多高”。如果所有变更都走同一条审批链，要么把低风险变更拖成瓶颈，要么让高风险变更悄悄溜过。因此，变更类型识别与风险分级是审批策略的起点：先判断变更动作的性质，再用影响范围、合规要求、业务关键度三个维度量化风险，最后映射到审批层级与验证强度。

一、五类变更动作的语义与边界

主数据变更按动作语义可分为五类，它们对数据模型和下游系统的冲击方式完全不同。

• 新增（Create）：向主数据域引入一条此前不存在的实体记录，例如新增一个客户、一个物料、一个供应商。新增的风险主要来自“重复”与“不完整”——是否与已有记录重复、必填属性是否齐全、编码规则是否符合规范。
• 修改（Update）：对已有实体的属性值进行变更，例如客户地址、物料计量单位、供应商银行账号。修改的风险取决于被改字段的敏感度：描述性字段影响小，而银行账号、税号、信用等级等字段一旦改错，会直接引发资金或合规问题。
• 失效（Deactivate）：将实体标记为不可用，但保留历史数据。失效不是删除，它影响的是“新业务能否继续引用该实体”。若失效时机不当，可能导致在途订单、未结发票无法关联。
• 合并（Merge）：将两条或多条重复实体归并为一条主记录，保留一条黄金记录，其余记录被标记为已合并并指向黄金记录。合并的风险在于引用迁移：所有下游系统中指向被合并记录的引用都必须重定向，否则会出现“悬空引用”。
• 拆分（Split）：将一条实体拆分为两条或多条独立实体，通常发生在原记录混合了多个业务对象时，例如一个客户账户下混有多个法人主体。拆分的风险在于历史交易归属的重新划分，必须明确哪些历史数据归到哪个新实体。

这五类动作并非互斥。一次治理操作可能同时包含合并与修改，例如合并两条客户记录后，还要修正黄金记录的统一社会信用代码。审批系统需要支持“主类型 + 附加动作”的组合表达。

二、三维风险评分模型

风险分级不能凭感觉，需要可计算、可复核的评分模型。建议从三个维度分别打分，再合成风险总分。

维度一：影响范围（Impact Scope）。衡量变更会波及多少下游系统、多少业务单据、多少组织节点。可按引用该实体的系统数量、近90天交易笔数、涉及组织数来估算。例如，仅影响一个本地报表的物料描述修改，影响范围为低；而被ERP、MES、WMS、财务共享四个系统引用的供应商银行账号修改，影响范围为高。

维度二：合规要求（Compliance Requirement）。衡量变更是否触及法规、审计、内控或行业监管要求。涉及个人信息、财务账户、税务标识、药品批号、食品追溯等字段的变更，合规要求高；纯内部管理属性（如内部备注、分类标签）合规要求低。

维度三：业务关键度（Business Criticality）。衡量该实体或字段对核心业务流程的支撑程度。客户主数据中的信用额度、物料主数据中的安全库存、供应商主数据中的付款条件，都属于高业务关键度字段；而物料图片、客户行业分类等属于低关键度。

每个维度可按1～3分打分（1=低，2=中，3=高），风险总分 = 影响范围 × 合规要求 × 业务关键度，取值范围1～27。根据总分划分四级风险：

三、从评分到审批策略的映射

评分模型的价值在于把“拍脑袋定审批人”变成“按规则自动路由”。下面给出一个可落地的判断逻辑示例。

输入：变更类型 type、影响系统数 sysCount、近90天交易笔数 txnCount、
      合规字段标记 isCompliance、业务关键字段标记 isCritical

影响范围得分：
  if sysCount >= 3 or txnCount >= 1000: impact = 3
  elif sysCount == 2 or txnCount >= 100: impact = 2
  else: impact = 1

合规要求得分：
  if isCompliance == true: compliance = 3
  elif type in [合并, 拆分]: compliance = 2
  else: compliance = 1

业务关键度得分：
  if isCritical == true: criticality = 3
  elif type in [失效, 合并, 拆分]: criticality = 2
  else: criticality = 1

风险总分 = impact × compliance × criticality
若总分 >= 21：路由至数据治理委员会
若总分 >= 13：路由至数据经理 + 业务负责人
若总分 >= 5：路由至数据经理
否则：路由至数据专员

这个逻辑可以直接配置在审批引擎的路由规则中。需要注意的是，合并与拆分即使不涉及合规字段，也至少获得合规得分2，因为这两类操作天然涉及数据血缘和审计追溯。

四、变更类型与风险维度的关系图

下图将五类变更动作与三个风险维度、四级风险等级、审批路由放在同一视图中，便于快速判断一次变更应该走哪条路径。

五、分级后的差异化验证要求

风险等级不仅决定谁审批，还决定验证做到什么程度。低风险变更只需在审批界面完成格式校验和唯一性检查即可提交；中风险变更需要先运行引用影响分析，确认没有下游系统会因该变更而中断；高风险变更除了引用影响分析，还应在测试环境中对关键下游系统做回归验证，例如供应商银行账号修改后，验证付款批处理能否正常读取新账号；极高风险变更必须准备回滚预案，并采用灰度发布——先在一个组织节点或一个业务单元生效，观察一个结算周期后再全量推广。

变更类型识别与风险分级不是一次性的分类动作，而是贯穿审批、验证、发布、回滚全过程的治理基线。只有把类型判断和评分规则固化到系统中，才能让每一次主数据变更都走在可预期、可审计、可回退的轨道上。