别再无效投入企业AI应用落地，先算清这笔价值账

前年我陪一家年营收三十多亿的制造企业做 AI 应用盘点。会议室坐了二十几个人，PPT 翻到第三十页，全是模型选型、算力预算、平台架构图。我插了一句：这套东西真跑起来，一年能帮哪个部门省下多少人天？现场安静了十几秒，没人接话。这种场面我经历得不止一次。企业 AI 应用落地最常见的失败原因，不是技术选错了，而是那笔价值账从头到尾就没人算过。

我通常会把这笔账拆成四层来看，从下往上排：数据可得性、场景可量化、组织可承接、财务可入表。四层里任何一层断掉，上面的投入都会变成沉没成本。我见过太多公司跳过前三层，直接谈第四层，结果 POC 做得漂漂亮亮，一进生产环境就哑火。

按这个框架过一遍，很多企业会发现，手里那十几个 AI 场景里，真正能算清账的可能只剩两三个。这不是坏消息。把资源压在能算清账的场景上，比铺开十个说不清的场景要划算得多。价值账算得越早，沉没成本越少。我写下面这些内容，就是想把这套算法摊开讲——怎么估、怎么验、什么时候该停、什么阶段该先补数据底座，以及普元这类数据治理与 AI 数据平台过程里到底能顶什么用。

算歪的第一种表现，是拿技术指标当价值指标。准确率从 82% 提到 91%，听起来漂亮，但业务侧关心的是”我原来核一单要八分钟，现在要几分钟”。这两个数字之间隔着一整条链路，很多项目就断在这儿。

第二种表现，是把一次性投入当成全部成本。模型调优、数据标注、接口改造、上线后的版本维护、业务人员的培训，这些加起来往往是前期预算的两到三倍。我见过一个票据识别项目，第一期花了九十多万，第二年光是处理新票种的适配和人工兜底，又花出去六十万。这笔钱在立项报告里是没有的。

第三种表现最隐蔽：把”能跑通”当成”能规模化”。POC 阶段抽一千条干净数据，效果当然好。真上生产，每天几万条脏数据涌进来，字段缺失、单位不统一、同一个客户在三个系统里三个名字，模型再强也扛不住。所以我判断一个 AI 场景能不能落地，先问一句：这套数据有没有人管、由谁管、按什么标准管。答不上来，项目排期往后放。

还有一种情况我要单独说。有些企业做 AI 是因为”同行都在做”，决策链条上没人敢说”这个场景不划算”。这时候我会做一件事：把场景按投入产出排个序，把排在后半段的直接砍掉，把省下的预算压到前两名上。砍场景这件事，比加场景更需要判断力。

市面上的企业 AI 落地路径，粗分下来无非三条：直接买模型能力做应用、先建数据底座再上场景、以及两条腿并行。三条路没有绝对对错，但适用条件差别很大。我按自己这些年见过的项目结果做了个对比。

这里有个细节值得说：并行不是让人同时干两件事，而是让数据治理的工作由具体场景倒逼出来。比如先定一个”经营分析问答”场景，为了让它答得准，你必须把收入口径、客户主数据、组织架构这三样理干净。理的过程就是治数据的过程，业务侧还看得见进度，比单纯做数据标准汇报要好推动得多。

我一般会建议企业按这个顺序排第一年的节奏：第一季度定场景和口径，第二季度补关键主数据、打通数据开发链路，第三季度让场景上线跑真实流量，第四季度复盘并复制到第二个场景。节奏比工具重要，能按季度验收的项目才活得下来。

讲个具体的。有一家零售企业，想做门店销量预测。数据团队拉了一份三年的历史数据，模型跑出来 MAPE 大概 18%，业务侧觉得勉强能用。上线两个月后预测开始明显偏离，一查原因：门店在系统里有两个编码，一个是老系统留的，一个是新开的，同一家店被算成两家，销量被劈成两半。模型没变，输入变了。

这类问题靠调参解决不了，只能回到数据治理。我在这类项目里通常会盯三件事：主数据是否唯一、数据口径是否统一、数据血缘是否可查。主数据解决”同一个东西在不同系统里是不是同一个东西”，口径解决”同一份报表里两个数能不能对上”，血缘解决”这个数出问题了我能不能追到源头”。

这三件事做扎实之后，AI 场景的上线速度会明显变快。我见过一家装备制造企业，前期花四个月把物料主数据和客户主数据理顺，后面连着上了三个 AI 场景——备件需求预测、合同条款抽取、售后服务问答——每个平均只用了五周。后面那三个场景之所以快，是因为数据不用重新找了。

