猫奴二胖子总结当下RPA实施中遇到的困惑

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

https://zhuanlan.zhihu.com/p/36080728

写在前面：

最近在自我总结的时候，总是感觉可能从客户或咨询顾问的角度，对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技术的可行性有何关系，未来出现新的验证码种类，比如拖拽滑块，完成拼图等，我们是不是又要修改验证码程序了？技术顾问的人天也是不便宜的，让一个技术顾问写出一个成熟的验证码识别模块，人天的咨询费用加起来可以用上面的人工打码工具识别几百上千万个验证码了，是不是捡了西瓜，丢了芝麻呢？


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


梁一纲
你好啊~我觉得我的身份跟你非常像，我就是去年从四大开始爆发的时候进入RPA领域的。我现在主要也是做RPA方向的咨询，所以我觉得我们可以多交流交流。关于你上面提到的问题，下面是我的一些看法。

1.RPA技术本身

RPA当然不是万能的，目前主流的（就是我自己了解下来的）看法是，RPA是流程自动化的一个必然的产物，他是传统人工操作转换成未来的人工智能操作的基础。但是作为RPA顾问，肯定不能只关注技术，以我个人的经历来说，我是融合了系统开发、数据分析师、流程优化咨询的经历的，所以我在面对RPA的机会的时候，我更关注的是流程的优化，而RPA只是流程优化的其中一个解决方案而已，流程标准化才是RPA成功的前提。而RPA作为一个开发技术，其实和传统的软件开发相比，优势其实是流程梳理到实施落地非常快速。理论上传统IT开发没有解决不了的问题，就是时间和钱够不够罢了。那RPA的最大的优势是类似“可见即可得”，就是用户现在怎么做的，我也怎么做就行了，所以只要流程梳理好了，标准化了，RPA的开发需求文档也就有了，实际开发起来就很快了。但是老实说实际运行效率并不会比传统开发快，只是取舍不一样。而我认为未来的趋势会是软件开发和RPA是共存的，软件以后都不是给人用的，都是给RPA用的。

2.RPA咨询顾问的价值

我觉得你的看法很对，乙方的咨询顾问应该能够带来更多外部的最佳实践。但是RPA角色的定位我觉得不应该仅仅与ERP实施项目的角色对应。我觉得RPA顾问本质上是一个流程优化大师。我一直认为RPA的出现是和当年制造业自动化兴起是一样的。起码我在做RPA调研的时候，我脑子里想的不只是RPA，而是流程的优化，RPA只是一个手段，正好我比较了解，对于不适合RPA去解决的问题我们应该也能够提出合理的建议。所以RPA咨询顾问这个抬头里面，我觉得咨询顾问的工作要比RPA的要多。RPA的开发工具很多，也很友好，很方便，但是熟练使用他们的，是RPA开发工程师。对于流程梳理很在行，设计解决方案很厉害的，是流程优化咨询师，能够把流程梳理完，并且能够应用RPA作为解决方案的一部分的，才是RPA咨询师，或者我们其实更应该把自己叫做流程自动化咨询师，或者流程智能化咨询师。

3. POC的目的

POC是什么相信大家一查就知道。我觉得题主的问题更多的是对于目前商业环境的不理解。我本人也在非常非常初步探索的阶段，所以这里我也不多说，就简单的讲几点。

一是客户要找多家来做POC的目的有很多，可能是想贪小便宜，可能是要考察不同的供应商，可能是想从这些不同的供应商中间取长补短，不一而足，但是作为甲方这么做也无可厚非，毕竟现在大家都在探索阶段，还算是买家市场。等到那一天RPA做得非常大了，大家都认可了，POC就不用做了。虽然我不了解，但是我猜想当年ERP推广到风行也是有这么一个过程的吧。

