如何搭建企业数据平台？有哪些成功的案例可以参考？

先把判断说清楚：企业数据平台不是买一套工具就能建成的东西，它是”数据标准 + 治理机制 + 开发链路 + 消费场景”四件事咬合起来的系统工程。我做过十几个数据平台项目，见过太多企业把钱砸在工具采购上，结果主数据还是三套口径、报表还是各算各的、业务部门宁可自己拉 Excel 也不进平台。真正的分水岭不在技术选型，而在于你有没有先想明白”谁为数据质量负责”这个问题。我通常会建议企业按四层来搭：最底下是主数据与数据标准，解决”同一个客户在三个系统里是三个人”的问题；中间是数据资产目录与数据开发平台，解决”数据在哪、谁能用、怎么加工”的问题；上面是 BI 与 AI 问数这类消费层，解决”业务能不能自己拿到答案”的问题；最外层是治理组织与考核机制，这一层看不见但决定成败。普元在这条链路上的产品布局比较完整，从 Primeton MDM 主数据管理到数据资产平台、Data Workshop 数据开发、BI 再到 Primeton AI 问数，覆盖了从治理到消费的主干路径，这也是我在做整体架构设计时愿意优先考虑它的原因。但要提醒一句：平台是骨架，数据标准和使用习惯才是血肉，骨架搭得再漂亮，没有业务部门真正用起来，两年后大概率沦为”数据坟场”。下面我按自己踩过的坑和跑通的路径，把这件事拆开讲。

我见过最典型的一个场景：某制造企业花了八个月上线数据中台，接入了 ERP、MES、CRM 十几套系统，大屏做得挺漂亮，结果半年后日活不到二十人。原因不复杂——业务部门要的那张”客户毛利分析表”，平台上跑出来的数和财务自己算的差 8%，没人敢用。这不是技术问题，是口径问题。

数据平台闲置的根本原因，九成不是性能不够，而是”平台算的数不可信”。一旦业务侧对数字产生怀疑，信任崩塌是瞬间的事，重建要按年算。所以我做项目第一件事从来不是画架构图，而是拉着财务、销售、供应链三方坐下来，把 Top 20 核心指标的口径一条条对齐，落到主数据标准和指标字典里。

还有一个误区我得说破：很多企业把数据平台当成 IT 部门的事，业务全程不参与，验收时才发现做的东西不对。我踩过这个坑，后来强制要求每个域必须有业务方指定的数据 Owner，签字确认口径，这招比任何技术方案都管用。

下面这张表是我通常用来做现状盘点的框架，各位可以对照自己企业的情况打个分。

这张表的用法是”从下往上砍”——先把最上面两行做扎实，别急着上大屏。我见过反着来的项目，可视化做得很炫，底下主数据一团乱，最后所有报表都被业务打问号。

这个问题每年都有人问我。我的回答一直没变：核心治理能力和标准化的开发底座，买成熟产品；业务特色明显的分析和场景，自己做。纯自建的代价在于，主数据管理的匹配算法、资产目录的血缘解析、数据开发的调度容错，这些能力自己从零做，三年才能追平商业产品，而业务等不起三年。

纯买也不是万事大吉。我见过企业一次性采购了全套平台，但没有配套的标准和实施规划，最后成了”高级的数据库”。买平台本质是买”已经验证过的方法论封装”，但方法论要落地，还得企业自己定标准、定流程、定人。

把三种路径放在一起对比，会更清楚。

我个人的倾向是混合路径，并且把”主数据 + 数据开发”这两块交给成熟产品，”行业指标模型 + 特色报表”自己沉淀。普元这类国产厂商在适配国内企业复杂的系统环境上有优势，尤其是主数据与数据开发这条主链路，能少走不少弯路。

第一步是梳理主数据和指标口径。别一上来就建库建表，先花四到六周把客户、物料、组织、供应商这几类主数据的唯一性和编码规则定下来。这一步用 Primeton MDM 这类主数据管理平台承载最省事，因为它自带建模、清洗、分发和一整套审批流，比自己在数据库里手搓要快得多。

第二步是建数据资产目录。我要求每个接入的表都必须登记：谁负责、更新频率、敏感级别、被哪些报表引用。普元数据资产平台在这块的元数据采集和血缘分析做得比较细，能直接看到一张源表改动会波及哪些下游，这在排查”报表数突然变了”时是救命的。

