企业如何挑对合适的RPA业务流程

近来发现若企业已经完成了第一个Robotic Process Automation (RPA)项目,需要再进行第二个专案选择流程时会相较第一次的态度还谨慎许多,开始越来越主动询问该怎么去找到更适合导入RPA的流程,加上RPA的相关社群里也不时会有些技术和流程分析谁重谁轻的相关讨论串…个人觉得这有点像挑对象一样吧,RPA专案也是有其筛选条件的,这边不妨先从RPA的创造目的开始讨论起。

企业如何挑对合适的RPA业务流程

RPA之所以被广泛应用在企业协助性质的办公室作业中(corporate support function) 例如行政管理、人资、财务、IT…是因为这类性质的工作其实就是成本费用本质,变动性和附加价值也没有像核心部门那么高,难以明显计算出ROI及绩效,所以仅能在成本效能(Cost Efficiency )上多加着墨去达到管理阶层所要求的KPI。

在全球多数企业普遍难以在营收上突破的大环境下,越来越多公司开始关注自己的行政管理成本到底占整体营运成本的比率。根据研究报告指出,产业排行前段1/4的公司其协助性质成本占营收比率比后段1/4的成本营收比少约45%~75%如下图

由此可见在协助性质业务部门上的成本删减(cost down) 或效能提高会直接显著影响公司经营报告上的数字。

若企业已经决定选择自动化作为解决管理成本(G&A cost) 过高的工具,那为什么还是要细部去看怎么选择流程呢?

通常对自动化的追求揭示了企业实施过程改进的重要机会,这些改进不仅可以提高自动化的潜力,理论上还可以提高工作效率。

概念验证(PoC)简单来说就是选择一个可以代表整条流程的区段,并同时涵盖像是ERP, MS office的主要实施的系统。如果为概念验证选择的流程用例过于复杂,就会导致专案进展缓慢。如果用例没有创造足够的“令人惊叹”的结果,就不会推动经营管理层去积极决策。假设A公司在应付帐款(AP)中选择了一个用例,该用例提供了显著的投资回报(ROI),但它包含了相当程度的非结构化数据,并且需要OCR+ ,加入OCR厂商能力相关等不可控的变数会让专案越来越大坨,大大增加原本规划专案时程延长的和对技术丧失信心的风险。

也有案例是公司选择相对简单的流程并短时间内成功地自动化了,选择单纯的流程没有不好,但需要格外注意有没有产生良好的ROI或其他引人注目的好处。流程选择的艺术在于怎么将自动化的潜在复杂性和好处之间取得平衡,无论是直接人工小时的减少,还是错误率的降低还是员工跟机器人协作的满意度等等…。

以下简单提供个实施策略,X轴为数位化程度Y轴为流程的标准化固定程度,分为四个象限去审视:

左上第一象限因为有太多非结构性资料: 像是需要人工读取PDF里的发票资讯并整理,加上流程常常变动,所以不适合导入RPA;右上第二象限要考量的是潜在的自动化变动成本,这时候需要再进行第二层的综观评估,用流程的复杂性和自动化的效益得出它是属于以下哪种类型:

A. “Quick win”直接快速看到成效

B. “Low hanging fruit” 可以轻易达成目标

C. “Must Do/ Long Term Improvement” 必须/长期实施流程改善

左下第三象限是最有潜力达成节省FTE效果的流程,右下第四象限是自动化程度已经很高的流程,需求力道不高。

接下来我们进入正题,不管在概念验证(POC)阶段或是在正式导入阶段,要怎么评估出更适合RPA的流程呢? 有三个大的面向可以评估。

一、 RPA流程性质

流程性质归纳四种如下:

  1. 手动且重复性质高Manual & Repetitive >> 大部分是使用者来进行操作,流程步骤几乎是固定标准化的,规则导向(rule-driven)是RPA流程最基础的施行指标
  2. 半人工且重复性质高Semi-Manual & Repetitive >> 流程本身有半自动化的工具辅助例如Macro 或是Outlook的插件
  3. 自动化程度很高>> 有些制造业的流程自动化程度很成熟,或是你会发现其实企业标准化程度高几乎不太会变动的流程早就已经被自动化了XD
  4. 手动且缺乏重复性Manual but not Repetitive >> 流程掌握在user手上且其步骤规则会不时变化

