[经典推荐]RPA最佳实践，RPA初学者必读

安永（Ernst and Young）在2017年发布的一篇报告中指出，30%到50%的RPA初始项目以失败告终，而造成这些项目失败的原因之一就是选择错误的流程实施RPA自动化。面对多个候选业务流程，RPA项目管理者经常陷入决策困境：应该做哪个？哪个应该先做？本文会对以上两个问题进行探讨。

哪些业务流程适合RPA？

流程改进不可以一刀切地选择方案。RPA作为流程改进的一种工具，适合于重复、规则导向、稳定少变的流程。

关键词1:　重复　(Repetitive）

开发RPA流程会有一定的成本，如果一个流程只是一次性的，那么就没有花时间和人力去RPA 的必要。最佳的选择是高频重复的流程，这样一是可以优化ROI，二是可以在最短时间内搜集足量的测试数据，缩短开发周期。

关键词 2:　规则　(Rule-based)

目前RPA技术通常能够自动化以规则为导向的、标准化的流程。这并不说明，需要人为判断的流程就不能用RPA自动化了。如果一个流程的某个步骤需要人为经验判断，可以考虑使用attended bot，或人机回圈（human in the loop），在自动化流程中融入人为干预实现人机互动。但如果一个流程有相当数量的步骤需要人为介入，那么这个流程就不适合RPA。

关键词3:    稳定  (Stable)

当操作流程或用户界面发生改变时，需要对RPA程序进行相应的调整。因此为了减少维护成本、提高项目ROI, 实施RPA项目需要挑选相对稳定的流程。流程稳定性包含两个层面，一是看流程的业务逻辑是否有很多变化或变种；二是看流程的软件系统是否在短期内会有大的改动。通常业务逻辑和系统在三到六个月内不会有大变化的流程才适合RPA。

我们有多个候选业务流程，应该优先做哪个流程？

两个围度

业界普遍的做法是从“复杂性”和“预期年化效益”这两个围度来量化衡量所有的候选流程。

➤ 围度1：复杂性

复杂性是由许多因素决定的，UiPath建议了一套很好的复杂性评分系统（见下图）：

1、软件系统屏幕切换数量：也可以用流程步骤数量替换。其实还有一种简单粗暴的方式就是衡量人工处理时长，通常我们认为五分钟以内的流程较为简单，十分钟以上的流程相对复杂。

2、流程场景数量：并不需要穷举所有场景，要考虑主要场景所占比例，进而思考需要自动化的是哪些场景。

3、输入的标准化程度：如果输入数据来自不同的部门或组织，且标准化程度低，那么RPA之前的准备工作比如流程改进或流程标准化的复杂性和周期就会增加。

4、流程软件系统的种类：比如基于浏览器运行的软件(WebApp)RPA起来要比基于Java的软件或SAP软件来得简单。

5、是需要基于图像的自动化：比如有些软件需要通过Citrix Receiver接入。在RPA时就需要应用OCR自动化这种较复杂的技术。

6、非结构性输入所占比例：非结构性输入包括自由文本(free text)输入、图片和扫描的PDF文档。如果这些输入占有相当比例,那么单靠RPA制定解决方案是不够的，需要结合其他AI技术比如自然语言处理(NLP) 和OCR来提供方案，复杂程度则相应提高。

通常RPA项目管理人员需要咨询专业开发人员的意见，给这些因素付以权重。然后针对这些因素给候选流程逐一进行难度打分，最终算出每个候选流程的加权难度值。

➤ 围度2：预期年化效益

衡量年化效益也需要从多角度考虑，通常的做法只从人工节省单方面考虑，但这样未免过于片面。对于难以量化的效益，项目管理者可以充分咨询业务团队的意见进行评估。

矩阵

将所有候选的流程从两个围度量化后，可以将它们画在一个2乘2或3乘3的矩阵图内。如果您的团队还处在试点(Proof of concept) 阶段或者在RPA实施方面经验不多，请务必先从右下脚的“甜蜜区” (quick wins) 开始。选择难度最小，价值最高的流程。在制定RPA实施蓝图时，先做低难度区，再过渡到高难度区。因此，建议的选择顺序为：Quick wins—>low hanging fruits—>must do improvements—>long term improvements。

如果您的团队在RPA实施方面已经成熟，对于各种RPA技术已经有相当的应用经验。那么可以先看高价值区，再到低价值区。建议的顺序则为Quickwins—>must doimprovements—>low hanging fruits —>long termimprovements。

当然不要忘了还有其他重要的因素决定着RPA项目的优先排序，比如与其他正在开展的项目所具有的关联性、预估到的业务量的突然增长、以及法规和监管的要求。蓝图路径的制定也需要和企业战略，开发预算等其他因素结合起来进行考量。

最后，笔者想要和大家分享的是，失败并不是魔鬼，不要把RPA实施过程中某个项目的失败当作一件坏事。学习型的团队和组织会从失败中吸取经验而获得更多成功。