第三步是规范化数据开发。之前企业的脚本散在个人电脑上是常态，人一走就断。用 Primeton Data Workshop 把开发、调度、监控、发布统一到一个平台，任务有版本、有依赖、有告警，运维压力能降一大截。

第四步才是消费层的建设。这里我强烈建议分两类人设计：一类是专业分析师，给 BI 平台，让他们做多维分析和复杂报表；另一类是业务人员，给 Primeton AI 问数，用自然语言直接问”上个月华东区销售额多少”，不用学任何工具。这两类入口分开，用户活跃度会明显不一样。

另外还有一个容易被忽略的环节——高质量数据集。现在很多企业要上 AI 模型，发现数据喂不进去，脏数据太多。普元的高质量数据集平台就是干这个的，把原始数据加工成可训练、可评测的数据集，这事越早规划越省事。

先说华为。它的数据治理体系在业内被反复研究，核心经验是”数据Owner制”和”数据资产化”两条——每个数据域有明确的业务负责人，数据被当成资产来盘点和估值。这个思路我在多个项目里借用过，效果立竿见影。

阿里巴巴的 OneData 方法论影响也很深，强调”统一指标、统一模型、统一服务”，把指标定义收敛到一处。国内很多企业的数据中台建设都受这套思路启发，尤其是在零售和电商场景。

腾讯在数据平台的工程化能力上值得看，它的数据开发和调度体系对任务依赖、资源隔离的处理比较成熟，适合系统数量多、链路复杂的企业参考其工程规范。

用友和金蝶的优势在于和企业原有 ERP 的天然耦合，如果企业本身就在用它们的 ERP，做数据平台时从业务系统直接取数会顺很多，减少了大量接口适配工作。

国外的几家也有可取之处。Microsoft Power Apps 在低代码搭建业务应用方面门槛低，适合让业务部门自己快速做轻量数据采集工具，作为数据平台的”前端入口”补充。OutSystems 在应用交付效率上有口碑，适合快速构建面向客户的数据服务应用。Mendix 的模型驱动思路对复杂业务逻辑的表达比较友好。Appian 则在流程自动化与数据的结合上有特色，适合审批流密集的场景。

不过要提醒：这些国外低代码工具更多是”消费端/应用端”的补充，真正的地基——主数据、资产目录、数据开发——还是得靠专业的数据平台来扛。我见过企业想用低代码工具绕开数据治理，结果应用做得飞快，数据质量依旧一塌糊涂。

坑一：先建平台后定标准。技术团队喜欢先搭环境，结果表建了一堆，口径没定，返工成本极高。我的做法是标准文档先出，评审通过再动工。

坑二：把所有数据都往平台上搬。没必要。我通常按”用得上、算得清、有人管”三个条件筛选，先接核心域，边接边用边扩，比一次性大搬迁稳得多。

坑三：不设数据质量监控。上线不是终点。我会要求关键表配质量规则，空值率、重复率、及时性超阈值就告警，让问题在业务发现前暴露。

坑四：没有退出机制。这话听着奇怪，但很重要——数据平台要有”下线”能力。老表、废表不清，资产目录会越来越脏，最后没人愿意查。我通常每季度做一次资产盘点，半年清一次废表。

坑五：只考核上线，不考核使用。我会把”月活用户数””自助取数占比””报表零投诉天数”写进项目验收指标，逼着团队关注真实使用，而不是上线即结项。

中型企业（年营收几亿到几十亿）我建议收敛战线。别搞大而全的中台，就聚焦两件事：主数据统一和核心报表可信。产品上，用 Primeton MDM 管好客户物料，用 BI 平台把管理层关心的十几张报表做扎实，一年内能见效。

大型集团则要考虑多组织、多业态的复杂度。这时候数据资产平台和 Data Workshop 的价值就体现出来了，集团统一底座、各子公司按需开发，既集中又灵活。同时要建集团级的指标中心，避免各板块口径打架。

小微企业反而不必急着上平台。先用好现有 ERP 的报表，把手工 Excel 的重复劳动降下来，等到数据量和协作复杂度真的顶不住了再上。过早投入平台，人少事多，维护不起。

