1 前言

RPA 项目因涉及到流程开发等内容，区别于传统的 IT 项目建设更类似一个开发形式的项目。自带衍生出的多方对接、需求沟通、周期拉长等特性，这使它拥有了更多的项目流程控制环节。此文根据本人 RPA 项目的实施交付经验，梳理 RPA 项目整体架构与项目过程中涉及到需注意的事宜，对于基础的项目实施、环境准备等内容在此不做阐述、见公司产品文档。个人鄙见，多多指点。

2 项目交付

主要分为项目准备阶段、项目实施阶段、注意事项进行梳理探讨。

2.1 项目准备阶段

2.1.1 项目计划

RPA 项目大体主要从两部分组成。需求流程的开发与 RPA 平台的部署。项目准备阶段的项目进度计划准备也围绕这两个大纲进行设计。

2.1.1.1 流程开发

建议流程开发的阶段分为以下四个：

注意：

l 充分评估用户提供的测试环境和生产环境的一致程度判断切换生产环节所需时间。

2.1.1.2 平台部署

RPA 项目通常是由业务部门 OR 运管部门进行统筹建设。和传统 IT 建设直接对接 IT 部门有明显的区别。不排除会出现要求更严格，支持力度不充分的情况。

注意：

• 对于新建项目 IT 部门通常有评审要求，提前评估准备需二次开发内容。

2.1.2 人员安排

对于较多体量流程的 RPA 项目。建议流程开发和平台部署并行实施。所以也需由不同的人支持。

注意：

对于个别的厂商或者部分用户要求。会提出一个流程的实施需要流程开发工程师和业务顾问两个角色参与。虽说在用户看来观感会更好，但我觉得会有以下弊端影响实施：

• 业务顾问的转述无法让实施人员完全理解需求
• 出现反复沟通情况，沟通成本较大
• 业务顾问存在无法判断流程可行性的可能。

所以我还是建议实施人员必须同时承担起业务顾问的角色。虽说对个人能力要求较高，但作为 RPA 工程师能做好一个业务专业的角色，过程中沟通能力、理解能力、逻辑梳理能力、流程优化的建议能力对个人的提升也是极大的。

2.1.3 架构设计

整体 RPA 项目系统架构的设计在准备阶段是至关重要的。这将影响到后续的实施、上线、投产等诸多细节内容。务必与用户充分沟通做好决策。

RPA 平台主要分为 RPA 控制平台与 RPA 机器人两部分。其中 RPA 控制平台肯定是在 ECC 部署，而 RPA 机器人分为数据中心部署和业务场景部署两种形式。在此列出两种模式的优劣。

对于少量 RPA 需求项目（不考虑后期大量扩容），建议采用业务场景部署模式。轻量化整体项目资源投入。

对于较多 RPA 需求的项目，建议数据中心模式部署。实现统一的管控和调度。且业务流程毕竟涉及到行方敏感信息。有更高的安全要求。

2.2 项目实施阶段

2.2.1 环境准备

正常的项目实施从开始到上线，一般会经历两个环境：测试环境和生产环境。（不排除有 sit 环境、uat 环境、生产环境、数据中心环境这种过程。）。

因 RPA 的运行是依赖于系统环境决定的。所以环境的准备也至关重要。高度一致的环境准备可以减少许多不必要的流程配置、切换和调试时间。

2.2.1.1 流程开发环境

l 测试 or 生产环境

因 RPA 涉及到诸多第三方系统的交互，测试环境和生产环境可能在系统、数据上均有差异。但必须尽可能的向用户要求确保测试环境与生产环境高度一致。别忽略了分辨率也要保持一致。

l 数据准备

测试环境往往缺少数据，RPA 流程在少量数据甚至无数据情况下并不能很好的进行流程配置和稳定性测试。必须尽可能的向用户要求在测试环境提供充裕的数据以供测试。

l 网络环境资源

若是数据中心部署、对于新建系统。必须提前汇总好各业务流程需要访问的系统、IP、端口等信息至数据中心进行放通。

l 账号资源准备

对于 RPA 机器人涉及到的多个系统登陆账号事宜。因存在很多系统不同的账号进入后因权限不同界面也是不同的。（特别是测试账号和生产账号的差异）。建议用户提供机器人的专属账号，并督促用户尽早提供。

l 应用资源准备

对于新建机器人终端。通常缺乏各种 RPA 流程所需的应用。必须提前汇总好各业务流程需要的支持应用，如：office、outlook 等工具。督促 IT 部门尽早准备。

l 机器人资源分配

尽早汇总梳理好各个业务流程的耗时及资源需求。与用户沟通、分配好各机器人负责的流程和运行时间。建议按需求部门、处理类型等形式划分。

2.2.1.2 RPA 平台准备及部署

在此只讨论难度、复杂度更高的数据中心部署模式。架构通常如下：

l RPA 控制平台

1. 按 RPA 系统要求标准部署便可。

2. 若用户提供的是非 CentOS 系统，需准备好相关 C++ 编译等环境扩展包。

