Surinch
页面加载中Surinch
页面加载中客户、商品、组织等核心实体散落在 ERP/CRM/MES 多套系统里，口径不一、下游打架。本文讲透 MDM 三种模式、落地六步与四大常见坑。
数字为行业示例性估算，旨在说明问题的普遍程度，非特定企业实测。
主数据（Master Data）是企业核心业务实体的数据——它们相对稳定、被多个业务流程共享、是各系统运转的"骨架"。常见的五大主数据域：
这些数据和交易数据（订单、流水）不同：交易数据每天都在涨，主数据相对稳定且被反复引用。一旦主数据乱了，所有引用它的交易数据、分析报表都会跟着错。
CRM、ERP、客服系统各存一份客户信息，同一客户在不同系统里名称、联系方式、分级都不一样，营销和风控拿到的"客户"不是同一个。
采购用一套物料编码，生产用另一套，财务又是第三套。一个物料三套编码，库存对账永远是扯皮大会。
HR 系统的组织树和财务的成本中心对不上，部门绩效算不清归属，跨部门协作反复确认"这个部门到底归谁"。
BI 报表里"活跃客户数"和"有效客户数"差 30%，因为两个分析团队用了不同系统的客户清单作为分母。
不是所有企业都要上最重的方案。按改造力度和控制力，MDM 分三种模式：
不移动数据，只建一个"主数据索引"，把各系统的同一条记录关联起来。各系统仍各自维护，MDM 只提供统一标识与查询入口。
适用：系统自治要求高、主数据变动频繁、只想先解决"找到并关联"的场景。
把多系统的主数据抽取汇聚到一个中央"黄金记录"库，用于分析和报表；但原系统仍是权威源，变更不回写。
适用：以分析、报表、数据仓库为主要目标，暂不要求事务级一致的场景。
MDM 成为唯一权威源，所有主数据变更都先在 MDM 落地，再分发给各业务系统。事务级一致，但改造和治理成本最高。
适用：强合规行业（金融/医疗）、对主数据准确性要求极高、愿意做深度治理的企业。
别贪多。先选一个痛感最强、价值最高的域（通常是客户或物料），跑通再扩展。范围蔓延是 MDM 失败的头号原因。
确定每条主数据该包含哪些字段、字段标准、唯一键、取值优先级（哪个系统是哪个字段的权威源）。
对存量数据做去重、合并、标准化。识别"同一条实体"是难点——模糊匹配、规则 + 人工确认结合。
主数据不是建一次就完。新增、变更、停用都要有明确流程：谁申请、谁审批、谁执行、多久同步到下游。
主数据是跨部门资产，必须有业务牵头的数据 Owner 和治理委员会裁决标准争议，纯 IT 项目必然失败。
把黄金记录分发给消费方系统/数仓，并监控数据质量指标（完整率、一致率、及时率），形成闭环。
MDM 的终极目标是建立单一事实源（Single Source of Truth）——全企业对"一个客户是谁""一件商品是什么"有且只有一个权威答案。
主数据的本质争议是业务标准（"什么叫有效客户"），不是技术。没有业务 Owner 牵头，IT 部门推不动，最后沦为一张数据表。
一上来就想管客户+商品+组织+供应商+员工五个域，必然哪个都做不深。单域试点 → 跑通 → 复制，才是正路。
建了黄金记录库但没有变更维护流程，三个月后数据又脏了。维护流程和数据质量监控比初始清洗更重要。
源头数据本身就脏（重复、缺失、格式乱），不在清洗匹配上花够功夫，MDM 就是个"脏数据的权威副本"。
传统 MDM 套件最痛的不是"建不起来"，而是"维护不动"——识别实体、匹配去重、变更分发这些活儿高度依赖资深人力。InchStack 用 Agent 能力补强这些最耗人的环节：
扫描各系统 schema 与数据样本，自动识别哪些是核心主数据实体、它们之间的关联关系，减少人工梳理。
基于规则 + 语义相似度做模糊匹配，识别"同一实体的不同记录"，给出合并建议与置信度，人工只复核边界 case。
主数据字段从哪个系统来、流经哪些加工、被哪些下游报表使用，全链路血缘可视，定位口径问题不再靠猜。
主数据变更走在线审批流，通过后自动分发到订阅的消费方系统，变更可追溯、可回滚。
从一个域试点起步，用 Agent 能力把识别、匹配、维护的人工成本降下来。InchStack 支持私有化部署，主数据不出域。