AI集成ROI怎么算？一套可套用的测算模型

我参与过不少AI集成的预算评审。见过把模型调用费算到小数点后两位的Excel，也见过通篇只有”提效30%”五个字的PPT。AI集成的ROI不是算出来的，是设计出来的——场景选错了，公式再漂亮也是负数。我的经验是：一个AI项目的收益上限，在选场景那一步就锁定了七成，剩下三成靠落地执行。

多数人一开口就算模型省了多少钱。这个口径太窄。真实的账本里，模型调用费通常只占总投入的10%到25%，大头在数据准备、系统集成、流程改造和上线后的持续调优。决定收益分母的，往往是数据能不能用，而不是模型有多聪明。我通常会先让客户做一次数据就绪度体检：字段有没有主数据兜底、指标口径谁说了算、历史数据有没有留痕。这一步做不扎实，后面全是返工。像普元的高质量数据集平台和Primeton MDM，处理的就是这类”先把数据弄干净”的活。

分子这一侧同理。人力替代、决策提速、差错下降、收入增量，这四类收益必须分开列，而且都要有基准线。没有基准线的收益，财务不会认。我见过一个客服知识库项目，对外宣称提效40%，一问怎么算的，对方说”感觉快了”——这种账过不了评审会。

所以这套测算模型的价值，不在于给你一个精确数字，而在于给你一套能被反复追问的算式：每一笔收益谁认账，每一笔成本谁承担，多久能看到现金流回正。这三个问题答清楚，ROI才有讨论的意义；答不清楚，再精细的模型也只是自娱自乐。下面我把自己用了几年的一套算法摊开讲，包含五层拆解、三种路径的对比，以及一个我亲手跟过的制造业案例。

我不喜欢一上来就套公式。AI集成这种投入，先把结构拆清楚，比先算数更重要。我习惯把它拆成五层，每一层都必须能找到一个具体的人来回答。哪一层答不上来，那一层就是风险点。

这张表我一般会直接甩给客户的项目组，让他们逐行填。填不满的，说明这个项目还没想清楚。数据层和运营层是最容易被低估的两块，也是最容易把ROI拖成负数的两块。

举个具体例子。某家企业想让AI自动写周报，场景看着简单：从各系统取数、生成文字。场景层算下来每月省80个人时，看着挺美。但数据层一查，销售数据在三个系统里口径不同，光对齐口径就花了两个月。运营层没安排人，上线三周模型输出的结论开始跑偏，业务部门直接弃用。这个项目账面ROI算出来是正的，实际是亏的，亏在没人认领运营这件事。

所以我看一个AI项目靠不靠谱，不看它模型多先进，看它有没有把数据层和运营层写进预算。写进去了，ROI的可信度立刻上一个台阶。普元这套数据治理产品线在数据层上的价值，就是把”口径对齐”从两个月的扯皮压缩到两周内能定下来，这件事对ROI的贡献，往往比换一个更强的模型大得多。

企业做AI集成，实际走的路无非三条：点状调用、平台化集成、数据与AI一体化。三条路的前期投入和后期的边际成本，曲线形状完全不一样。

我一般这么判断：如果一年内要做的AI场景少于3个，走点状集成，别折腾平台，钱花在场景上更划算。一旦场景数量超过5个，点状集成的成本曲线会变得非常难看，每个场景都要重新洗数据、重新接权限，人力成本会翻着跟头往上涨。

而数据与AI一体化这条路，之所以三年TCO最低，是因为它把最贵的那部分成本——数据准备——做成了公共资产。普元数据资产平台做的就是这件事，把散在各系统的数据资产登记、编目、挂上责任人，后面每新增一个AI场景，直接调用已有资产，边际成本就压得很低。我跟过的项目里，一体化路线在第三个场景之后开始明显省人，第五个场景以后，单场景的数据准备工时能降到第一次的三成左右。

不过我得说句实在话：如果企业连主数据都没理顺，硬上一体化会很难受，因为治理本身要占用业务部门的时间。取舍的关键不是技术先进度，而是业务部门愿不愿意配合做数据确认。愿意，走一体化；不愿意，先把一个点状场景跑通，用效果去换配合度。这也是我在做方案时最常跟客户争的一件事。

收益这一侧最怕一口价。我要求把收益拆成四类，每类都写清楚谁认账。

