不换 ERP，我们给老系统配了一个 AI 搭档

接着上一篇，今天继续分享。那套用了十年的国产 ERP，现在还在跑。交易还是它管，财务还是它管，库存账目还是它管。

我们没有动它的地基，但我们给它配了一个 AI 搭档：腾讯的 WorkBuddy。

这也是我想借这个案例讲清楚的一件事， 很多企业遇到老 ERP 问题，第一反应是换系统。但在真实项目里，换 ERP 往往不是一个轻松决定。

报价不低，周期不短，实施期间还会牵动业务、财务、仓库、生产、管理层。老板看完三份方案，把报价单扣在桌上说一句“我再想想”，这一想可能就是半年。

我们介入时，没有先建议他们换 ERP。

因为这个 ERP 不是完全不能用。它管交易、管账目、管库存记录，这些核心能力还在。真正拖慢业务的，是 ERP 管不到的地方：

订单怎么进来，流程怎么转，数据怎么看，老板怎么在手机上掌控。

这些事，不一定需要换 ERP， 需要的是在 ERP 外面加一层能帮人做事的业务层。

ERP 是底盘，WorkBuddy 是大脑，RPA 是手脚

我们的架构，用一句话讲就是：

ERP 是底盘，WorkBuddy 是大脑，RPA 是手脚。

ERP 继续管交易和账目。

WorkBuddy 作为 AI Agent，负责业务分析、数据整理和流程编排。ERP 已经开放的数据接口，我们封装成 MCP 服务，交给 WorkBuddy调用。那些没有接口、只能靠界面操作的动作，再交给 RPA 去执行，比如登录系统、点击按钮、录入表单、导出数据。

说得更直白一点：

WorkBuddy 不替代 ERP，也不重写 ERP。它做的是在 ERP 外面加一层会编排的业务层。

人说需求，WorkBuddy 判断要处理什么业务、整理哪些数据、该调用哪个 MCP 服务查数据、该调用哪条 RPA 流程做录入。遇到异常，再把问题抛给人确认。

这里有一个关键分工：WorkBuddy 负责想清楚怎么干，RPA 负责具体动手。

如果只上 RPA，很容易变成把人的点击录成脚本。短期能跑，但一遇到字段变化、业务规则变化、异常订单，就会卡住。

如果只讲 AI，不接 ERP、不接 RPA，也只是一个会聊天的入口，落不到业务动作里。

这个项目真正要解决的，是把分析、编排、执行和人工兜底串起来。

第一步：订单先被整理，再被录入 ERP

上篇讲过，这个厂最头疼的第一道关，是客户下单方式太乱。

客户 A 有自己的订单系统，给了工厂一个账号。以前文员每天要登录进去看单子，再手工抄。

现在 WorkBuddy 编排 RPA 流程，自动登录客户 A 的系统，按设定时间去巡单，有新订单就抓回来。

客户 B 发邮件，附件是 Excel。这里不是简单把 Excel 丢给 RPA 去录入。WorkBuddy 的订单处理能力会先分析和整理订单数据：识别客户、读取 Excel、做字段映射，把客户自己的表格转换成 ERP 能接收的订单格式。

客户 C 最随性，微信群里甩截图。这个看起来最麻烦，但也能处理。

WorkBuddy 调用 OCR 能力，把截图里的表格识别成结构化数据，再交给订单处理能力做字段校验和格式整理。

三种渠道先被整理成统一订单数据，再由 WorkBuddy 调用 RPA 流程录入 ERP。

录完之后，WorkBuddy 推一条消息给文员：“今天新增 32 笔订单，已自动录入，请你逐笔审核确认。”

文员的角色变了，她不再是录单机器，而是审核确认的人。

自动化不是把人完全拿掉，而是让人站到更该出现的位置。

第二步：打单从 15 步变成一句话

订单进来的问题解决后，下一道关是流程运转。

打一张出货单，原来要点 15 下。这个痛点的解法更直接：让 WorkBuddy 判断要走哪条业务流程，再编排 RPA 去替人执行。

操作员对 WorkBuddy 说一句话：“打今天下午要发的这批出货单。”

WorkBuddy 先分析这批出货单对应哪些订单，要走哪些流程节点，有没有异常条件。确认流程后，再调用 RPA 自动登录 ERP、选模块、查询订单、填表单、提交审核、打印、归档。

