RPA(虚拟员工)在互联网公司的应用


背景知识

RPA

Robotic Process Automation
)是白领机器人,可以完成重复性工作,来提高人的效能。类似于按键精灵,不过更高级更智能。



转载自:滴滴内部技术社区 

作者:Mike
 



RPA
之前更多是用在银行
/
税务这些跨系统的劳动密集型白领工作上,比如开具发票,报税之类的。滴滴里面的
RPA Center
是互联网企业应用虚拟员工在业务里面的第一个尝试。

 


RPA(虚拟员工)在互联网公司的应用插图

 

传统观念会认为,互联网里面没有
RPA
的需求。大家想象中的互联网企业是怎样的呢?是打满鸡血,熬夜加班的程序员,或者是是整天开会讨论需求的产品经理。似乎这些创造性劳动,很难被
RPA
这种自动化工具替代。

 

互联网是否有
RPA
的需求

抱着这个问题,我去滴滴第一线做了大量调研。足迹遍布全国主要区域。和城市经理,区域职能,总部职能 
都做了很多访谈和沟通。


RPA(虚拟员工)在互联网公司的应用插图(1)

结果是非常有趣的,大部分总部中高层会觉得
 “
业务没有重复工作



产品研发团队都能支持



流程已经被梳理得不错了

 

但是如果从更一线的员工了解他们每天在做什么,我们会得到不一样的图景:有同学
 “
每天审批
6000
个权限

,有同学
 “
每天配置十几个运营活动,每个运营活动需要
20
分钟

,有同学
 “
凌晨
2:00
起床把数据变成
CSV
报表,导入人群标签系统

RPA(虚拟员工)在互联网公司的应用插图(2)

 

这样的看似完全不同的结果背后的原因是什么呢?核心在于,传统企业是信息金字塔结构,老板掌握所有信息。而互联网企业腰部的中层和底层有大量创新和信息,

让听得见炮声的人做决策

,高层维护一个目标和愿景,老板反而往往并不一定掌握所有细节和信息。

 

基于调研和访谈,我们意识到词汇的混乱会造成沟通的低效。于是首先在内部重新定义概念,把
 “
重复工作
” 

 “
流程
” 
这个概念里面分割出来。

 

RPA(虚拟员工)在互联网公司的应用插图(3)

 

 

RPA
中的
P
就是

Process

,机器人流程自动化。在沟通过程中,会有很多歧义。别人会觉得,流程是流程团队的事情,梳理流程这个不适用互联网公司,我们业务变得太快,流程是滞后的,是低效的。

 

而今天,我们重新定义了一个术语,叫

重复工作


  
重复工作是自下而上的过程,是真实存在真实发生的。而流程是相关部门制定的,存在文档和系统中的(甚至可能和现实不一致),是自上而下的过程。

 

在定义词汇的时候,想起了加西亚
·
马尔克斯的《百年孤独》的开头:



世界新生伊始,许多事物还没有名字,提到的时候尚需用手指指点点。

 

这也正是让我们激动和兴奋的地方。

 

RPA(虚拟员工)在互联网公司的应用插图(4)

 

滴滴内部是矩阵型组织架构,有法务财务人力这种职能线,也有网约车这种业务线。

 

我们在业务里面做
RPA
的初衷很简单,财务几百人的规模,业务几千人是财务的
20
倍。那么应该有
20
倍的重复工作,也理应拿到
20
倍的收益。

 

RPA(虚拟员工)在互联网公司的应用插图(5)

 

我们愿景很简单,


干掉低价值重复劳动


。人最宝贵的是时间,很多公司
996
,但是在每周的
72
个小时工作时间里面,有多少时间是在做创造性活动,而又多少是在重复工作。

我们希望通过工具,通过技术的赋能,把重复工作消灭掉。让人回归到更快乐的创造性工作的本质上。

 

工业革命把人变成了机器,而
RPA
把能人变回人(通过把机器变成人)

 

RPA(虚拟员工)在互联网公司的应用插图(6)

 

目前
RPA
解决的重复工作,每天为公司节省了
240
小时,合计
30

HC

7
月份开始做,投入
3
个人。算下来年化
20
倍的
ROI
,这个是极其惊人的数量。

 

RPA(虚拟员工)在互联网公司的应用插图(7)

 

目前我们典型项目交付周期是
2.5
周,为了进一步提高交付速度,规范一致性,避免重复造轮子。我们设计了一套可复用模块的规范,并抽象出多个可复用模块。

 

RPA(虚拟员工)在互联网公司的应用插图(8)

 

 

互联网的特点是,研发人员占比高,微软
28%

Google 35%
,阿里巴巴甚至到了
51%

 

但是,虽然有很多研发,可需求数量是更多的。研发资源相对稀缺。

 

我们调研到某个业务,年初排期堆积了
200
个,年中增加到堆积
300
个需求。这意味着,如果当下没有排上期,会永远也排不上。因为接下来业务变化,会有更多更战略性的,更高优先级的需求。

 

 

 

RPA
最大的优势,一个是快,一个是省。

 


是快速响应,我们从需求到上线的典型时间是
2.5
周,明年希望通过赋能

可复用模块 等各种方法,把响应时间再缩短一半,到
8
天左右。这样比起传统的产品经理需求,评审,排期,上线 
的按周或者月计的交付时间,有显著的差别。

 

 

RPA(虚拟员工)在互联网公司的应用插图(9)

 

 



是成本优势,一个几年工作经验的
Java
工程师要几万块,而我们现在用大学本科毕业生培训一个月就可以上岗,明年如果我们在三线城市设立异地的交付中心,成本还可以进一步降低。降到目前工程师
1/6
的成本,这样就有了显著的成本结构的差异。

 

这样的结果是,传统工程师非常厉害,前端后端都能做,有绝对优势。而
RPA
这块实施的范围要弱一些,不能写
App
也不能做不存在的功能,只有操作键盘和鼠标。但正是因为



,所有比较优势。

 

这件事情背后的本质是,更好用的工具让
技术民主化了。让编程这个事情好用到大家都可以使用。

 

这样的比较优势形成了补充的开发资源,反而帮助到传统的工程师,释放他们的时间专注在更困难的问题上。

 

RPA(虚拟员工)在互联网公司的应用插图(10)

 

 

RPA
传统的使用最广泛的领域是 
金融,央企,电力,电信。有几个共同的特征:
1) 
咨询公司销售驱动。
2) 
内部系统陈旧异构。
3) 
技术并非主营业务

 

而互联网公司,和这类型公司差异挺明显的。我们历史短负担小,异构的存量系统少,并且内部技术能力强,内部工具团队建系统。

 

那么需要找到更合适的适用于互联网公司的
RPA
模式

 

RPA(虚拟员工)在互联网公司的应用插图(11)

 

 

最后我们总结下,今天的
Key Learnings

3

: 1) 
互联网公司的 重复工作 
是真实存在的痛点。
2) 
高科技行业程序员有绝对优势,但是
RPA
有比较优势。
3) 
有成本结构的差异化,就有存在的机会。


——————————————————————————————

为开发者而生的滴滴云服务器低至9.9

滴滴云官网:

本文由 RPA Club 作者:Editor 发表,其版权均为 RPA Club 所有,文章内容系作者个人观点,不代表 RPA Club 对观点赞同或支持。如需转载,请注明文章来源。

发表评论