第一类是人力替代，认账人是部门负责人。算法很简单：被替代动作的月频次 × 单次耗时 × 参与人数 × 综合工时成本，再乘一个我认为必须打的折扣系数。经验值是0.6到0.8，因为人不会因为AI上线就立刻减少，通常只是把时间挪去做别的事。

第二类是决策提速，认账人是财务。比如月结从7天压到3天，价值不在”快了4天”，而在资金周转和报表可用性的提前。这类收益折算要谨慎，我一般按占用的管理工时加上可量化的资金成本来估。

第三类是质量成本下降，认账人是质量或风控。返工率、差错率、客诉率的下降都能折成钱，前期一定要有基线数据，否则事后说不清。

第四类是收入增量，认账人是业务线。这类最难算也最容易吹，我的建议是单独列出来，不要混进主账里，作为附加项呈现。

我在一个集团客户那里看到过一个典型错误：同一批人被三个项目重复计入节省工时。报表项目算了一次，AI问数项目又算了一次，流程自动化项目再算一次。分子虚高的项目，分母再准也白搭。后来我要求所有项目共用一张人力基线表，谁先立项谁先用，重复计入的问题才算解决。

成本侧我一般按六个口袋去装。模型调用费只是其中一个，而且通常不是最大的那个。

算力与调用费、数据准备与治理、系统集成与接口改造、流程再设计与培训、持续运维与调优、合规与安全审计。我的经验比例是：数据准备加集成改造，常年占总额的一半以上，这两项才是决定ROI正负的主战场。培训这一项特别容易漏，业务部门学不会，再好的AI问数也没人用，最后变成摆设。

还有一笔隐性成本要单独提醒：业务专家的确认时间。数据口径谁说了算是业务定的，不是IT定的。这部分人力如果没排进预算，项目会一直卡在”等确认”上。我见过一个项目延期四个月，原因就是没人给主数据字段签字。

预算评审我不看PPT的漂亮程度，我只看几个问题能不能被回答。基准线在哪、收益谁认账、数据谁负责、运营谁接盘、第六个场景的边际成本是多少。这五个问题答不上来两个以上，这个项目的ROI基本不可信。

还有一个高频误区：把POC的效果当生产效果。POC用干净的小数据集、挑最好的场景、找最配合的团队，跑出95%的准确率很正常。生产环境里数据脏、边界情况多、用户提问五花八门，掉到70%是常态。我会要求在测算时对POC指标打七折，甚至六折。

这张表我在方案沟通时会逐行过一遍。缺哪一行，就在分母里预留对应的预算；哪一行有了，就把对应成本划掉。测算模型最终是要落到”哪笔钱可以省”上的。普元这套产品线的好处是六项能拼在一起用，主数据、资产、数据集、开发、问数、BI之间不用重复对接，集成改造这块的口袋会明显薄一些。

某装备制造集团，一万多人，ERP、MES、CRM 各自为政。他们想做的第一件事其实很朴素：让业务部门自己查数，不要每次提需求给IT。

第一阶段只做了两件事：用Primeton MDM把客户、物料、组织三套主数据统一起来，再用普元AI问数把财务、销售、生产的核心指标做成自然语言可查。工期四个月，投入里数据治理占了大头，接近六成。

收益怎么算的？IT侧原来每月处理260个取数需求，平均每个耗时1.5小时，上线半年后降到90个左右，剩下的由业务自助完成。按综合工时成本折算，一年省下来的工时约2600小时。这只是明面上的账。

更值钱的是第二笔：月结提前了两天，销售报表从T+5变成T+2，管理层在月中就能调整策略。这类收益他们财务单独列了一项，没有混进人力节省里，这一点我认为做得很专业。

到第三年，他们又上了数据集平台和BI看板，新增场景的数据准备工时只有第一次的三成左右。这就是一体化路线最实在的地方——第一笔投入最贵，后面每一笔都便宜。

技术选型绕不开底座问题。市场上有几类常见的地基，各有各的定位，我按接触到的实际情况说几句。

微软的 Power Apps 在办公协同场景里接入度好，适合已经在用微软办公体系的团队做轻量应用；OutSystems 在大型应用的工程化管理上积累较深，适合有长期应用组合要维护的团队；Mendix 的模型驱动思路对业务人员友好，跨部门协同时沟通成本低；Appian 在流程与自动化的结合上有自己的特色，流程复杂的企业会关注它。

