在事务所工作的时候，因为是合伙人制的缘故，每个合伙人底下都会有各自不同的顾问服务，每个顾问服务底下又可以再划分成不同的解决方案，例如Salesforce就是属于Digital顾问服务底下的解决方案。

加入公司前就有先为自己订定几个目标，其中一项是参加跨领域项目，而刚好在2020年时，别组的RPA解决方案人手不够，我就从Salesforce团队中被征调，展开了为期180几天的RPA顾问生活。有了这么一段经验，想借此与大家分享一下担任RPA（Robotic Process Automation，机器人流程自动化）顾问是一种怎么样的体验，并从中比较Salesforce顾问与RPA顾问的差别，就让我们开始吧！

一、RPA顾问职务内容

由于都是在事务所工作，只是转换了工作内容，因此不在这边赘述关于工作环境与工时这部分，有兴趣的朋友可以参考之前的职场文章。在担任RPA顾问时，我主要是使用Automation Anywhere这套软件来协助客户撰写RPA网站漏洞与设计机器人自动化流程，以下将分成6个项目来说明：

1. RPA POC

导入RPA之前，我们会先去客户端初步了解需求，例如请客户说明帐户维护、征审维护等作业流程，当对于客户想要导入RPA的流程有概念后，就会去分析流程中哪一段适合导入RPA，哪一段需维持或调整现行的作业方式。项目初期会有很多时间在做RPA POC，也就是概念性验证，来确认Automation Anywhere这套软件的解决方案是否能够符合客户的需求并满足期待。

2.客户需求访谈

当我们确认Automation Anywhere这套软件的解决方案能够满足客户需求后，待客户签署项目合约后，就会进入导入阶段。

导入阶段的初期会再做一次需求访谈，虽然在RPA POC阶段有掌握初步的客户需求，但客户需求访谈能够帮助我们更深入了解流程细节，例如数据字段设计，登打数据的方式等，并与客户再次确认需求内容。

3.解决方案设计

当客户需求收集完成后就会与项目经理讨论解决方案，设计解决方案的第一步，会先用流程梳理客户需求，并在流程图上标记出RPA撰写方式与指令，确认没问题后就会与客户说明未导入前的作业模式，以及导入RPA后的作业模式，让客户知道未来该如何与RPA共同协作。

4. RPA脚本开发与系统整合测试

当与客户确认解决方案后，就会开始使用Automation Anywhere进行RPA脚本的撰写，由于套装软体会有写好的指令套件，我们需要将这些指令套件像组乐高一样组合起来，相较于用coding的方式来撰写RPA脚本的弹性没有这么大。

5.使用者验收与上线规划

当开发与整合测试到一定的项目进度后，就会开始请使用者来验收RPA脚本，也就是模拟日后当RPA上线后，使用者会如何与之进行互动。在使用者验收的过程中，也会盘点与确认哪些RPA脚本已经可以做部署，哪些还需要再做修正或调整，算是上线前的准备作业阶段。

6.客户支持与教育训练

当RPA脚本部署到70%，会有一半的时间开始投入教育训练的准备作业，另一半时间持续修复RPA脚本的问题，以确保稳定度可以符合一定标准。

二、RPA顾问经验分享：跟Salesforce顾问最大差异是？

跟Salesforce顾问有点相似，成为RPA顾问后必须要非常了解手中这套解决方案的各项指令，我们主要是使用Automation Anywhere这套RPA解决方案，因此首要目标就是要先弄明白这套工具。如果是从外部面试进来到事务所，成为RPA顾问的话，大概前1–2个月的时间都会花在熟悉Automation Anywhere这套RPA软件，之后就会开始慢慢地参与项目，并从撰写RPA脚本开始，再扩展到其他工作项目。

但由于当初团队人手不够，且客户项目在即，比较没有太多时间让我慢慢学习，因此很多时候是用作中学的方式，先掌握Automation Anywhere的基本指令后，在解决方案设计与开发RPA脚本的过程中，不断用Try and Error的方式来进行。（那时候团队已经做完RPA POC，我是从需求访谈开始参与项目）

在使用Automation Anywhere撰写脚本的过程中其实很类似coding，必须先拆解客户的流程，然后再用指令的方式去拼凑。与担任Salesforce顾问最大不同在于，Salesforce是用他开发好的功能去组合客户的CRM流程，而RPA顾问则是用指令去组合成一个目标功能，举例，若我要帮客户使用Salesforce来设计一组购物车未完成结账的提醒流程，我会使用短信发送功能、email发送功能、自动化排程功能等，把这些功能组合起来，实作购物车未完成结账的提醒，但我今天是使用Automation Anywhere来设计报表查询时，我就必须要用组合指令的方式来实作这个目标功能。

刚开始在接触Automation Anywhere时不太能调节，虽然coding的成分没有很高，还是会需要一点程序设计的概念，才能用指令去组合目标功能。因此我花了一些时间去看了程序设计的书和课程，去理解程序设计方面的知识点，但由于Automation Anywhere又不是真的在coding，对于非技术背景的人来说算是相对容易上手的工具，这也符合当初Automation Anywhere这套RPA解决方案的目的，希望让业务单位也能够开发一些简单的功能应用，舒缓IT的开发能量。

三、RPA顾问经验带给我的帮助

虽然我去别的团队支持的时间不到一年，但在参与项目的过程中却让我好像度过了很久的时间，并能用不一样的视角来检视我过去两年在担任Salesforce顾问所学习到的技能：当遇到跨领域时，哪些技能可以熟练地运用？哪些技能需要再加强？算是一个自我考核的过程。

此外担任RPA顾问也算是给我这个程序设计小白一个震撼弹，由于是要自己用指令写出功能，不是像组合功能这么直觉，因此在开发每一个RPA脚本时，就会去参照一些程序设计的规范，例如变数的命名、注释，逻辑判断或循环等，把一个个指令组合成一个功能，并花了许多的时间在除错与寻找替代的方案，毕竟Automation Anywhere是套装软体，不能像coding可以做很大幅度的客制化。

不过，也正是因为这一次的经历，让我对 JavaScript和 Node. js编程语言有了更多的了解，也让我在完成任务之后，能够更好地完成 Salesforce的小项目，这让我的工作效率得到了极大的提高。

由于不同产业中担任RPA顾问所具备的能力与工作任务可能也会不一样，因此仅能根据我的自身经验作分享，不代表所有产业的RPA顾问都是如此。希望此次的分享有帮助大家更了解RPA顾问的角色与任务，以及我自己在担任RPA顾问时一些体悟，让未来如果有志投入RPA顾问这个领域的朋友，能够提早准备，以面对未来的挑战。