(1)RPA是一种软件技术,也就是说RPA概念中所谓的“机器人”并不是指有物理形态、物理实体的机器人,不是工厂中的机器手臂、自动设备、家里的扫地机器人以及银行大堂的迎宾机器人。说到底,它就是计算机中的程序代码,所以被称作软件机器人( Software Robot),也可以把运行在RPA中的机器人称作BotRPA技术的核心能力是模拟和替代人工劳动。工厂中那些物理形态的机器人替代的是工人的体力劳动,扫地机器人替代的是家庭主妇的清洁劳动,而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的雏形阶段,即利用系统或软件自带第一种模式是传统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的区别是,普通的脚本必须依赖于某一个特定的软件,比如A只能在 Microsoft Office中使用,而不能自动化地操作 Oracle EBS的用户界面。RPA在技术原理上调用的是操作系统底层技术,它能够识别和处理 Windows系统中几乎全部的应用程序、客户端、浏览器,甚至是远程虚拟桌面,所以比起传统的执行脚本方式,RPA可以起到强大的用户操作集成作用。

(5)我们还要解释一下RPA与自动化测试( Test AutomationTA)的区别,很多测试人员也许使用过如QTP和 Selenium这样的自动化测试工具。二者在很多方面看起来十分相似,如都是为了避免重复的人工操作,避免人工处理过程中引入的错误和风险,基于结构化数据和固定的业务规则等一个基本的前提是,RPA可以代替TA工具,但在测试设计上需要做些特别的改进,也就是说RPA基本兼容了TA的功能。TA与RPA比起来有一定的局限性,如TA的目的是测试,输入的是测试案例,加载于测试环境;而RPA既可以用于测试,也可以用于生产输入既可以是测试案例,也可以是实际生产的案例,并且RPA可以加载于开发、测试和运行环境中。由于RPA可使用真正的生产数据,所以需要RPA能够兼容各种异常,跟踪和记录所有的用户操作行为,对机器人的执行过程进行严格监控,这些能力都是TA软件所不具备的。通常TA具有两个目的,一个是回归测试,另一个是压力测试。为了达成这两个目的,自动化测试只需要关注于某个测试案例或测试场景的成败,而不需要关注整个业务流程的处理过程和业务逻辑从而可以把这些内容都交给后端程序。RPA既可以实现单任务的自动化,也可以实现多任务的长流程自动化。另外,RPA可以把真正的业务处理逻辑写在脚本或代码中,而TA的业务处理逻辑只能依赖于后台应用程序,因为TA的目的只是为了检验应用程序的正确性。总之,RPA是实现自动化的技术合集,通过模拟人类使用计算机的行为,实现了跨应用系统的操作集成。

RPA是什么样的机器人技术?