如何挑选合适的 RPA 机器人
近来发现若企业已经完成了第一个 RPA 专案导入，需要再进行第二个专案选择流程时会相较第一次的态度还谨慎许多，开始越来越主动询问该怎麽去找到更适合导入 RPA 的流程，加上 RPA 的相关社群里也不时会有些技术和流程分析谁重谁轻的相关讨论串…个人觉得这有点像挑对象一样吧，RPA 专案也是有其筛选条件的，这边不妨先从 RPA 的创造目的开始讨论起。
RPA之所以被广泛应用在企业协助性质的办公室作业中 (corporate support function) 例如行政管理、人资、财务、IT…是因为这类性质的工作其实就是成本费用本质，变动性和附加价值也没有像核心部门那麽高，难以明显计算出 ROI 及绩效，所以仅能在成本效能(Cost Efficiency) 上多加着墨去达到管理阶层所要求的 KPI。
在全球多数企业普遍难以在营收上突破的大环境下，越来越多公司开始关注自己的行政管理成本到底占整体营运成本的比率。根据研究报告指出，产业排行前段 1/4 的公司其协助性质成本占营收比率比后段 1/4 的成本营收比少约 45%~75%。相关阅读：企业如何挑选 RPA 工具
由此可见在协助性质业务部门上的成本删减 (cost down) 或效能提高会直接显着影响公司经营报告上的数字。
若企业已经决定选择自动化作为解决管理成本 (G&A cost) 过高的工具，那为什麽还是要细部去看怎麽选择流程呢?
通常对自动化的追求揭示了企业实施过程改进的重要机会，这些改进不仅可以提高自动化的潜力，理论上还可以提高工作效率。
而最初选择的几个测试流程用例往往是最关键的，因为最初的测试用例的效果好坏将直接影响公司内部大家对 RPA 的看法。 在没有充分评估待自动化流程的情况下，应该尽量避免将一切自动化的冲动，大部分正式 RPA 导入专案之前，会用”概念验证”(Proof of Concept) 的方式去试水温，并且让组织内部成员熟悉这项新的 IT 类型，之后才会进正式的 workflow 开发流程。
概念验证 (PoC) 简单来说就是选择一个可以代表整条流程的区段，并同时涵盖像是 ERP, MS office 的主要实施的系统 。 如果为概念验证选择的流程用例过於复杂，就会导致专案进展缓慢。如果用例没有创造足够的“令人惊叹”的结果，就不会推动经营管理层去积极决策。假设 A 公司在应付帐款 (AP) 中选择了一个用例，该用例提供了显着的投资回报(ROI)，但它包含了相当程度的非结构化数据，并且需要 OCR+ ，加入 OCR 厂商能力相关等不可控的变数会让专案越来越大坨，大大增加原本规划专案时程延长的和对技术丧失信心的风险。
也有案例是公司选择相对简单的流程并短时间内成功地自动化了，选择单纯的流程没有不好，但需要格外注意有没有产生良好的 ROI 或其他引人注目的好处。流程选择的艺术在於怎麽将自动化的潜在复杂性和好处之间取得平衡，无论是直接人工小时的减少，还是错误率的降低还是员工跟机器人协作的满意度等等…。
接下来我们进入正题，不管在概念验证 (POC) 阶段或是在正式导入阶段，要怎麽评估出更适合 RPA 的流程呢? 有三个大的面向可以评估。
** 一、 流程性质 **
流程性质归纳四种如下:
手动且重复性质高 Manual & Repetitive >> 大部分是使用者来进行操作，流程步骤几乎是固定标准化的 ，规则导向 (rule-driven) 是 RPA 流程最基础的施行指标
半人工且重复性质高 Semi-Manual & Repetitive >> 流程本身有半自动化的工具辅助例如 Macro 或是 Outlook 的插件
自动化程度很高 >> 有些制造业的流程自动化程度很成熟，或是你会发现其实企业标准化程度高几乎不太会变动的流程早就已经被自动化了 XD
手动且缺乏重复性 Manual but not Repetitive >> 流程掌握在 user 手上且其步骤规则会不时变化
1、2 为比较适合导入 RPA 的流程，3 相对没必要直接跳过， 4 是风险性和成本都会较高本质上不适合导入 RPA
上面的四种其实都要搭配例外情境的考虑，有多少是我们能事先掌握的。 假设今天我们要设计一个摩天大楼的电梯， 那是不是不能只考量到四肢健全的人，盲人呢? 行动不变的人呢? 小孩? 老人? 又或者电梯尖峰时间的流量、每层楼会接触的用户性质、进出权限和场景… 像 RPA 这种已经偏系统面的流程设计，仅考量 Happy Path 的这个面向会导致专案上线失败的风险。
二、复杂度模型
每个企业的实际状况不尽相同，这边提供一些大的指标如下，可以用来参考并产生属於企业自己的复杂性模型 (Complexity model)
High Level FTE Assessment model; Source from Uipath Academy
萤幕截图数 (Number of Screens) > 这可以在一开始评估时用来估算流程步骤数
if/else 的场景数 (Variations/Scenarios) > 用来估算商业逻辑 Business logics 的数量
应用程式 / 系统数 (Types of Applications) > 这流程会涉及到的像是 Java based 的系统、Mainframe app, SAP, web, Dotnet, MS office…
结构性的资料 (Structured Inputs) > 可以被系统读取较标准化的资料 图片或是 email 里信件 free text 内容是非结构性资料
标准化的资料 (Standard Inputs)
使用远程画面开发 (Image-based automation)> 像是用 citrix or VDI
自由文字 (Free text) > 像是信件的内容文字
1,2,3 越高表示需要越多开发时间 若 4,5 的百分比越高就表示越简单可以开发 6 会大幅改变开发方法并且技术风险性很高，而公式会在 123457 加权算出一个复杂度比例后若有 6，再加成一个倍数。
例如原本算出来是 50% 被界定为中等开发难度的 range，若需要以画面为基础开发 倍数比率设为 *1.4 = 70% 直接晋升为高复杂度的流程范围
三、效益类型
COST Saving: 人工小时 (FTE) 节省 (同时也意味着交易 / 处理量要大才能达成显着效益)
Productivity Gain: 增加一时间段能处理的容量 、 减少转手时间或次数、平均处理时间 (Average handle time) 降低
Business Agility: 使业务可以用更快的速度灵活反应
Quality Improvements/ Error reduction: 降低错误率
Customer Satisfaction: 这部分是属於价值型 (Value_added) 的因素 像是加快客服速度就能大幅提高顾客满意度
Flexibility: 具有可以规模化或是被复制的弹性
Compliance: 可以符合监管要求
讲起来很抽象，不同流程所适用的效益类型也不尽相同，但商业效益必须在这时候就是流程一开始就加入评估。个人认为在导入 IT 专案要有 “以终为始” 的精神，一开始就要清楚知道这专案导入后效益会落在哪个维度。导入团队和流程使用者便能在专案过程中有最终目标的轮廓和施力的方向。
四、流程的系统基础环境
环境建立往往比想像中更耗时间，如果再加上你所选定流程涉及到的系统过不久就要升级、改版、换框架、换语言…，那整个开发团队会花很多时间在来回沟通并等待 IT 协助设定好环境。遇到以上将要发生的系统变动请必须慎重考虑是否暂缓这项自动化流程开发，有很高的风险会像是道路铺好柏油没两周又要挖开布置底下线路一样，既浪费人力时间和金钱，也会进扰人的更改合约需求 (Change Management) 的程序。
好的开始是成功的一半，其实各国有许多 RPA 开发人员或流程分析员 (Business Analyst) 也不约而同认为选择对的流程几乎可以是影响专案成败的关键因素，所以宁愿花多点时间在一开始的评估上面也不要急着就进流程开发。
