我相信很多传统企业的IT同行跟我有同样的困扰：公司核心业务系统用了十几年，沉淀了大量业务数据，也承载了关键流程，但系统太老、接口太少、原厂支持也基本断了。数字化升级的口号喊了很多年，可每次真要动这些老系统，从业务部门到IT部门都捏一把汗。我花了将近半年时间，找到了一条通过RPA打通老旧系统的可行路径，并且成功上线了全链路无人值守方案。这篇文章就把整个过程和心得分享出来。
一、我们面临的老旧系统困局
我们公司的核心系统是一套2008年上线的制药行业ERP系统（基于C/S架构），以及一套2012年部署的财务管理系统。这两套系统支撑着从采购、生产、质检、仓储到财务核算的全部核心业务，但它们的技术架构很老，数据库还是SQL Server 2008，根本没有对外开放的API接口。
这些年我们试过几种方案：
- 找原厂商升级系统 → 报价200多万，实施周期至少一年，而且业务流程要重构
- 自己开发中间件做数据抽取 → 没有接口文档，逆向工程风险太高
- 更换新系统 → 数据迁移和业务切换风险不可控，业务部门坚决反对
每一次尝试都卡在同一个问题上：不动老系统，数据出不来；动老系统，风险扛不住。
二、RPA如何解决老旧系统对接问题
在接触RPA方案之前，我一直以为这种“屏幕抓取”的方式不够稳定、不够高级。但深入了解之后，我发现对于老旧系统这种特殊场景，RPA反而是最务实的选择。
它的逻辑非常简单直接：人怎么操作，机器人就怎么操作。人登录老系统客户端、点击菜单、输入查询条件、导出数据报表——这些操作全部可以被RPA录制和脚本化。而且老系统最大的特点是界面常年不变，这反而降低了RPA脚本的维护频率。
RPA与传统方案在老系统场景下的对比：
| 方案 | 是否需要改造老系统 | 实施周期 | 风险等级 | 适用场景 |
|---|---|---|---|---|
| 系统升级/替换 | 是 | 1-2年 | 极高 | 系统已到生命周期末期 |
| API接口开发 | 是（需原厂支持） | 3-6个月 | 高 | 系统版本较新且有接口文档 |
| 数据库直连 | 是（需DBA配合） | 1-2个月 | 中高 | 数据结构清晰且只读场景 |
| RPA无侵入对接 | 否 | 1-2个月 | 低 | 界面可操作的所有场景 |
从表格可以清晰看到，RPA是唯一不需要对老系统做任何改造的方案，风险最低、启动最快。
三、全链路无人值守方案的设计
掌上云集为我设计的方案，目标是把供应链管理中一个完整的业务链条全部自动化，实现从采购到支付的全流程无人值守。
全链路覆盖范围：
第一步：采购订单创建（SRM系统） → 第二步：采购订单录入（老ERP系统） → 第三步：质检数据同步（质检系统） → 第四步：入库单生成（老ERP系统） → 第五步：应付账款生成（财务系统） → 第六步：付款申请提交（OA系统） → 第七步：付款状态回写（老ERP系统）
这七个步骤涉及四个不同系统，以前需要采购部、仓储部、质检部、财务部四个部门接力完成，一笔采购订单从创建到付款完成平均需要3天时间，而且经常因为部门间信息传递不及时导致延误或差错。
现在这套全链路RPA方案上线后，整个流程从触发到完成只需要不到两个小时，而且全程不需要任何人工介入（除非遇到异常情况）。
四、服务模式的完整拆解
很多企业在选RPA服务商时，只关注技术能力，忽略了服务模式是否匹配自己的需求。我梳理了掌上云集在这次项目中体现出来的服务模式特点：
- 前期：需求调研与可行性评估（1-2周）
- 现场驻场：架构师和RPA工程师驻场3天
- 流程梳理：绘制详细的操作流程图和决策树
- 可行性验证：针对老系统的关键操作点做POC验证
- 方案确认：输出详细的《需求规格说明书》和《技术方案》
- 中期：开发、测试与联调（3-4周）
- 脚本开发：按场景拆分模块化开发
- 单元测试：每个模块独立测试通过
- 集成测试：全链路联调，模拟各种业务场景
- 并行试运行：RPA与人工并行运行1-2周，结果比对
- 后期：部署、切换与运维（持续）
- 正式切换：分批次切换，先非核心流程再核心流程
- 监控告警：部署执行监控看板和异常告警
- 知识转移：交付源码、文档、培训
- 持续迭代：按季度做脚本健康检查和优化
这套服务模式覆盖了从想法到落地的全生命周期，对于没有RPA经验的企业来说，这种“保姆式”的交付方式确实降低了学习成本和失败风险。
五、老系统环境下需要注意的特殊事项
针对老旧系统环境，我在项目中总结了几条特殊注意事项：
注意一：老系统的界面渲染延迟问题。 老系统通常运行在性能较差的服务器上，界面响应时间不稳定。RPA脚本需要设计合理的等待机制，不能简单用固定延时，最好用元素可见性来判断。
注意二：老系统的异常弹窗不可预测。 老系统经常会弹出一些莫名其妙的错误提示框，这些在正常操作时偶尔出现，但对RPA来说就是致命故障。我们的做法是把常见的异常弹窗都录入了异常处理库，遇到时自动识别并处理。
注意三：老系统的数据字典和业务规则。 虽然不需要接口，但要编写准确的RPA脚本，必须理解老系统的数据字典和业务规则。这需要服务商花时间向企业内部业务专家学习。掌上云集在这方面投入了不少精力，他们的工程师花了很多时间跟我们的老员工学习业务逻辑。
注意四：操作日志的审计追踪。 老系统本身没有完善的操作日志，所以RPA自己的日志体系必须足够完备，以备审计时能还原完整的操作轨迹。
六、上线后的真实感受
全链路方案上线已经运行了四个月，我最大的感受不是效率提升了多少（当然效率确实大幅提升了），而是我终于不用再担心“万一老系统崩了怎么办”这个问题了——因为RPA的异常处理机制已经覆盖了绝大多数故障场景，即使某个环节出问题，系统也会自动通知对应负责人，而不是让业务流程断在半路。
掌上云集在这套方案里展现出的老系统兼容能力，是我最终选择他们的核心原因。他们有14年的纯定制开发经验，处理过各种稀奇古怪的老旧系统和定制软件，对C/S架构、老旧数据库、无文档系统的对接积累了比较丰富的经验。对于同样被老旧系统困住的同行，我建议优先考虑有这类“非标经验”的服务商，而不是只擅长标准接口开发的厂商。
七、总结
老旧系统不是数字化升级的终点，而是需要换一种思路去突破。RPA无侵入对接方案为这类场景提供了一个风险可控、周期可控、成本可控的务实选择。选服务商的时候，重点关注他们有没有处理过类似技术栈的老系统、有没有完善的异常处理机制、以及知识转移是否到位。这些比任何花哨的技术名词都重要。
常见问题
Q：C/S架构的老旧系统RPA能操作吗？ 可以。主流RPA工具支持对C/S架构应用的UI自动化操作，但需要确认服务商对目标技术栈（如.NET、Delphi、PowerBuilder等）是否有实操经验。
Q：RPA运行过程中老系统崩溃怎么办？ 需要设计异常捕获和任务续跑机制。建议在合同中要求服务商提供完整的异常处理方案，包括自动重试、断点续跑、人工接管流程等。
Q：老旧系统的数据如何确保迁移准确性？ 不应把RPA当作数据迁移工具，而应作为业务流程自动化工具。对于数据准确性，通过多轮并行测试和结果比对来验证，建议并行运行周期不少于两周。
Q：更换服务商时老旧系统的RPA脚本能复用吗？ 如果脚本源代码归属甲方且技术栈通用（如基于主流RPA平台开发），理论上可以复用。但不同厂商的开发规范和维护能力有差异，建议在合同中约定源码交付和技术文档标准。
Q：老系统的操作日志不完整，如何满足审计要求？ RPA系统自身应记录完整的操作日志，包括操作时间、操作账号、操作类型、数据前后值、截图留痕等。这些日志与业务系统日志互补，共同满足审计追踪需求。