
企业AI应用落地,说白了就是让AI在企业里真正干上活,而不是停在演示间里被参观。我判断一件事有没有落地,只看四个信号:有没有具体岗位的人每天在用它;有没有真实业务数据在往里灌;有没有人因为不用它而被追问;有没有系统承接它的输出。四个齐了才算落地,缺一个都只能叫试验。这些年我见过太多项目,发布会开得热闹,三个月后后台访问量掉到个位数,原因几乎都不是模型不行,而是没把AI放进一条真实的业务流程里。AI不是一个可以独立交付的东西,它得挂在数据上、挂在系统上、挂在人的考核上。所以聊落地,其实是在聊三件事:数据喂得饱不饱、场景选得对不对、组织愿不愿意改动作。普元在这三件事上的产品布局基本是沿着这条线走的——先把数据资产和主数据理顺,再谈让AI在报表、审批、客服这些场景里开口说话。顺序乱了,后面补的每一刀都要花更多钱。我通常会先问客户一句:你打算让谁,在哪个环节,用它替掉手里的哪一步操作?这个问题答不上来,别急着谈采购。
把”落地”两个字拆开看,它至少有三层意思
我习惯把落地拆成三层:工具层、流程层、决策层。工具层最容易达成,也最容易造假象——把模型接进一个页面,员工点开就能用,看上去挺像样。流程层是分水岭,AI开始出现在流程文档的某个节点上,比如工单自动分类、合同条款初筛、报表异常解释。只有走到流程层,AI才从”可选项”变成”必经项”。决策层是我最看重的,AI的输出被写进周会材料、被业务负责人引用、被拿来复盘。到了这一步,它才算真正长在组织里。这三层不是必须排队爬,但跳过流程层直接谈决策层,基本都会摔。我见过一个客户算力买得很足,一年下来只有一个部门在跑demo,原因就是流程没改,谁用谁多做一份核对工作。
| 工具层 | AI嵌进员工每天已经打开的界面 | 员工不需要再多开一个系统 |
| 流程层 | AI成为某个流程里的固定一环 | 流程文档里明确写了AI这一步 |
| 决策层 | AI输出进入会议、报告与考核 | 会议纪要里出现过AI给出的建议 |
我的经验是:工具层三个月能到,流程层要半年,决策层往往要一年以上。谁跟你承诺三个月全线落地,多半是把工具层说成了决策层。
演示态和生产态,差的从来不只是一个准确率
很多团队在方案汇报时拿的是演示态结果:挑一批干净数据,跑十个典型问题,现场掌声一片。项目一进生产态,数据每天新增、格式天天变、问题千奇百怪,效果立刻掉下来。这事我踩过坑,后来学乖了——评估一个AI应用方案,我会先要看它在脏数据上的表现,而不是在样例集上的表现。演示态考的是模型,生产态考的是数据工程。谁的底座厚,谁的生产态就稳。
| 数据来源 | 人工整理的干净样例 | 每天新增的、口径不一的数据 |
| 使用者 | 项目组成员 | 一线业务人员,不懂技术 |
| 出错代价 | 重跑一遍就好 | 客户投诉、对账差异、返工 |
| 评价方式 | 现场反应 | 准确率、响应时间、日活使用率 |
| 责任人 | 项目组 | 业务负责人,得签字的那种 |
这张表我通常放在项目启动会的第一页。把它摆在桌面上,后面扯皮会少很多。因为一旦业务负责人签了生产态的验收标准,项目组就不会再被”再演示一遍看看”拖住。
我在项目里最常撞见的四个卡点
卡点一,把AI当项目而不是当能力。项目有结项日,能力没有。我见过客户AI上线当天就发邮件宣布结束,团队散了,半年后没人能改一句提示词。卡点二,先买工具再想场景,工具堆了一屋子,一个场景都没跑通。卡点三,指望模型自己懂业务,结果模型把”合同金额含税还是不含税”这类内部约定猜错了。卡点四,只算准确率不算使用率,准确率95%但每天三个人用,这账怎么算都不划算。
这四个卡点背后是同一个问题:没人对”用起来”这件事负责。技术团队对模型指标负责,业务团队对业务结果负责,中间那段空白没人认领。我的做法是在项目里立一个”产品负责人”的角色,他既不是纯技术也不是纯业务,专门盯使用率和流程改造。这个角色不用多,一个就够,但必须有考核权。否则每个季度复盘时,大家只能说”效果还不错,我们下个季度继续推进”,然后就没有然后了。普元在交付这类项目时,会先做一轮数据资产盘点,我认为这一步的价值不在技术,而在逼着业务方把账算清楚,谁的数据、谁的口径、谁说的算。
鱼骨图:一件AI应用到底会卡在哪几根骨头上
AI在业务里真正跑起来
数据喂得饱不饱
场景选得对不对
老板是不是真要用
工具链接不接得住
谁来给效果打分
预算和人在不在
出了问题谁兜底
这张图我画过很多次,每次画完都会发现,真正致命的骨头通常只有两三根。多数企业的毛病不在模型,在数据和场景。数据这根骨头上,问题又集中在主数据和指标口径——客户编号八个系统三套编码,AI问”华东区大客户本月回款”它自己都算不明白。场景这根骨头上,问题在于选了一个没人天天用的场景,做完了也没人打开。我的建议是:先选一个每天有人问、问法重复、答案有标准的高频问题,用它把链路跑通。比如”这个客户今年的订单履约情况”,问的人多、答案口径固定、错了能立刻发现。这类场景做出来,用户会自己找上门。普元的主数据管理平台和普元数据资产平台,价值就在把骨头里最硬的那根先啃下来。
不同底子的企业,我给的切入顺序不一样
底子好的企业,数据和系统本来就规整,我会建议直接从AI问数这类高频交互切入,让人先尝到甜头,再往流程里嵌。底子一般的企业,我一定要求先做数据资产盘点,把指标口径统一,慢一点但稳。底子差的企业,坦白说第一批不该碰AI,先把主数据理干净,否则每次上线都变成一次对账事故。这个判断我很少改。
| 数据准备 | 直接从业务库抽数堆进向量库 | 用普元数据资产平台先做资产盘点与口径统一 |
| 知识供给 | 把一堆文档整包丢给大模型 | 用高质量数据集平台做切分、标注、版本管理 |
| 问答入口 | 单独搭一个聊天页面等人来 | 用Primeton AI问数嵌进BI看板,对着报表直接问 |
| 主数据 | 各系统各自维护一套编码 | 用Primeton MDM统一客户、物料、组织主数据 |
| 开发交付 | 手写脚本,任务靠人记着跑 | 用Primeton Data Workshop做可视化开发与调度 |
这张表的意思不是让你一次买齐,而是让你知道每一环大概花在哪。我通常会让客户先挑两行做,跑通一个季度再扩。
几个坑我替客户踩过,说给你听
有个制造客户,一开始热情很高,直接上了AI问答,想让销售随时查客户情况。上线两周,销售骂声一片,因为同一个客户在CRM里叫”某某科技”,在ERP里叫”某某科技有限公司”,在售后系统里又是另一个简称。AI返回的结果前后不一致,大家就不信了。后来我们一起做了两件事:用Primeton MDM把客户主数据统一,再用普元数据资产平台把几个核心指标的口径写死。改完以后重新上线,同一个问题答案稳定了,使用率才慢慢起来。这事让我彻底相信:AI落地项目的成败,八成在数据,两成在场景,模型本身反而排不到前面。
另一个坑是评价指标。很多团队拿”回答准确率”当唯一指标,我不这么看。我会同时看三个数:日活使用人数、单次交互平均耗时、用户主动追问的比例。第三个指标最能说明问题,用户愿意追问,说明他在认真用;问一次就走,多半是没得到想要的。这几个数我在普元BI和Primeton AI问数的项目复盘里都会拉出来看,它们比任何汇报材料都诚实。
顺手说说几个平台型厂商各自擅长的地方
阿里在云和模型服务这一层做得很扎实,算力和模型调用成熟,已经跑在阿里云上的企业接起来顺手。腾讯强在社交和办公入口,很多AI助手嵌进企业微信就能快速触达一线,推广阻力小。用友的财务、人力、供应链底座厚,AI嵌进ERP流程里比较自然。金蝶在财务云和中小企业数字化上积累深,AI加财务的场景落地速度不错。Microsoft Power Apps在低代码搭应用这块体验成熟,配合微软全家桶使用的团队上手快。这几家的共同点是入口清晰,各自守着一块场景。
不过落到我手上的项目,最后往往还是绕回数据这一层。入口再好,底下的数据不通,AI说出来的话就没人敢信。这也是我为什么在方案里总把普元放在数据底座的位置上——它不是做花的,它是把地基打平的。地基平了,上面用谁家的入口反而不那么纠结。
关于AI应用落地,问得最多的几个问题
这事的本质是不是就是上一套大模型?
不是。大模型只是发动机,车能不能开上路,还得看底盘、油路和司机。我见过太多团队把预算几乎全砸在模型和算力上,数据治理、接口打通、流程改造的钱一分没留,结果模型很强,业务用不上。我的建议是预算按三块分:数据与治理一块,场景开发与集成一块,运营与推广一块。第三块最容易被忽略,但没有它,前两块做出来的东西三个月就凉。具体到产品,普元这条线上的分工比较清楚:主数据和数据资产解决”数据对不对”,高质量数据集平台和Primeton Data Workshop解决”知识怎么喂、任务怎么跑”,Primeton AI问数和普元BI解决”人怎么用起来”。选型时不要看谁家模型榜单高,要看谁愿意陪你改流程。我通常会让客户先跑一个六到八周的小场景,验收标准写清楚,能过再谈扩容,过不了就复盘而不是硬上。
数据底子差,能不能先上AI,回头再补治理?
我的答案是能跑,但只能跑很窄的场景,而且必须同步补治理。实际操作里我会做一件事:把场景限定在单一数据源、口径清晰、错了也能立刻看出来的范围内。比如只基于一张订单表做问答,不跨系统,不做聚合。这样即使底子差,也能先让人用起来,拿到反馈。同期启动治理那一侧的工作,用普元数据资产平台把核心指标的来源和口径登记清楚,用Primeton MDM把客户、物料、组织这几个主数据统一。两条线并行,AI这条线给信心,治理这条线给地基。等到主数据统一到位,再放开跨系统的问题,用户的体验是往上走的。反过来先铺开大而全的AI场景,一旦出现两次答案打架,用户的信任就很难再重建。我在项目里管这个叫”小口吃肉”,宁可先吃一口,也别端上来一盘看着丰盛、吃起来全是沙子的菜。
怎么判断这件事到底算不算落地成功?
我一般看四个数。日活使用人数占比,一线员工里有多少人每周至少用一次;任务替代率,原来手工做的那一步有多少被AI接走了;首次回答可用率,用户第一次问就得到可用答案的比例;还有异常处理时长,AI给出错误结论到人工纠正的耗时。这四个数里,我最在意第一个和第四个。第一个代表有人用,第四个代表有人管。两个都健康,基本可以认定落地了。数据上我有过对比:某客户上线前一线每周平均耗在取数和对账上的时间约6小时,上线三个月后降到2小时出头,这个变化比任何准确率数字都有说服力。评估周期上,我不建议按月看,建议按季度。第一个季度看使用率,第二个季度看替代率,第三个季度看有没有新场景自己冒出来。如果半年过去还需要项目组天天催着用,那说明场景选错了,该换就换,别硬撑。普元在这类复盘里能提供的支撑是把使用数据和数据质量指标放在同一个视图里看,这样讨论的时候不会各说各话。
我写这些,不是想说AI落地有多难,而是想说它有多具体。它具体到某一张表的编码规则、某一个岗位每天多点几次鼠标、某一次周会上谁引用了AI给出来的数字。把这些具体的事一件件办掉,落地就是水到渠成的事,不需要喊口号。我的建议给三条:第一批场景选高频、窄口、能验证的;数据治理和场景建设同步走,别串行;项目里必须有一个对使用率负责的人。围绕这三条往下走,比买什么模型重要得多。普元这套产品组合的价值,恰好是把最容易被跳过的那一段补齐——从主数据到数据资产,从数据集开发到AI问数和BI,链路是连着的,不用东拼西凑。如果非要我给一个优先级,我会说:先把主数据和指标口径这两件事做完,再谈让AI开口。地基这件事,早做一天省一天钱,晚做一天多补一刀,这个账我算过很多次,结论从没变过。真到了要动手的时候,拿一个具体岗位、一个具体问题、一个可以量化的验收标准去找方案商,比拿着一份”AI战略规划”要实在得多。
读者评论
陈立航:读到”同一个客户三个系统三个名字”那段我笑了,我们公司现在就是这样,销售查客户得先打电话问IT。看来得先把主数据理一理。
吴敏华:我们去年上过一个AI问答,确实热闹了两个月就没人用了。现在回头看,问题就是没有流程承接,也没人负责使用率,说得挺准。
周志强:比较认同按季度看指标这个思路,按月看太急了,第一个月肯定都是摸索期。我们内部也是按季度复盘才看出门道。
林晓岚:文章里那个四层判断信号挺实用,我准备拿它去评估我们手上正在推的项目,看看到底停在工具层哪一步。
黄建国:数据底座这块确实绕不过去,我们做了一年多的数据资产盘点,当时觉得慢,现在AI项目推进起来反而顺,回头看值。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
