如何评估RPA需求？

在当今数字化的商业环境中，RPA（Robotic Process Automation，即机器人流程自动化）的需求日益增长，因为它能够帮助企业提高效率、减少错误、节省成本，以及提高员工满意度。然而，尽管RPA的潜力巨大，但并不是所有的流程或任务都适合自动化，也并非所有的组织都具备实施RPA的技术能力。因此，对RPA需求进行准确的评估是至关重要的。这涉及到对组织的目标、流程、技术能力和资源进行深入的理解和分析。

在这篇文章中，我们将讨论如何评估RPA需求，以帮助你确定RPA是否适合你的组织，以及如何最有效地利用RPA。可以参考下图中五项要点。

在这里插入图片描述

1、大量的、重复的

需要关注的是某项需求的投资回报率（ROI）的是多少，量级越大，每月工作重复内容越多，若由RPA来实现替代，ROI的分子–收益就越多，这个项目的经济价值就越大。

在这里就不赘述大量和重复的意义，但有一点参考：不同于传统系统开发，RPA的价值虽倾向于长期高频的任务(每日甚至每小时)，但也有不少一次性但巨量的任务，RPA也是可以施展拳脚的。

在一个历史项目中，我们面临了一项为了满足业务增长而进行的大规模升级。这个升级涉及到ERP系统的迭代，以及财务科目编码规则的改变，从原本的6位编码扩展至10位。此外，相关的辅助字段编码也进行了调整。在这个升级过程中，我们可以通过在ERP系统内部导入数据库来完成升级。

然而，问题在于我们的采购系统，这是一个与ERP系统对接的外部SaaS平台。由于安全考虑，采购系统的供应商不提供后台数据库修改，也不提供接口调整。他们仅支持通过前端页面进行操作，也就是说，我们需要手动打开采购系统的网页，逐个找到相关订单，并更新财务科目代码及辅助字段编码，然后保存。

这项工作涉及到数万条数据，需要花费上千小时，这个工作量远超出了人力可以承受的范围。

但面对如此数量级的重复工作，即使开发的RPA流程用上这一回，也是值回前期开发投入的“票价”。最终通过不到十个小时的开发和调试，配置了10台电脑经历了4天连轴转，以100%准确率，轻松完成这项数据迁移工程。

在这里插入图片描述

由此可见，一个RPA项目无论长生命周期也好，一次性应用也罢，关键衡量点是其产出是否可以覆盖前期开发投入，并多多益善。

2、明确的规则

明确的规则有三层要求：1 详细规则；2 内容准确；3 严格遵守

详细规则

以系统登录为例，虽然只是一项简单的任务，但实际上，根据具体的登录方式，步骤可能会有很大的差异。

例如，如果采取扫码登录的方式，那么你需要在手机端已经登录了该软件，并且进入扫码模式，在完成扫码后，还需要在手机端进行登录确认。

如果是验证码登录，那么你需要输入手机号，然后注意查收验证短信，并将收到的验证码填写回系统中。

如果是账号密码登录，那么账号密码需要提前储存，当需要登录的时候，再读取并输入。

除此之外，还有一些其他的登录方式，比如跳转登录、插Ukey登录、Token随机码登录等等。不同的登录方式需要采用不同的自动化解决方案。有些登录方式可能由于技术限制无法实现完全自动化，这就需要考虑人机协作机制。因此，对登录步骤的详细规定显得尤为重要。
在这里插入图片描述

内容准确

以下图系统为例，虽两个系统模块名称类似，功能也近似，但某项功能是“New”版独有，若业务需求方对系统不熟悉，给出错误指导，开发出来的机器人有可能方向走偏。当然，最好的应对方式是照着业务需求方提供的指南再摸索一遍，大部分问题可以在摸索的过程中暴露出来并在设计方案中及时修正。

在这里插入图片描述

还有一些问题可能相对隐蔽，比如下图中，业务需求方要求页面展示的数据都全量导出，给出的指导方案是勾选红圈中全选框，再点击导出。这是按照正常逻辑的操作，小范围模拟也没有问题，但RPA项目交付后，发现当遇到几十条数据时，RPA导出的数据经常缺内容。事后追踪才发现，问题恰恰出在全选框，当全选框勾住后，意味着选中当页所有数据。当数据超过页面限制的15条，或者更多数据时，正确的做法是不进行任何勾选，直接点击导出。

在这里插入图片描述

当然，不同的系统勾选和选中的逻辑可能有所差别，业务需求方也并非产品经理，提供的操作指导仅作为参考，不可照抄。此外RPA方案并非仅限于人工的单纯模仿，因为是代码操作效率相比人工更高，不少场景是可以改造优化的，比如人工操作是单个下载数据，而RPA可以走批量下载功能，再后台拆分数据。当然，这是之后的方案设计环节了，之后文章再展开来分析，总之在RPA方案设计之前，对相关系统的功能熟悉理解也是RPA项目组的重点要求之一。只有熟悉了系统，才可确保与业务沟通需求后，可以正确理解甚至纠正业务某些不正确的指导操作。

严格遵守

