RPA与AI的边界:为什么我们不急着把所有事都“系统化”

RPA与AI的边界：为什么我们不急着把所有事都“系统化”

一个问题引发的三层思考：技术阻塞、投产比，还是组织演进的自然节奏？

上周AI大赛期间，一位评委老师问了我一个很实际的问题。他说，他看到我们同事数据分析时，用RPA工具把各个系统里的数据拉下来做核对。他好奇：这种取数核对的动作，理论上完全可以通过一个数字化项目来做，为什么之前没做？是因为中间有技术阻塞需要AI来解决，还是纯粹因为投产比不划算——项目太慢、成本太高？

他还补了一句自己的观察：AI确实在解放一线业务团队的能力边界，可另一方面，如果把一些业务流程完全放给业务同事去“vibecoding”（凭感觉写代码或搭工具），好像也不一定是好事。

这个问题问得很准。它戳中了很多企业数字化转型中的一个真实困境：面对系统壁垒和历史数据孤岛，我们到底应该走“正规军”的系统化建设，还是鼓励“游击队”式的快速工具？这两者如何平衡？

我想借这个机会，把我们的一些实践和思考整理出来，未必是标准答案，但也许能提供一个参考。

—

一、系统壁垒不是技术问题，而是数据定义的自然边界

首先，为什么很多企业里会出现“明明可以系统化做的事，却用RPA跑了好几年”的现象？

朋友猜测是“技术阻塞需要AI解决”或“投产比问题”。这两个原因确实存在，但不是全部。

更本质的原因是：数据从底层到经营核算，天然有层级和定义边界。 不可能完完全全从原始业务单据一路拉通到最终的核心指标。生产系统的“物料编码”和财务系统的“成本中心”可能不是同一个颗粒度；销售部的“签单时间”和财务确认收入的“权责发生时间”永远有差异。

这不是技术打通就可以消除的——它来自业务本身的多元视角。所以你会发现，很多看似“低效”的RPA动作，恰恰是在承认这种边界的前提下，用最快的方式完成数据衔接。RPA不是技术落后的表现，而是对现实复杂性的务实回应。

有的公司也在自建企业层级的ERP，试图从底层把系统壁垒打掉。但即便是那样的系统，也无法消灭所有“派生指标”和“衍生指标”的个性化定义。天然就一定会有边界的。

所以，回到评委老师的问题：为什么之前没做数字化项目？一部分是投产比——建一个跨系统的数据中台，周期长、投入大、优先级排不过来；另一部分不是技术阻塞，而是“业务语义阻塞”。 AI能帮你写代码，但它不能替你决定：你今天看的这个“收入”，到底要不要包含未回款的合同？

—

二、让业务“先动起来”的价值，大于一步到位的完美系统

既然系统建设很难一蹴而就，那么当我们面对一个具体的提效场景（比如对账）时，应该怎么办？

我的做法是：鼓励业务同事先用自己的方式动起来，哪怕是用RPA、用飞书多维表格、用AI写个脚本。

这背后有一个朴素的逻辑——干中学。你不知道什么方案真正适合自己，直到你亲手做一遍。

在去年到今年，我们通过内部AI推广（抱歉，还是要提一下，因为这个机制确实起了作用）萃取出了一大批优秀案例。很多想法在概念阶段非常粗糙，但跑起来之后，问题就显形了：原来这个数据源每周只更新两次，原来那个核对逻辑需要三个部门的确认，原来财务同事最痛的不是取数，而是取完数之后没人认领差异……

这些真实的痛点，坐在办公室里画系统架构图是发现不了的。

所以回到评委老师担心的“vibecoding会不会坏事”的问题——坏事的不是业务动手，而是没有后续的筛选和组织化承接。 我们允许业务先“飞一会儿”，但飞完之后必须做三件事：

