?

在事務所工作的時候，因為是合伙人制的緣故，每個合伙人底下都會有各自不同的顧問服務，每個顧問服務底下又可以再劃分成不同的解決方案，例如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顧問這個領域的朋友，能夠提早準備，以面對未來的挑戰。