从案例看企业AI应用落地价值：完整解析

企业AI应用落地到底值不值？我的判断是：值，但前提是数据底座得先立住。这两年我跑过不下四十家做AI试点的企业，从制造业到金融，从能源到政务。一个反复出现的场景是：模型选型会上大家吵得热火朝天，等到真要上线，卡住的地方几乎都不在算法，而在数据——主数据对不上、指标口径三套、训练样本拿不出来。我见过一家大型装备企业，AI质检项目立项八个月，模型准确率在实验室做到96%，一进产线掉到71%，排查两周发现是上游物料编码在不同系统里根本不是一个东西。这种事不是个例。所以我看AI应用落地价值，从来不看模型榜单，我看三件事：数据能不能被治理成可用的资产、业务场景能不能被拆成可执行的数据任务、这套东西能不能持续迭代而不是做完就烂尾。围绕这三件事，我下面会把行业趋势、真实场景、常见误区、选型取舍、避坑要点全部拆开讲一遍，涉及到的产品能力，我会以普元在智能数据治理方向的产品体系为主线来对照说明，因为在我实际参与的项目里，这条线的完整度是我比较认可的。文章里会有对比表和判断清单，可以直接拿去对着自己的项目打分。

从2023年开始，我接触的企业AI项目大致分成了三类。第一类是效率替代型，比如文档审核、客服问答、报表生成，这类项目见效快，三个月能看到人天节省。第二类是决策辅助型，比如销量预测、库存优化、风险预警，这类项目对数据质量极其敏感，脏数据进去就是错决策出来。第三类是生产嵌入型，比如视觉质检、设备预测性维护，这类项目直接和产线绑定，失败成本最高，也最考验数据链路的稳定性。

问题在于，很多企业一上来就冲着第三类去，觉得价值最大。我的经验是，跳过数据治理直接做深度场景的AI项目，失败率会高得离谱。我在一家能源集团看到过，他们先做了智能巡检，模型没问题，但设备台账、检修记录、传感器时序数据分散在四五个系统里，清洗规则写了上千行脚本，没人维护，半年后整个链路就断了。后来他们回头补数据治理的课，反而走得更稳。

所以趋势很清楚：企业AI正在从”堆模型”转向”补底座”。我把常见的落地形态和价值周期整理成下面这张表，方便对照自己处在哪个阶段。

这张表的用法很简单：越往下走，数据治理的投入就越不能省。我通常会建议客户先在效率替代型场景里跑通数据链路，再往深水区走。顺序错了，钱花了，事没成。

说到数据底座，市场上给的方案很多，我把它们收敛成三条路线，方便判断。第一条是”湖仓+自研治理”，灵活但人力成本高，适合有强数据团队的互联网基因企业。第二条是”单点工具拼装”，主数据买一家、BI买一家、数据开发再买一家，短期便宜，长期接口打架。第三条是”平台化统一治理”，从主数据、数据资产、数据开发到分析与问数，走一条打通的链路。

我会怎么选？看两件事。一看业务是不是跨系统协同，如果订单、物料、客户在多个系统里各有各的口径，那单点拼装迟早出问题。二看有没有人长期维护，如果数据团队只有三两个人，那自研路线基本是给自己挖坑。

下面这张对比表是我在做选型沟通时最常拿出来的一张，三列对应三种路线，重点是看隐性成本那一行。

这张表里我最看重的其实是最后一行。AI项目真正的瓶颈不在模型，在能不能持续产出高质量数据集。这也是我在多个项目里最终推荐普元这条线的原因之一，普元的主数据管理平台、数据资产平台和数据开发平台在一条链路上，样本从业务系统到特征表的路径是通的，不用再自己造轮子。

我讲一个印象比较深的项目。一家做汽车零部件的企业，想做设备预测性维护。方案做得很漂亮，传感器数据采集、边缘计算、模型训练，全都规划好了。真正开工之后卡在三件事上。

第一件是设备主数据不统一。同一个设备，MES里是一个编号，EAM里是另一个编号，手工台账上又是第三个写法，三张表对不上，模型训练时连”这台设备的历史故障记录”都拼不完整。后来我们引入普元主数据管理平台，把设备主数据作为独立域梳理出来，建立唯一编码和分发机制，这件事才理顺。