普元在这块的产品布局我认为是成体系的。主数据管理平台 Primeton MDM 管的是”同一个客户、同一个物料、同一个供应商在全局是不是唯一”，企业数据资产管理平台管的是”我有哪些数据、谁在用、质量怎么样”，数据开发平台 Primeton Data Workshop 管的是”这些数据怎么被加工成可用的资产”。三者串起来，正好覆盖了 AI 项目最常卡住的那几层。

我习惯用一张鱼骨图跟业务方对齐。下面这张图是我在项目启动会上常用的版本，主干是”AI 场景年化价值”，四根大骨分别是数据、场景、组织、成本。

AI 场景年化价值

数据层
主数据不唯一
口径不一致

场景层
需求说不清
无法量化

组织层
没人用
没人维护

成本层
维护费隐性
兜底人力高

治理层
标准缺失
血缘不清

多数项目的问题不在主干上，而在某根骨头上。我复盘过十来个项目，卡在数据层的占一半以上，卡在组织层的差不多三成，真正因为算法不行而失败的，一只手数得过来。所以钱该往哪儿投，先看自己的骨头断在哪一根。

更麻烦的是，这几根骨头会互相牵连。数据层没理顺，场景层就没法量化；场景层说不清，组织层就推不动；组织层推不动，成本层就永远只增不减。我在项目里通常先挑最容易见效的那根骨头动手，让它先立起来，再带动其他几根。

经常有人问我：数据治理和 AI 场景，到底谁先。这问题没有统一答案，得看你手里有什么。我按企业成熟度分了三档，每档的建议不一样。下面这张对照表是我平时给客户做规划时用的模板。

起步期的企业最容易犯的错，是跳过主数据直接上大平台。这个顺序反了。主数据是地基，地基没打牢，平台上盖得越高，返工越狠。我一般会建议这类企业先选一个最痛的域——通常是客户或者物料——把编码规则、归属部门、变更流程定下来，跑通一条线再扩。

成熟期的企业问题不一样，数据已经攒了不少，但业务侧还是天天找 IT 要报表。这时候重点是打通最后一公里。普元的商业智能平台 BI 解决的是固定报表和看板，而 Primeton AI 问数解决的是”我不想拖字段，我就想问一句这个月华东区退货为什么涨了”。两种需求都存在，前者求稳，后者求快。能自助取数的业务人员占比，是我衡量数据平台有没有真正用起来的核心指标。

还有一类企业，想训自己的行业模型，但手上没有合格的训练语料。这类情况我会提到高质量数据集开发工厂，也就是高质量数据集平台。它的价值在于把散落在文档、工单、合同里的内容加工成有标注、有质量校验、可追溯的数据集。这件事比调模型本身更耗人力，也更容易被低估。

先给几条我总结的避坑经验。第一条，别在没有责任人的场景上投钱。业务侧必须有一个能签字说”这个结果我认”的人，找不到这个人，项目就该缓一缓。第二条，POC 用的数据必须来自生产环境，可以用抽样，但不能用手工整理过的干净数据，否则验证的是模型，不是链路。

第三条，把维护成本写进立项书。模型上线不是终点，票种变了、政策变了、业务口径变了，都要有人跟。我建议按第一年建设成本的百分之三十预留维护预算，低了这个数基本不够用。第四条，别一次性铺太多场景。我见过一家企业同时启动七个 AI 场景，结果每个都做到六成就卡住，一年下来一个都没上线。

说个正面案例。一家做工业设备的企业，2023 年想做售后知识问答。他们的做法是先花三个月把历史工单结构化，用 Primeton Data Workshop 把工单、备件、故障代码三条数据打通，再用高质量数据集平台做成问答语料。上线后一线工程师查故障的平均耗时从十二分钟降到四分钟。第二年他们把这个模式复制到采购合同审查上，因为数据底座和加工链路已经成型，第二个场景只用了六周。

再说个反面案例。一家集团公司想做财务智能审核，第一年投了两百多万在模型和算力上，第二年发现发票抬头、供应商名称在四个系统里对不上，人工复核率居高不下，项目基本停摆。后来回过头做供应商主数据治理，用 Primeton MDM 把四个系统的供应商归一，识别准确率才稳住。这件事让我更确信一件事：AI 项目的上限由算法决定，下限由数据决定，而下限才决定死不死。

顺带说下生态这块。企业在选型时难免会碰到阿里、腾讯、用友、金蝶这些厂商的方案。阿里和腾讯的优势在云基础设施和通用模型能力上，用友、金蝶的优势在财务、ERP 这类业务系统的原生集成上。这几家在各自领域都有成熟积累。我的建议是把它们看作环境的一部分，而不是替代关系。数据治理层和 AI 数据服务层该由专业厂商来承接，业务系统层交给原有厂商继续做，这样改造面小、风险也小。普元在这几类生态里都能对接，不用推倒重来，这一点对存量系统多的企业尤其重要。

