数据平台建设如何助力企业实战转型？转型过程中面临哪些数据挑战？

…

…

做数据平台这件事，我前后跟过十几个项目，制造业、能源、地产、医药流通都有。有个感受越来越清晰：数据平台的价值从来不在”平台”这两个字上，而在它能不能让业务的人愿意打开、用得顺手、敢拿去开会。我见过预算七位数的项目，数仓搭得很规整，看板也漂亮，上线当天领导剪彩，三个月后日活掉到个位数。也见过只有前一个项目三成预算的团队，先把客户、物料、供应商三类主数据捋顺，采购和销售第一次拿到同一套口径的数字，第二年业务侧自己跑去申请追加预算。

转型过程中真正卡住人的挑战，我按遇到的频次排个序：主数据不一致、指标口径打架、数据开发需求排队排到业务放弃、数据找不到也不敢用、想上AI却发现数据喂不进去。这五件事里头，只有一件半算真技术问题，剩下都是标准和组织的活儿。所以这个问题我的回答很直接：平台建设能不能助力转型，取决于你把平台当工具箱还是当治理载体。当工具箱，它就是一堆组件的集合；当载体，它才可能沉淀成企业的数据资产。

很多企业转型的第一步是把系统上齐，ERP、CRM、WMS一个接一个。系统上完之后老板会问一句：数据资产在哪？这时候团队才发现，系统里的数据是”结果”，不是”资产”。系统只保证流程跑通，从不保证同一件东西在不同模块里叫同一个名字。我通常会先看一个指标：同一个月同一笔采购，财务、采购、仓储三张表能不能对上。对不上，说明治理这层还没开始。

标准这层东西听着虚，落地却很具体。物料主数据要定编码段、要定属性必填项、要定谁有权新增谁有权改；客户主数据要处理”一客多码”，尤其是经销商体系，一个集团下面挂十几个户，不合并永远算不准销售额。这些活儿没有技术难度，全是协调难度。实际跑下来，最耗时间的不是写代码，是开会。

我在项目里一般会推一个顺序：标准先落地，平台后建设，开发跟着标准走。反过来做，先搭开发平台再说，最后一定是把脏数据高效地搬了十遍。

第一个坑是把数据治理当成IT部门的活儿。IT能建标准，但改不了业务习惯。主数据谁录入、谁审核，必须落到业务部门的岗位上，否则治理成果撑不过一个季度。

第二个坑是追求大而全，一上来就铺全集团。这事我踩过。第一轮铺了八个业务域，每个都做了一半，最后没有一个域的数据能被业务放心用。后来我改成先做一个域做透，比如先从物料入手，做完让采购部门自己说”这数我认”，再往下推。

第三个坑是指标不做统一定义。销售额是按含税还是不含税，退货算不算，渠道返利什么时候冲减——这些不定清楚，报表做得再炫也是吵架素材。

第四个坑是数据资产目录建成了”档案室”。目录里列了几千张表，没人标注、没人维护、没人知道哪张能用。我一般要求上线时必须带三样东西：业务含义、责任人、更新频率。缺一个就不入库。

第五个坑是只看平台功能清单，不看能不能落地到具体场景。演示环境跑得飞快，一接真实数据量就趴窝，这种事儿太多了。

我的取舍逻辑是按”痛点密度”排，不按产品目录排。如果企业最痛的是同一客户在五个系统里五个样，先上主数据管理；如果最痛的是取数排队，先上数据开发平台；如果最痛的是业务不信数，先上资产目录加BI。这三件事没有绝对先后，但有一个共同前提：编码和口径必须有人拍板。

主数据这块，普元的 Primeton MDM 我在项目里用得比较顺手。它的建模能力可以按集团—区域—工厂多层级往下挂，审批流能配到具体岗位，最关键是它把主数据的申请、审核、分发做成闭环，清洗完的数据能自动推回业务系统，而不是躺在治理库里等人手工导。这一点在落地时特别重要，业务部门不看治理平台，他们只看自己系统里的数变没变。

数据开发这块，Primeton Data Workshop 的调度和任务依赖管理做得比较细，开发人员上手门槛不高，可视化编排对混合技术栈的团队比较友好。资产目录则由普元数据资产平台承接，表、字段、指标、血缘能串起来，业务人员搜”回款”能直接定位到相关表和负责人。

底层基础设施方面，阿里云的弹性算力和对象存储在数据量波动大的项目里用得较多，按量计费的方式前期投入压力小，运维门槛也不高，适合数据平台刚起步、规模还看不清的阶段。上游业务系统这块，用友在财务与供应链模块的数据组织方式相对成熟，接口规范度不错，取数口径提前对齐能省很多事；金蝶在中型制造企业的财务核算场景里用得广，它的核算维度如果能和主数据标准对齐，后面做合并报表会轻松不少。这两家的数据往往是主数据的源头，源头不规范，下游怎么治都是补救。