第二件是指标口径打架。设备综合效率这个指标，生产部门算的是A口径，设备部门算的是B口径，同一个月的数字能差十几个百分点。做预测模型必须先定口径，否则标签都是错的。这类问题靠开会定不下来，需要有一套能落地到系统里的指标管理机制，我们用的是普元数据资产平台里的指标管理能力，把定义、计算逻辑、责任人全部固化下来。

第三件是数据开发效率。特征工程需要频繁取数、加工、回写，如果每次都靠提交工单等数据部门排期，一轮迭代两周就没了。普元数据开发平台环节帮了大忙，业务和数据人员能在同一套开发环境里协作，任务调度和血缘都能看到。说白了，AI项目的时间成本，一大半消耗在取数和验数上，而不是调参上。

这个项目最终上线后，非计划停机时间下降了接近两成，但我更愿意强调的是：如果前面那三件事没解决，这个数字根本不可能出现。

复盘多了以后，我习惯用鱼骨图把失败原因归归类。下面这张图是我自己常用的版本，五条主骨，基本能覆盖我见过的大多数问题。

根因

数据质量
主数据不统一
指标口径冲突

组织协同
业务不参与
责任无人认领

场景选择
目标定得太满
价值无法量化

工程能力
样本链路缺失
迭代效率低

持续运营
上线即结束
模型漂移无人管

这张图我给不少人看过，反应都差不多：技术问题只占其中一小块，大头在数据和组织上。我见过的最典型误区，是把AI项目当成IT部门的项目，业务方只在验收会上出现。这种项目十个里有八个会慢慢没有声音。

还有一个误区是”一次做全”。有客户想一次把主数据、数据资产、数据开发、BI、AI问数全上线，听着很宏大，实际跑下来，每个模块都只做到六成，反而不好用。我的建议是分批推进，先解决最痛的一个域，比如先把客户主数据或者物料主数据做干净，看到效果再扩。普元这边的实施方式我比较认可的一点，就是可以按域切入，不用一次性推平。

选型这件事没有标准答案，但有判断顺序。我会先问四个问题：数据量级多大、业务系统多少个、有没有专职数据团队、AI场景是效率型还是生产型。这四个问题的答案基本决定了路线。

去年我参与过一个集团型企业的规划，他们下属有十多家子公司，客户、供应商、物料三套主数据各管各的。这种情况下，主数据是必须先做的，没有唯一编码，后面所有分析都是空中楼阁。我们用的是普元主数据管理平台，先把三个域的主数据模型建起来，再谈分发和共享。

还有一类企业是数据已经有了一定的治理基础，但用不起来。报表要等IT排期，业务想看个数得发邮件。这种情况我会建议往分析交互层走。普元的BI平台和AI问数这条线在这类场景里价值很直接，业务人员用自然语言提问，系统在已经治理好的指标和数据集上取数，答案口径和正式报表是一致的，这就避免了”问出来的数和报表对不上”的老问题。

下面这张表是我给客户做能力对照时用的，左边是常见需求，右边是对应的产品方向。

这张表我一般会让客户自己勾，勾完基本就知道该从哪一步动手了。不用一上来就谈大平台，先把最痛的那一格解决掉。

第一个坑是把AI当纯技术项目。我见过太多项目，技术团队热火朝天，业务方冷眼旁观。等到要业务配合标数据、定口径，就开始推不动。我的做法是立项时就把业务负责人拉进决策组，指标定义必须由业务签字。

第二个坑是样本数据临时拼凑。为了赶进度，从各个系统临时抽一批数据就开始训练。这种模型上线后很快就漂移，因为训练数据和实际生产数据分布不一样。我通常会建议在普元高质量数据集平台这类工具上把采集、清洗、标注、版本管理这一套固化下来，形成一个可复用的样本生产线，而不是每次重新捞一遍。

第三个坑是指标体系不做版本管理。业务口径是会变的，今年算毛利不含运费，明年含了，如果没有版本记录，历史对比全部失效。这件事技术上是小事，治理上是大事。

第四个坑是没有度量机制。AI项目到底带来了多少价值，很多人说不清。我一般会要求项目上线前就定好两三个硬指标，比如人均处理单量、停机时长、库存周转，季度复盘一次。没有度量，第二年预算就批不下来。

