1.1　从基本概念谈起

RPA是Robotic Process Automation（机器人流程自动化）三个英文单词的首字母缩写，该概念有别于新兴的人工智能技术，如机器学习、深度学习、神经网络等，这些人工智能技术大多来自学术机构或科研单位的研究成果，学者们首先会通过一些论文和报告对某个技术给出清晰的定义，然后由相关科技公司研发和生产相关产品。而RPA概念来自信息技术自动化实战经验的总结。

1.1.1　RPA概念溯源

RPA概念由一家研发此类软件的IT创业公司和一家研究机构在2012年提出，远迟于机器学习（1959年）和深度学习（1986年）等概念的提出时间。随后，RPA逐步在外包服务领域以及为外包服务提供软件的厂商中推广开来。所以，RPA更多是通过厂商和用户的实战总结、口口相传后逐步推广开来的，所以目前尚无机构给出公认的权威解释。正由于此，在后续市场推广和宣传RPA的过程中，各软件厂商和服务供应商对RPA概念各执一词，使最终用户对RPA概念缺乏统一的认识。

如果只从字面来理解，“机器人流程自动化”其实就是“利用机器人技术来实现流程的自动化处理”。当然，将这样的简单字面理解直接作为RPA的定义，是远远不够的。要真正理解什么是RPA，通常需要对以下问题进行剖析。

第一，RPA是什么样的机器人技术？比如，这是个新技术还是传统技术？是人工智能技术的一种吗？与工厂里的机器人是一样的吗？

第二，RPA可以实现哪些流程的自动化？比如，像企业内已经实现的办公自动化吗？与利用工作流引擎来实现的自动化有什么区别？

第三，RPA可实现什么程度的流程自动化？比如，它能帮助或替代人类做什么？完全不需要人参与吗？

这三点也是在第一次听说RPA时，所有读者和用户头脑中首先冒出的一些疑问。

首先我们找到一些关于RPA的官方解释，然后对其内涵逐步细化和展开。

1.1.2　RPA的官方解释

隶属于IEEE标准组织，由领先的RPA软件厂商和咨询公司共同参与组成的一个工作组，针对智能自动化（Intelligence Automation）开展了一项概念梳理和定义工作，希望对智能自动化各个部分的概念达成行业共识。显然，这些概念的定义真正在行业中被广泛采用还需要相当长的时间。

2017年，IEEE给出了RPA的定义：“RPA通过软件技术来预定义业务规则以及活动编排过程，利用一个或多个相互不关联的软件系统，协作完成一组流程、活动、交易和任务，需要在人工对异常情况进行管理后交付结果和服务。”IEEE强调了RPA具有预定义规则、活动编排、串接不同的系统等主要特征。

“机器人流程自动化及人工智能”（IRPAAI）研究机构在2017年也给出了RPA的定义：“RPA是一种技术应用模式，使计算机软件或者‘机器人’能够捕获并解释现有应用的信息，从而能够处理事务、操作数据、触发响应以及与其他数字化系统进行通信。”IRPAAI强调了它是一种应用模式，具有获取现有应用的信息、不同系统的操作处理等特征。

Gartner在2018年AI技术曲线报告中对RPA进行了定义：“机器人流程自动化整合了用户界面识别和工作流执行能力。它能够模仿人们操作电脑的过程，利用模拟的鼠标和键盘操作来驱动和执行应用系统。有时候，它被设计成应用到应用之间的自动化处理。虽然它被称为机器人流程自动化，但是并不存在一个物理设备，相似于其他如工作流引擎和人工智能工具。”Gartner指出RPA能模仿人类，具有工作流执行能力，是软件并非物理设备。

IDC组织的“RPA软件带来业务运营变革”报告（2017）给出了RPA的定义：“RPA软件能够处理基于固定规则且重复执行的流程，而不需要人类操作。在那些高度重复、单调且劳动量大的工作中，RPA消除了对人类员工处理的需要。”IDC表达了能实施RPA的流程具有规则固定、重复执行和工作量大的主要特征。

IBM组织的“市场研究及远景趋势”报告（2017）给出了对RPA的定义：“机器人流程自动化（RPA）是利用软件来执行业务流程的一组技术，其按照人类的执行规则和操作过程来执行同样的流程。RPA技术可以降低工作中的人力投入，避免人为的操作错误，大大减少了处理时间，使人类可以投入到更加高级的工作环节中。”IBM强调了RPA是一组技术、按照规则执行流程，以及RPA带来的业务价值。

麦肯锡（McKinsey）给出对RPA的定义：“RPA是一种可以在流程中模拟人类操作的软件。它能够更快速、精准、不知疲倦地完成重复性工作，使人们投入到更加需要人类脑力的工作中，如情感、推理、判断或与客户沟通。”可见，模拟人类和替代工作是RPA的主要特征。