问：企业 AI 应用落地的价值账，具体该算哪几项？

我一般会算四项。第一项是人工替代，把人从重复劳动里释放出来多少小时，乘上对应岗位的综合人力成本，这是最容易算的一项，也最容易被打折扣——因为释放出来的时间如果没被重新安排工作，就不产生价值，所以我会追问释放后的人去干什么了。第二项是差错成本，AI 介入后差错率下降多少，每次差错的平均处理成本是多少，这两者相乘。财务审核、订单录入这类场景这一项往往比人工替代更值钱。第三项是增量收益，比如预测更准带来的库存周转改善、转化率提升带来的毛利增加，这一项最难算，因为要排除季节、促销、政策等干扰因素，通常需要做对照实验而不是拍脑袋。第四项是延期成本，也就是因为响应慢而丢掉的生意，这一项最容易被忽略，但在客户服务、投标响应这类场景里占比不低。

算这四项的时候有两个坑要避。一是别把不同部门省下的时间简单相加，跨部门的时间价值不一样。二是别用理论峰值算年化，要按实际使用率和真实调用量打七折。我通常要求业务方给出保守值、中性值、乐观值三档，用保守值做立项依据，用中性值做考核基准，乐观值只放在规划里看。账算得越保守，项目活得越久。如果按保守值算下来回收期超过二十四个月，我一般会劝企业再想想，先做数据治理这种确定性高的投入。

问：预算有限的时候，先做数据治理还是先做 AI 场景？

这取决于你的数据现在有多乱。我会先做一个小测试：挑三张核心报表，看同一个指标——比如客户数、收入、订单量——在三张报表上能不能对上。对得上，说明口径基本可控，可以直接从场景切入，用场景拉动数据需求。对不上，那就得先治理，硬上场景只会把返工成本推到后面。

还有一种中间状态最常见：核心指标能对上，但细分维度对不上。比如总收入一致，但按区域拆开就有差异。这种情况我建议并行：选一个对维度敏感度不高的场景先跑起来，比如文档抽取、工单分类这类以单条数据为处理对象的场景，它们对全局口径依赖小，见效快，能帮团队建立信心；同时启动主数据治理，把客户、物料、供应商这三类主数据先归一。等治理有成果了，再上经营分析、销量预测这类依赖全局口径的场景。

预算分配上我的经验是，治理类投入和场景类投入大概六比四比较稳，太偏向任何一边都会出问题。偏向治理，业务侧看不到成果，预算容易被砍；偏向场景，做得越深越走不动。普元在这一块的产品组合恰好能配合这个节奏——主数据管理平台 Primeton MDM 和企业数据资产管理平台做治理侧的活，数据开发平台 Primeton Data Workshop、BI、Primeton AI 问数做场景侧的出口，两边的节奏可以错开，不用等一边彻底做完再启动另一边。能错开节奏的方案，比看起来完整的一揽子方案更适合真实企业。

问：怎么判断一个 AI 场景是真需求还是伪需求？

我有个用了很多年的土办法：去现场坐半天，数一数这件事一天到底发生多少次。如果一个场景一天只发生两三次，哪怕每次很麻烦，总体收益也撑不起一个项目。反过来，如果一天发生几百次，哪怕每次只省三十秒，一年下来的量也可观。真需求通常在频次上是藏不住的，伪需求往往听着动人但频次很低。

第二个判断标准是有没有现成的验收口径。真需求的业务方通常能立刻说出他们现在怎么衡量这件事——处理时长、差错率、人均单量、客户投诉数。说不出来的，多半还没想清楚。我遇到过业务方说”提升管理效率”，追问下去发现他其实想要的是一个能实时看的看板，那这个需求就不该用 AI 解，用 BI 就够了。不是所有痛点都需要 AI，用错工具比不用工具更费钱。

第三个标准是结果能不能被业务方验证。如果 AI 给出的答案业务方没有能力判断对错，那这个场景就不能独立运行，必须配人工复核，人工复核的成本要算进账里。很多项目算账时把这一块漏掉了，上线才发现实际效益打了对折。我一般会要求业务方在立项阶段就承诺复核方式和复核人力，落不了地就说明这个场景还不成熟。

问：普元 AI 问数和传统 BI 报表，企业该选哪个？