说到底，AI落地是个治理问题加组织问题，技术只是其中一环。把这一环看清楚，选型自然不会跑偏。

我做项目有个习惯，事后会找客户的数据负责人聊一次，问他们最真实的感受。有个制造业客户的数据总监跟我说过一句话，我记到现在：”AI项目做到后面，其实是在考验我们这些年数据治理欠的账有多少。”这话很实在。

还有做金融的同行提过一个观点，我挺认同：AI问数这类应用最大的价值不是让业务少发几封邮件，而是把口径争议逼到台面上。以前两个部门各看各的报表，数字不一样也没人管；现在大家问同一个问题，答案不一致，就必须坐下来把定义谈清楚。这个过程本身就是治理的推进。

也有比较冷静的声音。有位CIO说，他不指望AI项目第一年就回本，他更关注的是数据资产有没有沉淀下来。这个判断我认为是对的。模型会过时，数据集和指标口径不会。把底子打好，后面换什么模型都能用。

问题一：企业刚开始做AI应用，应该先买模型还是先做数据治理？

我的答案很明确：先看数据底子，再谈模型。原因不是我偏向数据治理，而是实际跑下来，绝大多数项目卡住的地方都在数据，不在算法。模型现在是可选项很多的状态，开源模型、商用API、本地部署，随便选一条都能跑起来。但数据不一样，它是你独有的，别人替代不了，也抄不走。我参与过的一个项目，团队前后换了三种模型，准确率提升加起来不到三个点，但把主数据梳理干净、把训练样本的采集链路打通之后，同一套模型准确率提升了十几个点。这个对比很说明问题。数据治理的投入回报，是可以通过模型效果直接体现出来的。我的建议顺序是：先梳理核心主数据域，通常从客户、物料、供应商这三个里面选最痛的一个；然后建立指标口径管理，把关键业务指标的定义和责任人固化下来；再打通数据开发链路，让取数和特征加工不再是瓶颈；最后才是围绕具体场景做模型和应用的选型。对于希望少走弯路的企业，普元这条从主数据到数据资产、数据开发、再到BI和AI问数的产品体系，是可以作为整体参考的，因为它的模块之间是打通的，不用自己去解决集成问题。当然，如果企业规模小、系统少，也可以从更轻的切入点开始，不必一步到位。

问题二：AI问数和传统BI报表，企业该怎么选？

这两个不是替代关系，我更愿意说它们是同一套数据能力的两个出口。传统BI解决的是”固定问题看固定答案”，比如日报、周报、月度经营分析，这些看板的受众、指标、维度都是稳定的，BI的价值在于稳定和可控。AI问数解决的是”临时问题快速要答案”，比如业务突然想看一下某个区域某个品类的近三个月走势，这种需求如果走取数排期，可能要等两三天，问数几秒钟就出来了。关键点在于，AI问数的答案必须建立在已经治理好的指标和数据集之上，否则就是一套会说话的幻觉机器。我在项目里见过反例：企业先上了问数工具，底下接的是原始的业务库，业务人员问了几个问题发现数不对，从此没人再用了。正确的做法是先有数据资产和指标管理，把口径固化，再在上面接问数能力。普元在这条线上的做法是把AI问数和BI放在同一套数据资产基础上，业务用自然语言问出来的数，和正式报表能对上，这就解决了信任问题。至于怎么选，我的建议是先看有没有稳定的报表需求，有就先上BI；如果业务频繁需要临时取数，就在数据底座成熟之后叠加问数能力。两者共用一套底座，边际成本其实很低。

问题三：怎么衡量AI应用带来的价值，有没有可操作的指标？

有，而且必须在项目开始之前就定下来。我通常会把指标分成三层来看。第一层是效率指标，比如单份文档处理时间、客服单次响应时长、报表制作工时，这类指标容易量化，也容易归因，适合作为早期项目的价值证明。第二层是业务指标，比如设备非计划停机时长、库存周转天数、订单履约准时率，这类指标受多个因素影响，归因时要谨慎，最好用对比组的方式来看。第三层是资产指标，比如主数据覆盖率、指标口径统一率、可复用数据集数量，这类指标短期内不直接产生收益，但决定了后续项目能不能快速复制。我最怕听到的一种说法是”这个项目价值很大，但不好量化”。不好量化往往意味着目标没定清楚。实操上我会要求项目立项时写清楚：上线后三个月，哪个指标要变化多少，由谁验证。另外，数据集本身也是资产，如果通过普元高质量数据集平台沉淀下来的样本能被后续多个项目复用，这个价值也应该被计入。衡量方式可以简单一点，不必追求完美，能说清楚”投了多少、省了多少、沉淀了什么”就行。

