有关RPA项目方面的一些问题

写在前面：

最近在自我总结的时候，总是感觉可能从客户或咨询顾问的角度，对RPA的理解以及自身角色和价值方面有一些误区。不知道这篇文章能被谁看到，但愿能得到业内同僚或是前辈的指点吧。

RPA这个概念国外早已产生多年，但差不多直到去年初国内才由四大开始热炒起来，到现在不论行业或是企业规模，大家都开始如火如荼的实施相关项目，或者准备开始以及研究相关技术。我身在乙方，去年有幸加入RPA项目实施大军，今年更是有机会参与了一些项目初期沟通、招投标甚至是POC的过程当中。以下是我思考而不得的一些问题：

1、 有关RPA技术本身

"RPA技术是万能的"这个误区早已有所耳闻。RPA技术到底是什么这里就不说了，随手百度或者看新闻比比皆是。我不知道这个观点是由谁发起的，或是由谁宣传的，但显而易见没有任何一种"单一"的技术是万能的，之所以流程自动化现在在市面上如此玄乎，并不是因为RPA技术本身有多么的发达与成熟，而是因为第三次工业革命之后至今，互联网时代加强了各行各业的信息互联，也就造就了各种各样解决单一独立需求的工具的诞生和飞速发展。

"进项税发票处理机器人"包含了纸质增值税发票的扫描与识别、发票信息的归纳整理、发票查验以及ERP系统的数据录入这几个常见步骤，甚至还包括了最终机器人运行结果的报送。该机器人本身的脉络是RPA，这是没错，但是这里面除了RPA，没有OCR、非结构化数据处理、"人工智能"的验证码识别平台、各式各样的国税局发票信息API这些单独技术模块的任何一个，该机器人的功能就是不完善的，用客户的语言来表述就是"不能满足我们的需求"，若一个业务流程做了自动化之后，还是有很多步骤需要人机交互，还是有很多错误需要人工复核，那么是不是自动化的意义就很小了呢？人家的需求明明就是输入一批纸质发票，输出ERP系统内的会计凭证以及发票真伪的统计数据，为什么使用了RPA，还是需要人工去敲验证码？为什么发票时不时地会经常验不出内容？虽然我们可以解释说这是因为国税局的验证码设计就是为了防机器人批量查询，OCR技术的发展现今就是有一定的局限性，这些锅可不能由RPA来背，可是归根结底，和客户接触的人都是RPA项目的实施顾问，不该背的锅也得自己来背了。这种情况，真的是进退两难啊。

2、 有关RPA咨询顾问的价值

之前在做SAP ERP财务模块实施顾问的那两年多里，每个项目组里面的方案顾问、业务顾问、技术顾问各司其职，大家分工明确，我也从那时起建立了自己IT咨询项目的基础知识体系架构。传统ERP实施项目的架构发展这么多年稳定至今是有它一定的道理的，之所以咨询顾问要拆分为方案顾问、业务顾问和技术顾问，是因为三者职责、能力和经验是完全不同的，方案顾问行业经验丰富，更擅长从全局角度指定企业蓝图，更加了解市场发展趋势和同类客户的需求痛点，业务顾问更了解详细的业务流程和业务需求，也更加了解ERP系统内的模块功能点和系统配置，而技术顾问更了解ERP系统底层架构、编码工具和系统维护，三者各司其职方能保证项目正常运转，客户与顾问关系健康发展。

但后来在参与RPA项目实施的过程当中，这个概念却被弱化了，很多时候都是要擅长编程的人去与客户沟通业务流程，要更了解业务需求而不擅长编程的人去挠头苦写代码。有些人要说，UiPath、Blue Prism或者Automation Anywhere这些主流RPA平台不需要写代码啊，而且不是说只要在前台用这些软件把实际业务流程操作下来录一遍，简单改改就可以作为一个流程自动化机器人来用了吗？另外，这些平台都是有现成的activity可以拖拽拼装实现自动化的，不应该那么困难和复杂吧？

这些话，咨询顾问们听了简直要背过气去。现在RPA平台兴起，各个平台均鼓吹自己的上手有多么简单容易，编码量多低，殊不知"录一遍就出来"的业务流程是极其单一，毫无逻辑分支和异常处理机制在的，绝大多数情况下这个录制功能只是为了方便技术人员编写过程中少走些弯路，甚至是为了在不知道应该用哪一个开发的activity的时候录一遍来看看系统默认使用的是什么，为自己提供思路。那么在此基础上，是不是说RPA平台的开发代码量很低，就应该让技术背景薄弱的业务顾问去自行编制机器人了呢，或者让技术顾问去了解业务需求呢？这样不是就可以一个顾问完成一整件事了吗？我认为完全不应该，甚至通过这么多项目实施过程感觉这样会有很大的问题。首先业务顾问的长处是与客户沟通多年的经验和知识储备，在RPA项目中更擅长业务流程梳理、流程设计和测试，因为他们更了解客户需求，更明白预期效果，但他们没有编码基础，不知道这些主流RPA平台用的.Net是什么，VBA怎么写，怎样写JSON文件来实现巨复杂的后台实现功能，让他们来做RPA流程，基本上都只是前台的操作的简单实现，后台的复杂逻辑处理甚至是工具整合完全两眼一抹黑。在这样的基础上，长期以往业务顾问在做RPA项目时会畏首畏尾，并且做出来的机器人也根本达不到效率最优化的目的。而让纯技术背景的人去写机器人，虽然没有这些方面的顾虑，但是由于技术顾问缺乏业务知识和实战经验，很多时候客户习以为常的业务常识没有提到，技术顾问在设计流程时可能就不会想到，而且更多时候是客户解释实际业务怎样做，技术顾问就怎样做，完全不做业务逻辑的优化、流程的改造，这都是因为缺乏业务知识和相关经验造成的现象。