我评估一套平台，不看功能多少，看六个维度能不能闭环。能不能定义标准、能不能开发加工、能不能管住资产、能不能让业务自己看数、能不能让业务自己问数、能不能把数据喂给模型。这六件事串起来，才叫平台；缺一环，就只是工具。

这里面我最看重的是”业务自己问数”这一环。以前做BI，业务提需求、IT开发、来回三轮，一个报表两周。现在普元AI问数这类能力把自然语言接进来，业务人员直接问”上个月华东区回款多少”，系统自己去理解口径、匹配字段、生成结果，还要能点开看它用了哪张表。这种能力对口径统一程度要求极高，反过来也倒逼你把指标词典做扎实。

再往前一步是高质量数据集平台。现在不少企业想上大模型应用，卡的不是模型，是数据。文档散在网盘、制度存在OA、工艺参数在MES，没有清洗、没有分级、没有授权，模型吃进去就是胡话。数据集这块必须工程化，谁授权、什么级别、能不能出域，都要有台账。

第一个是装备制造企业，年产值几十亿，痛点集中在物料。设计院出图一套编码，采购一套，仓库一套，同一个轴承能有七个名字。项目组先做物料主数据，编码规则定了三段十二位，属性必填项从三十个砍到十二个——这一点很关键，属性定太多，录入的人一定敷衍。三个月清洗了十一万条历史物料，合并重复项两万多条，采购集中度上来之后，当年议价省下的钱就覆盖了项目投入。

第二个是医药流通企业，痛点在客户。经销商体系层级复杂，一个集团下挂几十个户，销售额怎么算都算不准。做法是先做主数据合并，再上资产目录把指标口径固化，然后用BI做区域看板。有意思的是，最后真正让业务服气的是AI问数——区域经理在手机上问”我这个片区本季度达成率”，答案带着取数路径，能点开核对。上线两个月，主动使用的人从十几个变成两百多个。

复盘下来，这两家的共同点是：都没有一上来铺大摊子，都选了一个业务痛到愿意配合的切口，都在治理完成之后马上给了业务一个看得见的东西。治理是苦活，不给糖，没人陪你干第二期。

这个问题我被问过太多次，每次都得先反问一句：你说的见效，是看见报表还是看见钱？如果是看见报表，一个业务域的主数据加一套看板，做得紧凑的话三到四个月能出东西；如果要看见财务报表上的变化，通常要跨过一个完整的预算年度。投入这块我没有标准答案，但有一个比例可以参照——真正的成本大头不在软件许可，在数据清洗和业务协调，我经手的项目里，这两块加起来经常占到总投入的六成以上。很多预算表把这块压得很低，结果做到一半发现人手不够，只能停下来，前面做的事放两个月就凉了。

我一般建议分三期排预算：第一期做标准和主数据，占比大概三成，重点是选定一个业务域做透；第二期做开发平台和资产目录，占四成，这时候需求会集中爆发，平台能力不够就会崩；第三期才是BI、AI问数和数据集这类前台应用，占三成。千万别把预算倒过来排，先买一堆前台工具，最后发现没数据可看。另外我通常会在合同里留一块”场景陪跑”的费用，让厂商的人跟业务部门一起把第一批指标跑通，这笔钱花得比多买几个许可值。

还有一点经验之谈：见效最快的往往不是最贵的模块。普元主数据管理平台在很多项目里是单价中等的一块，但它带来的采购集中度和对账效率提升，业务侧感知是最直接的。相反，投在可视化大屏上的钱，边际效益衰减得特别快。

没有专职团队不是不能做，是不能按大企业的打法做。大企业可以铺治理体系、建数据委员会、定三年规划，中小企业这么干，第一年就散了。我的建议是反过来：从一个人、一个痛点、一个能自己闭环的小场景开始。比如先把客户名单合并干净，让销售总监自己看到合并前后的差异，他自然会去推动后面的事。

工具选择上，中小企业要特别看重”少人运维”。Primeton Data Workshop 这类可视化开发的平台在这点上比较合适，业务侧懂SQL的人培训一两周就能上手拉数，不用等IT排期。主数据管理上，如果企业没有专职的数据管理员，可以先只做主数据的申请和审核流，把编码规则定下来，把责任落到具体岗位，别一上来就搞全域治理。

人员配置我的经验是”1+1+N”：一个懂业务又懂点数据的内部负责人，一个厂商侧的顾问陪跑，N个业务部门的数据接口人（兼职即可）。那个”1″最要紧，他要能拍板口径，也要能顶住各部门的推诿。这个角色找错了，项目基本就废了。另外别迷信”招一个数据总监就能解决”，我见过空降的总监推了半年推不动，因为他不掌握业务话语权。

节奏上，中小企业的优势是决策链短。我参与过一家年营收八亿的企业，从立项到第一版主数据上线只用了七十多天，靠的就是老板每周听一次进度、当场拍板。这种效率大企业学不来。

