这篇文章讨论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的其他内容，也可以给我留言或发邮件
（rrenzixu@126.com）。
识别以下二维码，可以关注本公众号。
附3. 关于本文作者
本文作者：任子旭 Zack Ren
微信号：plmok2018
识别以下二维码，可以与作者进行更为深入的交流。
