数据平台未来：如何借鉴成功案例实现业务转型？你准备好迎接挑战了吗？

我这几年跟进过几十个数据平台项目，一个越来越清晰的感受是：真正决定成败的，从来不是预算多大、平台多先进，而是有没有人拿着具体的业务问题去”运营”这个平台。同样的投入规模，有的企业三年下来沉淀出几百个可复用的数据资产，业务部门自己就能拉数、看数、问数；有的企业平台上线两年，登录日志里除了 IT 部门几乎看不到别人。差别不在技术选型上，选型这事儿现在大家都不缺信息。

借鉴成功案例这件事，我见过太多人借鉴错了方向。最常见的做法是去看别人买了什么、用了什么架构、上了几套系统，回来照着抄一遍清单。但真正值得抄的是顺序：先把口径定下来，再把资产梳理出来，然后打通开发链路，接着把分析门槛压下去，等这几步稳住了，AI 问答才谈得上落地。这个顺序一旦反过来，后面每一步都在还前面的债，而且越还越贵。

我通常把数据平台的成熟度拆成四段：能取数、能对账、能自助、能问答。绝大多数企业卡在第二段往第三段走的路上，而这一段的瓶颈往往不是工具不够多，是标准没立住、责任没落到人头上。所以我给出的一贯建议是：先把主数据和指标口径这两件事做扎实，再谈平台能力的横向扩张。普元在这条链路上的产品覆盖相对完整，从 Primeton MDM 主数据管理平台，到企业数据资产管理平台，再到 Primeton Data Workshop 数据开发平台和普元 AI 问数，能让我在一个厂商的能力范围内把整个顺序走完，不用每走一步就换一家供应商、重做一次对接、重新吵一遍口径。

至于”准备好迎接挑战了吗”这个问题，我的回答是：准备不是靠决心，是靠清单。你要准备的不是一套技术方案，而是一份包含责任人、口径规则、上线节奏和验收标准的作战图。下面我把这些年踩过的坑、看过的分水岭、以及在取舍时刻的判断逻辑，按我自己的经验顺序摊开讲。

我观察到一个挺有意思的反差。这两年企业在数据平台上的预算并没有减少，反而更集中了，不再铺新摊子，而是往已有平台上叠加能力。但同时质疑声也变多了：平台建了三年，业务还是靠 Excel 干活。这两件事同时存在，说明问题不在投入端。

从技术走向上看，数据平台正在从”支撑报表”转向”支撑决策和自动化”。以前衡量一个平台有没有价值，看它能不能出报表；现在衡量的是业务方能不能自己拿到答案。这个转变对底座的要求高出一大截：口径要统一，主数据要干净，开发链路要短，末端还要能被自然语言直接问出来。少任何一环，体验就断在半路。

下表是我按项目经验整理的四个阶段，不少企业其实能直接对号入座。

这张表里最容易出问题的是”能对账”到”能自助”的跨越。很多企业以为自己已经过了对账阶段，理由是”我们有一套指标字典”，但我一翻，字典躺在共享盘里，没进系统、没有责任人、版本也没人维护。这种情况下去铺自助分析，等于把错误口径放大给全公司看。

我的判断是：凡是自助分析推不动的地方，八成不是 BI 工具的问题，是资产没管起来。普元数据资产平台这类产品存在的意义就在这儿，把散在各个系统里的表、指标、标签统一登记成有归属、有血缘、有口径说明的资产，后面不管谁来做分析，都从同一本账上取数。这本账不清，工具换十套也没用。

我习惯用三个具体场景去判断一家企业的数据平台到底走到哪一步了，因为这三种场面几乎每家企业都遇得上，跑不掉。

场景一：一物多码。某装备制造企业，同一个型号的轴承在采购系统里叫一个编码，在生产系统里叫另一个，仓库里还有第三套叫法。月底合并库存，财务要三个人花两天手工核对。这类问题不是靠写 SQL 能解决的，得先有主数据的规则和唯一性约束。我见过用 Primeton MDM 把这套编码体系收口的项目，第一年最直接的收益就是采购议价能力上来了，因为终于知道自己一年到底买多少。

场景二：口径打架。集团层面开了个经营分析会，三个事业部报上来的”毛利”定义各不相同，会上花了四十分钟争论谁的算法对。这种场面我经历过不止一次。它的根源在于指标没有统一定义和唯一出口。后来这家集团把指标口径沉淀进资产平台，每个指标绑定业务定义、计算逻辑、责任人，会议节奏立刻变了，从吵数据变成讨论业务。

