1.2 RPA的九大主要特征
为了更清晰地说明RPA的主要特征，我们将使用一个完整的业务流程作为分析示例。这个例子是某企业采购部门员工的一个日常工作场景，如图1-2所示。
图1-2 采购部门员工日常工作场景的关联应用系统
员工A上班之后，首先要在办公系统（Ⅰ）中登录，签到打卡，以表明自己按时到岗上班，然后给自己泡上一杯茶，准备开始一天的工作。他打开自己的邮件系统（Ⅱ），检查是否收到了昨天供应商提出的采购请求的邮件，尔后在新邮件清单里发现确实收到了这封邮件，随后打开邮件检查对方的请求信息是否正确，核对无误后，便打开了公司的采购系统（Ⅲ），一项一项地将邮件中的请求信息复制粘贴到系统请求的页面中。录入过程中发现，有一项关于供应商的社会信用代码需要录入到系统中，他又不得不打开国家工商行政管理总局的信息网站（Ⅳ）查询到该供应商的信用代码，再次复制粘贴到系统中。
最终，他一项一项地录入了全部信息，但是过程中由于操作不熟练，导致几次将信息录入到错误位置，不得不停下来进行更正。而这还不是全部完成，因为他需要把这个采购请求发送给他的同事B进行复核，B需要打开原始邮件系统（Ⅱ），再打开采购系统（Ⅲ）查询到A所提交的信息，与A填写的信息进行逐项核对无误后，反馈回A，A才能在采购系统中正式提交请求生效，生成这笔采购订单。然后A需要将订单打印好，并将这笔订单信息同步记录到他自己电脑的Excel表（Ⅴ）中，以作后续的备查和统计使用，再将订单生成的反馈信息通过邮件系统（Ⅱ）回复给供应商。最后，A再将打印好的订单快递给库管部门。以上这样的业务处理过程对于企业的一线员工最熟悉不过了，而且可能一天要重复很多次。
我们来统计一下上面的操作过程，从a到o共计15个步骤，从Ⅰ到Ⅴ共计5个应用系统、网站或桌面软件程序，在一个系统中页面打开、关闭、查询、录入、核对、复制、粘贴、提交的次数就更多了。那么，我们来看看RPA的处理过程，如图1-3所示。
图1-3 采购部门员工日常工作场景中识别的自动化环节
员工A上班后的第一件事情是启动电脑里的RPA机器人，我们暂且把它称为Bot-A。Bot-A会根据员工A所提供的待办事项清单（To-do list）逐一完成工作。Bot-A在桌面系统中自动打开办公系统（Ⅰ）的登录页面，输入已经配置好的员工A的用户名和口令，并点击“登录”自动完成签到操作。当Bot-A完成第一项工作后，即在员工A的桌面上显示已完成签到的状态。Bot-A依据工作顺序，执行邮件检查工作。
Bot-A自动打开邮件系统（Ⅱ），登录后按照预制好的规则检查邮件的发件人、标题和时间信息，筛选出符合条件的邮件逐件处理。Bot-A自动打开那封关于供应商提出的采购请求的邮件，按照规则检查邮件内容是否完整和正确。如果不正确，Bot-A自动回复一封标准的退回邮件；如果正确，则自动打开采购系统（Ⅲ）将邮件信息填入进去。Bot-A按照录入规则判断，如果发现缺少了信息，则又自动打开国家工商行政管理总局的信息网站（Ⅳ）查询，查到后抓取信息自动回填到采购系统中，并自动提交这笔订单（l1），发送到打印机进行打印。
Bot-A继续打开Excel自动录入信息，并自动将相关信息写入反馈邮件回复给原发件人。当自动化完成上述所有工作后，Bot-A会在员工A的桌面上显示一条“已完成×××××订单”的提示信息。这时，员工A只需要到打印机前取回打印好的订单（l2），再快递给库管部门，全部工作就完成了。
我们再来统计一下，利用RPA技术可以全自动化或半自动化地实现从a到o其中的13个步骤，除了步骤b和o，因为这两个步骤都属于员工在现实世界的纯物理行为，而且与系统操作无关，所以RPA无法处理。在整个操作过程中，员工A几乎不需要参与整个处理过程，只是通过接收Bot-A的反馈消息，监督Bot-A的执行。
基于上面的例子，我们再来总结一下RPA有哪些主要特征，依据这些特征可以看到概念之外的细节情况。
1.2.1 模拟人类操作行为的系统，让用户“眼见为实”
例如，在a、c、f、g、m等步骤中，Bot-A的操作过程和操作行为几乎和人一模一样。员工A打开什么界面，Bot-A就打开什么界面；员工A怎么录入信息，Bot-A就怎么录入信息；员工A点击“提交”按钮，Bot-A就点击“提交”按钮。整个处理过程从后端系统看，是没有办法分辨员工A和Bot-A的区别的。另外Bot-A的整个模拟过程，对于用户是可见的，即用户可以看到Bot犹如魔法一般快速操作各类应用软件的整个过程。
这不单只是追求炫目的视觉效果，其实是在更深层面让用户对计算机产生了某种信任感，拉近了IT和用户的心理距离。由于传统应用软件的运行情况对于用户来讲就是个黑盒子，再加上用户缺乏对软件编程的足够了解，经常会出现用户不知道后端系统在做什么的情况，一旦出现系统响应延迟、不断报错等问题，用户就会抱怨。如果一个IT系统能够让最终用户眼见为实，会给这项技术加分不少，这也是为什么更多的计算机仿真和模拟程序不断出现的原因。
1.2.2 基于既定的业务规则来执行
例如Bot-A在d、e、f等步骤的处理中，需要依据事先已经预设好的规则来执行，比如预设邮件筛选的规则，包括选取什么时间段、由哪个邮箱地址后缀发出来、邮件标题中含某字段标识或是某种更加特殊的标志。筛选规则可以是简单的，利用脚本程序直接实现；也可以是复杂的，利用规则引擎来实现。如果是人工查找一封邮件，会先按照发件人或者时间排序，然后用目光进行搜索，找到那个熟悉的关键字后，再仔细看邮件的标题是否符合要求。
如果我们靠机器人和规则来实现，那么就不能再简单地模仿人的行为，而是需要让计算机明白那些业务规则。所以说，RPA模拟的只是人的行为，而不是人的思维，只会执行人类预先设计好的逻辑规则，而不会自己去思考如何工作。而人类的思维需要靠人工智能来“模仿”，这部分内容在3.4节详细描述。
1.2.3 带来确定的执行过程和执行结果
如例子中从a到o的所有步骤，RPA会按照确定的顺序来执行，且不会随意调整，这也与人类的行为习惯存在很大差别。虽然目前一些企业中已经有明确员工行为的规程或操作手册，但是由于无法做到细致的监督和管控，所以在真正的业务运行环境中，员工还是可以随意调整操作步骤的，因为人们通常觉得只要自己最后交付的成果是有效的就可以，过程并没有那么重要。但是很多生产问题恰恰是与操作顺序有关的。
例如办理“个人定期存款到期转存”业务时，银行柜员应该按照“先借后贷”的顺序，先办理个人定期存款到期销户业务，再办理新开户。如果柜员颠倒操作过程，一旦出现客户遗忘密码等不能正常取款的情况，就会产生银行垫款等风险隐患。所以，利用RPA来固化员工的业务操作顺序，也是一个重要的考虑因素。
另外，因为RPA的操作过程中不会出现任何人类常犯的一些错误，如敲错键盘、选错位置、点错按钮等，所以当同一逻辑、同一规则的RPA脚本执行完以后，处理结果都是相同的。如果对比上述例子中人工和自动化两个处理过程，就会发现在RPA的处理环节中少了i和j步骤，而这两个步骤就是我们通常所说的业务复核。业务复核是业务流程中最为常见的一种做法，其实就是希望复核人员能够再一次检查录入人员的录入结果，避免不必要的错误发生。甚至在一些特别重要的信息输入环节，很多企业还采取了“两录一校”的处理方式，即双人录入、一人校验的方式。但是我们可以发现，由于RPA执行带来的一定是确定性结果，并不需要再用一个机器人来加以校验，也就避免了复核环节。这项能力对于业务的效率提升以及人力成本的节省都是非常明显的。
1.2.4 提供全程操作行为记录
企业的管理者一直都希望能够了解和获取真实的业务运营情况，包括人员服务效率、事务周转率、各项作业时间等，基于此来衡量企业内部的作业成本、服务效率等。目前在数字化转型的趋势下，大多数企业主要通过信息系统中的数据分析来获取这些信息，但其中存在两个制约因素。
第一，由于运营流程中通常会涉及多个系统，流程中相关的运营数据也就散落在各个系统中，而且由于数据标准和质量的问题，很难将这些数据完整地串接和拼装成运营流程的全貌。
第二，即使拿到了系统中的数据，仍不能获取业务人员办理业务时真正的耗时情况，因为信息系统只能记录业务人员提交业务信息，即点击“提交”按钮那一时刻的时间，而并不清楚业务人员是从什么时候开始办理这项业务的，以及在各个环节中的耗时情况。
RPA替代人工完成了相应的操作，所以在自动化处理过程中也顺便留下了所有的操作痕迹，即操作日志。通过这些日志信息，管理者可以了解某项业务是什么时间开始、结束或者中断的，中间过程都与哪些信息系统或桌面软件做了交互，操作了几个软件，每段操作的耗时如何，并可以反向推导出业务人员的劳动效率、不同人员之间的协作效率、流程是否遇到瓶颈等问题，同时也为企业的内控合规人员和内外部审计人员提供了数据支持。
1.2.5 为企业带来流程优化和再造
从上面例子的一个细节对比中我们可以发现：在原来的人工流程中，员工A是提交这笔订单后就去打印订单，然后操作Excel表，发反馈邮件，最后寄快递。顺序是l→m→n→o。在机器人流程中，Bot-A是提交这笔订单后即发送打印机，继续操作完Excel表，发送反馈邮件；员工A再去取打印好的订单，最后寄快递。顺序是l1→m→n→l2→o。
所以在Bot-A的处理过程中，并不是一味模仿人类的流程，而是在流程优化和再造的基础上再来实现自动化。虽然例子中前后两个流程之间的差别很细微，也是很小的一件事情，但从侧面体现了RPA的特征，即原来流程中的某项任务可能会被重新拆解，分成机器人完成和人工两部分，比如打印订单这件事情，分解成机器人发送文件到打印机和人工取走打印文件两个环节。
自动化流程中，还可以将某角色同类的操作进行归并，减少不同主体之间的交互频率和时间。例如，将员工A取打印文件和寄快递这两个操作一起完成，可以减少来回奔波的时间，优化一下，甚至可以让快递员自己取打印文件。Bot-A将它要做的功能一起做完，再反馈给人类员工，也减少了人与机器人的交互次数。
所以，一般RPA实施过程中都会伴随着一定的流程优化和再造，并不是简单地模仿原有流程来实现自动化处理。这既优化了效率提升，也扭转了人们传统思维方式。更加详细的内容请参考6.6节。
1.2.6 符合人类的工作组织特征
这一特征主要由RPA软件设计机制所决定。大多数RPA软件都会提供一个基础的技术运行平台，该平台支持所有的底层技术实现，如模拟操作、屏幕抓取等技术。RPA到底需要具体做什么样的工作不是由平台决定的，而是由运行于平台之上的自动化脚本来决定，这些脚本定义了自动化流程的处理步骤、业务规则和异常控制等处理要求，由脚本在驱动平台上进行技术实现。一套能连续执行的脚本被称为一个自动化任务（Task）。一个独立的小的运行平台，也是操作系统中的一个进程，可被称为一个机器人，也就是前面提到的Bot。
某个Bot在某个时点只能运行一个任务，就像人一样，在一个特定的时刻只能做一件事情，但是当Bot完成这个任务后就可以继续下一个任务，当然也可以一直循环做同一个任务，这其实是由这个任务所要处理的业务量和每笔处理耗时情况来决定的。所以，当有多项自动化任务的时候，通常需要为Bot配置工作日程表，如9点到10点做财务核算工作的5个任务，10点到11点做新员工入职流程的3个任务，总之在满足业务流程的前提下，让机器人做的事情越多越好，时间安排越紧凑越好。
另外，为了保证更大规模的自动化业务并发量，企业只利用一个机器人按顺序执行任务是不够的，需要同时拥有多个机器人，再分别为这些机器人配置好工作日程表。（它们的日程表可以相同，也可以不同）。除此之外，企业还需要让不同的机器人在任务安排上做好衔接，不能产生业务上的冲突。这就如同你拥有了一支机器人军队。通过RPA监控管理平台来监督这些机器人的执行情况，就如同机器人军队有了一个作战指挥中心。
目前在一些大规模机器人应用的实践案例中，这个作战指挥中心被称为“自动化指挥中心”（Automation Command Center）或者“自动化运营中心”（Automation Operation Center），而整个运营机器人的管理组织被称为“卓越中心”（Center of Excellence，CoE）。详细内容可参见5.8节和6.7节。如此解释完之后，你是否觉得“机器人流程自动化”中“机器人”的叫法真的很贴切呢？
1.2.7 满足24×7×365的不间断执行
首先需要明确一个问题，虽然机器人的操作速度快，但也是需要处理时间的。如图1-4所示，我们把人工操作信息系统的时间分成两部分：第一部分是人工信息输入或检查操作用户界面的时间（T1），第二部分是系统响应人工请求后的处理时间和信息反馈时间（T2），原来的总处理时间就是T1+T2，虽然通常T2远远小于T1，但也不能忽略不计。由于机器人键盘鼠标操作的迅捷性，主要节省的是T1，并不会影响T2。通常机器人的操作时间是人工操作时间的10%～20%，甚至更少，我们称这个比例为η。实际上，机器人流程的处理时间是T1×η+T2。
图1-4 RPA流程处理时间计算方法
如果不能100%达到自动化，还需要把T1分割成必须由人工执行的部分T1m、其他可以由机器人替代的执行部分是（T1-T1m）×η，以及额外多出来的人机协作时间T1c，那么最终机器人流程的处理时间是（T1-T1m）×η+T1m+T1c+T2。
虽然看起来机器人执行仍然需要时间，但好处是它可以不间断地执行，达到每周7天、每天24小时、一年365天的持续无休，与人类员工每周5天、每天8小时的工作时间相比，相当于机器人的可工作时间比人类员工扩大了4.2倍（（24×7）/（8×5））。但需要注意的是，真实的运行情况并没有那么乐观，机器人的处理时间会受制于以下两种情况。
第一，机器人的运行需依赖于所要操作的应用系统，那么应用系统的运行时间反过来就会影响机器人的可处理时间。因为企业中一些传统的应用系统可能在晚间有停机休息的情况，那么机器人在这段时间里也就不能运行。如果机器人的处理流程中涉及多个应用系统的操作，那么机器人只能在那些应用系统同时运行的时间段运行。
第二，对于那些需要人工来配合执行的自动化流程，即有人值守机器人，其运行时间依赖于人的工作时间，人上班了，机器人才能上班，人下班了，机器人也就不得不下班。
总结一下，机器人的运行时间既依赖于系统又依赖于人，很难做到上面说的完全不间断运行。
但值得庆幸的是，我们可以通过机器人运行机制的巧妙设计来实现其处理时间的最大化。
首先，可以安排那些无人值守的且不依赖于外部系统运行时间的自动化任务在晚间运行，例如在外部网站搜集一些资料，处理Excel和Word文件等。
其次，安排那些无人值守的但依赖于系统运行时间的自动化任务在人们下班之后、后端系统停机维护之前执行，比如自动生成报表、校验业务信息等。
最后，安排那些既依赖于人工处理又依赖于系统运行时间的任务在日间人们的工作时间执行。
合理安排机器人的运行时间，就像是合理安排一名员工的工作时间，只不过机器人会比人类员工更听从指挥。
1.2.8 提供非侵入式的系统表层集成方式
ERP或CRM这样传统的应用系统，如果出现了问题，通常需要通过修改接口或修改底层程序代码、数据库的方式完成系统改造，甚至直接替换原有系统。但这些大型的应用系统的功能非常复杂，中间经历了多次升级，已经根深蒂固地深入企业的各个层面，这种方式的改造就会带来巨大实施风险，不但是程序功能之间会相互影响，也会导致业务中断这种高度破坏性的运营风险。所以一般IT部门在系统改造问题上都会持有谨慎的态度，而且时间越久、功能越复杂的系统，升级和改造的风险越大。
而RPA的实现方式是像人一样通过操作应用系统的用户界面来执行任务，既不需要更改应用系统的底层代码，也不需要更改应用系统的服务或接口，而是通过这种非侵入式的集成方式或修补方式，使得RPA实施过程对原有系统的影响最小，带来的风险最小。当RPA部署上线后，后端系统也不必中断或停止，这是传统系统上线切换后不太可能做到的。而且，RPA软件提供了可视化的自动化流程设计工具，让开发者只需要少量代码甚至不需要代码就可以编制自动化脚本，所以一些业务人员在培训后也可以快速上手，而不必完全依赖专业的IT开发人员，这也是传统系统难以做到的。
这种快速敏捷的特征也让RPA项目的实施周期远低于传统的系统改造项目，所以有人将RPA比作医用绷带或者创可贴，绷带的作用就是从外面牢固伤口，而不需要介入人的身体内部进行治疗。虽然绷带不能解决所有问题，但至少给我们提供了一种新的技术手段和方式。
1.2.9 支持本地和云端各种灵活的部署方式
相对来说，RPA的本地部署比较好理解，即RPA的执行机器人Bot和RPA的监控中心系统都部署在企业的内部网络中，运行在企业自己提供和负责维护的服务器或PC上。而RPA的云端部署模式显得更加复杂一些，与我们熟知的IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）以及BaaS（业务即服务）这几种云模式都不一样，甚至可以采用RPA as a Service（RPAaaS）或Robot As a Service（RaaS）这些新名词来重新定义RPA云服务模式。
现在的公有云经常为中小企业提供服务，RPAaaS也一样。当一家企业不能负担RPA的采购和运行维护成本时，可以采用云服务的租用模式来实现自动化。RPAaaS的方式有两种。
第一，机器人部署在公有云端来为企业服务。由于RPA机器人替代员工操作时是需要访问企业已有IT系统的，所以这种模式下首先需要解决如何从外部访问企业内部系统的问题。当然VPN（虚拟专用网络）是一种选择，但是由于安全性问题，很多系统仍然不能通过VPN访问，而必须采用远程桌面的访问方式，如Citrix。好在目前一些主流的领先的RPA工具已经实现Citrix的自动化处理。这样，企业就不需要自己购买RPA软件来实施RPA项目，完全可以租用云端RPA机器人的方式来为自己服务。这其实也是一种传统业务外包服务（BPO）的变形。
第二，将机器人的管理和控制部署在公有云端来为企业服务。由于数据安全和访问安全的问题，企业不愿意让机器人部署在公有云上，那么可以让RPA的运行机器人部署在企业内部的服务器上，而将RPA的监控中心部署在公有云上。机器人运行在企业内部保证了数据安全性，监控中心运行在公有云上则提供了RPA的管理、运行、监控和维护的便捷性。
在第二种方式下，企业除了需要购买机器人软件外，没有增加任何额外的工作量，因为机器人在企业内部自动运行，它们的控制和管理都由云端来提供。关于云原生RPA解决方案的详细内容可以参考6.3节。