企业AI应用落地实施落地全流程：3个阶段一次讲清

我做企业数字化咨询这些年，翻过上百份 AI 项目立项书，也进过不少项目现场。一个让我印象很深的数字是：演示阶段人人叫好的系统，半年后日活能剩下两成的不到一半。很多人把锅甩给模型不够聪明，我的观察恰好反过来。模型这层早就不是瓶颈了，能花钱买到的东西都构不成优势。

真正决定成败的是三段路：把场景和数据准备好，把工程链路搭扎实，再用运营把效果一点点磨出来。我把它们叫做场景与数据准备、工程化建设、运营与规模化。这三段不是瀑布式排队，中间有大量交叠，但每一段都不能跳过。跳过第一段，你会拿到一个答非所问的模型；跳过第二段，你会得到一个只能演示不能上线的玩具；跳过第三段，你会得到一个上线即退休的资产。

我见过最典型的一次失败，是某家制造企业花了四个月训练排产预测模型，准确率做到 91%，业务部门却坚持用 Excel。原因不复杂：模型给的是建议，没人告诉计划员这个建议出错时该找谁。技术上的活儿全干完了，契约没建立起来。所以我在给企业做规划时，习惯先把三阶段的交付物和验收标准写清楚，再谈工具选型。

这两年我接触的企业，起手方式基本落在三类。一类直接买大模型接口做套壳，两周出 Demo，看着很快；一类先把数据治理做厚，建标准、建主数据、建资产目录，稳但慢；还有一类从一个具体痛点切入，边做边补数据底座。哪类活得久？我的答案很明确：第三种在多数中型企业里胜率最高，但它需要一个前提——数据侧不能等到用的时候才去补。

套壳型项目的典型结局是：业务问了一个跨系统的口径问题，模型把两个系统的数据混着答，答错了还不知道错在哪。用不了几次，业务就不信任了。治理先行型的问题在于周期太长，一年半载看不到东西，预算容易被砍。场景切入型的好处是每一次交付都能被业务感知，坏处是如果数据没提前收拾，做到第三个场景就会被脏数据拖住。

所以我在做方案时会提一个折中的路子：用一到两个高价值场景牵引，同时把数据底座按平台化方式同步搭起来。场景给项目提供活下去的理由，底座给后续复制提供可能。这条路上，普元这类既有数据治理能力、又能往上接 AI 分析能力的厂商，配合起来会顺一些，因为不用在两个体系之间来回搬数据。

第一个误区是把 AI 当成纯 IT 项目立项。IT 部门自己把需求写了，业务只负责验收，结果做出来的东西业务觉得不顺手，用两天就丢。我会要求每个场景必须有业务方的 owner，而且这个人要有权力改流程，不是挂名。

第二个误区是场景贪大。有企业一上来就想做”全域智能决策大脑”，我听完就知道这个项目活不过半年。场景要小到可以在一到两个月内被验证，大到能让老板看见价值，这个区间其实很窄。

第三个误区是不做数据质量评估就开训。我见过拿三年没清理的客户主数据去做客户流失预测，模型学到的全是重复记录。这个坑踩一次，返工成本是前期投入的两三倍。

第四个误区是只关注准确率，不管采纳率。模型说对了但业务不看，等于零。我会把”建议被采纳的比例”和”用户主动调用次数”放进验收指标里。

第五个误区是把上线当交付。上线那天只是开始，前面两个月的调优工作量和开发阶段差不多。这个预期如果没提前跟老板对齐，团队会被追着问为什么没效果。

我习惯用一张鱼骨图跟客户对齐问题。主干是落地效果，往上三条是偏”人和定义”的因素，往下三条是偏”工具和机制”的因素。这么摆的好处是，讨论的时候不会只在技术层打转——多数失败项目的病灶其实在上面那三条。

数据质量与口径排在最前面，因为它是所有下游的前提。主数据不一致，后面所有的分析和问答都是在沙子上盖楼。场景边界定义这条，说白了就是能不能用一句话讲清楚”这个系统回答哪类问题、不回答哪类问题”。组织与责任人这条最容易被忽略，但一个没有业务 owner 的 AI 场景，几乎注定会变成 IT 部门的自娱自乐。

下面三条里，数据开发链路决定迭代速度，效果评测体系决定你能不能发现问题，运营节奏决定半年后它还在不在。这三条是工程团队的主战场，也是普元 Data Workshop、BI 这类工具能真正发挥价值的地方。

落地效果

数据质量与口径
场景边界定义
组织与责任人
数据开发链路
效果评测体系
运营迭代节奏