普华永道（PWC）给出对RPA的定义为：“RPA利用了流程自动化技术及更易配置的软件机器人，业务人员只需要少量IT经验，在快速培训后就能操作，以替代手工工作。”普华永道提到了RPA不需要专业人员就能快速实施的特征。

综上所述，看起来各家机构讲的是同一个概念，侧重点却各不相同。本书并无意重新定义RPA，只要我们能对前面提到的三个问题给出清晰的解释就可以了。

1.1.3　回答RPA的三个关键问题

问题1：RPA是什么样的机器人技术？

我们从五个方面来回答这个问题。

（1）RPA是一种软件技术，也就是说RPA概念中所谓的“机器人”并不是指有物理形态、物理实体的机器人，不是工厂中的机器手臂、自动设备、家里的扫地机器人以及银行大堂的迎宾机器人。说到底，它就是计算机中的程序代码，所以被称作软件机器人（Software Robot），也可以把运行在RPA中的机器人称作Bot。

RPA技术的核心能力是模拟和替代人工劳动。工厂中那些物理形态的机器人替代的是工人的体力劳动，扫地机器人替代的是家庭主妇的清洁劳动，而RPA这种存活在计算机里的软件替代的是办公室里员工的部分脑力劳动，以及诸如敲击键盘、点击鼠标、切换页面等系统操作动作。随着全社会进入信息化时代，几乎所有企业中的员工以及人们的日常生活都需要依赖计算机，一些大型企业更是同时拥有多套应用系统，员工在工作中经常需要登录不同的系统进行业务处理，而系统处理过程中必然存在大量的数据录入、数据核对以及数据报告等工作，RPA通过模拟人工操作的方式很好地解决了这类问题。

（2）RPA可无缝地实现跨系统连接。员工通常在工作中需要使用多个业务系统、桌面软件，以及不定时访问内外部网站来获取信息，所以在实际业务办理过程中，他们需要在不同系统间切换，将数据传来传去，不停地复制粘贴，从而花费了大量时间。RPA目前能够调用几乎所有桌面系统中的应用程序，如常用的办公软件Excel、PPT、Word、邮件和即时通信工具等，以及其他带有客户端的用户界面和各类浏览器支持的Web页面，这样就可以模拟员工的以上行为，无缝地集成上述业务操作，变相起到了不同应用系统之间集成的作用。而这样的集成方式并不需要修改后端程序的任何一行代码或数据库字段，也不需要打开后端程序的接口或服务，因为RPA只是在模拟人的行为，访问操作的是那些应用系统的页面。这种集成方式也被称作“At-the-glass Integration”，即“表层集成”。

正因为RPA不需要工作人员了解复杂的后端程序逻辑、数据库结构、软件接口和服务调用方式，而是主要利用图形化可拖拽的工具进行编辑，采用脚本语言编写程序并且不需要编译和部署，甚至可以用录制的方式自动生成，才使技术人员更容易上手，甚至于一些业务人员在经过培训后也可以直接使用。

（3）RPA是多种技术的组合应用。RPA其实是一类自动化技术的统称，通常包括键盘和鼠标的模拟操作技术、屏幕信息获取和定位的抓屏技术、流程控制处理的工作流引擎技术，以及自动化任务调动控制和管理技术等。这些技术各自可能已经有了很长的发展历史，但是能够将这些技术综合起来一起使用，而且能够稳定安全地使用，让用户用起来更容易，即真正商用，只有短短几年的时间而已。

（4）利用计算机来实现自动化计算、数据存储和业务操作，这似乎是计算机天生的属性。RPA和传统的自动化技术有什么不同吗？传统的利用计算机实现自动化的模式大致可以分为四种。

第一种模式是传统C/S或B/S的应用系统，需要人类通过操作应用系统的用户界面来驱动系统，实现所谓的数据计算和存储的自动化。虽然我们把办公系统叫作办公自动化（Office Automation），但距离今天对自动化的要求还差很远。

第二种模式是利用工作流（Workflow）引擎支持业务流程管理（Business Process Management，BPM）的自动化，即利用系统自动串接业务流程中不同岗位角色所做的任务，但在落实到每个具体的业务执行过程中，还是需要人工来操作用户界面，这样工作流引擎才能将工作任务自动流转到下一个节点。这种模式与RPA的区别是，工作流引擎实现的是不同角色之间业务流程的自动化，而RPA实现的是某个特定角色操作步骤的自动化。但是，RPA结合工作流引擎可以解决全流程的自动化，所以在部分高级的RPA软件中已经融入了工作流引擎技术。

