2. 供应商主数据治理框架：MDM核心概念、数据模型、主数据生命周期管理
供应商主数据治理不是一次性的数据清洗项目，而是一套持续运行的体系。本节从三个维度拆解框架：MDM核心概念（定义治理边界）、数据模型（定义数据结构）、生命周期管理（定义数据流转规则）。三者构成“治理-建模-运营”的闭环。
2.1 MDM核心概念：从“数据孤岛”到“单一真相”
主数据管理（MDM）在供应商域的核心目标是消除多系统间的供应商信息不一致。以下表格对比了MDM实施前后的典型差异：
| 对比维度 | 无MDM（数据孤岛） | 有MDM（单一真相） |
|---|---|---|
| 供应商编码 | ERP、SRM、OA各自编码，一供多码 | 全局唯一ID，跨系统映射 |
| 名称/地址 | 各系统手工录入，拼写不一致 | 标准化清洗，统一格式 |
| 风险标签 | 地缘风险、制裁名单分散在Excel | 集中维护，实时同步 |
| 交付评级 | 采购员各自记录，无统一口径 | 按规则自动计算，全局可见 |
关键原则：供应商MDM不是新建一个“超级系统”，而是在现有系统之上建立数据治理规则层，通过主数据Hub实现分发与回写。
2.2 供应商主数据模型：核心实体与属性
一个可落地的供应商主数据模型至少包含以下实体组。每个实体组对应一个数据域，由专门的属性集支撑。
- 基础信息域：供应商编码、法定名称、DUNS编号、注册地址、税号、企业类型。
- 联系信息域：法人代表、采购对接人、紧急联系人、联系电话、官方邮箱。
- 资质与合规域：营业执照有效期、ISO认证列表、行业许可证、制裁名单状态、地缘风险等级。
- 绩效与交付域：OTIF（按时按量交付率）、质量PPM、交货周期、配合度评分、最近一次审核日期。
- 财务与交易域：付款条款、信用额度、银行账户、发票偏好、账期。
以下SVG展示了供应商主数据模型的核心实体关系，突出“基础信息”作为中心节点，连接合规、绩效、财务三个关键域。
建模建议：每个域至少预留一个“扩展属性”字段（JSON或KV结构），用于应对地缘风险、贸易合规等动态变化的属性，避免频繁修改物理模型。
2.3 主数据生命周期管理：从创建到退役
供应商主数据不是静态的，它经历完整的生命周期。每个阶段都有对应的治理动作和审批节点。以下表格列出了六个关键阶段及其核心活动：
| 阶段 | 触发条件 | 核心活动 | 治理控制点 |
|---|---|---|---|
| 1. 创建 | 新供应商准入申请 | 资质审核、基本信息录入、编码生成 | 必填字段校验、重复检测 |
| 2. 激活 | 通过准入审批 | 分配采购组织、设置付款条款 | 合规状态确认、风险初评 |
| 3. 维护 | 信息变更（地址、联系人、资质） | 变更申请、审批、同步至下游系统 | 变更审计日志、版本控制 |
| 4. 监控 | 定期或事件驱动 | 地缘风险扫描、交付绩效计算、资质到期预警 | 自动评分、异常标记 |
| 5. 冻结 | 暂停合作、合规风险触发 | 禁止新订单、保留历史数据 | 审批链升级、通知相关方 |
| 6. 退役 | 终止合作、供应商注销 | 数据归档、关联合同关闭、编码回收 | 归档完整性检查、不可逆确认 |
以下SVG将上述六个阶段串联为闭环流程，突出“监控”阶段与“地缘风险+交付表现”的联合调优接口。
常见陷阱：很多企业只关注“创建”和“维护”阶段，忽略了“监控”和“冻结”环节。当地缘风险事件（如制裁升级）发生时，没有自动冻结机制，导致违规交易持续发生。生命周期管理必须包含风险驱动的状态转换规则。
2.4 数据治理组织与角色
框架落地需要明确的责任矩阵。以下是最小可行角色集：
- 数据所有者（Data Owner）：采购总监，负责供应商主数据的业务准确性和合规性。
- 数据管家（Data Steward）：专职数据治理人员，执行日常数据质量监控、变更审批、冲突解决。
- 数据生产者（Data Producer）：采购员/供应商管理员，负责数据录入和变更申请。
- 数据消费者（Data Consumer）：财务、计划、仓储等下游系统用户，依赖主数据进行业务操作。
落地建议：在初期阶段，数据管家角色可以由资深采购员兼任，但必须赋予其数据修改的否决权，避免业务压力绕过治理规则。