原来 15 步，现在变成 1 句话。以前 80% 的时间在机械点击，20% 的时间在处理异常，比如客户临时改数量、规格特殊需要确认。现在 AI 和 RPA 替你干掉那 80%，你正好可以把精力放在那 20% 真正需要判断的事情上。

当然，RPA 也不是一劳永逸。RPA 操作 ERP 界面，本质上还是模拟人的点击。如果 ERP 界面突然改版，按钮位置变了，弹窗逻辑变了，RPA 就会失灵。我们的做法是：WorkBuddy 在 RPA 失败时自动通知，人工介入处理，同时记录失败原因，定期维护 RPA 脚本。维护成本仍然存在，但远低于每天人工重复点击的成本。

第三步：老板手机上长出了看板

前两步解决的是订单进来和流程转起来。第三步解决的是老板最痛的事：数据看不见，出差就失联。

这里我们没有简单做一个“移动版 ERP 报表”，因为老板真正想看的，不是 ERP 原始报表，而是业务问题的答案。

第一步，把 ERP 已经开放的数据接口封装成 MCP 服务。

你可以把 MCP 理解成一组给 AI 用的数据接口。ERP 里已经开放出来的数据，不再让人导表，而是封装成服务，让 WorkBuddy 按业务问题去查。产量、出库、库存周转、排产进度、订单执行状态，这些数据可以直接查询。

第二步，把常用报表移动化、个性化。

过去老板看到的是 ERP 里的标准报表。现在看到的是按他关心的问题重组后的看板：产线日产量、订单执行进度、库存周转、今日出货，这是把 ERP 数据变成管理者真正看得懂的问题答案。

第三步，WorkBuddy 通过 MCP 服务接入这些数据，负责分析业务口径、组织回答。管理者可以用自然语言直接问。

接口查不到、还得从老界面导出的数据，再由 WorkBuddy 编排 RPA 去补。前提是先把订单状态、产量口径、换线记录这些数据接口和规则梳理清楚。否则自然语言查询只会变成一本正经地胡说。

这一步落地后，有一个场景我印象很深：有次工厂老板去外地出差，在机场候机。以前这个时候，他想知道工厂情况，得打三个电话，等十五分钟。这次他打开 WorkBuddy，问了一句：

“今天产线产出怎么样？”

WorkBuddy 直接回答：

“今天截至下午两点，A 产线产出 1200 件，完成日计划的 75%；B 产线产出 860 件，完成日计划的 62%，比昨天同期低 8%。主要原因是 B 产线上午换线花了 40 分钟。”

我把这个段子讲给我听的时候，我感受到了他的满足感。不是因为技术多厉害，而是因为他突然意识到：过去十年，他每次想知道这些数据，都要麻烦别人。麻烦文员导表，麻烦财务查系统，麻烦车间主任汇报。

现在，他不用麻烦任何人，直接问就行，技术本身不感人。

真正有价值的是，一个老板第一次觉得自己重新掌控了工厂。

不是换系统，而是先接管“伺候系统”的工作

这个电子厂的案例，给我的最大启发是：ERP 不会马上消失，但伺候 ERP 的人会越来越少。

过去十年，ERP 是工厂信息化的核心。所有数据都进 ERP，所有流程都走 ERP。问题是，ERP 擅长记录，不擅长交互。

于是企业里出现了大量人伺候 ERP 的工作：录单、打单、导数据、做报表、传 Excel。这些工作不创造多少新价值，只是为了让 ERP 能用起来，不得不付出的代价。

WorkBuddy 这样的 AI Agent 出现后，这些工作可以被重新拆分。

业务分析、数据整理、流程编排交给 WorkBuddy。
接口查询交给 MCP 服务。
界面操作交给 RPA。
异常判断和最终确认交给人。

这套分工，比单纯“上一个机器人”更稳，也比一上来换 ERP 更轻。

对很多企业来说，下一步未必是立刻换系统。更现实的动作，是先盘点一下：公司里有多少岗位，每天不是在创造价值，而是在伺候系统？

这些动作里，哪些可以通过接口查数据，哪些可以通过 RPA 执行，哪些必须保留人工判断？

把这张表列出来，很多 AI + RPA 项目的入口就清楚了。

如果你也遇到过类似的老系统问题，可以先从这三个问题自查：

订单是不是还靠人抄？
流程是不是还靠人点？
老板看数据是不是还靠别人导表？

这三个问题回答清楚，比先讨论换不换 ERP 更有价值。