第三种模式是利用服务器端的程序或脚本来实现日间或夜间批处理，也包括数据库中存储过程的执行，这种批处理执行方式是通过程序逻辑直接访问数据库，无须通过用户界面处理信息。这种模式与RPA的区别是，批处理能够大批量、高效地执行数据库处理，但批处理程序必须由专业的技术人员完成，而且一旦完成，由于批处理的逻辑复杂且处理的数据量庞大，难以再次修改。批处理过程和业务逻辑对于业务人员完全是不可见的，业务人员只能通过第二天所产生的报表检查业务结果是否正确。而RPA的脚本编制简单，容易上手，甚至业务人员也可以读懂，达到了所见即所得的效果。RPA模拟了用户的手工操作过程，业务人员看起来也更加熟悉和亲切；RPA仍是单笔业务处理方式，更符合用户日常业务的处理行为，当出现业务问题或程序异常时也可以及时进行修正。

第四种模式有点像RPA的雏形阶段，即利用系统或软件自带的脚本语言，编制一些简单的可以自动执行的脚本来帮助用户实现系统处理自动化，如Excel中的VBA、UNIX中的Shell等。这种模式与RPA的区别是，普通的脚本必须依赖于某一个特定的软件，比如VBA只能在Microsoft Office中使用，而不能自动化地操作Oracle EBS的用户界面。RPA在技术原理上调用的是操作系统底层技术，它能够识别和处理Windows系统中几乎全部的应用程序、客户端、浏览器，甚至是远程虚拟桌面，所以比起传统的执行脚本方式，RPA可以起到强大的用户操作集成作用。

（5）我们还要解释一下RPA与自动化测试（Test Automation，TA）的区别，很多测试人员也许使用过如QTP和Selenium这样的自动化测试工具。二者在很多方面看起来十分相似，如都是为了避免重复的人工操作，避免人工处理过程中引入的错误和风险，基于结构化数据和固定的业务规则等。

一个基本的前提是，RPA可以代替TA工具，但在测试设计上需要做些特别的改进，也就是说RPA基本兼容了TA的功能。TA与RPA比起来有一定的局限性，如TA的目的是测试，输入的是测试案例，加载于测试环境；而RPA既可以用于测试，也可以用于生产，输入既可以是测试案例，也可以是实际生产的案例，并且RPA可以加载于开发、测试和运行环境中。由于RPA可使用真正的生产数据，所以需要RPA能够兼容各种异常，跟踪和记录所有的用户操作行为，对机器人的执行过程进行严格监控，这些能力都是TA软件所不具备的。

通常TA具有两个目的，一个是回归测试，另一个是压力测试。为了达成这两个目的，自动化测试只需要关注于某个测试案例或测试场景的成败，而不需要关注整个业务流程的处理过程和业务逻辑，从而可以把这些内容都交给后端程序。

RPA既可以实现单任务的自动化，也可以实现多任务的长流程自动化。另外，RPA可以把真正的业务处理逻辑写在脚本或代码中，而TA的业务处理逻辑只能依赖于后台应用程序，因为TA的目的只是为了检验应用程序的正确性。

总之，RPA是实现自动化的技术合集，通过模拟人类使用计算机的行为，实现了跨应用系统的操作集成。

问题2：RPA可以实现哪些流程的自动化？

RPA是运行在计算机中的机器人程序，能实现的自动化流程必然是那些涉及电脑处理的，而现实物理世界中人们的行为就无法利用RPA来模拟和替代，如领导在纸质文件上的手写签名、取回已打印的文件、将寄送的包裹交到快递人员的手中等。不过RPA可以通过实现自动化的电子签名和校验来替代手写签名。如果企业还未实现无纸化办公，至少RPA可以做到将要打印的文件自动发送给打印机，并自动判断打印成功与否。虽然RPA不能亲自递交包裹，但是可以在快递公司的系统中自动下单，并自动化地检查快递物流的实时状态。

所以，如果在一个业务流程中，一部分步骤是人工的电脑操作，一部分是人在现实世界中的行为，那么可以肯定地说，RPA只能自动化地替代人工的电脑操作，而对于人类的物理行为无能为力，不过这时那些拥有物理手臂和可以自动行走的机器人就可以派上用场了。

既然RPA是利用程序模拟人的操作行为，那么这些流程中的操作行为就必须要有明确的业务规则、明确的行为逻辑，才能转换成可执行的软件程序。目前RPA主要应用于商业领域，为企业用户服务。商业领域其实不像人们的日常生活，日常生活中大部分行为是受情感所支配的，如人们在“双十一”填满购物车，在各个网站上随意地浏览新闻。而在商业世界中，90%的业务行为都是有逻辑规则可循的，尤其一线业务人员的操作过程，更是需要严格遵守公司的操作规程。