3. 考虑到单点故障建议采用集群部署

4. 建议采用用户提供的 Mysql 服务

5. 建议采用用户的负载均衡（如 F5、A10、NetScaler 等）进行高可用。

l RPA 机器人

1. 必须要求用户提供的机器人终端在系统、环境、应用、文件目录上完全一致。

2. 若用户提供的机器人终端为虚拟机（通常都是），虚拟机一般为通过 mstsc 远程访问，当退出的时候会锁屏。RPA 机器人大多无法在锁屏状态下运行。解决方法有以下三点:

• 添加 IS-RPA 设计器自带的组件触发 Ctrl+Alt+Delete 解锁。
• 在虚拟机中新建 Bat 可执行文件。写入：
  @ %windir%\System32\tscon.exe 0 /dest:console
  @ %windir%\System32\tscon.exe 1 /dest:console
  @ %windir%\System32\tscon.exe 2 /dest:console
  管理员运行强制退出远程桌面但不锁屏。

• 在所有机器人终端前增加一个跳板机。在跳板机中 mstsc 访问机器人终端后最小化，不关闭远程桌面。保持跳板机一直运行。

1. 若用户提供的机器人终端为虚拟机，许多虚拟机是默认适配显示器分辨率输出的。分辨率的变化也会影响 RPA 流程的稳定性。务必要求 IT 部门在虚拟机管理平台中通过设置固定分辨率输出。

2.2.2 流程开发

2.2.2.1 需求调研

需求调研的目的为充分了解业务需求。其中务必做到：

l 输出业务认可的需求分析书、也方便后续需求交接的可能。

l 在此阶段全面的判断各业务逻辑可实现性

l 因业务人员不具备 IT 开发思维。需工程师充分发挥主观能动性，在不影响业务流程硬性规定和结果的前提下提出更优的 RPA 实现方式。让 RPA 流程实现更轻量和快速。往往存在许多按业务逻辑更复杂的情况。

l 需明确是否拥有人机交互环境、制定更优的交互方案。如可以建议用 ftp/sftp 会更方便高效。

2.2.2.2 流程配置

RPA 开发出来的流程，必须可交接，具有高度的可读性。其中需注意：

l 流程配置的目标。稳定占最高优先级。效率其次。但保底需提高 50% 的效率。

l 必须做好注释

l 必须配套编写开发设计文档

l 开发代码必须规范

l 变量定义必须规范且拥有文档说明

l 流程配置过程中务必阶段性与业务核对需求。

l 流程配置建议在业务附近，当遇到业务问题可及时沟通确认。

l 对于切换环境导致需要更改的配置通过变量实现，切换会更加高效。

2.2.2.3 生产切换

涉及到真实业务的环节务必谨慎。

2.2.2.4 上线发布

当生产环境调试运行验收通过后，就到了上线投产阶段。业务场景部署模式直接运行便可。若数据中心部署上线。这时候就需要到数据中心进行切换、发布。

1. 可以通过 RPA 平台的流程管理模块将工程文件传入数据中心。

2. 数据中心给与的时间往往不会太多。提前准备上线手册。让上线更加顺利。

需注意：

l 此处的超时时间为当流程运行超过该时间后会强制停止。提前评估流程时长设置合理值

l 机器人 agent 默认 5 小时请求一次服务器的策略。建议手动修改至合适的时间。建议 5 分钟内。

l 数据中心部署的话运维比较困难，不排除流程异常的情况。建议所有流程在开始的时候都检查一次当前桌面是否有浏览器、office 等应用然后关闭。避免后续流程无法运行。

l 利用好 RPA 控制平台的监控和报表模块。输出相关数据做好汇报工作。

2.3 特别注意事项

2.3.1 对接方法

RPA 项目因其项目形式的特性需要对接多方人员。包含各种业务部门、统筹部门、数据中心、开发中心等。为了更好的处理项目事宜。必须做好分工及明确各对接负责内容。避免项目过程混乱。

流程实施人员：

平台部署人员：

PM：

2.3.2 需求变更

RPA 项目实施过程中，实施人员对接通常为直接业务人员。免不了出现业务人员变更需求、增加需求等情况。这部分内容往往占着也不少的工作量且会影响进度。为了避免项目延期的可能和过量资源的投入。必须制定需求变更办法。通过规范化方式控制业务需求和控制项目进度。

2.3.3 建议

l RPA 必定是一个长期增长的需求。RPA 平台在扩展性上必须拥有相应的权限模块、机器人管理模块。目前 RPA 平台仍缺乏针对机器人、流程的权限分类管理。

l RPA 通常涉及到敏感业务信息的处理。在业务安全及自身平台安全上仍有完善空间。如数据加密处理，传输加密处理，工程加密处理，平台自身 UEBA 数据的脱敏等。

l 大部分业务流程涉及到 EXCEL 处理。目前 EXCEL 处理的组件较缺乏。采用手动编码的形式实现需求不太具有竞争力且无法完全契合设计器的初衷。