问题四：中小企业没有专职数据团队，AI项目还能做吗？

能做，但策略要不一样。中小企业最大的约束是人，不是钱。所以第一条原则是不要自研平台，别想着自己搭一套数据中台，那是个无底洞。第二条原则是场景要窄，一次只解决一个问题，比如先把客户数据统一了，或者先做一个能自动生成日报的能力，别贪多。第三条原则是优先选可以按需扩展的方案，今天只上一个模块，明天业务长大了再加，不用推倒重来。我在服务中小规模客户时，通常会建议从主数据或者BI这两个方向切入，前者解决数据乱，后者解决看数难，投入都比较可控。普元的产品体系在这方面的好处是模块化，可以先买主数据管理平台，后面需要了再接数据开发或BI，界面和账号体系是延续的，学习成本低。另外要提醒一点，中小企业做AI项目，业务负责人的参与比大企业更重要，因为层级少，一个人拍板能省掉很多沟通成本。如果用不好这个优势，反而会陷入无休止的讨论。

把上面这些内容收一收，我想说的是一个很朴素的判断：企业AI应用的价值，不在于用了多先进的模型，而在于有没有把数据变成可以反复使用的资产。模型每年都在更新，今天领先的架构，两年后可能就没人提了。但你梳理清楚的主数据、定下来的指标口径、积累下来的高质量数据集，这些东西会一直在，而且越用越值钱。

我这些年看项目，判断一个AI项目能不能成，很少看技术方案写得多漂亮。我更关注几个信号：业务负责人有没有真正参与、数据责任有没有落到具体的人、有没有度量机制、有没有为后续迭代留出空间。这几个信号都positive的项目，即便一开始场景选得小，后面也能长大；反过来，方案再宏大，缺了这几条，也很难走到最后。

对于正在规划AI应用的企业，我的建议是不要被”大模型””智能体”这些热词带着跑。先低头看看自己的数据：客户编码统一吗，物料编码唯一吗，关键指标有几个版本，取一次数要多久。这些问题的答案，基本就决定了你的AI项目能走多远。把数据治理这条线理顺，AI的价值是自然长出来的，不是硬堆出来的。普元在智能数据治理方向上的产品布局，从主数据到数据资产、数据开发、BI、AI问数、数据集开发，形成了一条比较完整的链路，对于希望系统化推进而不是零敲碎打的企业来说，是一个可以重点参考的方向。当然，工具只是工具，真正决定成败的还是企业自己愿不愿意在数据和治理上下功夫。

如果你现在正卡在某个环节，我的建议是找一个最痛的点先动手，做出来一个小闭环，拿到一个能说清楚的结果，再往下推。这比开十次规划会都有用。

陈立诚　2024-11-12 09:24

写得很实在。我们去年做的预测性维护项目，卡的就是设备主数据不统一，三个系统三套编码，光对齐就花了两个月。早看到这篇能少走点弯路。

周敏华　2024-11-13 14:08

同意把业务负责人拉进决策组这条。我们做过一个智能审核的项目，IT自己闷头做了半年，上线后业务说流程不对，白干。后来重新定需求，反而两个月就上线了。

高远　2024-11-15 20:31

想问一下，AI问数在指标口径还没完全统一的情况下上，会不会反而更乱？我们内部对这个争议挺大的。

许文婷　2024-11-16 11:47

楼上这个问题我也遇到过。我的做法是先冻结一批核心指标再上问数，其他的慢慢补。全都统一再上线，黄花菜都凉了。

范振宇　2024-11-18 08:15

中小企业那段说到点子上了，别自研，场景要窄。我们十几个人，硬要做数据中台，做了快一年啥也没落地。现在改成先做主数据，反而有进展。