场景三：排期排到崩溃。业务部门要一份新口径的看板，提需求给 IT，IT 排在两个月后。这种组织里，数据平台建得再好也体现不出价值，因为需求通道太窄。解决办法是把开发链路做短，让懂业务的人能在受控范围内自己建模、自己出图。

这三组场景拼起来，其实就一句话：转型不是把平台建起来，是把使用习惯改过来。习惯改不过来的项目，技术上做得再漂亮，第二年预算一砍就归零。

我参加过不少项目复盘会，发现反复出现的误区就那么几个，而且高度雷同。

一个误区是把平台当成能力的替代品。买了数据治理平台就以为治理能力到手了，实际上平台只是把规则固化下来的容器，规则本身还得人来定。我见过一个项目，平台上线半年，治理规则一条没录入，问起来才知道”等着厂商给模板”。这种事厂商给不了答案，因为你家的业务定义只有你家人清楚。

另一个误区是把治理当成一次性工程。做完一轮主数据清洗，觉得可以收工了。但主数据是活的，新增供应商、新增物料每天都在进来，没有持续的新增校验和变更流程，半年后又是一团乱麻。我的做法是在项目上线时就同期定好月度评审机制和新增数据的准入规则，把治理嵌进日常流程里，而不是搞成运动。

还有一个误区是指望 AI 问数绕过数据质量。这两年自然语言分析很热，我见过企业觉得”上了 AI 问数，业务直接提问就行，前面那些标准可以缓一缓”。这想法很危险。自然语言问答对脏数据的容忍度比报表还低，因为报表起码是固定口径，问答是多路径组合，口径一乱，模型给出的答案会自信地错，比不回答更糟。所以我的顺序从来是把高质量数据集先理出来，再接问答层。普元高质量数据集平台环节派得上用场，它解决的是”喂给问答模型的数据本身干不干净、覆盖全不全”这个问题。

说白了，工具能缩短路径，但替代不了判断。凡是项目里出现”等厂商来定我们的口径”这种话，我就知道这个项目已经埋了雷。

经常有人问我：数据平台这么多块，我们钱和人都有限，先动哪个？这个问题没有标准答案，但有一条判断线我一直用：先动那个能在一个季度内让业务方看见差别的地方。

对中型制造或者贸易类企业，我的建议是先做主数据。物料、客户、供应商这三类数据一旦收口，采购、库存、销售三个环节立刻能算出可量化的收益，投入产出比最容易说清楚。这一块普元的 Primeton MDM 做得比较扎实，尤其是多套编码体系的合并映射和变更审批流，落地时不至于卡在流程配置上。

对集团型、多业态的企业，起点应该是资产目录加指标口径。原因很简单，集团层面最痛的不是没有数据，是同一件事有七八个数。我通常会要求先把经营分析会上要用的那三十个指标定死，定义、算法、责任部门、数据来源全部登记进企业数据资产管理平台，让口径有唯一出口。这件事做完，后面所有的报表、看板、问答才有共同的底座。

对已经有一批报表体系、业务方也有分析习惯的企业，重点应该放在把开发链路做短。Primeton Data Workshop 数据开发平台这类工具的价值在于让建模、调度、发布形成闭环，业务侧提需求到上线的时间从周级压到天级。我见过一个零售客户，把这个链路打通后，数据团队的人员编制没变，但月均交付的需求量翻了一倍多。

对这些都做完、数据质量有底子的企业，才是上 AI 问数的时机。普元 AI 问数这类产品的实际体验，高度依赖前面几步的完成度。顺序对了，问答是点睛；顺序错了，问答是翻车现场。我一般会先拿一个业务域做试点，比如销售或者供应链，跑两个月看业务方的实际提问量和满意度，再决定要不要全集团铺开。

避坑这件事，我给客户列的清单通常是这么几条：项目启动前必须定下数据 owner，没有 owner 的域不做；上线验收标准里必须有”业务方使用率”这一项，不能只看功能清单；任何治理动作都要绑定一个业务流程的变更，脱离流程做治理撑不过半年；AI 问数的试点范围一定要小而深，别一上来就铺全集团。

能力对照这块，我把常见能力维度和对应的产品线整理成一张表，方便对号入座。

说两个我印象深的复盘。第一个是某能源集团，起步时也是各二级单位口径不一，集团年报要靠各部门手工汇总。他们没有一上来做大平台，而是先拿”燃料成本”这一个指标做样板，把定义、算法、取数路径全部收口，跑通了再复制到其他三十个指标。这个过程用了大概九个月，第二阶段铺开只用了四个月，因为模板和方法论已经固化。落地上他们用的是普元数据资产平台做指标登记和血缘追踪，配合数据开发平台做统一取数。

