1012-RPA与目标使用者

这篇文章讨论RPA、目标使用者、IT技能之间相关的话题。

所谓“目标使用者”，意思是开发RPA功能的是技术人员（IT人员） or 业务用户（非IT人员）。

一、源起

基于以下事项，作此文。

源起1

最近有几个RPA项目在并行中，不断斟酌着项目质量和项目进度之间的微妙平衡。

到项目中后期，IT技能的合理应用变得越来越重要。

源起2

有客户业务部门的同事在经过简单培训后，也开始动手实现部分RPA功能。

但是，与他在遇到问题时的交流，能够明显感觉到：没有IT的基础，对于他快速有效地解决实际问题会造成很多的困扰。

源起3

有网友在知乎私信我。

问：财务转RPA是不是有前途？答：可以有。

问：不编程是不是可以走得远？答：走不远。

源起4

目前市场上有很多RPA产品，我个人认为RPA产品们希望讨好的受众（目标使用者）其实并不一样。

二、观点

想表达的很多，贪多嚼不烂，Less is more。

观点1：关于RPA产品目标使用者的定位

目前在个人了解的RPA产品中：

UiPath是希望优先讨好业务用户（非IT人员）；

其他产品则更倾向于迎合技术人员（IT人员）。

观点2：从公司层面，看待RPA，是一个IT项目

从公司层面，RPA项目是一个IT项目。

对于IT技能是有起码的要求（而且还不算低），强大的IT技能对于提升RPA项目质量大有裨益。

RPA项目与其他IT项目没有本质的差别。

观点3：从个人层面，看待RPA，是一个桌面工具

从个人层面，RPA可以作为一个工具，并且可以有效地帮助到业务人员。

从我们的项目实践来看，借助UiPath（优先讨好业务用户的软件），即便没有IT背景的同事（仅有财务背景），也是可以在经过简要培训后，独立开发出能够满足其多数的相对不那么复杂的RPA功能的。

三、阐述

针对以上三个观点，各作一个延伸的阐述。

阐述1：站在RPA产品方的角度，希望讨好谁？希望谁帮我推广产品？

首先，业务人员（非IT人员）和技术人员（IT人员）对于同一类产品的喜好评价角度不仅是不一样，而且差异很大！（例如：部分程序员甚至并不认为RPA开发活动属于编程序）

其次，RPA产品公司会考虑选择哪些咨询和实施的合作伙伴？（业务人员偏多 还是 技术人员偏多）（偏咨询 还是 偏技术）

最后，RPA产品公司希望首先突破业务部门还是IT部门？（希望业务部门的人口口相传 还是 希望IT部门的同事大力推荐）

小彩蛋：假如业务部门人手一个RPA License，将会是多大的一个市场？

阐述2：站在公司IT部门的角度，对RPA的态度如何？

在拙作《1003-RPA的优势》中提出目前IT部门普遍面对以下两个矛盾：

矛盾1：企业日益增长的对IT系统的需求与IT系统有限的资源投入之间的矛盾。

矛盾2：企业对业务变更迅速响应的需求与IT系统建设需遵循固有周期之间的矛盾。

如果有一项技术/工具，

既能快速满足业务部门需求（解决矛盾2），

并且投入成本不高（ROI明显，解决矛盾1），

那么IT部门应该选择什么样的态度？

个人建议：主导之！

阐述3：站在最终用户个人的角度，RPA来了，我该怎么办？

-问：作为一名财务人员，RPA来了，我该怎么办？

-答：还能怎么办？盘它！

RPA算是一个新技术，是一个工具，是一项很有用的武器。

积极拥抱新技术，新工具，新武器，可以让财务人员（包括但不限于财务人员）从繁琐重复，低附加值的工作中解脱出来，神清气爽地做您觉得有价值、有意义的事儿。

换个角度，如果非要说有淘汰，那么也一定不是一个技术/工具/武器淘汰某个岗位或某个人，而是被武装了这些技术/工具/武器的其他岗位或个人淘汰了。

（正文结束）

---

附1. 全部文章

点击以下链接↓↓↓，查看全部原创RPA文章列表：

https://zackmiya.com/

附2. 关于微信公众号

微信公众号ID：RPA2018

微信公众号名称：RPA流程自动化机器人

感谢您的关注和阅读，希望这篇文章能为您带来帮助。

欢迎转载与分享，也请注明出处。

如果您有需要了解的关于RPA的其他内容，也可以给我留言或发邮件

（[email protected]）。

识别以下二维码，可以关注本公众号。

附3. 关于本文作者

本文作者：任子旭 Zack Ren

微信号：plmok2018

识别以下二维码，可以与作者进行更为深入的交流。