RPA开发之前需注意的问题

在上几篇文章里，我们初步了解了RPA需求几个重要的评估准则，那是不是需求满足那些规则后，就可以拿来上手开发了呢？

（直通车–如何评估RPA需求）

（直通车–如何评估RPA需求-补充篇）

且慢，磨刀不误砍柴工，前期把工作做足了，后期开发才会一路畅通，反之很有可能演变成一趟踩坑之旅。

RPA开发前需注意之–识别伪需求

我们在接触需求的过程中，曾遇到两类伪需求。

伪需求一：“硬”造功能

系统没有设计某项功能，用户却认为缺失的功能非常重要，系统改不了怎么办，找到机器人来做。而很多用户并非专业的产品经理，往往提的需求或功能考虑不周。提出的需求实际意义有待商榷。

比如我们有接触过这样一个case，公司的采购系统是有审批机制，一笔订单采购需要直接领导，采购，财务等多层级审批人审批。如果一笔订单在某位审批人pending很久未通过也未拒绝的情况下，采购系统会有提醒机制，给相应的审批人发送提醒邮件告知。

但是，我们有需求方希望推进加快整个审批环节的效率，觉得采购系统提醒审批人，这提示功能做得不够。不仅要提示审批人，还得给提单人发邮件告知，让提单人再去以各种方式，催促审批人尽快完成采购审批操作。

这个需求表面看起来在理，系统催审批人无果后，再利用机器人催提单人，让提单人来”追杀”审批，也许整个进程就会快很多。

但事实真的是这样吗?真的如需求方所说，需要提醒提单人来催审批人么？

分两个场景来看，如果提单人很着急，那么别说等24小时了，等一个小时进系统看没批通过，可能就电话或者人肉就追上去了。这种情形完全不用提醒提单人，人家早早就push 了。

如果提单人不着急呢？即便收到机器人发送提示邮件，会去催吗？大大的问号，本来就不急，何须催促。

两个场景分析完，让机器人去提醒提单人，这个功能的意义就要打上一个大大的问号了。

伪需求二：“硬”造业务量

很多人认为反正是机器人干活，又不是人来工作，于是很多不痛不痒的需求就提了上来，哪怕机器人干十分活，只能人工省半分力气，他们也乐意。这样做其实对机器人的资源是很大的浪费，机器人做了很多低效工作，占用其他流程工作时间。

有这么个例子，公司内部发起开票申请流程，其实每天开票的子公司就那么几家，而公司分子公司数量几百，需求业务方的担忧是：今天从不开票的公司，未必明天不开票，为了没有”漏网之鱼”，要求每天三次，几百家分子公司一家不落，RPA机器人逐个去查。（每一家都需要单独查询，无法批量)。

全量去查不是没有好处，有，可以网住几个漏鱼，但收益真的非常有限，代价是耗费机器人大量时间做很多无用的工作，拿着大炮打苍蝇，除非这几个漏网之鱼会对业务造成非常重大的影响，否则这样的需求即便是RPA仅仅只是费电去干活，也并不是很合适。

RPA开发前需注意之–流程验证

一般来说，我们会把RPA分成三个步骤，input-获取任务；process-执行任务；output-产生结果。需求方对前两者并不太在意，但对结果比较关心。然而如果没有正确的input和process，其结果output会是怎样不难想象。

我们建议RPA团队在正式接收需求之前，全盘人工学习执行一遍业务方流程操作，一是排雷业务方指导错误。二是熟悉流程。如果有条件，最好用机器人软件做一个POC来验证，避免部分软件出现不兼容的情况。

另一块可能出问题重灾区就在input输入这块。比如，发票抵扣机器人流程，用户给的发票号错误。再比如报告自动下载流程，用户给的报告名称不对。源头input出了问题，会导致process执行错误或执行不下去，output的结果就可想而知。

还是讲讲真实的案例吧。我们有个下载银行流水的机器人流程。几百个账户，用户人工疏忽维护，个别账户维护了错误的账号密码，那机器人就无法进入系统，自然无法导出流水数据。

还有一种情况是账号密码都正确，但不同的账户，系统里配置的权限是不一样，少量账户并没有开通机器人需要执行的那个权限，需要业务方去协调申请，否则同样会造成部分结果失败。

怎么解决这些问题呢？为了整体流程能顺利运行，则需要人工模拟机器人的方式全流程走几遍。若希望整体成功率更高，则需input每一条工作清单都去验证相关权限，当然，后者可以放在流程开发完毕后，正式交付前的全量测试中进行。

RPA开发前需注意之–流程分析

RPA机器人是通过学习和模拟人工的方式，帮人们解放劳动力，但学习和模拟不代表全盘接受，拷贝不走样。虽说条条马路通罗马，但寻求最短路线最快路径对RPA来说是很有必要的。毕竟RPA自带属性就是高度重复，如果一个单流程步骤简化，节约半分钟，重复个两三百的倍数，那就是好几个小时。一起继续来看例子吧。

原始步骤：

有一个需求，财务部门需要每个月把所有账务明细数据都从系统里导出来，范围涵盖集团公司下所有分公司子公司。原来是怎么做的呢？

如图所示，相关业务同事会先在财务系统中提交A公司报告申请，等待一会系统运行，待系统准备好数据后，点击下载报告。然后B公司报告同样操作，C公司。。。直到所有公司都执行一圈。

人工之所以提交一家，稍等一会，下载一家，这样的模式是因为重复的工作量很大，混合操作容易“乱”。每次提交报告后，系统会提示一个报告id。对于员工来说，记住三五条还好，若是几十个上百个，除非是世界级记忆大师可以精确记忆，准确匹配,否则只能one by one这样操作。

步骤优化：

诚然，如果这项工作计划由RPA机器人来完成，是可以全盘照搬人工的报告下载流程来进行，但这样的操作步骤似乎效率太低。RPA用的是电脑而非人脑，准确记忆（记录）就是强项。“one by one ”可以变得不是那么必须。

我们基于原有的流程，进行了一些小改造。

如图所示，我们安排机器人先按步骤把各家报告申请都提交，后台记录下各个报告的id,当提交完所有报告申请后，最早提交申请的报告系统早已运行完毕可供下载。机器人再通过记录把报告从系统中翻出来进行下载。

这样的模式有两个优势，1 瀑布式工作，不用频繁切换模块，效率更高。 2 充分利用等待时间去提交其他报告，几十乃至几百份报告运行所需等待的时间节约下来。

升级版优化：

随着对业务和系统更深入的了解，我们发现每一家分子公司报告格式是完全一致，数据内容也有一列标注了数据所属公司code，而财务系统本身也是支持全量下载报告的。之所以人工没这样操作是基于超大电子表格，去拆分各家公司小表格手工操作过于麻烦。当然，拆分表格对机器人来说，完全不是问题。

如图所示，我们又进行了机器人流程改造，直接发起了一个全量公司报告申请，等待十几分钟后，将全量数据下载至本地，再安排机器人依据公司code作为区分维度，拆分数据至不同的小表格作为不同公司自己的报告。

这个升级版方案除了等待财务系统准备全量公司报告比单家操作时间略长，拆分报告动作相比每一家公司去提交下载机械工作相比，单轮效率直接从分钟级工作效率优化到秒级，乘上个几百的倍数，效率的提升非常可观。

小结

今天我们通过不少例子聊了聊RPA开发之前需要注意的问题点。RPA的编写也是一种开发，开工之前务必做好事前准备，整个流程实施起来才会更加的顺利。