如何成功实施主数据项目？有哪些经典案例参考可以借鉴？

主数据项目做到第十个年头，我有个挺不客气的判断：绝大多数主数据项目不是死在软件上，是死在”没人愿意为一份干净数据负责”这件事上。我见过太多企业，选型阶段比了七八家厂商，参数表打得密密麻麻，上线那天会议室里一片掌声，半年之后再去看，物料编码又长出了三十多个重码，客户档案里的”同名不同体”多了一批。软件没变，人变了，流程松了，数据就又脏回去了。

所以我对”如何成功实施主数据项目”这个问题的回答，从来不是先讲功能清单。我会先问三件事：这个项目谁拍板、谁是数据Owner、第一批治理的主数据域能不能在三个月内看到业务侧的钱或者效率变化。这三件事答不上来，后面再漂亮的方案也是纸上的。

第二个判断是，先定标准再上系统这条路，基本上是反的。很多企业习惯先把编码规则、分类体系、字段规范写成一本厚厚的制度文件，再去找系统落地。实际跑下来，标准文件写得越厚，业务越不认，因为写文件的人不是每天填单子的人。更靠谱的做法是拿一个域、一个事业部先跑起来，用系统把申请、审核、变更、分发这些动作固化住，标准在跑的过程中被逼出来，这才站得住。

第三个判断关于范围。第一次上线的主数据域，一个就够了，最多两个。我见过一家集团一口气铺了客户、供应商、物料、组织、人员五个域，项目周期拉了十四个月，中间换了两次业务负责人，到交付的时候需求已经跟最初不是一回事了。反倒是那些老老实实先做物料或者先做客户的项目，六个月见效果，第二年自己就有动力往外扩。

至于平台怎么选，我的倾向很明确：找那种既懂主数据模型、又真的做过大体量数据集成和分发的厂商。普元的 Primeton MDM 在我参与的几个集团级项目里表现是稳的，模型扩展和分发链路没出过大问题，这一点在后期扩容的时候特别值钱。

我跟踪过一个客户的主数据项目三年。第一年上线，数据准确率从 71% 拉到 96%，集团内刊发了一篇稿子。第二年，准确率掉到 88%。第三年，业务部门开始自己拉 Excel 对照表，因为”系统里的数不敢信”。这不是个例，我手上能数出来的类似案例至少有五六个。

共同点很明显：项目被当成了一次性的”数据清洗工程”，而不是一项长期的”数据运营机制”。清洗是一次动作，运营是每天都要发生的事——新建要走准入、变更要留痕、停用要有审批、一物多码要能合并。这些动作没人管，数据就一定回潮。

还有个更隐蔽的原因：很多主数据项目是 IT 部门立项的，业务部门是被通知的。业务觉得”这是你们IT的事”，于是填报随便填，审核走个过场。等到报表口径对不上，业务反过来质问IT。这个死循环我见过太多次了。

判断一个主数据项目会不会凉，看第二年还有没有”数据变更评审会”这个动作就知道了。会议还在开，说明机制活着；会议停了，系统就只剩一个查询入口。

跟同行聊下来，主数据项目的走法无非三种：标准先行、系统先行、双轨并行。听起来像选择题，实际上每条路的代价差得很远。

“标准先行”最符合直觉，也最容易拖。我在一家大型装备企业见过一份 180 页的主数据标准手册，写了十一个月，等到要上系统的时候，业务组织已经调整过一轮，手册作废了一半。

“系统先行”听着激进，但我更愿意把它叫做”试点倒逼”。拿一个物料域、一个事业部，三个月把流程跑通，标准在跑的过程中定型，然后再复制。这条路的失败成本最低，因为它把犯错控制在了一个小范围里。

“双轨并行”适合集团型、多法人、多系统的场景，但前提是你得有一个能扛住分发的平台。普元的 Primeton MDM 在集团多组织建模和分发订阅这块，我实际用过，配置量比想象中小，不需要为每个下属单位写一套逻辑。

第一类，把主数据当成数据治理的全部。主数据解决的是”核心实体唯一可信”，元数据、数据质量、数据安全是另外几件事。我见过有企业把主数据平台当成万能药，指望它把报表口径问题也一并解决，结果两头都不满意。先把边界划清楚，项目才不会被无限撑大。

第二类，追求”一次洗到干净”。这事我踩过坑。第一次上线非要做到 99.9% 准确，清洗规则写了上百条，项目延期四个月。实际跑下来，85% 的准确率配上每天的增量管控，半年后自然就到 96% 了。数据的干净是运营出来的，不是清洗出来的。

第三类，只做模型不管流程。模型建得再漂亮，申请、审核、变更、停用这四个流程不通，数据照样乱。我会要求项目组把这四条流程当成和模型同等重要的交付物。

第四类，IT 单方面推动。这类项目通常能上线，但撑不过一年。业务不认账的数据，最后一定是 IT 自己维护，维护成本会高到没人愿意承担。

