今天谈下RPA机器人流程自动化，因为RPA这个概念在我脑子里面转了快2年了，一直没有深入去分析下具体的应用场景和解决的问题。在我看数字化转型的很多文章和技术的引入的时候，很多都会谈到通过RPA机器人来实现自动化和智能化。
因此有必要专门写篇文章来谈下PRA机器人。
RPA机器人流程自动化概述
首先还是看下百度百科对RPAd的一些标准定义和说明。
机器人流程自动化（RPA）系统是一种应用程序，它通过模仿最终用户在电脑的手动操作方式，提供了另一种方式来使最终用户手动操作流程自动化。
在传统的工作流自动化技术工具中，会由程序员产生自动化任务的动作列表，并且会用内部的应用程序接口或是专用的脚本语言作为和后台系统之间的界面。机器人流程自动化会监视使用者在应用软件中图形用户界面（GUI）所进行的工作，并且直接在GUI上自动重复这些工作。因此可以减少产品自动化的阻碍，因此有些软件可能没有这类用途的API。
机器人流程自动化工具在技术上类似图形用户界面测试工具。这些工具也会自动地和图形用户界面上互动，而且会由使用者示范其流程，再用示范性编程来实现。机器人流程与自动化工具的不同点是这类系统会允许资料在不同应用程序之间交换。例如接收电子邮件可能包括接收付款单、取得其中资料，输入到簿记系统中。
流程机器人（RPA）软件的目标是使符合某些适用性标准的基于桌面的业务流程和工作流程实现自动化，一般来说这些操作在很大程度上是重复的，数量比较多的，并且可以通过严格的规则和结果来定义。
成功部署企业RPA带来以下好处：
- 更高的运营效率：节省时间并释放员工的能力
- 增强准确性，可审计性，监视，跟踪和控制业务流程执行
- 可扩展且灵活的增强型“虚拟”员工队伍，能够快速响应业务需求
- 协作和创新的文化，使我们的业务人员和IT人员可以一起工作
实际上上面百度对RPA的定义说明已经相当清楚，即RPA是通过机器人来模拟人，将人在一个应用系统或多个应用系统间的可重复操作自动化掉。
RPA使用场景进一步分析
当我们在谈RPA机器人的时候，一定要重点关注一个核心要素，即RPA本身对已有的应用系统无侵入，类似一个模拟人操作的外挂。理解了这个点我们才好开始讨论RPAd的一些应用场景。
对于应用场景，我们仍然选择一些有代表性的场景进行讨论和说明。
场景一：应用系统不受你控制或调整
这个是RPA应用很主要的一个场景，即你使用的应用系统并不受到你的控制，或者会完全满足你的需求而调整。比如一个企业每月都需要进行报税操作，但是报税的内容以及完全整理在一个Excel文件里面。
这个时候你肯定是希望有一个功能能够直接批量一次性导入Excel文件完成报税操作。但是报税系统往往并不会提供这种功能。即使你报税的过程如此繁琐和重复，但是也需要人工去完成，你也无法推动系统进行变更。
那么这种场景下使用RPA机器人是合适的。也就是说通过机器人来模拟人完成上述动作，只要我能够将规则定义清楚，让操作步骤完全可重复，那么一定就可以自动化。
场景二：应用的UI级自动化测试
说实话，当我第一次看到RPA机器人的时候，马上就会类别当当前的自动化UI测试工具。或者说是规则(Python脚本)+自动化UI测试工具。
RPA机器人完全就是一个支持规则灵活配置和定义的UI自动测试和验证工具。
那么当然RPA机器人就可以应用到当前的自动化系统测试中，比如常说的UAT测试，完全可以通过RPA机器人来完成在UAT阶段的各种回归测试操作。
场景三：类似按键精灵的所有场景
对于RPA机器人应用的发展源头，实际上往往就是两类。一类就是前面谈的基于规则的UI自动化测试工具。还有一类就是类似按键精灵的模拟鼠标，键盘动作并自动化录制和执行的工具发展而来。
两种场景都是为了解放人，让工作自动化执行。
但是本身两种场景产生的背景又有明显的差异，对于第一类场景重点是单人执行多步的业务流程和操作并通过流程来自动化。而对于场景二往往则是在多人制定简单重复操作上。
当你清楚这个后才清楚按键精灵这种更多的是使用在了你有多个应用或手机终端下执行简单重复操作上，类似秒杀抢购，挂活跃在线用户，僵尸粉等的评论，点赞等操作上面。也就是说有了类似按键精灵，你一个人操作100台手机都没有问题。
场景四：多个已有应用系统间的协同
这个场景实际上是场景一的扩展。即当要完成一个操作的时候，你发现需要在多个业务系统中进行操作和协同，但是这些操作本身是有规律可以寻找，并且在提取规则后可以重复和自动化的操作。
我们举一个例子来说明：
一个企业上SaaS化的报销平台，实现了差旅费和日常费用的报销。但是SaaS应用本身在报销完成后，还需要手工将凭证数据录入到内部的类似金蝶等财务管理软件中。如果一天要处理100个报销单，那么就需要完成100次数据的录入。
这个过程本身没有复杂的规则，完全可以考虑将在两个系统间做的事情自动化掉。这个自动化本身应该是两个业务系统间通过接口来完成集成的事情，但是由于你无法推动，导致你需要通过类似RPA技术来实现自动化。
再举一个例子：
一个企业每个月要开一次会，在会上都需要对企业的经营情况进行汇报。但是汇报数据往往需要查询ERP，合同，采购，报账等多个业务系统的数据，然后再整理到Excel中，最后再通过Excel出最终的报表或图表展现。
整个过程本身也是有章可循，也是重复性工作，那么我们同样可以考虑通过RPA机器人来实现自动化操作。
RPA只是一个临时外挂
首先我要表明自己的一个观点，即：
RPA仅仅是数字化转型或企业信息化建设过程中的一个临时外挂，而非终极解决方案。RPA存在的原因是我们在无法推动应用重构和优化中所做出的妥协。
临时方案还是最终方案？
在几年前，我们上线的一个应用系统出现了一个问题，即应用系统大量产生应用日志，不断地将磁盘写满。而对于这个问题，我们在前期采取的思路是编写了一个类似RPA的自动化呈现，定时地去将日志文件进行处理，仅仅将日志中涉及异常部分保留，其它全部删除掉。同时对于日志文件进行压缩处理并释放磁盘空间。
而在去年我们彻底进行了大的优化和重构，即对应用系统中日志管理部分逻辑进行改造，通过应用自动去清理和压缩日志，同时自动将历史日志从本地磁盘迁移到NFS分布式存储中。
上面两个方案，第一个是临时方案，第二个是彻底解决。
而对于RPA机器人整体感觉即是一种解决问题的临时方案而不是终极方案。
存在需要RPA的场景我在前面也谈到了，即你无法去推动业务系统去优化和变更，特别是当你使用外部系统的时候。
比如你通过银行去发员工工资，但是这个银行本身就没有代发工资或批量转账发工资的功能。你虽然整理好了Excel工资表，你还需要一个个的手工去处理。那么这个问题临时方案是RPA，而更好的方案是银行提供批量发工资的功能。
其次，就是RPA帮助你去解决了多个系统间的集成问题，这个集成问题本身应该是两个系统通过接口进行集成，但是你无法去推动，或者说集成本身成本和代价很大，因此你采用了类似RPA的解决方案来处理。
还是接着上面的例子进一步说明
企业本身实施了报账系统，在报销系统中按道理员工的报销单审批完成后，应该自动形成应付发票或凭证，基于凭证就应该自动和银行连接来完成报销打款操作。这个时候你无法去集成和协同两个系统，因此采用了RPA机器人。但是更好的方式是实现报销系统和银行系统间的接口集成，类似我们常说的银企互联，最终完成整个流程的自动化操作。
建设总结就是本应该是两个业务系统经过底层API或接口集成来完成协同的事情，有由于成本或无法推动的原因，你选择了RPA方案来解决。
为何不建议RPA？
前面已经谈到了临时方案和最终方案的差别，如果条件允许一定是采用最终方案来从根本上解决问题，而不是选择一种临时方案。
RPA通过机器人自动化，但是本质还是模拟的人。一个好的自动化方案和提升效率的方案一定是应用底层逻辑的自动化和批量化，应用系统间的自动化接口和数据协同。这往往才是最高效的。
当你使用RPA的时候，你还面对如下问题需要解决。
其一是人员技能水平，一个RPA真正的价值往往并不是完全简单的可重复，而是通过抽取规则后变得可重复，而规则的抽取和定义，往往就偏技术知识和技术思维，对人员的IT技术要求会增加，这个不是一般的业务人员能做到的。
如果不是给一般业务人员用，而是给IT人员用，那么又出现一个悖论，你会觉得有开发经验的IT人员会去使用RPA解决问题吗，这个估计还没有自己写点Python自动化的脚本来的快。
当然如果真在业务人员有自动化思维，估计在没有RPA之前自己也已经将Excel工具，宏录制和自动化等用得滚瓜烂熟了。这些使用起来完全可以起到类似RPA的作用。
其二是应用本身的变更容忍度，由于应用系统对你不可控，因此你采用了RPA的外挂来解决问题，那么自然你对应用系统的变更也不可控。那么应用功能一旦出现变更，你会发现你原来录制的脚本和规则都要进行修改。
那么可以看到应用变更越频繁，录制脚本和维护脚本的工作量也就越大。这个工作量投入往往并不比你重复录入数据小，对于频繁变更的应用自动化本身就没有价值。
其次就是应用虽然变更不频繁，但是对于规则要求极高，那么通过RPA机器人自动录入一些数据进去你能够做到完全放心吗？是否还会出现RPA帮你处理完成后，你还得去做重复检查的情况。
我们再把上面的场景扩展一下。
一个企业在某个业务场景下引入了RPA机器人给业务人员用，那么如果业务人员采用RPA机器人后导致了应用系统中的数据出现了错误，这个时候的责任人究竟是谁？公司领导是去找RPA机器人的麻烦还是业务人员的麻烦。
你自己通过一些excel或python脚本实现一些自动化，公司领导不关心，因为最终系统中数据正确性的负责人还是你自己。但是公司层面去引入RPA机器人，为了是减轻员工重复处理的工作量，还要为最终应用数据正确性担责，我想没有哪个领导愿意去做这个事情。
多系统集成和持久化场景是关键
在前面谈了RPA的应用场景，再次强调下对于RPA解决方案，涉及到的多个业务系统间的自动化集成和协同往往才是一个关键的需求点。
这类场景由于涉及多个系统，推动的难度最大，因此采用RPA方案是一个可行的选择。
同时要看到当你处理多场景协同的时候，一定存在中转和数据的暂存，一个好的RPA方案一定需要提供数据的持久化处理机制。比如数据导出到Excel 或写入到数据库，再比如RPA可以自己去定义中间的数据对象存储等。
典型的场景就是类似前面谈到的在报销系统中先查询中已经报销审批完成的单据，然后将单据导入到ERP系统中去。如果要实现这个完整过程，实际上需要对中间报销单据进行暂存，以方便中间的处理和数据清洗。
如果没有这种暂存和数据持久化能力，那么RPA就变成了独立两段操作，没有意义。
数字化阶段需要的是底层真实连接
最后再次总结下，在数字化阶段我们一直在强调连接，强调万物互联。这个连接需要的一定是物和物，人和人，人和IT系统之间的真实连接。同时进一步的期望是将人和IT系统间的连接转变为底层自动化数据采集和自动连接，转变为底层IT系统之间的自动化接口对接。
对于RPA，如果是在解决传统企业IT架构，传统应用间业务和流程协同的问题，那么RPA确实是一个好的解决方案。但是在数字化阶段，我们对连接的理解已经发生了根本改变，这个连接绝对不是靠机器来模拟人完成的。
靠机器模拟人来解决自动化问题，往往让你进一步忽视了对事物本质问题和根源的探索，让你很难从底层系统构建逻辑去解决该有的问题。
简单来说RPA本身是反数字化思路的，只是将人和物，人和IT系统之间的一些连接自动化掉了，而不是从本质上去解决问题。
一个核心的数字化逻辑应该是连接本身就应该是底层自动化技术来解决掉，而不是通过机器人模拟人来自动化掉。其次，数字化下的流程本身就应该是自动化协同，而非是通过RPA才能够完成自动化协同。
任何通过RPA才能够完成的自动化协同流程，都不是一个好流程。