1 业务流程的梳理和分析
该阶段也可用于完成自动化流程的机会评估，即通过分析现有的业务流程，从中找到那些适合自动化的流程，计算业务收益和实施成本，以判断RPA实施的优先级。
我们首先需要了解做RPA流程分析的一个痛点，那就是如果希望获得精确的结果，就需要分析到业务流程的最终细节。通常我们按照业务流程的颗粒度，可以分解为5个级别。
·领域（Domain，例如：信贷）
·阶段（Phase，例如：贷前处理）
·活动（Activity，例如：信用审核）
·任务（Task，例如：获取客户的信用信息）
·步骤（Step，例如：根据客户名称查询客户的信用记录）
对于传统的应用开发，将流程分解到第五级——步骤级别（Step）已经足够细致，可以直接转换为IT开发使用的需求文档。但是对于流程自动化开发，还需要做到更细致的一个级别——动作级别（Action）。例如将“根据客户名称查询客户的信用记录”这个步骤分解为不同的动作，如Action 1，登录客户征信系统；Action 2，打开客户信用查询页面；Action 3，录入客户名称，以此类推。因为只有将流程细化到动作级别，才能准确评估RPA所执行的工作，包括自动化的可行性以及流程可自动化的比例。
但是，如果我们在梳理流程的一开始就基于这种颗粒度去分析，往往是不可行的。
第一，由于分析的工作量巨大，不只是文档收集和整理工作，还包括现场的调研和访谈工作。
第二，由于细化的流程只有基层的操作人员才真正了解，需要调用太多的企业内部资源才能完成此项分析工作。所以，在流程梳理和分析过程中，企业普遍采用的是逐步细化的分析方式。
·第一步：按照业务板块、业务领域或者业务阶段进行“泛扫描”（Wide Scan），即通过对业务领导访谈和初步沟通，或者基于通常的行业经验，采用定性的方式初步选定某一流程范围。定性分析可以参考第4.4节。
·第二步：在选定的流程范围内，通过研讨会和调研表的方式对流程范围进行“细扫描”（Narrow Scan），此时，可以基本圈出一些自动化可能性较大的业务活动。
·第三步：基于圈定的业务活动的具体操作，通过现场调研或收集细化的流程标准、操作规程来制作细化的流程图。基于细化的流程图，再进行自动化可行性分析，这个步骤可以称作“深度扫描”（Deep Scan）。通过深度扫描的结果反推细扫描中流程的自动化可行性，最终明确由泛扫描筛选的流程范围中的自动化可行性流程。同时，分析这些候选流程的工作量情况，最后折算成FTE。一般我们采用调研表的方式从基层部门搜集一些信息，主要包括该流程发生的周期（每月、每周还是每天）、处理时段、发生数量、处理时间等。
·第四步：专业人员依据这些信息计算RPA机器人的处理时间、RPA机器人的数量、RPA流程的实施工作量。最终，依据企业目前的运营成本和未来RPA的成本投入，为每个候选自动化流程计算它的投资回报率。
·第五步：根据投资回报率的分布情况以及实施难度和风险，识别那些投资回报率高且风险低的业务流程并优先实施自动化，剔除那些投资回报率低且风险高的业务流程。对于投资回报率高且风险高的业务流程，尽早拟定风险缓释方案和计划，再将其纳入优先级第二梯队。对于投资回报率低且风险低的业务流程，将其纳入优先级的第三梯队。企业会依据不同的梯队分布情况，结合自身的IT投入情况来拟定自动化实施的优先级顺序。
5.2.2 编制自动化需求
经过第一阶段的流程分析，企业已经很明确需要实施自动化的流程范围。接下来，企业需要进一步对流程的细节进行观察和分析，定义出流程中每个步骤的操作过程，标识出哪些步骤由人工来操作，哪些步骤由机器人来操作，人和机器人如何配合工作，并采用业务流程图或者电子表格的方式来表达。这个需求文档通常叫作PDD（Process Definition Document）文档。
但是，我们在实际编制需求文档的过程中发现，由于需要将业务步骤的操作过程描述得非常详细，就需要将操作界面屏幕进行截图，并配以大量的文字说明，这会造成需求文档编制人员花费大量的工作时间在琐碎的细节描述上，而且最终呈现给开发人员的效果并不好。在正规的软件开发中，需求文档的编制是不可避免的，但在RPA领域是否有更高效的方式来完成这个过程呢？
实践证明，采用流程图加视频说明是一种更有效率的工作方式。业务人员将自己的操作过程录制成视频，在视频录制过程中，一边操作，一边解释，利用最直观的方式将业务需求传达给RPA开发人员。敏捷的需求生成有利于知识的传播和使用。
5.2.3 RPA设计、开发和单元测试
RPA的设计、开发和单元测试是RPA项目实施的核心阶段。这个实施过程并非是遵循传统的瀑布式软件开发方法，而是遵循敏捷方法论，采用冲刺Sprint和迭代增量Scrum相结合的方法。Sprint指的是一次冲刺迭代，通常是以最快的速度完成一次开发任务的时间周期。Scrum包括一系列最佳实践和预定义角色的管理过程，是一种更高效开发软件的管理方法。
在RPA项目团队组织上，我们可以将实施团队划分成不同的工作小组，每个工作小组关注1～2个完整流程的自动化实现。
图5-5为一个冲刺Sprint实现流程。工作小组成员通常包括流程负责人、Scrum教练、架构开发和测试人员。他们在一起紧密工作，从RPA设计到开发，再到单元测试可以被称为一个冲刺Sprint。当一个冲刺Sprint完成后，工作小组就可以将RPA提交给UAT测试，进而转入下一个冲刺Sprint。项目经理和总架构师需要划分不同工作小组的工作范围，跟踪任务进度。当多个工作小组并行工作时，他们可以充分复用已有资产，也并不会产生工作内容上的冲突。
图5-5 一个冲刺Sprint实现流程
1.设计过程
在RPA流程的设计阶段，通常每个流程都需要产出一个独立的方案设计文档（Solution Design Document，SDD），这样就保证该流程实施的独立性，包括后续的开发、测试、部署上线工作。与传统软件开发中的概要设计文档一样，SDD承接了PDD中的流程需求，体现了整体的设计要求，以及对后续RPA开发过程的指导。通常在单流程设计前，RPA架构师可将项目的整体架构设计、设计开发原则和指南、可复用组件等一切共性内容，都提炼到整体架构设计或解决方案设计文档中。
虽然，目前在业内仍没有一套标准格式的SDD文档，但基于之前一些项目的最佳实践，我们可以大致罗列出RPA设计文档中的主要内容。
·流程概述：定义该流程的基本描述和运行情况、PDD中的业务用户需求，明确流程的业务负责人和沟通接口人，以及RPA设计的前提假定、技术约束、环境依赖和所要求的服务水平协议等。
·涉及的应用系统/工具：描述该流程需要操作的应用系统、工具、技术。例如，是B/S架构还是C/S架构。
·描述流程中所涉及系统的用户登录方式，如哪些系统需要业务用户登录，如果需要，在开发或测试环境下所使用的用户名和口令是什么。
·现状业务流程：内容主要来自PDD中对于业务流程的描述。与SDD的区别是，SDD中所描述的业务流程必须是能够被RPA设计人员所理解的。
·目标业务流程：主要目的是清晰地告诉业务人员，引入RPA之后的业务流程是如何运行的，其中包含机器人处理的环节、人工处理的环节，以及双方的协作环节。那么，设计人员就需要收集汇总该流程在业务层面的优化点，以及由于引入机器人之后所带来的流程改进点，并将这些统一体现在目标业务流程的定义中。
·机器人处理流：目标业务流程是面向业务人员的，而机器人处理流是面向技术人员的。机器人处理流可以拆分出该流程需要几个机器人、几个自动化任务，以及这些自动化任务的执行时间是什么，任务之间是如何编排的。
·文件目录结构：为了区分不同业务流程的处理过程，机器人通常需要拥有专属的文件目录。SDD中应清晰地定义出机器人程序的存储目录和所需处理的文件的存储目录，避免出现不同流程输入、输出文件混用的问题。
·机器人设计要点：体现机器人程序之间的依赖关系，包括所需要复用的代码库、配置文件、机器人的控制方式、数据安全和数据管理、业务连续性处理手段等一切需要重点说明的设计内容。
在一些RPA项目中，实施人员常常会忽视对自动化业务流程的设计过程，打着“敏捷快速”的旗号直接从需求阶段转入开发阶段，这是十分有害的。如果开发人员不在RPA的开发过程中仔细思考如程序结构、人机协作、目录划分、异常处理等设计问题，则只能依赖于后续不断地开发迭代来解决前期的设计缺陷，反而会大大拉长开发周期。
2.开发过程
RPA的开发过程通常是依据SDD中的设计成果，在整体架构设计的要求下，一步一步将业务流程步骤转化为自动化脚本、流程图或者自动化程序。对于SDD文档中不能清晰表达的业务操作过程，开发人员还需要邀请具体业务办理工作人员直接参与到RPA开发过程中，以明确告知开发人员每个步骤的业务目的和处理方式。由于RPA项目的敏捷特征，RPA的设计人员和开发人员通常是在同一个工作小组，甚至是同一个人，从而节省了从设计到开发过程中的沟通时间。
在RPA实际开发过程中，开发人员经常会遇到之前流程分析过程中所没有考虑到的情况，比如某个界面元素抓取不到，或是自动化操作不成功（手动操作成功），这就需要RPA开发人员临时转换思路，换一种技术手段来实现自动化处理。这些技术手段通常与RPA程序运行的稳定性有关，通常我们需要在开发过程中尝试那些稳定性更高的技术。如果按照自动化程序运行稳定性排序，由强到弱依次为捕获界面控件、快捷键操作、界面图像比对、界面坐标定位。如果各种自动化技术手段都无法解决这个技术障碍，那么就需要与该流程的负责人沟通，寻求业务层面的解决方案。
基于最佳实践，开发人员可以采取循序渐进、多次迭代的方式来实现RPA代码的开发，这也符合敏捷开发的指导思想。
·第一步，搭建整个RPA程序框架。编写代码前，先开发主辅程序的调用方式、配置文件的读取方式、预处理、中间处理和后续处理等环节，并预留异常处理和程序补偿机制的处理环节。
·第二步，以流程中某个业务实例的正常处理过程为基础来开发RPA程序。将业务数据以常量的方式来表达，这样可以快速发现该流程中所需要的自动化技术，以及存在的技术障碍点，便于尽快寻找解决方案。
·第三步，当正常处理流程可以自动化运行之后，按照业务处理要求，再在RPA中加入必要的循环处理、分支处理，并将原来程序中的业务数据常量转换为参数变量。这样，多个业务流程就可以实现自动化了。
·第四步，在满足了正常情况的自动化处理之后，开发人员需要在RPA程序中增加必要的日志跟踪和异常处理。异常处理需要覆盖可能出现的业务异常情况和系统异常情况，并设计相应的RPA补偿机制。这样，当机器人重启后，不会影响之前的操作成果。虽然这些异常在实际运行中很少出现，但在RPA开发过程中却要花费大量的精力去设计。也就是说，我们不得不利用80%的开发时间来处理那些只有20%概率发生的异常情况。
·第五步，当RPA程序开发完成之后，开发人员就需要为将来可能存在的横向扩展、环境变更等定义项配置文件，将程序中的部分参数改为读取配置文件的方式，为下一步最终用户的UAT测试做准备。这个过程和传统的自动化测试开发非常相似。
RPA的开发过程和单元测试过程几乎是融合在一起的，一边开发一边测试，开发完成，基本单元测试也就完成了。RPA开发人员需要基于一定量的样本数据对自己所编写的自动化脚本或程序进行测试。这里需要注意的是，所准备的样本数据应尽量贴近真实的业务数据，而且应具备可逆性或可重复性，避免一些数据在提交之后，下次就再也不能重现之前的业务操作，导致无法利用RPA技术，并反复地进行测试工作。这个测试过程和传统的自动化测试过程也是极其相似的。
最后，开发人员完成一定规模的样本测试之后，就可以执行最终用户的UAT测试了。
5.2.4 最终用户的UAT测试
与传统应用系统项目一样，RPA项目的UAT阶段相当于业务人员对RPA运行程序的一个确认签收过程。只有在业务部门确认和签收完成之后，RPA才能上线，这一点在RPA项目中尤为重要。因为以前经常会出现系统上线，但业务未上线的情况，即由于某种原因，无业务用户真正使用这个系统。而RPA的作用就是替代人工操作，如果RPA上线之后，无法与业务人员的操作达成一致，必然会带来灾难性后果。
本质上，最终用户的UAT测试过程与前面开发人员的单元测试过程是基本相似的，即给出一些符合真实场景的业务数据样例，让机器人来运行，由业务人员校验运行成果是否满足业务要求。虽然这是一种黑盒测试，但在测试数据中必须要同时考虑正例和反例的存在，以保障机器人运行的可靠性。
对于UAT测试人员来说，也需要学习新的RPA知识，并转换原来的思维方式。因为测试人员不能按照传统的业务流程要求和处理过程来测试这个新的自动化流程，新的自动化流程替代了全部或部分原来的手工处理过程，必然给业务人员的传统认知带来挑战。所以，UAT测试人员必须与RPA设计和开发人员一起提前了解这个新的自动化流程，如机器人是如何触发启动的；中间是否有需要人机协作的环节；当异常发生以后，业务人员如何再次接管工作，或者再次启动机器人等，不能只是检查机器人处理后的最终数据结果是否正确。
RPA的UAT测试过程通常分为以下几个步骤。
·第一步，测试准入审核。判断前期的设计和开发工作是否完成，文档和代码是否齐全。
·第二步，准备测试数据。这些测试数据作为提供给机器人的输入数据，用于测试自动化处理过程。测试数据包含一些异常数据，以及可能出现的分支处理情况的业务数据。
·第三步，编写测试案例。定义该案例的测试目的、输入数据和预期的处理结果。
·第四步，执行测试。依据测试案例，执行测试，检查测试结果是否符合预期的要求。
·第五步，签收确认。认同通过RPA自动化处理过程和处理结果，将该流程统一部署到生产环境。
UAT测试可以让一线的业务人员真正感受到机器人的处理方式，对未来RPA上线后的运行效率和人机协作方式的改进都会有帮助。
5.2.5 机器人的部署上线
有别于传统应用系统的部署上线，RPA的部署上线不受某个特定的时间窗口限制，也不会牵扯后台数据库的迁移和切换等工作，只是替代了一线业务人员的手工操作，所以对传统的数据中心运维人员来说，通常是无感的。而且，RPA可以分批次部署上线，所以对原有系统和业务运行的冲击和影响很小。
在RPA部署上线前，开发人员需要协助运营人员同步完成RPA运营手册，比如配置文件、机器人启停时间或计划表、运行异常时的解决方案等，相当于开发团队到运营团队的工作成果确认和工作交接过程。
RPA部署上线的核心处理事项是将RPA的程序代码从测试环境迁移到生产环境。在迁移过程中，我们需要注意如下几点内容。
·环境配置的参数调整：最理想的情况是RPA的测试环境和生产环境完全是一样的。如果不能满足，RPA通常采用读取配置文件的方式来适应运行环境的调整，不只是输入输出文件的目录改变，还包括不同环境下的浏览器版本、应用版本等。
·将自动化程序整体打包部署：由于RPA所实现的自动化任务之间存在依赖关系，如A任务调用了B任务，或者该自动化任务与其他类型自动化脚本或程序也存在依赖关系，如在RPA任务中调用其他Python或者JavaScript脚本，所以在RPA部署上线时，需要将所有的自动化程序统一打包。
·版本的管理和控制：由于RPA具有敏捷实施的特性，自动化流程又经常出现变更的情况，而且每个流程的RPA程序版本是分开管理的，导致RPA版本管理的复杂性增加。RPA的管理平台可以与SVN等版本管理工具相结合，另外应有专人负责版本的发布，管理所有在开发态、测试态和生产态的RPA版本。
在RPA部署上线之时，企业就应当配备好相应的运维团队，明确好各方的角色和责任，并制定好RPA机器人管理流程，以便机器人上线之后就能保持正常运行。如果在极端特殊情况下，RPA上线后出现大的问题，需要做下线处理，或者恢复之前的版本，则必须按照事先制定好的后备计划来执行。尽管后备计划可能都不会被使用，对于重要业务流程做万全准备，还是非常有必要的。
5.2.6 RPA机器人的监控和维护
由于RPA机器人运行时会出现异常、中断、故障、业务数据非标准、案件超权限范围、规则未考虑到等情况，所以，运营人员需要既具备系统管理员、业务监督员的角色特征，又需具有能及时响应问题的速度。
企业并不需要为RPA重新建立一套运维体系，而应当基于企业原有的运维体系，再结合RPA特性，进行优化改良。这套运维体系应当具有对运行问题和风险主动监控的能力和被动响应的能力，如图5-6所示。
图5-6 主动监控和被动响应
·主动监控是指当运行的RPA平台或者平台中某个自动化流程发生问题时，监控平台应当有能力自动探测到这个问题，并发出警告，及时通知业务部门以及运维经理。
·被动响应是指当业务用户发现RPA机器人未按照预期提供工作成果，或者发现RPA机器人中断执行时，可以将问题上报给RPA运维团队，然后由运维团队通过现场或远程的方式来解决问题。
不管是主动还是被动的方式，运维团队可以依据问题的重要程度或优先级安排技术人员解决，也可以采取问题逐步升级的方式，引入更多更专业的技术资源。如果问题涉及原有的应用系统、操作系统、数据库、存储或是网络等基础环境的调整，那么就应当引入更多的专业资源。除了发现问题和分析问题外，RPA运维人员还需要采用最敏捷的手段将程序补丁快速部署到生产环境中，将影响降到最低；并且持续完善问题知识库、问题影响性分析、问题检查表等工作内容。
RPA问题侦测、发现、分析、跟踪、解决的整个过程中既需要符合企业已有的IT服务管理流程，如问题管理、工单管理、事故跟踪管理等，又需要满足RPA所制定的特殊性管理要求，如服务水平协议、变更管理等。最终，RPA运维服务情况和传统应用系统的服务管理信息应当形成统一的服务管理报告。
5.2.7 实施过程总结
虽然RPA实施过程与传统的实施过程有很多相似点，都是遵循需求–设计–开发–使用的实施过程，但是整个过程中重心和目的是不一样的。更准确地说，RPA遵循的是学习–构建–执行–提高的实施过程。
·学习：RPA脚本和程序学习人类的操作过程。
·构建：RPA设计、开发、测试和部署上线的过程。
·执行：RPA机器人在真实业务场景下的运行管理。
·提高：依据RPA机器人运营情况所做出的改进和优化。
后两个环节甚至比前两个环节的作用更为重要，也会持续为企业自动化转型工作提供动力。
接下来，将会介绍企业RPA之旅中最需要重点考虑的一些因素，包括机器人的稳定性、安全性、开发和运行效率，以及扩展能力。