所以，是不是不同背景的顾问本应该做不同的事情，大家相互配合才能够达到效率和结果的最优呢？

从另一个角度来看，RPA咨询项目和顾问的价值难道就在使用现成的工具，使用熟练地编码技术去把手工的业务流程变成机器人吗？难道不应该是在了解业务流程后去深究根本需求，以解决需求为目的优化流程甚至改造流程，再去进行自动化吗？乙方咨询的核心不应该是各行业海量咨询项目的知识积累、各种客户业务痛点需求和相关解决技术工具的了解，能够为客户提供最适合的解决方案吗？

如果咨询顾问和咨询项目如此简单，只要会写代码编流程就可以了，那么只要会.net的人客户自己招两个去学学平台知识自己开发不就行了？何必招咨询顾问来写代码，而这帮咨询顾问除了写代码以外，客户说怎样就怎样写，还比自己员工贵上许多，何苦呢？

3、 有关POC的目的

最近参与了一个客户的POC，客户几乎拿出了自己的所有业务需求来让一大堆的厂商挨个做一遍，最终汇报的时候，我们在讲到增值税发票查验这个流程时，客户质问了我们两个点，一个是最初统一讲解业务需求的时候，我们这边表示国税局验证码自动录入的功能可以实现，可是我们为什么最终没有选择这种方法完成这个POC流程，为什么使用的是第三方API来自动获取发票信息。

这里面，以我的看法，我觉得可能现在大家对POC、对RPA项目的流程实现上，都有一些误区。POC顾名思义，Proof of concept，目的是验证RPA这个技术，甚至是我们使用的RPA平台，能不能满足实际业务的需要。如果以此为目的，是否真的有必要在POC阶段拿出所有十几个业务流程需求让所有厂商用不同的工具挨个做一遍，而且还限制在一周多一点的时间内呢？难道不应该是同类型的核心痛点业务需求拿出来就可以推演到整体业务需求的实现可行性吗？POC现在在国内，似乎变成了免费实施某些核心业务流程自动化，或者是不同乙方咨询公司打擂台比谁做得好做的快了，我倒觉得与其这样，还不如不叫POC了，旧瓶装新酒，没什么意义吧。

另外，在上面客户质问我们的问题中，我们是这样解释的，首先我们的理解，客户的需求核心是校验这张发票的真伪，而不是"扫描发票-登录某网站-录入验证码-回传信息整理-比较-输出结果"这一个很详细很详细的流程。能够达到检验发票真伪这个目的的途径有很多种，这些方法中，最快的方法就是使用成熟可靠的API来直接获取发票数据，免去了前台系统网站登录、录入验证码和回传信息整理这三大步骤的时间，从业务效率上来说是最优化的，最终也是能够完全达到需求的目的的，为何要纠结于一定要录入验证码这件事情呢？如果客户完全不信任任何第三方API，那么也好，我们可以去市面上买验证码的API，现在市场上有很多"打码赚钱"的网站，这些网站一个验证码只要不到一分钱，只需要不到两秒的时间网上就有人手工去帮你识别录入，回传结果了，不论你的验证码是图片、文字还是有颜色要求或者其他干扰，人眼总归是能识别出来的，能够保证最终结果的准确性。我们也可以推荐使用这种工具，一万张发票的查验也就不到100块钱，成本极低。如果POC阶段非要我们开发验证码识别的代码，我们需要专业的技术顾问去分类筛选验证码的种类和可能性，针对每种不同可能性去设计不同的识别算法，最终还要完成编码、封装、测试、整合进RPA这几个步骤，试问短短一周多的时间何以实现。而且就算我们加班加点赶出来了，这又与验证RPA技术的可行性有何关系，未来出现新的验证码种类，比如拖拽滑块，完成拼图等，我们是不是又要修改验证码程序了？技术顾问的人天也是不便宜的，让一个技术顾问写出一个成熟的验证码识别模块，人天的咨询费用加起来可以用上面的人工打码工具识别几百上千万个验证码了，是不是捡了西瓜，丢了芝麻呢？

不知道以上这些问题，是我自己的问题，还是市场上的共性问题呢？

来源：知乎 www.zhihu.com
作者：知乎用户（登录查看详情）

【知乎日报】千万用户的选择，做朋友圈里的新鲜事分享大牛。 点击下载