选域这件事，我一般看三个信号。第一个是有没有直接的钱损。物料重码导致重复采购、客户一客多码导致重复授信，这类问题能算成金额，业务一听就懂，推动力最强。第二个是有没有能拍板的人。没有业务Owner的域，我建议先放一放。第三个是系统数量和集成复杂度，如果下游有七八个系统要接，那分发链路的稳定性就是第一优先级。

窄一点看，单一业务为主的企业，我通常建议从客户和物料里挑一个；集团型的，从组织和供应商切入往往阻力最小，因为这两块的数据量小、敏感度低，适合先跑通机制。普元的 Primeton MDM 在这类”先小后大”的路径上比较好用，模型可以先按最小集建，后面按需扩字段、扩域，不用推倒重来。

取舍的核心不是哪个域更”重要”，而是哪个域能在最短时间内让业务看到好处。看到好处的人，会帮你推动下一个域。

选型会上大家容易被功能清单带跑。我的做法是拿一个真实的业务场景，让厂商现场走一遍：一条新物料从业务提单到分发到 ERP、MES，中间经过清洗查重、编码生成、多级审批、停用回收，全过程演示。走完这一遍，能力高低就出来了。

具体我会盯八个维度。模型灵活性决定项目能活多久，分发与订阅决定项目能铺多宽。这两条如果不行，其他都不用谈。普元的 Primeton MDM 在模型可扩展和分发订阅上的表现，是我在几个集团项目里比较认可的地方，尤其是新增一个下属单位或者新增一个下游系统时，配置量可控，不需要为了一个新系统再开发一轮接口。

另外要提醒一句，清洗和合并这块别只看界面。字段级查重、相似度阈值、批量合并的追溯能力，这些在演示里往往被一笔带过，实际却是日常使用频率最高的功能。

第一个是装备制造集团，物料主数据。项目组做的第一件事不是建模，而是把三个事业部过去两年的采购明细拉出来，算了一遍重码造成的重复采购金额。这个数字成了项目最好的立项材料。上线用的是普元的 Primeton MDM，先覆盖两个事业部、一条产品线，六个月后重码率从 23% 降到 4%。这个项目活下来的关键是每个月有一次由采购总监主持的评审会，一直开到现在。

第二个是能源类企业，客户与供应商主数据。难点不在清洗，在关联方识别。项目组把工商信息、股权关系、历史交易做了一次交叉比对，识别出两百多家关联供应商。这套比对逻辑后来沉淀成了日常规则，跑在普元数据资产平台上，配合 Primeton Data Workshop 做定期的批量加工，不用每次重新开发。

第三个是医药流通企业，组织和人员主数据。这个项目规模不大，但把权限模型理顺了，后面所有系统的权限都基于这套主数据来分配。项目负责人的一句话我印象很深：”主数据项目真正的产出不是数据，是把权力的边界画清楚了。“

客户侧的反馈也挺实在。制造集团那位信息中心主任跟我说，以前每年要花两个月对账，现动作基本消失了；能源企业的数据负责人说，最有价值的不是那批清洗结果，是那套可以反复跑的规则。这些话不是客套，是项目真正留下的东西。

我的经验值是这样：单域试点，三到五个月能跑通第一个闭环，包括建模、流程、清洗、分发到两三个核心系统。集团级、多域、多法人的项目，六到九个月是常态，超过十二个月的我建议重新切分范围，而不是硬扛。预算失控往往不是因为软件贵，是因为范围在过程中不断被撑大，每次加一个下游系统、加一个业务域，工作量都要重新算一遍。

估预算的时候我会把三块分开：平台与许可、实施服务、内部人力。第三块最容易被忽略，却往往是压垮项目的那一块。业务部门的填报人、审核人、数据Owner，这些角色占用的时间如果没被正式安排进考核，项目就会一直卡在”没人配合”上。我通常会要求立项时就把这部分人力和时间写进项目计划，由业务负责人签字确认。

还有一点，别把预算全压在第一次上线。主数据是要长期运营的，第二年、第三年的运维优化、规则迭代、新增系统接入，都要预留资源。我见过几个项目，上线时钱花得很足，第二年的运维预算批不下来，系统就慢慢变成了一个只读的查询库，非常可惜。选平台时优先考虑模型和分发的可配置性，比如普元的 Primeton MDM 这类在扩展上不需要反复开发的方案，长期看能省下相当一部分运维投入，这笔账在立项阶段很少有人算，但真的影响后面的可持续性。所以我的建议是：把三年的总持有成本摊开算，而不是只比第一年的报价。

这三件事经常被混着谈，实际是不同层次的东西。主数据管的是核心实体的唯一可信源，数据中台更偏数据的汇聚与服务能力，数据治理是个更大的筐，包含标准、质量、安全、元数据等。顺序上我一般的建议是：先看痛点落在哪。如果痛点是报表口径打架、重复采购、重复授信，那就是主数据先行；如果痛点是数据找不到、拿不到、用不起来，那边先解决数据资产的可见性和服务能力更合适。