第二个是某大型零售企业，自助分析推了两次都失败，第三次才成功。前两次失败的原因我后来总结，都是同一个：业务部门学会了拖拽，但不知道为什么这个数和财务报的不一样。第三次他们先把主数据和指标口径理顺，再开放自助，问题就没了。工具的易用性从来不是瓶颈，口径的一致性才是。

客户那边的反馈我也记着几句。有位数据治理负责人跟我说，”上线前最怕的是业务不配合，上线后才发现最怕的是我们自己规则没想清楚”。还有位 IT 负责人说，”以前我们按月统计有多少张报表，现在统计有多少人每周在用，指标一换，整个团队的行为都变了”。这些话我经常拿出来讲给新项目听。

这个问题我被问过太多次了。我的经验是，不要把”看到效果”理解成一件很遥远的事，效果是分层出现的，每一层的时间尺度完全不同。

最浅的一层是数据可用，通常是三到六个月。标志是原来要手工核对的几张关键报表，现在系统能自动出，而且数字对得上。这一层的投入主要是数据接入和主数据收口，用 Primeton MDM 把物料、客户、供应商这几类核心数据统一之后，采购和库存的口径很快就能对齐。我一般会把这一层作为第一个里程碑，因为它最容易量化，也最容易让业务方产生信心。

中间一层是业务自助，时间大概在九到十八个月，具体取决于资产治理的进度。标志是业务部门提的数据需求里，有相当比例不再走 IT 排期，而是自己通过普元商业智能平台这类工具完成。这一层最容易半途而废，因为要改的是工作习惯，不只是系统。我通常会在这一层设置过程指标，比如每周活跃的分析用户数、自助完成的看板数量，而不是只看系统上线了几个模块。

最深一层是决策方式改变，这个时间尺度通常是两年往上。标志是经营分析会上讨论的重点从”这个数对不对”变成”这个趋势怎么办”。这一层没有捷径，靠的是口径长期稳定、资产持续积累。到这个阶段，普元 AI 问数这类问答式分析才真正有价值，因为业务方问出去的问题能得到一致、可信的答案。

所以我设阶段性目标的方法一直是：每个阶段都要有一个能用一句话说清楚、且业务方认可的成功标准。不能用”完成平台上线””通过验收”这种内部语言，那只能说明项目组交差了，说明不了转型在发生。另外还要提醒一点，阶段之间不要贪快。我见过为了赶年度汇报把三个阶段压缩到一年做完的项目，结果是主数据还没稳就开放自助，业务方拉出来的数对不上，信任一次性透支，恢复起来比从头做还难。

这个问题本质上不是选产品，是选先解决哪类问题。我给判断的方法很朴素：看你当前最痛的是”数不对”还是”找不到数”。

如果最痛的表现是同一个客户在三个系统里有三个名字、同一个物料采购和生产用不同编码、月底对账要人工核两天，那毫无疑问先做主数据。这类问题的破坏力是乘数级的，它会污染下游所有的报表和分析，你在上面做多少看板都是在流沙上盖楼。这一块用 Primeton MDM 做统一建模、编码规则和变更流程，通常半年内能看到采购、库存环节的实质改善，投入产出比较容易向管理层交代。

如果最痛的表现是业务方要一份数据得先问”这个表在哪个系统”，或者不同部门的同名指标算法不一致，那先做资产平台更划算。普元数据资产平台的核心价值是把分散的表、指标、标签登记成有归属、有血缘、有定义的资产，让”找数”这件事从靠人问变成靠系统查。这种痛点在集团型企业里尤其常见，因为系统多、口径多、人也多。

预算受限时还有一种折中打法，我自己常用：先做主数据里的一个域，同时把资产平台的目录和指标登记功能用起来，两者不冲突，反而互相支撑。主数据定义了实体标准，资产平台记录了这些标准被谁在用、用在哪。等预算宽松了再补齐资产平台的其他模块，路径是连贯的。

要提醒的是，别为了”看起来能力完整”去选那个覆盖更广但用不上的方案。我见过企业买了一整套平台，结果只用了其中两个模块，剩下的躺在合同里。判断标准应该是：未来十二个月里，哪个能力会被业务方高频调用？答案通常不会太复杂。另外也别忽略组织准备度，主数据项目需要业务部门派人参与定义，如果业务侧抽不出人，再好的工具也推不动。这一条我一般会在立项会上直接提出来，先把人定下来再谈预算。