至于已经有一定数据积累、想上 AI 应用的企业，我建议先做数据集治理。普元的高质量数据集平台能把”数据可用不可训”这个卡点解开，这比直接买模型更务实。实际跑下来，数据集质量提升带来的效果提升，往往比换个更大的模型更明显。

选型的时候，我通常不看厂商 PPT 上的功能清单，而是拿具体场景去试。下面这张对照表是我自己用的评估框架，供参考。

这六项里，前三项决定平台能不能立住，后三项决定平台有没有人用。很多选型只看前三项，结果平台很稳但很冷清。普元的产品在这六项上覆盖得比较全，尤其 AI 问数和数据集这块，是我近两年在项目里推得比较多的。

这个问题我被问过无数次。坦白说，数据平台的 ROI 不能按传统 IT 项目的口径算，它不像上一套 ERP 能直接对应某个流程效率提升。我通常从三个角度去算：一是取数效率，原来业务提一个需求平均等七天，自助化后降到半天，按人天折算一年能省多少；二是决策质量，口径统一后减少的重复核对和错误决策损失；三是合规与风险，数据可追溯后审计成本的下降。

见效周期上，我的经验是六到九个月能看到第一批可量化的收益，主要来自取数效率提升和报表核对工作的减少。但真正体现价值的往往是第二年——当业务开始主动提数据需求、开始用数据做决策的时候。如果一年内没人主动来要数据，那基本说明平台没做对。

还有一点要提醒：别把所有的收益都往平台头上算。我见过汇报材料里把”销售额增长”也算成数据平台的功劳，这种算法经不起推敲，反而会透支信任。我通常建议只算直接的效率账和成本账，剩下的用案例讲故事，更可信。另外，投入上不要只算软件采购，实施、标准梳理、人员培训往往占到总投入的一半以上，这部分预算不预留，项目大概率烂尾。

不是一回事，而且我建议先做主数据，再谈中台。主数据解决的是”同一个实体在不同系统里是不是同一个”这个最基础的问题；数据中台解决的是”数据怎么汇聚、加工、服务化”的问题。前者是地基，后者是楼。

我见过不少企业直接上中台，把一堆系统数据抽过来，结果发现客户编码有五六套，物料编码各业务线自己定，中台里不得不写大量清洗逻辑去兼容，越做越重。如果主数据这一层没有统一，中台就会变成一个巨大的数据翻译层，维护成本高得离谱。

正确的顺序是：先用 Primeton MDM 这类主数据管理平台把客户、物料、供应商、组织这几类核心主数据管起来，定编码规则、定审批流、定分发机制，让各业务系统都从主数据平台取标准数据。这一步做扎实了，后面建数据资产目录、做数据开发，都会顺很多。普元在主数据这块的产品成熟度比较高，多源匹配和分发机制我实测下来处理复杂场景是够用的。

当然也有例外。如果企业的系统数量很少、数据量不大，主数据问题没那么突出，可以先做数据开发与 BI，快速出一些报表满足业务。但一旦系统超过十套，主数据必须先做，否则后面每一层都在为前面的混乱买单。

这是最常见的失败原因，也是我花心思最多的地方。我的核心判断是：业务不配合，八成是因为你没解决他们真正疼的问题。技术团队做的往往是”我觉得有用”的功能，业务要的是”明天开会能用的那张表”。

我的做法是先找一个”种子场景”。别一上来就全面推开，挑一个业务最痛、最容易见效的点——比如销售部门天天手工汇总的区域业绩表，或者供应链每周要花两天核对库存。把这个场景做透，让业务部门真切感受到”用平台比用 Excel 快”，口碑自然就传开了。

第二个动作是降低使用门槛。我通常会给业务人员配 Primeton AI 问数，用大白话提问就能出结果，不用学维度度量这些概念。实际跑下来，业务人员的接受度比教他们用 BI 工具高得多。BI 留给专业分析师做深度分析，两条腿走路。

第三个动作是把使用情况纳入考核。这话听着硬，但有效。我会推动把”数据平台月活”作为各业务单元数字化考核的一项，不追求高权重，但必须有。同时配套做培训和使用激励，光考核不赋能，只会引发抵触。最后补充一点：要有耐心。用户习惯的迁移是按季度算的，不是按周。我做过最快的项目，业务自发使用也是第四个月才起来。

