RPA 将被越来越多的企业认同

　　RPA（Robotic Process Automation）流程自动化机器人的软件产品有多种选择，总得来说，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 软件会越来越多的被企业所认同而应用。