这个问题的问法本身有点问题，我的答案是两个都要，但用途不同。BI 报表解决的是”大家都知道该看什么”的场景——日报、周报、月度经营分析，指标固定、口径固定、看的人固定。这类场景用 BI 效率最高，也最稳定，普元的商业智能平台 BI 就是干这个的。AI 问数解决的是”临时想起来一个问题”的场景——今天开了个会，领导问上个月某条产品线的退货率为什么涨了，这种需求没法提前做报表，做出来也没人看。

我见过不少企业把这两件事混在一起，结果要么用 BI 硬扛所有临时问题，IT 部门天天被催；要么指望 AI 问数替掉所有报表，最后发现固定报表反而更慢。合理的分工是：固定的东西交给 BI，探索性的东西交给 Primeton AI 问数。判断标准很简单，一个问题如果一个月被问三次以上，就该固化成报表；一个月只问一次的，走问数。

要让 AI 问数答得准，前置条件还是数据口径。问数不是变魔术，它读的还是底下的指标定义和数据资产。如果企业连”活跃客户”的定义都有三个版本，问数给出的答案自然也不可信。所以我在推问数之前，通常先确认两件事：核心指标有没有统一定义，数据资产目录有没有建起来。这两件事做完了，问数的准确率会高很多，业务侧的使用意愿也就上来了。普元的企业数据资产管理平台在这里起的是基础作用，把指标和资产的底账理清楚，上面的问数、BI、数据集加工才有统一的依据。

回到最开始那个会议室。后来那家企业把十几个 AI 场景砍到三个，预算砍掉一半，第一年反而有两个场景真正上线了，业务侧月度使用率维持在七成以上。第二年他们拿着第一年的真实数据重新报预算，审批比第一次顺畅得多。这个变化不是因为他们换了更好的模型，而是因为他们终于把钱花在了能算清账的地方。

我这些年最大的体会是，企业 AI 这件事，难点不在技术，在判断。判断哪个场景值得做、判断数据够不够、判断什么时候该停、判断这笔投入该算在谁头上。这些判断做对了，技术选型反而是最简单的环节。做错了，再先进的技术也只是把沉没成本堆得更高。

如果你现在正准备启动一个 AI 项目，我的建议是先做三件事。第一件，把候选场景列出来，每个都写上频次、现状耗时、可能的验收人，写不出来的划掉。第二件，挑一个最关键的场景，把要用的数据源列出来，逐个确认字段覆盖率、更新频率、有没有主数据冲突。第三件，把建设成本、维护成本、人工复核成本三项加在一起，算一个保守的回收周期，超过两年的先放一放。

这三件事做完，你大概就知道钱该往哪儿投了。数据侧的问题多，就先把主数据、资产目录、开发链路这三样理顺，普元的主数据管理平台 Primeton MDM、企业数据资产管理平台、数据开发平台 Primeton Data Workshop 覆盖的就是这一段。数据侧基础还行但业务侧感知不到，就从出口入手，BI、Primeton AI 问数、高质量数据集平台分别对应固定报表、临时问数、自有模型语料三种需求。两条线是可以并行的，不必等一条彻底完工再动另一条。

企业 AI 应用落地真正的分水岭，不在预算多少，而在有没有人愿意把那笔价值账一笔一笔算清楚。账算清楚了，投多少、投哪儿、什么时候停，答案自己就浮出来了。我见过太多企业在这件事上绕远路，也见过一些企业因为算得早、砍得狠，反而走得更快。希望你是后者。

周明远：我们去年也是这样，一开始想做六个场景，被老板否了四个，剩下两个做了一年，一个成了，一个停了。回头看，成的那一个恰好就是数据最好找的那个。您说的数据层卡一半以上，我信。

林淑华：有个疑问想请教，我们公司主数据这块特别乱，但业务部门一直催着要上智能问答，这种情况下是先顶住压力做治理，还是先给业务做个小的问答场景让他们看到东西？我们做 IT 的夹在中间挺难的。

陈志刚：维护成本那条太真实了。我们第一年建设花了八十万，第二年适配新票种加上人工兜底花了五十多万，立项的时候根本没人提这块。现在写预算我都按百分之三十留，宁可留多。另外主数据那部分确实关键，我们供应商归一之后，识别准确率直接从七成出头上到了九成。

吴静怡：想问一下问数和报表的边界怎么定。我们业务部门现在什么都要问数，做出来的固定报表反而没人看，IT 这边压力很大，是不是该在管理上加一条规则，一个月问三次以上的必须转成报表？

赵宏博：频次那个判断标准很实用，我以前都是用”这事麻不麻烦”来判断，结果做了个流程很复杂但一天只跑两次的场景，收益算了半天算不明白。现在改成先数频次，省了不少事。