RPA 和低代码平台怎么选，各自的短板在哪
低代码平台和 RPA 常被放在一起比，但两者不在同一个维度。低代码是开发平台，造的是新系统，RPA 是代替人操作软件的工具，干的是既有的活。真正的分界是流程的数据最终落在哪个系统的库里。这篇讲清两者差在哪四个地方、混着用怎么搭，以及低代码和 RPA 各自什么情况下该退出去。
同一件事的两种做法
需求来了，部门说这个流程想自动化一遍。IT 面前通常摆着两条路。一条是低代码平台，拖拽配置，几天出一个表单加审批。另一条是 RPA，机器人登录现有系统，模拟人操作，把数据搬来搬去。
会议室里最常问的一句话是，低代码平台能替代RPA吗，以后是不是只留低代码就够了。
这个问题问得早了一点。低代码平台和 RPA 压根不在一个维度上。低代码是一个开发平台，它造的是新系统。RPA 是代替人操作软件的工具，它干的是既有的活。两者的产物不同，代价不同，失败时的样子也不同。
要说 RPA和低代码的区别，能拿来判断的只有一件事。这条流程最后的数据，落在哪个系统的库里。
很多人以为 RPA和低代码的区别在于功能多少。低代码能不能点开另一个系统的网页，RPA 能不能拖出一个漂亮的表单，这些都不重要。功能清单可以互相抄，抄来的功能用起来还是两种手感。
流程落在哪，差别就在哪
设想一个具体场景。财务每月把 OA 里审批通过的报销单录进财务系统，录完还要把结果回填到 OA。
这条流程有两条实现路径。
低代码平台的路径，是重新做一套报销表单放在平台上，审批走平台，数据进平台自己的库。然后再想办法把这份数据搬到财务系统里去。
RPA 的路径，是机器人登录 OA 读出审批结果，登录财务系统一条条录进去，录完回填。
两条路径的最终数据都进了财务系统，区别在中间那一段。走低代码，数据先在平台存一份，是一份拷贝，平台自己成了数据的第二个来源。走 RPA，数据从 OA 直接到财务系统，OA 还是唯一来源。
这就是那条分界线。如果一条流程从头到尾是新建的，数据天生就长在平台上，低代码直接做，省事得多。如果这条流程的核心数据在老系统里，而且那个老系统是权威来源，RPA 更顺，因为它不去建第二份数据。
选低代码还是选RPA这个问题，落到实处的判断是这条流程的数据归属，不是工具偏好。也有人反过来问，低代码平台能替代RPA吗，答案是能替代一部分，另一部分替代不了，替代不了的那部分恰好是最费劲的那部分。
具体差在哪四个地方
把两条路径摊平对比，有四处差别最要命。
第一处，交付物。低代码交付一套新系统，包含表单、页面、审批流、报表、权限。这套东西上线之后归你维护，以后业务提新需求，是在这套东西上加字段、加流程。RPA 交付一条流程，流程挂在别人的系统上跑，你自己这边多出来的是一份流程定义加一份操作说明。
第二处，对目标系统的要求。低代码通常要求数据最后能被它访问，常见做法是把数据导进它的库，或者接对方的 API。RPA 的要求低得多，目标系统有个网页界面，账号能登进去，机器人就能操作。这个差别在老系统上体现得最明显，有些老系统连 API 都没有，只有界面。
第三处，出错时的样子。低代码平台一般自带流程状态和重试，某个节点失败可以退回前一步，表单数据还在。RPA 停在某一步的时候，页面往往停在半截状态。录到第三笔的时候，对方的系统里可能已经留了一条不完整的记录。这个坑很实在，也是很多团队上 RPA 之后半夜被叫起来处理的第一件事。
第四处，谁来改。低代码改的是配置，业务的人自己能拖两下改个字段。RPA 改的是流程定义，改动通常落在开发或者流程工程师手里。业务方提一句这里要加个审批环节，落到 RPA 上就是排期。
低代码赢在哪
低代码平台的价值在于它把软件开发的门槛降下来了。
做一套内部用的报工、审批、领用、盘点表，拖拽加配置，几天能出东西，业务人员自己就能改。权限模型、消息通知、审批流转、数据看板这些是平台自带的，不用自己造。数据都在自己的平台里，建什么模型就是什么模型，不用迁就谁家的接口。
这些优势在纯内部流程上最明显。业务在自己的平台上提需求，自己就在平台上改，IT 不需要每个字段都排期。
低代码还有一个常被忽略的好处，流程本身是一等公民。表单、流程、权限、消息、报表连在一起，改一个字段下游跟着动。做 RPA 的时候，流程的每个环节是流程定义里的一段，谁改字段谁改流程，改完还要回归一遍。
RPA 赢在哪
RPA 的价值在于它能进入一个你无权改造的系统，并且把这件事做得稳定。
目标系统是别人的，接口不开放，数据口径只有那里最准。RPA 从界面上取数，绕开了接口，绕开了对方排期，也绕开了改造老系统的风险。跨系统的搬运也是，多个系统之间转数据，每个系统字段都不一样，人工复制粘贴最容易错，机器人按固定规则搬反而可靠。
还有一类活 RPA 干得比低代码好，就是操作对象本身就是界面动作。填一张网页表单，点一个下载按钮，在一个老式客户端里勾选一堆选项。这些事低代码接不上，它的组件围绕自己的表单和流程设计。
RPA 和低代码的差别，说到底是改造新系统还是接管旧流程。低代码改的是自己的东西，RPA 接管的是别人的流程。
混着用怎么搭
不少团队最后两边都用，各干各擅长的活。常见的搭法是这样。
低代码做前台，收集和审批。员工在网页表单里填单，提交，审批流在平台上走。这一段数据天生在平台里，用低代码最顺。
RPA 做后台搬运。审批通过之后，平台把待办推给 RPA，机器人登录下游系统取数或者写回，写完把结果回填到平台表单上，通知相关的人。
分界线画在数据边界上。平台到平台这一段是低代码，平台到外部系统这一段是 RPA。
这么搭有几点要提前想清楚。
- 交接给谁。平台和 RPA 之间传递的是数据，得定一个双方都认的格式，中间字段谁负责。
- 失败了怎么办。RPA 那段失败，平台上的单子是什么状态，能不能重跑，重跑会不会重复写。
- 怎么查。平台有日志，RPA 有日志，两边的记录要能对上一条单子。
混着搭的代价是排查链路变长。一次数据不对，得先判断是平台填错了还是机器人搬错了。所以两边都要留痕，留同一套单号。
什么情况下别选
低代码平台有它不该接的活。
流程的最终数据必须留在老系统里，而且老系统是唯一权威来源。这时候在平台里做一套，就是多一份数据源，对账的时候要解释两份数据为什么不一样。常见于财务、库存这类口径敏感的地方。
目标系统只有界面，没有接口，也不肯开接口，还要求数据留在它那边。低代码的数据出不来，这条路直接断。
还有一种情况，业务自己就想在平台里建一套新系统，替掉某个没人愿意维护的老流程。这时候硬用 RPA 去操作那个老流程，等于把一个该淘汰的东西续命三年。
RPA 也有不该接的活。
流程是纯内部新建的，没有老系统要接管。低代码几天做完，RPA 要写流程要测要维护，成本差着量级。
流程一个月跑不到几次。做一条流程的成本摊到几十次运行上，每次省下来的时间还不够还开发成本。
业务规则一天一变，或者规则本身要人判断。规则写不进流程定义，就会变成一个不断打补丁的脚本，越改越脆。这种活让 RPA 做，一年下来没人愿意维护。
目标系统改版频繁，改完没人通知，界面一变机器人就找不到控件。这种情况下维护成本会慢慢吃掉自动化省下来的时间，到某个点不如手工做。
三个问题问完，方向就清楚了
选型会上问这三个问题，答案基本能定方向。
一，这条流程最后的数据落在哪个系统的库里，是新平台还是老系统。
二，这个目标系统有没有 API，接口稳不稳定，有没有人在管它。
三，这条流程半年里会改几次，将来改它的是谁。
第一个问题定路线，落新平台就往低代码走，落老系统就往 RPA 走。第二个问题定可行性，接口稳定就优先用接口，RPA 是接口不稳时的退路。第三个问题定成本，改得频繁又没人能改的流程，自动化本身会变成负担。
三问都答完，工具基本就那一个了。这时候再去比平台功能，比的是价格和易用性，不是能不能做。选低代码还是选RPA这个问题，问到这一步基本有答案了，剩下的时间是拿去和供应商谈条款。
延伸阅读