二是POC阶段要做到什么样的程度，这一个点是供求双方的一个博弈。对于甲方来说，POC做到跟真的一样最好，反正不要钱，真做出来了我们买的话风险很低。对于乙方来说，POC越简单越好，哪怕是纸糊的，客户认可就行。在上面的例子里面，我也做过这一个业务的项目。我认为RPA的职责是调用OCR的能力，所以其实这里应该分成2个POC来做，1个是识别码的POC，一个是RPA能够调用别的OCR的POC。RPA的POC相信大家都很快可以做出来，OCR的就需要一些技术沉淀了。这个已经上升到了公司战略方向的问题了，譬如是自主研发，还是采用第三方技术。这个就看企业了。但是总的来说，我们要做的就是诚实地去做项目，能做就说能做，不能做就说不能做（这里能不能做不是说技术上，而是整体考虑投入产出的问题），沉下心来，付出总会有回报的。


slice
slice1 个月前

我觉得poc少写代码可以，实施基本都在写代码啊。

想让脚本稳定执行还是需要靠自己码代码。真要用的时候发现rpa软件欠缺的部分罄竹难书，呵呵。。。

我对poc是当成减少后续实施的风险来看待的。每个rpa软件有其自身的短板，识别对象出问题或者偏移啥的承接下来后没法交付才要哭死呢。

确实流程的梳理和重构才是王道。

软件给rpa用就有些夸张了。靠数据流和bpm执行任务并给出需要的结果或许也是可能的未来，UI本来就是提供给用户操作的。机器人要界面干啥？所以我们要开发AI干掉自己近期的饭碗，再给自己创造没有想象过的新工种走上新台阶。


joseph
joseph29 天前
经历几乎完全一样，SAP从业者涉足RPA领域。简单回答一下：1、技术问题 RPA的几大工具，能实现的功能都极其有限，更不要说什么万能。但是他们在系统对接和获取各种系统的返回值方面有独一无二的优势，因此被热捧。说穿了，他们可以替代人的简单重复的跨系统操作（同一系统的传统代码可以解决）。 2、顾问的意义 讲真，顾问是比原来难做了，但是SAP顾问把自己圈在传统思维里的也不在少数。SAP发展这么久，技术完备，资料充足，很适合你讲的分工方式。但是当进入RPA领域，或者说，对于客户来说是不是使用RPA、SAP都不重要。作为顾问，能够梳理客户的业务，却不能提供最合适的技术又有什么意义呢？顾问本身就是桥梁，完全不涉及技术的话只能闭门造车。当然，团队很重要，如何让技术牛听懂客户需求是顾问的职责。3、POC 我不是做国内的不懂国内怎么做。但就你说的例子，客户对某个个例，要求一种他们认可的验证途径是合理的。利用第三方平台本身就有安全问题需要事先和客户沟通好，更不用说大数据时代你的每分信息都是珍贵的，不能轻易交到别的平台手里。至于客户夹带私货要求实现功能之类的，我不了解国内客户的做法没法评价。

梁一纲
梁一纲回复slice25 天前

我觉得你说的很对的，不过其实什么软件欠缺的都是很多的，其实关键还是看能不能满足业务需求就可以了。POC就是可行性分析的一部分（对于客户和实施方都是），不过无法避免的是销售/售前为了能够拿下单子，其实也是没办法硬着要答应一些原本没有做过的东西的，至于接下来做不做得到，或者说效果是否客户一开始想要的、满不满意结果，这些其实看的还是销售/售前如何控制客户期望以及实施的时候项目管理的事情了，技术人员和前线人员都相互理解体量就好了。
slice
slice23 天前
唯一不变的就是变化嘛。poc验证的不就是自己觉得最有可能出问题的部分？其他的算是当初自认为次要的可控部分…
徐鹏程
徐鹏程23 天前

我也在做RPA项目，国外国内客户都做了几个。对于POC的问题，我觉得事先和客户确认好范围，后面效果确认的时候就没这么多话了，另外RPA咨询顾问的价值的问题，可能技术人员实现验证码方案对于单个项目费用很高，但是作为共通模块，可以展开到其他项目的话，费用就不显得高了。
陈键
陈键1 天前

对于甲方来说，希望用最小成本看到效果，这是非常常见的。曾经经历过最短POC，一天之内就要提供一个Demo。当然实际业务开发时间不可能这么短。