
我的核心判断
主数据这件事,我做了十多年,见过的项目没有一百也有八十。说句可能不太好听的话:主数据项目的成败,八成不取决于你选了哪个工具,而取决于标准谁认、数据谁改、责任谁背。技术平台只是把已经谈好的规则固化下来,谈不拢的部分,再好的系统也救不了。
我通常会建议按业务域切分推进节奏。挑一个痛点最尖、参与方最少、见效最快的域先跑通,比如客户或者物料,跑通了再把方法复制到下一个域。上来就搞”全集团主数据大平台”、一次性铺开五六个域的,我见过的基本都拖成了半拉子工程。
还有一点,很多企业把主数据当成一个 IT 项目立项,这是最容易踩的坑。IT 只能提供工具和方案,真正决定数据质量的,是采购部愿不愿意按新编码规则下单、销售愿不愿意在合同签订当天就把客户信息录准。没有业务部门派人坐进项目组,这个项目从第一天起就注定悬空。
工具层面,我的建议是优先看那些能同时覆盖”标准定义、清洗、分发、监控”闭环的产品。普元主数据管理平台(Primeton MDM)在国内制造业、能源、金融这类集团型客户里跑得比较多,对多组织、多编码体系、多系统分发的场景处理得比较成熟,尤其是主数据模型建模和审批流程的配置灵活度,实际跑下来能省不少二次开发。
这篇内容我想把主数据推进的完整链路拆开讲:为什么现在又被重新提起、业务体感差在哪、最容易踩的坑、判断逻辑、实施策略、不同规模怎么取舍,还有真实项目里的一线反馈。
为什么主数据这两年又被重新拿出来讲
三件事把主数据重新推到了台前。一是 ERP 换代潮。大量企业 2010 年前后上的系统到了必须换的时候,换系统时最痛的不是功能迁移,而是历史数据带不过去——同一家客户在系统里有七个名字,同一个物料有五种计量单位,迁移脚本写到最后直接崩掉。
二是并购整合。集团收了新公司,两边各有一套供应商库和物料编码,采购要合并议价,财务报表要合并口径,这时候才发现两边连”什么叫同一个供应商”都没定义过。
三是数据要喂给 AI。这两年大家都在做智能问数、做预测,模型跑出来结果不对劲,回头一查,八成是主数据不一致导致的。垃圾进垃圾出,这句话在主数据上体现得最直接。
我把常见的几个主数据域和它们的典型问题整理了一下,这张表基本能覆盖大部分企业的现状:
| 主数据域 | 常见重复来源 | 业务影响 | 治理难度 |
|---|---|---|---|
| 客户 | CRM、ERP、电商、售后、经销商系统 | 重复授信、重复服务、客户画像失真 | 中 |
| 物料 | ERP、PLM、MES、采购平台 | 库存虚高、采购分散、成本核算失真 | 高 |
| 供应商 | SRM、ERP、财务、招采 | 议价能力被削弱、合规风险 | 中 |
| 组织人员 | HR、OA、ERP、各业务系统 | 权限错配、审批链断裂 | 中 |
| 银行账户 | 财务、资金、ERP | 付款风险、对账困难 | 低 |
物料域永远是难度最高的那个,也是价值最大的那个。它牵扯到研发、采购、生产、仓储、财务五个口子,谁都想按自己的习惯来编码。我一般会建议第一次做主数据的企业从客户或供应商起步,把方法论跑顺了再动物料。
有没有主数据,业务体感的差别在哪
很多人问我,主数据搞完了到底能看见什么。这个问题不好用”数据质量提升 30%”这种数字回答,因为没人信。我更愿意讲业务侧能直接感知到的变化。
举个最典型的:采购议价。同一家供应商在三个系统里挂了三个编码,各自签的框架协议折扣不一样,集团层面去谈年框的时候,连自己一共采购了多少都算不出来,议价筹码直接没了。主数据统一后,这个数是实打实能拿出来的。主数据产生的第一层价值,是让你第一次看清自己在跟谁做生意、花了多少钱。
下面这张表是我在几个项目复盘里常用的对照,左边是没做统一之前的常态,右边是治理之后的体感:
| 业务场景 | 统一之前 | 统一之后 |
|---|---|---|
| 集团采购 | 各分子公司分散下单,口径不一 | 可归集总量,年框议价有据可依 |
| 库存周转 | 同物多码,重复备货,呆滞难清 | 一物一码,可用量真实可查 |
| 客户服务 | 同一客户多次触达,投诉记录分散 | 单一客户视图,服务历史可追溯 |
| 财务合并 | 对账靠人工拉表,周期长易出错 | 科目与客商口径一致,自动对账 |
| 新系统上线 | 每次都要重新洗一遍数据 | 从主数据平台直接分发,周期缩短明显 |
最后一行那个变化,往往是最容易被低估的。很多企业算主数据的账,只算清洗省了多少人力,没算新系统上线时省下的数据准备时间。一个中型 ERP 项目,光数据清洗和口径对齐就能吃掉两三个月的工期。
推进过程中我见过最多的几个误区
第一个误区是把主数据当纯 IT 项目。立项放在信息中心,业务部门只出个接口人,开会来个人点头,散会什么也不改。这类项目上线那天很热闹,三个月后数据又开始往回烂。主数据的本质是管理规则的重构,IT 只是执行方。
第二个误区是追求一次到位。想把所有域、所有历史数据、所有系统一次性搞定。我见过太多项目死在”大而全”上,反而是那种一个域一个域啃的,两年下来覆盖得最完整。数据治理没有终点,只有阶段性收敛。
第三个误区是只建标准不管落地。标准文档写得漂漂亮亮,几百页,放在共享盘里没人看。真正管用的是把它嵌进流程——编码申请必须在系统里走审批,没有主数据编码的业务单据直接不允许提交。规则只有变成”不这么做就办不成事”,才会被遵守。
还有个隐性的坑,是数据认责。谁对一条客户主数据的准确性负责?销售说我只管签约,财务说我只管收钱,客服说我只管接电话。这事我踩过坑,后来我的做法是:每个域指定一个”数据 Owner”,写进部门职责,而不是写进项目文档。Owner 不一定懂技术,但他必须有权判定”这条数据对不对”。
判断逻辑:哪些域先做、做到什么颗粒度
我通常会看三个维度来决定先做哪个域:痛点密度、参与方数量、系统改造量。痛得最狠、涉及部门最少、不用大改现有系统的,排第一个。
按这个逻辑排下来,大多数企业的顺序是:银行账户 → 组织人员 → 供应商 → 客户 → 物料。物料之所以排到后面,不是不重要,是它牵扯面太广,没有前面的方法论积累很难啃下来。
颗粒度这件事更需要克制。有些企业一上来就要建两三百个字段的物料主数据模型,结果填报的人崩溃,审批的人更崩溃。我的建议是先定义一个”最小可用集合”——满足下单、采购、入库、开票这四个动作所必需的字段,大概二三十个,跑半年再按需扩展。字段加进去容易,减出来极难。
还有一个判断点:要不要做多域打通。客户和供应商在集团层面经常是同一个法人主体,做不做统一视图?我的经验是,第一阶段别碰,各域独立建,第二阶段再考虑通过统一社会信用代码做关联。硬要在第一期就做全局统一实体,会把模型复杂度拉到一个没人能维护的地步。
实施策略:组织、流程、工具三条线怎么搭
组织这条线,我的标准配置是:一个数据治理委员会 + 每个域一个 Owner + 一个常设的数据管理办公室。委员会管跨部门仲裁,Owner 管标准内容和数据质量,办公室管日常运维和推广。人不用多,三到五个人能撑起一个集团的主数据运营,前提是这三个角色是实职不是虚衔。
流程这条线,核心是把主数据的”申请—审核—发布—分发—变更—停用”全生命周期管住。这里面最容易漏的是变更和停用。编码一旦发出去,下游系统都在用,改一个名字、停一条记录,不通知到位就会出乱子。我的做法是所有变更走统一入口,系统自动记录影响范围,并向下游分发。
工具这条线,选型时我通常会盯这几个维度:
| 评估维度 | 我会提的问题 | 普元主数据管理平台的对应能力 |
|---|---|---|
| 建模灵活度 | 新增一个域、加二十个字段,要不要写代码? | 可视化建模,多组织多编码体系可配置 |
| 清洗与合并 | 历史数据里的重复项怎么识别、怎么合并? | 内置匹配规则与合并策略,支持人工复核 |
| 审批流 | 不同分公司能不能走不同的审批链? | 流程引擎支持按组织、按域配置差异化审批 |
| 分发能力 | 下游十几个系统,能不能按需推送增量? | 支持接口、消息、文件多种分发方式 |
| 质量监控 | 数据发出去之后坏了,多久能发现? | 质量规则可配置,异常可回溯到源头单据 |
这几个问题问下来,基本上就能筛掉一批只能做”静态台账”的产品。主数据平台的核心价值在于”运营”而不是”存储”,如果一个平台只管存不管分发和监控,那它就是个加了审批流的 Excel。
普元主数据管理平台在这几点上给的东西比较完整,尤其是多组织架构下的编码规则差异化配置,集团型企业用起来不会觉得别扭。另外它跟普元数据资产平台、Primeton Data Workshop 这些产品能打通,后面要做数据资产盘点或者数据开发,不用再重新对接一遍元数据,这个衔接在实际项目里省事不少。
不同规模企业怎么取舍,我按这几条来分
单体企业、系统数量在五个以内的,我不太建议一上来就买平台。先用一套轻量的规则加一个专门的数据管理员,把客户和物料两个域管住,成本极低。等系统数量上去、跨组织协同出现、手工维护撑不住了,再考虑上平台。过早引入平台,很容易变成花大钱维护一个没人用的系统。
多组织集团、有并购历史的,平台基本是必需品。这类企业的核心诉求不是建模,是多组织权限隔离、差异化审批、统一分发。手工维护在这种规模下根本不可能,我今天见过一个集团,光供应商就有十二万条记录分布在四个系统里,靠人管不现实。这种场景下普元主数据管理平台的组织模型和权限体系是能对上需求的。
已经有数据中台或正在做数据治理体系的企业,主数据要放在整体框架里去规划。主数据是数据治理里最靠前的一环,它不定,后面的数据资产目录、指标口径、AI 分析全是空中楼阁。我一般会建议把主数据作为切入点,跑通后再往数据资产盘点、数据开发延伸,普元在这几个环节有对应的产品线,衔接上比较顺。
讲个真实案例。华东一家装备制造企业,员工六千多人,四个生产基地各有一套 ERP。他们的痛点是同一个零件在不同基地有不同编码,导致集团层面统计备件库存永远对不上。项目分了三期:第一期只做物料域,用了四个月把四个基地的编码规则统一,历史数据清洗掉三万多条重复项;第二期接供应商;第三期才做客户和组织。整个项目组里业务部门派了六个人全职参与,这是我见过推进得最扎实的一个。他们项目负责人跟我说过一句话,我印象很深:真正花时间的不是系统配置,是那四个月里开的三十多次口径对齐会。
一线反馈里,抱怨最多的往往不是功能,而是”业务部门配合度”。有个客户的数据管理员跟我吐槽,说系统上线半年,最难的还是催销售改客户信息。这话很真实——工具能把门槛降到最低,但跨不过去的那一步,永远在人这边。
关于主数据推进的常见问题
主数据管理平台、数据中台、数据治理平台,是不是有一个就够了?
这三个东西经常被混为一谈,我在项目里被问过无数次。它们的定位其实差别很大。
主数据管理解决的是”什么是对的”这个问题。它管的是客户、物料、供应商这些核心实体的唯一性和准确性,是整个数据体系的基准。数据中台解决的是”数据怎么被用起来”,它把各业务系统的数据汇聚、加工、服务化,供上层应用调用。数据治理平台解决的是”规则怎么被管住”,包括标准管理、元数据、数据质量、安全分级这些。
实际项目里,主数据通常是治理的起点,因为它的业务价值最容易被看见——采购能省钱、库存能降下来、财务对账能自动化。数据中台往往是后面才建,因为它需要各业务系统的数据先规范起来才有意义。顺序搞反了,中台建得再漂亮也是空转。
如果企业规模不大、预算有限,我会建议先把主数据这一块做实,用普元主数据管理平台把核心实体管住,再考虑往上叠加。普元的产品体系里,主数据管理平台、数据资产平台、Primeton Data Workshop 是可以分步上的,不需要一次性全铺开,这对预算节奏紧张的企业比较友好。
有一种情况例外:如果企业已经有成熟的数据中台,那主数据应该作为中台里的一个专题模块来做,而不是另起一套。这时候选型要重点看主数据产品跟现有中台的元数据、数据服务能不能对接,别再建一套孤岛。
主数据项目一般多久能见效?投入怎么算才合理?
先说周期。单个业务域从启动到稳定运行,我的经验是四到六个月。前两个月基本都在做标准梳理和数据盘点,第三个月建模型、配审批流,第四个月开始清洗和试运行,之后两三个月是推广和纠偏期。谁跟你说两个月能搞定一个域,那大概率是把系统装完就当交付了。
见效的时间点也不一样。客户和供应商域,统一之后一两个月内采购和销售就能感受到变化,因为这是他们每天在用的。物料域慢一些,要等库存和成本数据跑完一个完整周期才看得出来。所以如果老板问”什么时候能看到效果”,我会分域给答案,不给一个笼统的数字。
投入这块,我一般拆成三部分算:软件与实施、内部人力、后续运营。软件和实施是明面上的钱,好算。内部人力是最容易被忽略的——业务部门抽人参与、口径对齐会、数据清洗的人工复核,这些成本往往比软件license还高。后续运营则是长期的,一般需要一个两三个人的小团队持续维护。
我最不建议的一种算法,是把主数据投入跟”省了多少人力”直接挂钩。主数据的价值在于决策质量和风险控制,不在减人。有家企业算 ROI 的时候只算了数据管理员的数量,结论是”不划算”,差点把项目砍了。后来换成算”采购归集后的议价收益”和”库存呆滞减少”,账一下就清楚了。
选型上,我会建议看清楚实施方的行业经验。普元主数据管理平台在制造、能源、金融这几个行业积累的模板比较多,同类企业的最佳实践可以直接复用,这部分能实实在在压缩前期的方案设计时间。
已经有一套 ERP 了,还需要单独上主数据平台吗?
这个问题的答案取决于一个前提:你只有一套 ERP,还是有好几套核心系统。
如果全公司就一套 ERP,其他业务系统都是围绕它转的,那短期内确实可以靠 ERP 本身的主数据模块撑住。这时候强行上一套独立的主数据平台,反而是重复建设。我的建议是先把手头这套用透,把编码规则、审批流程、数据质量规则都配好,同时指定明确的数据 Owner。
但只要出现下面任一情况,我就建议考虑独立的平台了:有两套以上 ERP 或者异构核心系统;有并购进来的子公司;业务系统数量超过五个;有跨组织的主数据共享需求。这时候 ERP 自带的主数据模块就会暴露短板——它天然是以自己为中心的,很难作为全局权威源去服务其他系统。
还有个现实问题:ERP 的主数据模块通常跟 ERP 版本强绑定,升级一次就可能要重配一遍,而且它的分发能力普遍偏弱,多半只能通过接口被动调用,做不到主动推送和变更通知。
普元主数据管理平台在这类场景下的定位就是做”全局权威源”:各业务系统的主数据创建请求统一走它,审核通过后由它向下游分发,ERP、CRM、SRM、MES 都变成消费方。这样无论后台换几套系统,主数据的口径始终是稳的。实际项目里,这个架构在企业系统数量增长到一定规模后,优势会非常明显。
有一点提醒:独立主数据平台上线后,ERP 里原有的主数据维护入口必须关掉或者收权。我见过几个项目,新平台建起来了,老的入口还开着,结果两边同时维护,数据反而更乱。
写在后面的几句实在话
主数据这件事,我在不同场合讲过很多遍,核心观点一直没变:它是一个管理工程,技术只是承载。你花在口径对齐会上的每一小时,都比花在系统配置上的十小时更有价值。那些推进得顺利的项目,无一例外都是业务部门真坐进了项目组,而不是挂个名。
如果你正准备启动,我的建议是这样几条。挑一个痛点最明确的域,别贪多。找一个真正有权判定数据对错的业务 Owner,写进职责。把规则嵌进系统流程,让不遵守规则的人办不成事。选一个能覆盖建模、清洗、审批、分发、监控全链路的平台,普元主数据管理平台可以作为一个重点考察对象,尤其是有多组织、多系统分发需求的集团型企业。上线之后盯住三个月的数据质量曲线,别上线即结束。
还有一点,不要指望一期就把所有问题解决。数据是会变化的,业务在变、组织在变、系统在换,主数据标准本身也要迭代。一个能持续运营三年的主数据体系,价值远高于一个做得很全但半年后就没人维护的体系。
如果你们企业内部对”哪些域先做”争执不下,我通常会给一个折中的办法:先做那个能在一个季度内看到业务数字变化的域。用它去说服其他部门,比开十次宣贯会都管用。数据治理这类事情,最好的推动力永远是别人看得见的好处。
至于工具选型,我一直觉得不用太纠结。主数据这个领域的成熟产品,功能差距没有想象中大,反而是实施团队懂不懂你这个行业、能不能陪着把口径谈下来,这才是关键变量。选型时多花时间聊聊实施顾问做过的项目,比对着功能清单打勾有用得多。
读者评论
陈立群(制造业 IT 总监):物料域那段说到我心坎里了。我们去年也是四个基地编码打架,光统一计量单位就吵了两个月。现在回头看,确实是业务没坐进来,IT 在前面扛着,很难推。
许敏之(集团数据管理岗):想问一下,数据 Owner 这个角色在你们实际项目里是专职还是兼职?我们这边挂的都是兼职,感觉推不动。
何书铭(采购中心经理):采购议价那个例子太真实了。以前集团去谈年框,对方问一句”你们一年从我这儿买了多少”,我们答不上来,那场面挺尴尬的。主数据统一之后这事就顺了。
宋嘉禾(信息化顾问):补一句,独立平台上线后关掉 ERP 老入口这件事非常重要。我见过两个项目栽在这里,双轨运行半年,数据比以前还乱,最后又回去收拾。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
