51RPA一起来聊聊RPA技术和产品

RPA（Robotic Process Automation）流程自动化机器人的软件产品有多种选择，就三大独角兽从国内当初市场来看，从起初2016年率先火爆的Automation Anywhere在大连很是盛行，从BPO巨头简伯特，以及软件企业IBM和咨询巨头埃森哲都在普及使用，甚至对日日立以及欧美嘉士伯，默克等都在内部项目中普及，而另一面是BluePrism以上海为主，主要在四大里面的普华永道以及美企江森和日企索尼等普及应用，而如今的独角兽UiPath在2018年之前的时候还很不起色，因为总是莫名的bug问题被各大企业嫌弃，如今的突飞猛进除了和社区版免费以外和产品良好的使用有很大关系。但总体来说，各有其特点，RPA软件产品的内部架构包括了RPA集成开发环境、RPA服务器端、以及RPA客户端这三个部分。集成开发环境缩写为IDE，算不上技术架构的部分，基本上第三方RPA产品都会提供一个IDE，而RPA客户端包括了交互式和非交互式两大类，即我们常说的有人值守和无人值守模式。

RPA客户端安装在PC端，模拟人进行“大量重复”且“规则固定”的业务流程处理，而RPA服务器端则用来监测和管理RPA客户端。RPA集成开发环境则是机器人开发实施人员的设计和发布平台，类似于开发RPA的Visual Studio或者Eclipse，这样比喻应该好理解。

RPA服务器端也可理解为RPA管家，就是负责管理RPA“机器人”，主要的职责包括：RPA功能版本管理、RPA客户端运行监控、任务分配、运行结果展现及日志分析等，需要有RPA系统管理员维护和监控RPA管家的运行情况。

RPA客户端则依据是否需要与用户进行交互，分为交互式RPA和非交互式RPA，非交互式RPA就是完全不需要人参与的机器人（即无人值守机器人），交互式RPA的“交互”可以理解为“人机交互”，而另外一种对交互式RPA的定义是机器人的启动是否需要人工触发，必须由人工触发启动的机器人也称为有人值守机器人，需要有RPA前台用户处理RPA无法处理的数据或者步骤操作，比如一些参数的灵活配置及时变更，或者硬件如税盘插入等。

RPA也有很多不能处理的业务场景，那么就需要通过外部接口来扩展其功能。设计外部接口的目的是为了让RPA更专注于其擅长的领域，需要设计考虑的接口包括：PowerShell、Webservice、数据库、DLL插件。

PowerShell：名副其实，是很Power的“Shell”脚本工具，另外如果处理Excel还可以考虑使用VBScript（脚本版本的VBA）。

WebService和数据库：这是个万能的套路，用你的经验去预测。

DLL插件：这个算是基于RPA产品的二次开发

需要注意到，一些客户，特别是企业内部的客户，通常并不愿意直接从市场上购买第三方RPA产品，而是更期望由IT部门针对不同需求自开发RPA应用出来，这可能是企业领导认为购买RPA产品需要很大一笔投资在软件license上，并且产品质量可能并不稳定，当然，而最大的考量在于投入产出比。从市场上购买的第三方RPA产品需要支持License费用，对于各种类型功能需求的支持做得较为完善（尽管很多功能在一个项目的实际应用中并没有用到），开发工具强大因此开发周期较短，很少写代码或基本不用写代码，维护成本也较低；而自开发的RPA应用不需要License费用，需要针对功能写代码，功能支持相对单一，开发周期较长，维护成本较高，和业务系统可以做更深层的集成。最终如何选择要看客户的需要。在过去两年，我大概交付了16+RPA应用，有使用第三方RPA产品的，也有自开发RPA应用的。对于自开发的RPA应用，我们开发了一系列的包括VBA，Selenium WebDriver和Sikuli等在内的RPA应用开发工具包，有效地提高了自开发RPA应用地开发交付效率，降低了维护成本。

当然了，不管是从第三方购买的RPA产品，还是自开发的RPA应用，和SAP系统集成有一个悖论，如果可以直接访问目标系统的数据库，目标系统已经开放了接口（ETL，Web Service，ETC），是不是就不需要用RPA了？对的，从技术层面上而言,的确如此，但是，从客户角度而言，选择什么样的技术解决方案需要考虑到更多因素，比如“实施成本”，“实施速度”以及安全风险等等，老实说，对于客户而言，毫无疑问，RPA是一款非常amazing的Quick-Win的技术解决方案。

就目前的国内市场以及国际RPA发展趋势，RPA软件会越来越多的被企业所认同而应用。

原文链接：https://www.51rpa.net/rpaedu/279.html