有关RPA咨询顾问的价值

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

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

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

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

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