RPA应用领域主要包括财务会计、人力资源、采购、供应链管理等，如费用报销、单据审核、人员入职、开具证明、订单核对等流程。

另外，并非所有能够实现自动化的流程，都要真正地实现自动化，如上面几个定义中所提到的，RPA的目的是要处理那些重复执行且工作量大的流程环节。其实，这里讨论的是自动化的必要性，而不是RPA能否实现自动化的问题。

首先，需要考虑投入产出比的问题。因为使用RPA最原始的动力是替代人工劳动，降低人力成本。这部分工作通过人工操作是需要成本的，但是RPA的软件、实施和维护也需要成本，需要对比一下哪种方式成本更低。

其次，还要考虑业务灵活性的问题。RPA一旦将业务流程和处理规则固化下来，也就意味着业务人员在业务办理中的自主控制力会降低，随之会带来业务灵活性和业务人员及时应变能力的问题。当然，我们还需要从效率、风险、安全、IT建设周期等其他维度来判断一个流程是否需要自动化，详细内容参见第4章。

通常得出的结论是，那些重复执行且劳动量大的工作一定是人力相对密集的流程，越多的人执行这样的流程，规则越不会轻易调整，将这些流程进行自动化所带来的业务收益通常也会更大。这也就是为什么RPA首先应用于外包服务和企业内部共享中心的原因。

总之，RPA适用于那些具有明确业务规则、重复执行且业务量较大的、相对稳定的业务流程。

问题3：RPA可实现什么程度的流程自动化？

如上所述，RPA模拟用户在计算机上的操作行为，那么流程中只要涉及用户界面的操作过程就都有可能被自动化。首先说明，我们所谈的流程自动化，并不是指流程100%的步骤都实现了自动化，也就是说流程中的部分环节仍然难以被自动化技术所实现或者技术实现成本过高，仍需要通过手工方式完成。但是随着技术的进步、推广和普及，以及企业管理成熟度水平的提升，流程自动化的比例自然会逐步提高。一些流程自动化比例不是很高的企业也决定开始尝试使用RPA技术，因为只有通过实际的应用才能充分了解实施过程中的风险和问题，培养自身的能力，构建相匹配的团队，为将来更大规模的RPA应用做准备。可以预想到，开始由于流程自动化比例较低，更多是由RPA来配合人类完成工作，而发展到未来，随着流程自动化比例的升高，可能就会颠倒过来，更多是由人类来配合RPA完成工作。

由于流程不是100%的自动化，人类和RPA之间就会产生协作，也就必然产生一种全新的与RPA机器人的协作方式，事实上产生了人、RPA机器人、应用软件三者之间的协作，如图1-1所示。

图1-1　人、RPA机器人、应用软件三者之间的协作

其中，我们最熟悉的就是人使用应用软件的方式，人通过用户界面来操作应用软件（Input），应用软件处理后（Processing），再将结果反馈给人（Output），也就是常说的IPO，这也是所有软件工程领域，包括需求人员、需求分析人员、设计人员、开发人员和测试人员等共同遵循的话语体系。由于RPA是模仿人类的操作，Bot使用应用软件的方式和人类似，不同的是由于Bot也是一种软件，它可以选择不去操作UI，而是通过Service或API来直接调用应用软件。

那么人如何触发这些软件机器人呢？主要有以下三种方式。

第一种是手工触发，即通过手工方式随时随地地启动一个Bot让它开始运行，既可以启动本地电脑上的Bot，也可以启动远程的Bot。

第二种是通过人们事先编排好的机器人工作日程表，让Bot按照这个日程表来工作，可以是在某日某时让Bot开始运行，也可以设置为上一个Bot运行完成后，下一个Bot再开始运行。

第三种是Bot按照事先设定好的规则来触发机器人的执行，如收到一封邮件，订单量超过全年30%等，这些都可以作为触发机器人启动的外部事件。当RPA系统监听到这些外部事件后，会自动调用机器人执行自动化任务。然后，在机器人完成任务后，将结果反馈给人类，或者并不需要完全执行，而是执行了一部分，再将其余的工作转交给人继续完成。不单是人可以调用Bot，应用软件也可以反过来采用Service或接口的方式来调用Bot。举一个RPA已经可以实现的有趣例子，企业中的员工可以通过手机App启动办公室里的某台电脑中的Bot，由Bot操作电脑中的某个应用软件来完成任务，完成任务之后，再由Bot通过微信将完成结果发送给该员工。

总之，RPA不只是单纯的技术创新，而是创造了一种新的技术应用模式，是一种新的人机交互方式和协作方式。