1、为比较适合导入RPA的流程,3相对没必要直接跳过, 4是风险性和成本都会较高本质上不适合导入RPA

上面的四种其实都要搭配例外情境的考虑,有多少是我们能事先掌握的。
假设今天我们要设计一个摩天大楼的电梯,那是不是不能只考量到四肢健全的人,盲人呢?行动不变的人呢?小孩?老人?又或者电梯尖峰时间的流量、每层楼会接触的用户性质、进出权限和场景…像RPA这种已经偏系统面的流程设计,仅考量Happy Path的这个面向会导致专案上线失败的风险。

二、RPA复杂度模型

每个企业的实际状况不尽相同,这边提供一些大的指标如下,可以用来参考并产生属于企业自己的复杂性模型(Complexity model)

  1. 萤幕截图数(Number of Screens) > 这可以在一开始评估时用来估算流程步骤数
  2. if/else的场景数(Variations/Scenarios) > 用来估算商业逻辑Business logics 的数量
  3. 应用程式/系统数(Types of Applications) > 这流程会涉及到的像是Java based的系统、Mainframe app, SAP, web, Dotnet, MS office…
  4. 结构性的资料(Structured Inputs) > 可以被系统读取较标准化的资料图片或是email里信件free text内容是非结构性资料
  5. 标准化的资料(Standard Inputs)
  6. 使用远程画面开发(Image-based automation)>像是用citrix or VDI
  7. 自由文字(Free text) >像是信件的内容文字

1,2,3越高表示需要越多开发时间若4,5的百分比越高就表示越简单可以开发6会大幅改变开发方法并且技术风险性很高,而公式会在123457加权算出一个复杂度比例后若有6,再加成一个倍数。

例如原本算出来是50% 被界定为中等开发难度的range,若需要以画面为基础开发倍数比率设为*1.4 = 70% 直接晋升为高复杂度的流程范围

三、RPA效益类型

  1. COST Saving: 人工小时(FTE)节省(同时也意味着交易/处理量要大才能达成显著效益)
  2. Productivity Gain: 增加一时间段能处理的容量、 减少转手时间或次数、平均处理时间(Average handle time) 降低
  3. Business Agility: 使业务可以用更快的速度灵活反应
  4. Quality Improvements/ Error reduction: 降低错误率
  5. Customer Satisfaction: 这部分是属于价值型(Value_added)的因素像是加快客服速度就能大幅提高顾客满意度
  6. Flexibility: 具有可以规模化或是被复制的弹性
  7. Compliance: 可以符合监管要求

讲起来很抽象,不同流程所适用的效益类型也不尽相同,但商业效益必须在这时候就是流程一开始就加入评估。个人认为在导入IT专案要有“以终为始”的精神,一开始就要清楚知道这专案导入后效益会落在哪个维度。导入团队和流程使用者便能在专案过程中有最终目标的轮廓和施力的方向。

最后还有个很重要的一点- 流程的系统基础环境

环境建立往往比想像中更耗时间,如果再加上你所选定流程涉及到的系统过不久就要升级、改版、换框架、换语言…,那整个开发团队会花很多时间在来回沟通并等待IT协助设定好环境。遇到以上将要发生的系统变动请必须慎重考虑是否暂缓这项自动化流程开发,有很高的风险会像是道路铺好柏油没两周又要挖开布置底下线路一样,既浪费人力时间和金钱,也会进扰人的更改合约需求(Change Management) 的程序。

本文是51RPA中文社区原创文章。发布者:RPA小当家,转载请注明出处:https://www.51rpa.net/rpaedu/3430.html

(6)
RPA小当家的头像RPA小当家
上一篇 2019年10月23日 上午8:30
下一篇 2019年10月25日 下午7:28

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注