说说“人手一个机器人的事儿”

“人手一个RPA机器人”，这句话我是听UiPath说的，华丽且振奋人心。华丽是因为描绘出了未来的景象，振奋是因为可以推断这是个巨大规模的市场。

然而，当理想照进现实，我们究竟是“起舞弄清影”呢？还是“把酒问青天”？

先说理想：“别跟我谈理想，我的理想就是不上班。”恭喜你，明天可以不用来上班了。RPA机器人已经接手了你的工作。它能做报表，能分析，能操作计算机，还不偷偷搞办公室恋情，不说老板坏话，它不光不要福利，就连工资都不要。哦，对了，它还是个加班狂魔。你说气人不？！

未来，你的竞争者有可能不是办公室里面的政治对手，而是那台每天跟你面对面的计算机。对，没错，它成精了，自己会干活了！

开始说人话，“人手一个RPA机器人”，不是给每个人配一个RPA机器人，而是给每个人配一个RPA机器人设计器，人通过使用设计器来为自己设计自动化的流程，将手头上单纯重复的作业自动化，为自己争取出更多的时间来思考和创造。这是我对“人手一个RPA机器人”的理解。

再说现实：现实就是，当下还有很多需要“把酒问青天”的问题。例如：

1. 为什么不直接给我机器人，而是要给我机器人设计器？

2. 谁来教会我使用设计器？

3. 我用什么时间来学习和使用设计器？

4. 市面上那么多机器人设计器，我该怎么选择？

5. 我真的能行吗？花时间学了，学不会怎么办？

6. 学会了使用设计器，谁给我升职加薪？

7. 公司允许我在生产电脑上安装机器人吗？

8. 机器人把我活干了，我是不是就得调岗去干其他活了？

9. 机器人把活干完了，我也不能提前下班吧？

10. （诸如此类，乱七八糟的问题）

试问，有多少企业员工能熟练使用Excel函数、公式、宏？有多少员工可以将制表这项工作自动化，而不是通过复制粘贴来完成？

RPA开发是图形化界面，通过简单的拖拽操作，就可以轻而易举的做成一个业务流程图（注意最后一个“图”字很重要），它不是业务流程。什么区别呢？

编程思想，亦或者说编写程序的逻辑思维。

举个例子：我们做一个系统自动登录的流程吧。它的具体步骤是这样的：

1. 打开浏览器

2. 输入网址

3. 输入用户名和密码

4. 点击登录按钮

编程思想/思维会额外去思考如下一些重要问题，目的是保证机器人的健壮性、稳定性、可扩展性、安全性等等一些有关“性”的问题：

1. 打不开浏览器时，怎么办？

2. 无法访问网络或网站维护时，怎么办？

3. 用户名和密码被变更时，怎么办？

4. 登录超时，怎么办？

5. 更换用户登录，怎么办？

6. 重试三次系统自动将账户冻结时，怎么办？

7. 保存了用户名和密码的机器人被其他人启动，误操作时，怎么办？

8. 浏览器版本更新，机器人无法正常运行时，怎么办？

9. 系统升级，需要输入验证码信息时，怎么办？

10. （诸如此类，怎么办的问题）

这就是程序设计开发人员与业务人员思维上的不同。这些“怎么办”的问题，程序设计开发人员就会尽可能周全地考虑到并教会给机器人，正所谓“术业有专攻”。

总结：“人手一个RPA机器人”这件事儿，不是不可实现，也不是遥不可及的梦想。路，要一步一步走；饭，要一口一口吃。眼下，为了解决企业信息孤岛和业务流程老化的问题（历史发展必然会出现的问题），RPA机器人还是越早上越好。

通过RPA机器人的引入，必然会影响一部分业务人员积极参与到机器人设计开发中来，进而优化企业业务流程、完善机器人设计开发体制。RPA机器人运行是全流程可见的（跟放电影似的），企业也可以通过这种方式培训新员工，这也是节省成本的一种切实有效的方法。


 

继续阅读：流程自动化   RPA

未经允许不得转载：RPA中国 | RPA全球生态 | 数字化劳动力 | RPA新闻 | 推动中国RPA生态发展 | 流 > 说说“人手一个机器人的事儿”