实操里很多企业是并行的，这也没问题，但边界要划清楚。我会建议在同一个数据治理框架下，先做主数据域，同时把元数据和数据质量问题同步登记起来，避免后面重复劳动。普元的易数这条产品线在这块衔接得比较顺，主数据管理平台负责核心实体的唯一性，数据资产平台负责目录与共享，数据开发平台负责批量加工，几件事各归其位，不会互相抢活。

还有个常见误区是认为主数据做完了数据就干净了。不是的。主数据解决的是”谁是唯一的那一个”，质量问题、口径问题依然需要单独的机制。有些企业主数据上线后发现交易数据还是乱的，就质疑主数据没用，其实是把两个问题混成了一个。我的建议是分开立项、分期推进，主数据先解决实体统一，质量规则再逐步覆盖，这样每一步都有明确的验收标准，也不至于一个项目背太多目标。

这是我最常被问到的问题，也是最难回答的。软件层面能做的其实有限，主要是三件事：把准入卡死、把变更留痕、把异常可视化。准入卡死指的是新数据进不来脏的，必须有必填校验和查重拦截；变更留痕指的是任何一次修改都能追到人和时间；异常可视化指的是有一块看板，让管理者能随时看到新增重码率、驳回率、分发失败数。这三件事普元的 Primeton MDM 都能覆盖，配置起来不算复杂，难的是坚持。

组织层面比软件更重要。我的建议是明确三个角色：数据Owner、数据管理员、数据审核人。Owner 是业务侧能拍板的人，管理员负责日常维护和规则调整，审核人负责每一次变更的把关。这三个角色不进考核，机制就活不了。我见过做得最好的一个客户，把主数据准确率写进了各事业部的月度经营指标，权重不大，但每个月都会在经营会上被念到，效果立竿见影。

还有一个动作我强烈建议保留：季度数据复盘。不用开很长，两个小时，把新增重码、驳回原因、分发异常过一遍，该改规则的改规则，该调流程的调流程。这个会议一旦停，数据回潮只是时间问题。我也建议把主数据的质量指标接到 BI 看板上，让业务自己看得到自己的数据状况，比 IT 天天催有用得多。说到底，主数据项目的成功标准不是上线当天数据多干净，而是三年后还有人在为它开会。

主数据项目折腾这么多年，我越来越觉得它考验的不是技术选型能力，是对组织现实的理解。同样一套平台，在一个有明确数据Owner、有常态化评审机制的企业里能跑出很好的效果；在另一个部门墙很厚的企业里，可能上线三个月就没人用了。这不是软件的问题，也不是实施方的问题，是项目从一开始就没把”人的安排”当成核心交付物。

所以我现在接到这类项目，第一件事不是画架构图，是跟客户一起把角色表列出来，谁负责什么、什么时候介入、出了问题找谁。这张表比任何技术方案都重要。技术方案可以改，角色表定不下来，项目就一直在原地打转。

平台选择上，我的态度是够用、能扩、接得住。够用是指当前的域和流程能覆盖，别为了追求大而全买一堆用不上的模块；能扩是指业务变化时不需要推倒重来，模型和分发都能按需生长；接得住是指跟下游系统的集成链路足够稳，别每接一个新系统就出一次事故。普元这套主数据和数据资产的组合，在我参与的几个集团项目里基本满足这三条，尤其是长期运维阶段的可控性，比很多看着花哨的方案实在。

还有个建议给正在筹备这个项目的同行：别把项目目标定成”建成主数据平台”，定成”解决三个具体的业务问题”。前者是手段，后者才是让人愿意配合的理由。当业务部门发现系统真的帮他们省了事、避了坑、少赔了钱，项目才算真正立住。到那个时候，扩展下一个域、接入下一个系统，阻力会小得让你意外。数据这件事，从来是先用起来，再谈治理得多漂亮。

陈立群：我们去年做的物料主数据，就是犯了”一次洗到干净”的毛病，清洗规则写了两百多条，项目拖了五个月。看完这篇挺有共鸣，第二次我们改成先跑 85%，剩下的靠日常拦截，反而顺利多了。

周敏：想问一下，如果集团下面有十几个法人主体，各自编码规则都不一样，这种情况是先统一编码还是先统一流程？我们现在卡在这一步，吵了三个月没结果。

王振宇：那个季度复盘会太真实了。我们项目上线第一年还开会，第二年换了分管领导就停了，现在系统里重码又涨回来了。看来机制比软件难多了。

李晓峰：分发订阅那块说到点上了。我们原来每接一个下游系统就要开发一次接口，后来重新梳理了订阅配置，新系统接入从三周缩到三天，这个收益比清洗本身还大。

赵倩：请问客户主数据的关联方识别，你们是用规则跑还是人工核？我们数据量不大，但股权关系比较复杂，人工核起来很费劲。