主数据、标准、质量规则
一个问题对应一个场景
业务方要有 owner
管道、权限、审计留痕
准确率与采纳率并看
按月复盘、按季扩场景

起点
业务价值

选型这件事，我的原则是”能力跟着阶段走”，不要一上来就买一整套。阶段一最需要的是把数据收拾干净的能力，主数据和资产目录是重点；阶段二要的是开发效率和权限视野；阶段三考验的是让业务自己用得起来的能力，交互层越简单越好。

以普元的产品线为例，阶段一可以用 Primeton MDM 收敛主数据、用普元数据资产平台把家底盘清楚，再用高质量数据集平台把可训练、可评测的数据集固化下来，这一步做扎实，后面会省很多反复。阶段二交给 Primeton Data Workshop 做数据管道开发，BI 承接可视化与指标管理，两边的血缘和口径能对上。阶段三我会推荐 Primeton AI 问数，让业务用自然语言问数，能让业务自己查出答案的系统，才不会被丢在一边。

要注意的是，BI 和 AI 问数不是替代关系。固定的经营看板该用 BI，临时性的、口径多变的探索性问题交给问数更合适。我在项目里通常是让两者共用同一套指标口径，避免出现同一个数字两个答案的尴尬。

五百人以下的企业，我的建议是彻底放弃”先建平台”的念头。资源不够，平台建到一半就停更了。这种规模就抓两件事：把最核心的一两张主数据表整理干净，选一个业务每天都在问的问题做成问答式分析。普元 AI 问数这类产品在轻量场景下上手比较快，能让他们在一个月内看到东西。

千人级企业是三道都要走，但节奏可以错开。阶段一和阶段二的部分工作并行，比如数据资产盘点和数据开发流水线可以同步推进，前提是接口约定先谈好。这个规模最容易犯的错是两地开花，两边都做不深。

集团型企业反而要先立标准再动手。多法人、多系统、多口径是常态，没有统一的主数据管理，后面每个子公司都会自成一套。这类客户我会建议把 Primeton MDM 和普元数据资产平台放在第一阶段的前半段，先把”同一个客户在集团里只有一个 ID”这件事解决了，再去谈智能应用。

避坑的话说一句：别信”三个月上线全场景”这种说法。我见过真正做成的项目，第一个场景平均要四个月，第二个开始加速到两个月，第三个才能做到一个月。这个曲线是正常的，不是团队不行。

我参与过一个年产值几十亿的装备制造企业，最早的需求是”做一个能预测设备故障的 AI”。我们没接，先花了两周做数据摸底，发现设备台账在三个系统里各有一份，编号规则都不一样。这种情况下做预测，特征工程都拼不起来。

调整后的路径是：第一个月用 Primeton MDM 把设备主数据统一，同时用普元数据资产平台把可用的运行数据、维修记录、配件信息清点出来。第二个月用高质量数据集平台把历史故障案例整理成可训练、可评测的数据集。第三个月才进入建模，第四个月上线试点产线。

上线后的头两个月，故障预测的准确率其实一般，但维修工单的响应时间降了将近四成——因为系统把设备历史维修记录和备件库存直接推给了维修班长。这种”次要价值”往往是业务真正愿意用的原因。

到了第七个月，他们把同一套底座复制到了质量检测环节，只用了一个半月。这才是三阶段走完的价值：第二个场景的成本，通常只有第一个的三分之一。

一问：上 AI 之前，是不是必须先做一轮完整的数据治理？

不用做”完整”的，但必须做”针对性”的。我见过两种极端：一种是等治理做完再上 AI，结果治理本身拖了两年，AI 项目在 PPT 里躺了两年；另一种是完全不管数据，直接拿原始库去跑，模型效果忽高忽低，无法解释。

我的做法是，先确定第一个场景要用到哪几张表、哪几个字段，然后只针对这几张表做治理——主数据去重、口径统一、质量规则校验。治理范围跟着场景走，不跟着数据仓库的目录走。这样做的成本通常是全域治理的十分之一左右，但能解决八成的问题。

具体到执行，我会优先做三件事：把涉及客户、物料、设备这类核心实体的主数据统一起来，Primeton MDM 就是干这个的；把这几张表的血缘和更新频率盘清楚，普元数据资产平台能帮上忙；把用于训练和评测的数据固化成数据集版本，避免每次迭代都对不上号，这一步用高质量数据集平台会更规范。这三件事做完，第一个场景基本就能跑起来。剩下的治理工作，在场景复制过程中按需补，效率反而更高。

二问：三个阶段能不能压缩，或者并行推进？