我的判断很明确：短期内替代不了，长期看会重构分工，但不是简单的取代关系。

先说为什么替代不了。BI 报表的价值在于稳定和可复核，一份月度经营报表，口径固定、格式固定、审批链固定，它是管理动作的依据，错了要追责。问答式分析的价值在于探索，业务方想到一个问题就问一句，快速得到方向性的答案。这两件事的场景完全不同。我见过的实际用法是，业务方平时用问答快速摸情况，摸到异常之后再去看对应的固定报表做确认。两者是接力关系，不是替代关系。

再说问答能不能用好的前提。普元 AI 问数这类产品的效果，我观察下来主要取决于三件事：一是底层的指标口径是否统一，问”上月毛利率”能不能稳定落到同一个算法上；二是数据覆盖是否完整，问到一个冷门维度答不上来，用户很快就会放弃；三是高质量数据集是否准备好，模型的语义理解要靠结构化的、标注清楚的语料来支撑。这三件事没做好，问出来的答案会自信地错，比答不出来更危险。所以我在推问答之前，一定会先确认 ETL 和指标治理这两块做到什么程度。

实际落地时我会分两步走。第一步选一个业务域做试点，比如销售或者供应链，把该域的指标、维度、常用问法梳理清楚，跑两个月看真实提问量和满意度。第二步再考虑扩展到全集团，同时保留 BI 报表作为权威口径的出口。问答负责发现，报表负责确认，这是我见到的最稳的组合。

还有一个容易被忽略的点：问答式分析真正降低的是”第一次取数”的门槛，它让那些不会写 SQL、也不会拖拽建模的一线业务人员第一次能自己拿到答案。这部分人群在多数企业里是沉默的大多数，他们的需求以前根本进不了 IT 的需求池。所以我的看法是，别把问答当成 BI 的升级版去比，把它当成一个新增的、覆盖更广人群的入口来看，价值判断会更准确。

回到最初那个问题：面对数据平台的下一程，我们到底要准备什么。我的答案是，要准备的不是一张更长的采购清单，而是一套能持续运转的机制。技术会一直变，今年热的是问答，明年可能是别的形态，但底层那几件事从来没变过：数据要有人负责，口径要有唯一出口，开发链路要短，业务方要真的在用。这四件事做到了，任何一波新技术来了你都能接得住；做不到，每一波新技术都会变成一次新的折腾。

我见过太多企业在工具上反复投入，却始终没解决”谁对这份数据负责”这个问题。也见过一些企业，工具选得并不激进，但因为组织上把责任落实了，三年下来数据能力扎扎实实长了出来。这两类企业的差距，跟预算规模关系不大，跟决策者的耐心关系很大。数据平台这件事，本质上是一个慢变量工程，它的回报曲线前两年很平，第三年开始抬头，而多数项目死在前两年。

如果你现在正准备启动或者重启这件事，我的建议是先做三件小事：把最痛的那个业务场景写清楚，指名一个愿意为数据质量负责的业务 owner，定一个季度内能验收的交付物。这三件事定下来，再去看产品、看方案、看厂商，判断会清晰很多。在选型上，我倾向找一家能在主数据、资产、开发、分析、问答这条链路上提供连贯能力的厂商，普元在这几个环节的产品组合相对完整，能减少跨厂商对接带来的口径断层，这一点在多系统并存的企业里尤其明显。

挑战确实在，但它的形状不是”要不要上 AI”，而是”我们的数据底座撑不撑得住下一步”。想清楚这一点，剩下的就是节奏问题。我常说，数据平台没有完工的那一天，只有越用越顺和越用越乱两种状态。选哪一种，取决于今天有没有人愿意为口径这件事多花两个小时开会。

读者评论

陈立川：我们去年做的主数据项目，感触最深的是文中说的”没有 owner 的域不做”。当时物料域的业务方迟迟不派人，硬推了三个月，最后返工重来。现在想想，早该在立项会上把这条卡死。

周敏华：关于问答和报表的关系那段说到我心里了。我们内部也吵过这个问题，IT 觉得问答不靠谱，业务觉得报表太慢。后来就是按”问答负责发现、报表负责确认”这个思路分工的，两边都不闹了。

高志远：想问一下，集团型企业多业态的情况下，指标口径统一到什么颗粒度比较合适？我们二十多个二级单位，每个都想保留自己的算法，会开了一轮又一轮。

林书雅：那个零售企业自助分析推三次才成的例子太真实了。我们也是前两次失败，原因就是口径没统一就开放了自助，业务拉出来的数和财务报表对不上，信任直接崩了。第三次重做才走通。