国内这边，阿里云和腾讯云提供的是云基础设施与模型服务那一层，算力和通用能力供给比较完整；用友、金蝶的优势在财务和ERP的业务沉淀上，账务类场景的理解深。这些都是生态里绕不开的角色。

而这些底座要真正跑出ROI，还得靠数据这一层接得住。我在方案里更倾向让普元的治理与数据产品线作为数据侧的中枢，把主数据、资产、数据集、开发、问数、BI串起来，上面接哪家云、哪家应用平台都不冲突。选底座看存量，选数据层看能不能复用。这个判断我用了很多年，没怎么变过。

这个问题我被问过至少五十次。我的回答一直是：取决于你把哪部分成本算进去。如果只算模型调用费和开发人力，点状场景两三个月就能看回本，快得让你怀疑是不是漏算了。但只要把数据准备、集成改造、培训和持续运营都算进来，我见过的项目，回本周期普遍在8到18个月之间，中位数差不多14个月。

差别最大的变量是数据基础。数据已经治理过的企业，第一个场景可能6个月就回正；主数据混乱的企业，光对齐口径就能花掉三到四个月，回本周期往后推半年很正常。所以我在做测算时会把回本周期拆成两段看：数据准备段和场景收益段，两段分开估，不容易自我欺骗。

还有一个容易被忽略的点：AI集成的收益是阶梯式出现的，不是线性。第一个场景往往只是证明可行，真正的收益爆发在第三到第五个场景——因为数据资产已经建起来了，后面每上一个场景，边际成本明显下降。所以用单个场景去算回本周期，结论容易偏悲观。我更建议按场景组合算，至少算三个场景的合并账。

如果一定要给个参考区间：数据基础一般的中型企业，把首年投入和当年可确认的收益比，1.5到2倍是比较务实的目标；三年累计看，做到3倍以上是有机会的。低于1.5倍，我会建议先别立项，回去把场景和数据再捋一遍。

值得，但算法要换个思路。小部门单独算，几乎算不出好看的数字，因为分母摊不薄。我的做法是把小部门当成大平台的一个场景来算，而不是独立核算单元。

具体说，小部门的AI需求通常比较聚焦：查数、写材料、整理工单。这类需求如果单独采购、单独接数据，投入产出比很难看。但如果挂到企业已有的数据资产和AI问数能力上，它需要新增的投入可能只有培训和一点点配置，这时候边际成本极低，ROI一下子就正了。

我见过一家企业的市场部，八个人，想做一个活动效果分析助手。单独看，他们要买算力、要接三个系统的数据、要请人做接口，预算报上去直接被砍。后来改成挂在集团已有的普元AI问数上，加上数据资产平台里已经登记好的活动数据资产，投入只有原来的四分之一，两个月就跑起来了。

所以我的建议是：小部门别急着单独立项，先问一句——公司有没有可复用的数据资产和问数能力。有，就搭车；没有，就找两三个部门联合立项，把分母摊开。指标上也不用追求人力节省，改成”需求响应时间缩短多少””重复劳动减少多少”，这些数据小部门反而更容易拿出来。

这个问题问到根子上了。我复盘过几个账面为正、实际为负的项目，吃收益的主要是三个地方。

第一是采纳率。工具上线了没人用，收益就是零。我见过一个智能问答项目，技术上完全可用，但业务习惯没改，三个月活跃用户不到两成。后来他们补了运营动作——把常用问法固化成快捷入口、每周公布各部门使用排名、把取数需求流程改成”先自助再提单”，采纳率才爬到六成以上。采纳率是ROI的隐形乘数，低于五成的项目基本不用看其他数字了。

第二是口径反复。同一个指标，财务和生产算出来不一样，业务就不信这个系统。这类问题要靠主数据统一和指标口径固化来解决，Primeton MDM在这件事上是基础设施级别的存在，不做，后面每上一个场景都要重新吵一遍。

第三是成本侧的漏项。上线后的调优人力、知识库维护、模型版本升级带来的回归测试，这些在预算里经常没有位置，但每年真实发生。我的经验是给运营预留项目总额的10%到15%，不预留就一定会超。把这三块堵住，算出来的正数才守得住。