如涉及人机交互的RPA流程，这是对业务方的要求，需要提前确认业务方的配合程度。比如人工交给机器人的表格，规则约定内容在sheet1，就不要填在sheet2；约定好的密码就不要修改；约定按照电子表格提供，就不可打包成压缩包。如没有严格遵守，人工可以灵活应对，但对于RPA机器人可能就是无法正常工作的大问题。

在这里插入图片描述

一般而言，人机交互的“业务方”参与人数是一两位，业务配合度会高一些，若“业务方”参与人数是一个中大型团队，甚至十几甚至几十人，很难确保每一位都百分百配合规则，难免有人遗漏，给机器人造成的故障轻则单个任务失败，重则整套流程卡死，延误工作进度。

比如有个项目，我们指定一个公共邮箱收集业务派发出来的账单任务，当RPA收到邮件里的附件后，便开始后续一系列与系统账单核对的工作。为了防止其他邮件干扰机器人，设置了一个“出账待处理”邮箱文件夹供机器人读取，并指定了主题含“首次账单”及“二次账单”关键字方可自动归入此文件夹。规则与业务团队同步后，却频频收到业务团队反馈RPA“无故旷工”，任务邮件发给RPA后“杳无音信”。当检查邮箱后，结果啼笑皆非，有不少业务同事会将主题错误命名为“账单”、“第一次账单”、“再次账单”，这种命名从人的角度来很好理解，但对机器代码来说，没有按规则的命名邮件都进不了指定的文件夹，更不可能让RPA去执行并完成任务。由此可见，如有人机交互的项目，业务团队的高度配合也是必不可少的一环。

在这里插入图片描述

3、结构化（半结构化）数据

Garbage in, garbage out，没有规范和正确的输入，无论是RPA机器人或是其他系统都难以给出正确及理想的输出。对于机器来说，长篇大段的优美文字反而属于garbage级别的数据，即使智能AI、语义理解高速发展的今天，机器的理解和人类还是有较大差距。

电子表格作为日常办公工具，也是RPA最常处理的数据载体之一。电子表格的合并单元格功能对人显示友好，对RPA来说却是大忌，如果将合并后的数据交给给RPA，是很难让其顺利完成工作的。比如下图中的案例，“人”填写的表格，即便是其他“人”无需特殊户解释也能理解表格内容。然而，同样一份表格，到了RPA这“机器人”这里却变得难以理解，甚至会丢失正确的表头信息，导致运行错误。

在这里插入图片描述

因此如果我们业务团队习惯于合并单元格，那之至少数据交给RPA之前，请将合并后的表格都恢复成常规表格，检查数据无误后，再由RPA来处理。

4、业务&系统相对固定

业务相对固定就比较好理解了，如果业务三天一变，需求两天一改，则RPA的代码逻辑可能无法满足业务最新需求或执行错误，那再如何高效自动化也没有意义。

系统相对固定是指，如果哪些需求希望由RPA来实现自动化，所涉及的系统或平台尽可能的低频调整，最好是不调整。我们曾为财务团队做过基于某付宝和某信支付商户平台的流水下载自动化项目，项目很快上线，但运行一段时间后RPA的工作始终不太顺利，原因就是这两个支付平台迭代过于频繁，过几天改界面，再过几天调整下载方式，RPA机器人长期处于半运行半调试的状态，难以长期稳定运行。后经多方评估之后，开发工程师的运维成本甚至高于自动化的收益，不得不放弃这个项目维护。

我们另有一个RPA项目涉及聊天工具某钉，设计方案是在此聊天工具中下载由员工能上传的入职相关材料，如证件、证书等信息，可以一定程度上降低HR同事收集信息工作量。然而在丰满的理想身后，现实更加残酷，聊天工具某钉不仅推陈出新的频率很高，而且还有着不少反机器人措施：滑动验证码、短信验证码、扫码验证等等拦路虎使得RPA自动化难以顺利继续。

因此，当一项新的需求涉及的系统或平台频繁变动或是近期可能调整发生变化时，建议多方评估其变动风险，三思而行。

5、例外事项较少

系统方面，除了功能固定，稳定性也需要重点考量，如果一个系统的稳定性较差，那我们编写RPA的流程虽然只是做一件事，但需要储备上四五条意外应对措施，整体的工作效率就降低很多，且额外的应对措施也会产生较多的开发工作量，还使整套流程臃肿。

我们曾有一个项目是为国外客户，通过RPA实现工单系统自动提单功能，内容并不复杂：登录、新建工单、配置收件组、插入附件、保存发送。但由于该客户工单系统多年疏于维护，稳定性较差，有各种例外情况需要应对，导致实际工作量会比预期暴增。

从下图对比就能看出，从登陆系统开始，登陆界面是随机中文界面或英文界面，我们不得不为此制作两套双语登陆模块，遇到什么用什么。接下来，即便是正确的账号密码登录，还是有可能加载失败，只能不断的关闭浏览器再重新登入重试。提交附件也有不稳定因素，上传的电子表格附件，有一定概率被系统误判为存在病毒风险，解决方案也很简单，同样文件再重试一次，因此，上传附件动作也要加入各种状态判断，再基于不同的状态进行下一步操作。

在这里插入图片描述