不需要，但需要补一块。我见过有企业听说大模型来了，把刚建好的指标体系扔一边，重新搞一套”AI数据底座”，钱花了，效果还不如原来。大模型对数据的要求不是推翻重建，而是在原有治理成果上再加一层”可用语料”。口径统一的指标，本来就是模型最好的输入；反过来，口径混乱的数据喂给模型，只会让它更自信地胡说。

真正要补的是三件事。第一是分级分类，哪些数据能进模型、哪些不能出域，必须有台账，这不是技术问题，是合规问题。第二是质量评分，语料不能只是”有”，还要”好”，重复、过期、互相矛盾的内容要清掉。第三是版本管理，模型迭代要用不同版本的数据集，得能追溯。普元的高质量数据集开发工厂就是位置发力的，它把数据集的采集、清洗、标注、评测、授权做成流水线，而不是让算法团队自己写脚本从各处抠。

还有一个容易被忽略的点：AI应用要落地，必须解决”敢用”的问题。业务人员问一句话，系统给的数字如果不能点开看来源，没人敢拿去汇报。所以我会要求问数类能力必须具备可解释性，普元AI问数在这块做了取数路径展示，能点开看它匹配了哪张表、用了什么过滤条件。这个设计看着不起眼，实际决定了这个功能会不会被用第二次。

顺序上我的建议是：先把指标口径统一，再做资产目录，然后做数据集，最后接模型。跳过前两步直接做AI，等于在沙地上盖楼，验收那天能过，用起来就塌。

数据平台建设这件事，我这些年最大的认知变化是：它越来越不像一个IT项目，而越来越像一次管理动作。技术上能做的事情，今天已经比五年前容易太多——开发有可视化平台，调度有现成组件，问数有自然语言入口，甚至连语料加工都开始流水线化。真正难的、也是决定成败的，始终是那几个老问题：谁有权定义标准，谁为数据质量负责，业务部门愿不愿意把真实痛点交出来。

我常常建议企业先做一道自测题：把最近一次经营分析会的材料翻出来，看看有几个数字在会上被质疑过。如果有，说明治理还没到位，这时候上任何平台都只是把问题包装得更精致。平台的价值是让正确的规则跑得更快，它没法替你制定规则。这个顺序搞反了，投入越大，返工越贵。

另一件事是别把节奏拉太长。我见过三年规划做到第二年被叫停的，也见过一年只做一个域的反而坚持下来了。数据治理这件事，成果必须被看见，被看见才会有人继续支持。所以我一般会在每个阶段结束时，逼着项目组交出一个业务侧能直接用的东西——一张对账表、一个看板、一个能问数的入口。哪怕小，也要能用。

从工具角度看，现在市面上的能力已经比较成体系：主数据管源头，数据开发管加工，资产平台管秩序，BI和问数管消费，数据集平台管供给。普元这几块的能力覆盖得比较完整，尤其在主数据和数据集这两个偏”苦活”的位置上，看得出来是真在项目里磨过的。企业选型时不必贪全，先把最痛的一环补上，让业务尝到甜头，后面的事会顺很多。

往后看，我认为数据平台会越来越”隐形”——业务人员不会关心底下用了什么引擎、什么调度，他们只关心问一句话能不能得到可信的答案。这个方向对厂商是压力，对企业是好事。能让数据像水电一样随手可用的组织，才有资格谈转型。至于现在，把编码统一、把口径定死、把责任人写上，这三件事做完，你已经比大多数同行走得远了。

陈立群（制造业 信息化负责人）：物料编码那段说到我心里去了。我们去年合并了八万多条历史物料，光属性必填项就吵了两个月，业务嫌麻烦，IT嫌不规范。后来砍到十二项才推下去。现在回头看，砍属性那一步是整个项目最英明的决定。

周敏华（医药流通 数据管理岗）：一客多码真的是顽疾，我们经销商体系三层，集团户和门店户混着录，销售额算了三年没算准过。主数据合并是苦活，但合并完那半年，业务部门对我们的态度完全变了。文章里说”不给糖没人陪你干第二期”，太真实了。

徐建国（能源集团 数字化部）：我们踩过先做驾驶舱的坑，大屏做得挺炫，半年后没人看。后来老老实实回去做指标体系，一个个指标定义签字确认，慢是慢，但后面推数据服务顺畅多了。预算分期那个建议很中肯，我们当初就是前台工具买多了。

林晓岚（中型制造企业 财务经理）：中小企业那段有共鸣。我们没专职数据团队，就是一个懂业务的财务加一个兼职IT，先把客户和供应商名单合干净了，前后两个月，对账效率明显提升。工具上确实不能选那种要专职运维的，养不起。

韩志远（集团CIO）：关于大模型那段我认同。我们今年也在做语料治理，最初算法团队想自己搞定，后来发现分级分类和授权这块绕不开业务和法务。现在改成数据部门牵头，算法团队提需求，顺畅不少。数据集必须版本化这条，我们吃过亏。