1. 识别高价值场景：哪些RPA工具是每天都要用的，能省下肉眼可见的人力和时间？
2. 企业化部署：把那些被验证有效的、通用的能力，集成到飞书、BI这样的企业底座里去，让大家直接调用，而不是每个人写一遍。
3. 分层管理：不是所有东西都要收归中央。办公提效类（如清理日志、自动回邮件）就让大家自己玩；垂直业务类（如营销内容生成、数据预警）由业务部门自己内化并修改流程；核心经营类（如月结报表、现金流预测）才走正式的数字化项目。

—

三、AI+BI：让数据的最后一公里被“走通”，而不是被“填平”

评委老师还提到一种感觉：AI让业务团队的能力边界扩大了，好像什么都能自己做。但他怀疑，对稳定流程来说，不一定好事。

我认同这个谨慎。能力的边界扩大，不等于责任的边界消失。

举个例子：我们用BI建设了一年多，大家已经习惯了看数据、做看板。但真正到决策的时候，仍然卡在“中间环节”——我们有原始数据和结果指标，但缺少一条清晰的路径：从“这个月回款下降了”到“是因为A类客户流失，而流失的原因是交付延期”之间，需要业务知识、指标树、以及价值链的拼接。

AI能帮我们快速生成分析，但它必须建立在业务语义结构化的基础上。这就是为什么我们在推进BI+AI时，特别强调指标数和指标树——把业务的流程、价值链、KPI之间的推导关系显性化。只有这样，AI给出的建议才不会是一堆正确的废话，而是“你说的是我的业务吗？”的准确回答。

所以，我们对业务vibecoding的态度不是放任，也不是禁止，而是引导到有“轨道”的方向上：用企业级的BI指标树作为共同语言，让业务同学在这个语言体系内搭建自己的小工具。你可以在轨道上自由跑，但不能自己铺轨距完全不同的铁轨。

—

四、从“个体效率”到“组织能力”：流程闭环、价值量化、部门复制

最后，回到评委老师最核心的那个问题：怎么判断一个场景应该用RPA快补丁，还是立项做系统？

我的经验是，不要做二选一，而是做三层过滤：

1. 流程闭环：这个RPA工具做完取数之后，数据去了哪里？有没有人基于它做决策、触发下一动作？如果没有，那它只是一个信息碎片，不值得系统化。如果有天然的闭环（比如拉完差异后自动生成催款单），那就是高价值，可以考虑企业化。
2. 价值量化：它到底节省了多少时间、减少了多少错误、影响了哪个业务指标？算不清楚的，先留着当个人工具，不要着急推广。算得清楚的，就可以拿出来作为复用的候选。
3. 部门复制：是不是只有你会用？还是你们部门有三个人以上能用、敢用、愿意改？这个维度决定了它能不能从“个体英雄”变成“组织能力”。

这三个维度，其实对应了我们内部常说的三个词：闭环、量化、复制。它们不是AI大赛的专属，而是所有数字化决策的共同标尺。

—

写在最后

评委老师最后说，他感觉AI时代让更多可能变得触手可及，但路径反而比以前更模糊了。

我告诉他，我们不急。去年推BI时有人问为什么推那么快，我当时的回答是：AI时代的到来，一定是强化人的判断力和洞察力。那些重复性的、可被替代的能力会被工具接过，而人会转向承接训练、修正、决策的新角色。这个转型不能等系统建好了再开始，必须让业务在干中学、在学中教。

我们做的所有事——BI大赛、AI大赛、指标树建设、系统集成——说到底就一个目的：让数据改善业绩。而绩效改进模型里，仅“数据反馈”这一项就占了35%的权重，这是正确的事。

所以，回到那个问题：RPA与数字化项目之间，AI与业务乱改之间，选择从来不是非黑即白。稳健的做法是：让子弹先飞一会儿，但记住给子弹画好靶子。

靶子就是：这个工具最终帮谁、在哪个流程里、产生了多少可测量的价值、以及能不能让下一个人轻松地接过去用。

想清楚这四个问题，你自然就知道——什么时候该让业务自己写个RPA玩起来，什么时候该拉产品团队把它做成企业级的按钮。