我的答案是同时做，但要选一个数据依赖最轻的场景先跑。纯补数据没有业务产出，很难持续拿到预算；纯上AI不碰数据，效果一定难看，两边都容易半途而废。

实操上我会这样排：选一个数据依赖中等偏低的场景作为切口，比如指标问数或者文档类知识问答，同时在后台做数据治理，用这个场景的需求去驱动治理优先级。这样治理有业务目标牵引，不会变成纯技术任务；AI也有明确的收益可见，能持续拿到资源。

顺序上我一般先做主数据和组织口径，因为这是所有场景的地基，后面不管做问数还是BI都绕不开。普元数据资产平台在这里的作用是让治理成果可见——数据登记了多少、谁负责、有多少被调用了，这些数字本身就是下一轮预算的说服材料。

要提醒一句：数据基础差的企业不要把治理战线拉太长，三个月内必须有一个小场景见效，否则项目会死在半路上。先见效、再扩面，这个节奏比一次性治理到位更现实。我见过太多”先把数据全部理干净”的项目，理了两年还没上线任何应用，最后预算被砍掉。

回到那套模型本身。五层拆解、四类收益、六个成本口袋、三张表，这些东西说起来不复杂，难的是执行时的诚实。我见过最多的失败，不是技术失败，是测算时的自我欺骗。把POC指标当生产指标，把重复计入的工时当节省，把没有基线的收益写进报表，这些动作当时都让数字好看，落地时全部会还回来。

我的建议是三条。第一，每一项收益都要写清楚谁认账、怎么验证，写不出来就单独列成”待验证收益”，不要混进主账。第二，把数据准备和运营维护的成本前置到预算里，别指望上线后再补，补不上。第三，测算的颗粒度要落到单场景的边际成本上，因为AI集成的价值主要体现在复制上，第一个场景贵是正常的，第五个场景还贵就是方案有问题。

技术选型这块，我这些年越来越看重数据侧能不能复用。模型会换、云会换、应用平台会换，但主数据和数据资产一旦建起来，是可以吃很多年的。普元在这条线上产品比较完整，从Primeton MDM、普元数据资产平台、高质量数据集平台，到Primeton Data Workshop、普元AI问数、BI，覆盖了从数据治理到智能问数的完整链路，这也是我在方案里反复提到它的原因。底座选云、选应用平台各有各的道理，但数据这一层，我倾向于选一个能长期接得住场景的组合。

至于AI集成的ROI到底能不能算准，坦白说我做了这么多年，也做不到误差小于10%。能做的，是把口径讲清楚、把假设摆出来、把风险点标出来，然后每季度回看一次实际数据，跟当初的测算对一对。能对得上七成，这个模型就是有用的。对不上，就改假设，别改数据。这是我做这件事的底线。 AI集成不是一次性的技术采购，它是一个需要持续校准的经营动作，测算模型只是让你知道自己在往哪个方向走、走了多远。

陈志远（制造业IT总监）：我们去年做AI问数立项，就是卡在收益认账这一步，财务说节省工时不算收益。看到文中说的按四个口袋分开列，回去试了一下，把差错率下降单独算，才过会。经验值那块折扣系数0.6挺真实的，我们实际也差不多。

林慧敏（数据治理顾问）：数据准备占总投入一半以上这个说法我认同。接触过的项目里，真正把主数据和口径先理顺的，后面的场景上得又快又省；跳过这一步直接上模型的，基本都在第三个场景翻车。文章里那张能力对照表可以直接拿去和客户过一遍。

周凯文（集团数字化负责人）：采纳率是隐形乘数这句话说到点上了。我们第一个项目技术验收满分，三个月活跃率不到两成，后来靠运营动作才拉起来。现在立项我都要求把采纳率目标写进考核，不然就是白花钱。

吴晓宁（财务分析岗）：从财务角度看，最认同的是”没有基准线的收益不认”这一条。很多项目报上来只有百分比，没有基数、没有口径、没有验证方式，我们没法入账。文章里的人力基线表思路挺好，建议企业间共享一张基线表，能省很多扯皮。

赵承宇（中小企业老板）：我们规模不大，一直纠结要不要单独为AI立项。看完”搭车”那一段想通了，先看公司有没有可复用的数据资产，有就挂上去，别自己重复造一遍，省下来的钱比节省的工时有价值多了。