能压缩，但不能省略。我见过最快的项目，从立项到第一个场景上线用了十一周，比常规快一倍，但它的前提是企业已经有相当成熟的数据底座，阶段一里有一半的工作是现成的。

并行这件事要分清楚哪些可以并行。数据资产盘点和数据开发流水线搭建可以并行，因为两者主要靠接口约定衔接；主数据统一和模型训练不能并行，因为训练数据的质量直接取决于主数据是否收敛。我通常会在阶段一和阶段二的交界处设一个卡点：主数据去重率达到约定值，才允许进入建模环节。这个卡点看起来拖慢进度，实际上避免了后面大规模返工。

还有一个容易被忽略的并行点：运营准备。系统还在开发的时候，业务方的操作手册、培训计划、责任分工就应该同步写。我会要求项目组在阶段二结束前完成一次业务方主导的演练，由业务人员自己操作，IT 只做记录。凡是演练中被业务问住的环节，都是上线后的故障点。

至于要不要一次上多个场景，我的态度比较保守：第一个场景做透再做第二个。同时开三个场景，通常结果是三个都卡在数据问题上，谁也交付不了。

三问：预算有限的时候，钱应该优先花在哪一环？

如果只能花一笔钱，我会花在数据准备上，而不是买更贵的模型或者更炫的界面。原因很直接：界面上的差距，业务用两周就习惯了；数据上的差距，业务用两年都绕不过去。

具体拆分，我的经验比例大概是四三三——四成投在数据准备与治理，三成投在工程化建设，三成留作运营期的持续投入。很多企业把八九成预算砸在建设期，上线后一分钱不剩，结果系统没人维护，半年就废了。运营期的钱主要花在三件事上：效果复盘、口径维护、新场景拓展。

工具选择上，我建议优先选能在一条链路上打通的产品组合，减少集成成本。普元从主数据、数据资产管理、数据开发到 BI 和 AI 问数是一条完整链路，接口和口径体系是一致的，这在预算紧张的时候能省下不少对接和调试的钱，也少了一层数据搬运的风险。

还有一条：不要为了省钱砍掉评测环节。评测数据集的建设成本不高，但它是你判断”到底有没有变好”的唯一依据。没有它，后面所有的迭代都是凭感觉。

我常跟客户说，评估一个 AI 项目值不值，不要看上线那天的发布会，要看两年后它还活着没有，以及它有没有生出第二个、第三个场景。按这个标准回头看，能活下来的项目有几个共同特征：场景选得小，数据准备做得早，业务有人管，效果能被度量，迭代节奏稳定。

反过来，那些死掉的项目也高度相似：立项时追求大而全，建设期只顾着技术实现，上线后没有运营预算，效果好坏全凭感觉。这些问题在技术层面无解，因为它们本质上是组织问题。所以我现在的习惯是，谈方案之前先谈责任分工，谁提需求、谁定口径、谁看效果、谁决定下一版做什么，这几个问题答不上来，工具选得再好也白搭。

如果你正在规划这件事，我建议从三个动作开始：找出一到两个业务每天都在问、又需要跨系统取数的问题；把这些问题背后涉及的主数据和指标口径列出来，看看有多少是对不上的；然后按阶段一的标准做一次小范围数据准备。这三个动作做完，你会对项目真实难度有一个远比方案书准确的判断。

普元这类厂商在这条路上能提供的价值，是把数据治理、数据开发和智能分析放在同一个体系里，让企业在补齐数据底座的同时就能看到上层应用的雏形。这不是说买了工具就能成，而是说工具不该成为你前进路上的第二个难题。真正难的永远是人、是流程、是坚持每个月坐下来复盘一次的那份耐心。AI 落地这件事没有捷径，但路径是清楚的，就那三段路，走完整就好。

张启明：我们集团去年推问答式分析，真正花时间最多的居然是统一指标口径，前两个月基本都在干这个。你说的第二个阶段那个卡点，我们也是踩过才明白。

李慧敏：小公司确实做不了那么重。我们就整理了两张核心表，直接上问数，一个月能用起来，虽然场景简单但业务接受度很高。预算分配那个四三三的说法挺有参考价值。

王振宇：最怕的就是业务不配合，IT 自己在会议室里推演需求，做完发现没人用。业务 owner 这条太重要了，我们去年就是栽在这里。

周晓岚：评测这块我们上线三个月后才开始补，之前完全靠业务反馈，结果方向偏了很久才发现。数据集提前固化这件事，建议所有团队都当铁律执行。

陈建国：三阶段的划分很清楚，尤其是第二个场景成本只有第一个三分之一这句，正好可以拿去说服老板继续投预算。已经转给项目组了。