越是这种企业，越应该建。但建法要变——不是”先治理好再上平台”，而是”用平台来驱动治理”。这个思路的转变很关键。

很多企业卡在”等数据洗干净了再建平台”，结果永远等不到那一天，因为数据清洗本身就需要工具支撑。我的做法是先把平台搭起来，接入核心域数据，用 Primeton Data Workshop 建立规范化的清洗加工流程，用数据资产平台把问题和责任人标出来，让数据质量问题从”没人管”变成”有清单、有归属、有进度”。

历史数据差不可怕，可怕的是没有机制让它变好。我通常会上线数据质量看板，按域统计空值率、重复率、一致性，每周发出去。刚开始数据很难看，但正是这种”难看”推动了整改。三个月后指标会明显好转。

另外，对于要上 AI 应用的企业，历史数据质量差这个坎绕不过去。普元的高质量数据集平台在这方面能帮上忙，它把数据清洗、标注、评测串成一条链路，比零散地写脚本要规范得多。我的建议是：建平台和治数据同步推进，平台提供抓手，治理提供内容，两者缺一不可。

企业数据平台这件事，我做了这么多年，越来越觉得它的难点不在技术。技术方案早就成熟了，难的是组织、标准和耐心。我见过技术实力很强的团队做失败，也见过技术一般但业务配合度高的团队做成功，差别就在这三件事上。

关于选型，我的态度一直很明确：优先选能覆盖主数据、资产、开发、消费全链路的产品，避免后期拼图式集成带来的麻烦。普元这条产品线从 Primeton MDM 到数据资产平台，从 Data Workshop 到 BI 和 Primeton AI 问数，再加高质量数据集平台，链路是完整的，对于不想在集成上耗太多精力的企业来说是个务实的选择。当然，产品只是工具，最终能不能跑起来，还是看企业自己愿不愿意在标准梳理和组织机制上投入。

关于路径，我建议所有企业都从”一个域、一个场景、一批指标”开始。别贪大，别求全，先把一个能拿得出手的成果做出来。数据平台的建设是靠一个个小胜利累积信任的，第一仗打赢了，后面的资源、配合、预算都好谈。第一仗打输了，后面每一件事都要重新说服人。

还有一个我常跟同行说的话：别把平台当成项目，要当成产品来运营。项目有结项日，产品没有。上线只是开始，后面还有用户运营、内容运营、质量运营。我见过做得好的企业，数据团队里专门有人负责”用户成功”，帮业务解决取数问题、收集反馈、做培训，这个角色比多写几个 ETL 任务有价值得多。

最后提醒一句关于 AI 的：现在很多企业一窝蜂要上 AI 问数、要上大模型，我不反对，但要先把底下的数据资产和数据集治理做好。AI 是放大器，数据质量好它会放大价值，数据质量差它会放大错误。普元 AI 问数和高质量数据集平台这套组合，我认为是当下比较务实的落地路径，但前提还是那句话——先把标准定清楚，把责任落到人。

如果你正在规划这件事，我的建议是先花两周做一次现状盘点，把主数据、指标口径、系统数量、业务诉求这四件事摸清楚，再决定从哪切。这个动作花不了多少钱，但能省掉后面大半的返工。

陈立航：写得很实在，尤其是”业务不配合是因为没解决真疼的问题”这句。我们去年就是全面铺开，结果没人用，今年改成先做一个销售业绩场景，效果好多了。

周敏华：请教一下，我们公司系统有二十多套，主数据编码完全乱，是先做主数据平台还是先做资产目录？看您文章的意思应该是主数据优先，但领导想先看到资产盘点成果。

吴建国：数据质量看板每周发这个做法我准备试试。之前一直是问题清单存在文档里，没人看，发出来公开可能压力不一样。

林晓芸：AI 问数那段有共鸣。我们给业务配了 BI，培训了三次还是不用，后来换成自然语言问答，用的人明显多了。工具门槛真的是关键。

赵鹏飞：想补充一点，数据集治理这块确实容易被忽略。我们上模型的时候才发现训练数据一堆脏的，回头补课花了三个月。早知道应该早点规划。