RPA的10项业务价值
(Business Value)来说,若是站在不同的角度就会看到不同的结果。
RPA软件厂商一般是最乐观的,表达的观点也最为激进;而提供RPA服务的咨询服务公司就会相对保守一些,同时还会埋下一些危机因素和恐慌意识,但同时也会告诉用户,只要这些问题都解决了,前景仍然是光明的。
各种市场宣传材料中通常会谈到RPA的第一个价值就是节省成本,因为通过自动化技术来降低运营成本,减少人力投入,这几乎就是产生RPA的原动力。
安永咨询公司称可以节省50%~70%的成本;IDC的报告称可以节省30%~60%的成本;Kinetic咨询公司甚至声称能节省90%的成本。
也有很多用户认为成本缩减没有达到预期,而且成本缩减的预期排序也落到了后面。
显然,对于RPA能够降低成本这件事情,大家是有共识的,但是对于能够降低多少成本,各方的意见还存在分歧。
所谓RPA能够降低的企业成本主要包括三部分内容:人力成本、管理成本以及可能存在的配置成本。
人力成本由机器人能够减小的FTE值来决定。FTE是指全时当量(Full-time Equivalent),即工作人员工作量的度量单位。FTE为1,相当于一个全职工作人员的工作量;FTE为0.5,表示完成全部工作量的一半。
配置成本是针对由于RPA替代而减员的情况,因为机器人不需要小隔间、办公桌、电脑、电话、办公场地等。配置成本是由减员数量来决定的。
原因一,企业可能对于自己目前业务流程中各个环节的运营成本是模糊的,也就没有办法进行量化核算,只能进行大致的估算,所以成本比例无法精准核算。
原因二,企业最早期对于RPA的印象很多是来自厂商的一些Demo演示。Demo中都会最大限度地体现自动化优势,而到了实际环境中,却发现由于自身业务流程标准化、规则不清晰等问题,致使能够实现的自动化比例过低,所以未能达到当初的预期要求。
由于企业各自运营情况、人员成本和IT系统的建设情况各不相同,也就没有一个确定的成本节省比例可以拿来直接参考。
在RPA的实施初期,管理者不应过多考虑节省成本这件事情,而应将其作为一个长期的考核目标。因为一旦谈及成本节省,员工就会不自觉地与裁员、降薪等词汇联系在一起,特别是在自动化的初期,并不利于该项技术的推广。
对于中国一些欠发达地区,员工薪资水平较低且技术人员能力较弱,RPA核算出来的投入产出比也并不会太好。
那些成熟运营的企业还是应该采用科学的方法,先摸清目前企业中的作业成本分布情况,再通过试点摸清RPA可能带来的自动化比例,明确未来运行RPA后的作业成本估算方法,依据这些因素来合理确定自己的期望值。
机器人以超于常人的速度工作,且可以24小时一直运行,而人类员工可能会因为疲倦、懈怠、分心等生理或心理因素拖慢正常的工作效率。
如果说目前不应过于讨论自动化的成本节省问题,那么值得讨论的问题就是时间的节省和效率的提升。我们与其费尽心机地计算每个环节的作业成本,还不如将精力投入到如何改进自动化的生产效率,人员应该如何配合自动化的过程。把目光放长远一些,成本减少不过是效率提升的一个副产品。
要考虑机器人的合理工作日程编排,充分发挥单个机器人的使用效率,以及机器人与机器人之间的协作效率。
尽量采用不需要有人参与协作的机器人运行方式,从而减少人机交互带来的效率损失。
对于刚刚尝试使用RPA的企业来讲,初期实施的流程都是简单流程,发生在整个流程中的某一环节,如比对数据、合并清单等。而单点效率的提升并不能代表整个流程效率的提升,更应该将RPA应用到端到端的全流程来提高企业的整体运营效率。
提高流程质量是为了最大化地提升该流程的交付成果质量,并在过程中减少浪费。
尽管一些企业已经有了非常严密的操作规范,但人类员工在工作中还是经常会出现处理步骤遗失或颠倒的情况,影响交付成果的质量,或给后续的处理流程带来隐患。这样的错误对于管理者来讲是很难监督的,因为不会采用人工的方式来监督员工的每个工作细节,通常是采用老员工“传帮带”的学徒方式。
员工通常对这些错误也是不自知的,可能直到多年后造成企业的直接损失之时才会被发现。而RPA必须按照既定的设计步骤来严格执行,而且通常会选取效率和质量最佳的人类员工的操作方式来执行,这些执行过程又是完全透明地展示在管理者的面前。
在一些复杂的业务操作中,员工手工操作容易出错,当出现错误时,又需要复杂的错误修正处理过程。RPA的流程处理基于结构化数据,所以理论上可以达到100%的准确性。但这并不意味着RPA永远都不出差错,如果出现了之前没有测试过的一些情况,则很有可能导致RPA机器人出现错误操作。
另外,一旦RPA有错误的操作,这个错误也会被100%执行,直到有人发现。所以,RPA不但需要完善的测试工作,还需要在生产中不断优化提升,进行定期巡检,逐步弥合真实运行环节的各种情况,不断完善机器人的稳定性和健壮性,就如同工厂里的老师傅爱护自己的机器一样,员工也要爱护帮助你完成工作的机器人。
由于企业内外部的监管合规要求不断加强,一些新规则和新法规的推出也给业务流程增加负担。为此,RPA可以记录业务处理的每个步骤,以防手动错误并为合规管理员提供完整透明的信息。
一些必要的合规操作要求可以统一加载到机器人的自动化脚本中,这样可以避免人类由于疏忽这些规则而带来的风险。企业中的风险和合规部门也可以使用RPA帮助自己执行检查工作,从而减少他们自己的日常工作量,提升监管效率。
一个是关于数据安全。企业中经常会涉及一些敏感业务数据的操作,如果这些数据经过人工来处理,就可能有被篡改和泄露的风险,如果引入RPA,由机器人进行数据处理,再将这个操作过程对人隐藏,就可以最大限度地减少员工与敏感数据的接触,从而降低欺诈和违规发生的可能性。
另一个是关于网络安全。一些企业会严格禁止员工在自己的工作电脑问外部网站。这是担心员工可能将企业的内部数据对外泄露,或是员工在浏览外部网站时,不小心受到木马病毒或网络攻击等。这种方式其实是一把双刃剑,保护网站安全的同时限制了员工便捷获取外部网络信息。但是RPA可以很好地解决这个问题,它只会按照既定的规则访问固定的网站,获取固定的信息,而不会点击或浏览其他信息,所以对RPA开放网络权限没有任何风险。员工需要什么外网信息,就可以利用机器人来帮助抓取。
RPA这种既像人类又像机器的特征,可以帮助我们解决很多企业运营中的难题。
除此之外,还有很多敏捷特征是在RPA实施过程中所体现的。例如,由于机器人模拟的人工操作有很多细节,所以通过传统的纸面书写的需求说明书难以充分表达,通常在开发过程中需要业务人员和开发人员一起参与,共同讨论来确定每个实现细节。这种敏捷特征非常像是“结对编程”,或者是Scrum。
维护RPA时也体现了其敏捷性。例如,一个小的业务变更不必像传统应用一样,需要业务人员将待修改的需求提交给IT开发部门,IT开发部门再来设计、开发、测试,一整套流程走下来耗时耗力。由于RPA的易用性,在一定的管理许可下,业务人员可在自行维护、提交,代码审核后发布上线。这样一线员工就可以根据业务的调整情况,随时更改机器人的配置和处理规则,以满足自己的操作需要。
第一,对于RPA处理流程的横向扩展能力。因为每个独立的流程都可以单独实现自动化,所以RPA项目不必像传统ERP项目一样,必须在全部梳理流程或整理需求的基础上才能进行,当未来再增加新的流程到RPA环境时,对之前实施的流程也没有影响。
第二,机器人数量的横向扩展能力。实际业务中经常会出现某类业务的业务量突然增加的情况,有的情况是有固定时间周期的,比如月末、月初;有的情况是随机出现的,比如股市大涨时,人们都去证券公司开户。但是原来负责这项工作的人员并不会突然补充进来,那么在这种业务波峰时段,业务会被积压或延时处理。如果有了RPA,就可以在人力不足时,及时补充有着同样能力的软件机器人。
机器人的资源可以随时调度,可以依据业务量情况灵活地扩大或缩小规模,以响应不经常出现的业务量激增或激减,从而避免新员工的招聘、培训或遣散,也不需要员工加班或者多班倒。
RPA项目只需要进行部署和实施,不需要设计和开放,比传统IT项目见效快。
第一,目前企业大多执行的是一些RPA试点项目,从IT的开发人员到业务人员再到主管领导,对RPA的思想理念、技术特征、软件产品、实现方法等都不熟悉,即使是那些外部服务供应商也只拥有少量的RPA专家,内外部的人才短缺都造成了较长的学习曲线,从而影响了项目的交付周期。
第二,企业已有的流程标准化程度和规则化程度不足以满足RPA项目的实施,所以在项目前期需要长时间的流程梳理和规则梳理工作,导致该项工作超出了原本的预期;另外,企业中原有的管理体系无法满足RPA项目的实施特征,如通常需要给机器人申请一个新的用户ID和口令用于系统操作,但企业原有的审批流程只是针对新员工入职的,所以在流程上就无法继续进行,中间需要多次沟通,类似的例子还有很多。
所以项目管理流程和机制上的障碍都是导致RPA项目无法顺利进行的原因。不过可喜的是,对于那些愿意参与RPA实践的行业领先者来说,他们愿意持更加开放的心态来看待这些问题,只有直面问题、解决问题,才能避免未来RPA项目大规模实施时的风险。
通常我们认为RPA只是为企业的后台运营提供帮助,而事实上RPA也能作用于对外客户服务领域。
第一,可以将RPA技术应用到对外客户服务领域,如利用机器人协助提供客户呼叫服务、客户保修服务、保险领域的理赔服务等。
虽然客户服务中心的工作尚不能像后台运营那样可以完全交给机器人去处理,但一些典型的流程已经交给RPA处理。例如RPA协助客服人员使用多个系统来查询客户信息。通过减少或消除烦琐且容易出错的客服工作,减少客户的等待时间,既提升了客户满意度,也可以让客服人员更加专注于与客户业务办理的沟通交流。
第二,RPA可以直接协助客户实现自助服务。我们发现在银行网点的自助机上会有一些十分复杂的业务办理,需要客户操作的步骤十分烦琐。
通常,客户遇到这种情况会叫来大堂经理寻求帮助。这样一来,自助机并没有起到它相应的自助作用,反而浪费了双方的时间,显得有些得不偿失。如果将RPA引入自助服务过程中,基于客户录入的基础信息,由机器人自动完成后续的操作处理,处理完成后,再由客户来确认结果。例如对公客户开户业务,一些银行已经开始推荐客户采用自助机来完成信息的录入,比如营业执照号码、办公地点、联系人、联系电话、注册资金等,这时如果采用RPA机器人到提供企业信息服务的外部网站上自动查询,或者通过图像识别技术对扫描后的营业执照进行识别,再将获取的信息自动回录到银行自助机上,就可以大大节省客户的办理时间。
第三,即使RPA只是应用到企业的内部作业流程中,由于后台的加速也会同样带来前台的加速,最终体现为对客户服务效率上的提升。
例如客户向保险公司申请理赔的流程,这不只是一个简单地与客户交互的过程,还包括保险公司内部作业的一些环节,包括检查请求信息、获取证明信息、检查和校验、判断理赔金额等,最终再将理赔结果反馈给客户。如果利用RPA技术自动检查信息、抓取证明信息、判断理赔处理的业务规则等,当保险公司的内部处理速度加快后,客户也就可以尽早地得到理赔。
当员工刚刚开始了解RPA时,他们可能会隐隐觉得机器人会影响到他们现有的工作,甚至会想到企业是否因此裁员。但是在所有的案例中,我们看到更多的是企业利用RPA来减少员工的重复工作和无聊的系统操作,或者利用RPA来补充那些长期人手不足的岗位。
所有的企业管理者对此都拥有清醒的认识,目前更需要的是人类和机器人可以共存并且能够并肩工作,希望能够避免员工在重复劳动中产生不良情绪。
消除不良情绪比起减少的工作量来说甚至更有价值,因为不良情绪可能会导致员工丧失工作积极性,甚至是离开现有的岗位或企业,而且这种情绪会在员工之间相互传染,导致整个团队的战斗力都会变弱。管理者都希望员工在工作中能够获得成长,而RPA可以准确地执行员工的手工任务,使员工可以将更多的时间投入到更多有价值的工作中。而一线员工可以成为问题解决者和关系构建者,使他们获得一个光明的职业前景。
从员工角度来看,其实也没有人愿意花一整天时间将数据从一个系统录入或复制到另一个系统,或是核对两张电子表格中的数据,如今RPA可以为员工带来工作环境的转型,使他们有机会转移到更有挑战性、更有创造力、更有价值的工作中。
人力资源部门也因此获得收益,在现有的团队规模下保持业务增长。一方面避免了招聘新员工的成本;另一方面也可以减少由于人员流动、工作交接而产生的摩擦性成本,同时提高整个团队满意度,使得公司对人才更具吸引力。
另外,RPA还可以起到一定的培训作用,在新员工对业务操作不清晰的情况下,可以通过观看机器人的操作过程来学习和了解业务。
正常情况下,端到端地拉通企业流程中相关的资源、组织、岗位、决策、规则等内容,然后利用IT手段对流程加以固化。
而RPA有机会让IT固化的层级做到更细,即“操作步骤”级,不但是固化,而且可以让机器人保留每个操作细节的数据,这对于人类员工是难以做到的。
这么精细的流程监控可以让管理者分析机器人的每个操作步骤,快速识别流程中存在的瓶颈,更清晰地了解运营情况,为企业中的流程持续优化提供机会。而且这种细粒度的记录还可以用于审计和报告,满足合规性管理的要求。
RPA不只是作为一种技术工具被动地支持细节流程的固化,同时也是一种推动流程标准化的理念和手段。例如在一些大型集团企业的共享中心经常出现这样一种现象,由于集团下属成员单位在某项业务处理上的细微差别,而无法做到流程上的完全标准化。那么,共享中心通常会设置不同工作组来对口办理不同成员单位的业务,后台的IT系统也就没有办法在后台逻辑处理上实现统一处理,只能将这种非标准化流程放手交给业务人员来灵活处理。这其实是通常说的“物理共享”,而非“逻辑共享”,即只是后台运营人员集中到一起办公,而没有真正达到共享中心业务集中办理的目标。这时,企业如果勉强采用RPA手段来实现自动化,由于业务的差异性,必然会导致RPA实施更复杂、工作量更大。
然而,我们可以换一种策略来推进该项工作,首先找一家业务相对规范和标准化程度较高的成员单位率先实现RPA,然后推广到其他成员单位。在推广过程中,集团需要让其他成员单位亲眼见到自动化所能带来的益处,并告知他们能做到自动化的前提是流程的标准化,如果你们和集团一起做到标准化,就可以直接利用已经实现的RPA机器人;如果做不到,你们只能回到传统的手工方式来办理业务。通常这种“现身说法”式的推广模式,好过那些采取行政命令的强制模式。
RPA其实是对原来的流程管理思想和管理体系的一种有效补充,借助于自动化可以更深地挖掘流程管理在企业运营的潜能,提升流程绩效水平,为流程管理者打开新的一扇窗。
关于传统企业的业务部门和科技部门的协作方式,一般是业务部门提出信息系统的建设需求,科技部门作为系统的承建方,负责系统的采购、建设、上线、运维等工作。
双方在协作过程中主要的矛盾点集中出现在两个地方,一个是需求阶段,另一个是维护阶段。
在需求阶段,科技部门认为业务部门提出的需求不够明确、不够细致,而且经常改变;而业务部门认为自己既不懂科技,又不懂系统建设,所以无法拿出更准确的需求。
在维护阶段,业务部门认为对于系统运行中出现的问题,科技部门修复不及时;对于新的补充需求,科技部门更是一拖再拖。而科技部门受制于系统架构和上线风险等问题,在投入资源有限的情况下,无法迅速做出反应。在这样的协作模式下,长此以往,双方经常相互抱怨,积累了很多怨气。
RPA的出现会带来局面上的改观。在业务部门一方,由于其需要深度参与到机器人流程的梳理过程中,而且可能会亲自参与自动化的维护工作,甚至是自己动手来修复程序的Bug,这样,业务人员会逐步了解计算机的工作机理,并且加深对科技部门的理解。这不但提升了整体的IT建设效率,而且提升了业务部门对自动化流程应用和维护的自身能动性。
当业务部门对RPA应用和维护的能力不断强化后,科技部门也将获得更少的自动化变更请求,可以减少系统维护的工作压力。
在科技部门一方,在RPA项目实施过程中,科技人员需要经常与业务人员并肩工作,讨论和分析每个环节的自动化处理方案,使技术人员深入地了解了业务过程,提升了业务水平。
由于RPA项目具有风险小、建设周期短、见效快的特征,科技部门能够迅速实现业务部门所提出的新增需求或变更需求,这也增加了科技部门在企业中的受信任度和满意度。返回搜狐,查看更多