職涯分享|擔任RPA顧問是一種怎麼樣的體驗?
分享RPA顧問的工作內容與需要具備的技能與能力
在上一篇《職涯分享|擔任Salesforce CRM顧問是一種怎麼樣的體驗?》有與大家分享我的Salesforce顧問生活以及工作上會遇到的挑戰。
在事務所工作的時候,因為是合夥人制的緣故,所以每個合夥人底下都會有各自的不同的顧問服務,每個顧問服務底下有可以在劃分成不同的解決方案,例如Salesforce就是屬於Digital顧問服務底下的解決方案,當時加入公司前就有先把自己訂定幾個目標,其中一項就是參加跨領域的專案,而剛好在2020年時,別組的RPA解決方案人手不夠,我就從Salesforce團隊中被徵調,加入了他們的團隊,展開了為180幾天的RPA顧問生活。
有了這麼一段經驗,想藉此與大家分享一下擔任RPA(Robotic Process Automation, 機器人流程自動化)顧問是一種怎麼樣的體驗,並從中比較Salesforce顧問與RPA顧問的差別,就讓我們開始吧!
一、職務內容
由於都是在事務所工作,只是轉換了工作內容,因此不在這邊贅述關於工作環境與工時這部分,有興趣的朋友可以參考上一篇文章。
在擔任RPA顧問時,我主要是使用Automation Anywhere這套軟體來協助客戶撰寫RPA腳本與設計機器人自動化流程,以下將分成六個項目來說明:
- RPA POC:再導入RPA之前,我們會先去客戶端初步瞭解需求,例如請客戶說明一下帳戶維護、徵審維護等作業流程,當對於客戶想要導入RPA的流程有概念後,就會去分析在這個流程中哪一段適合導入RPA,哪一段需維持或調整現行的作業方式,專案初期我們會有很多時間在做RPA POC,也就是概念性驗證,來確認我們的Automation Anywhere這套軟體的解決方案是否能夠符合客戶的需求並滿足期待。
- 客戶需求訪談:當我們確認Automation Anywhere這套軟體的解決方案能夠滿足客戶需求後,待客戶簽署專案合約後,就會進入導入階段,在導入階段的初期我們會再做一次需求訪談,雖然在RPA POC階段有掌握初步的客戶需求,但客戶需求訪談能夠幫助我們更深入了解流程細節,例如資料欄位的設計,登打資料的方式等,並與客戶再次確認需求內容。
- 解決方案設計:當客戶需求收集完成後就會與專案經理討論解決方案,在設計解決方案的第一步時,會先用流程梳理整個客戶的需求,並在流程圖上標記出RPA撰寫方式與指令,確認沒問題後就會與客戶說明未導入前的作業模式,以及導入RPA後的作業模式,讓客戶知道未來該如何與RPA共同協作。
- RPA腳本開發與系統整合測試:當與客戶確認解決方案後,就會開始使用Automation Anywhere進行RPA腳本的撰寫,由於他是套裝軟體,裡面會有他寫好的指令套件,我們會需要將這些指令套件向組樂高一樣,把他們組合起來,相較於用coding的方式來撰寫RPA腳本的彈性沒有這麼大。
- 使用者驗收與上線規劃:當開發與整合測試到一定的專案進度後,我們就會開始請使用者來驗收RPA的腳本,也就是模擬日後當RPA上線後,使用者會如何與之進行互動,在使用者驗收的過程中,也會盤點與確認哪些RPA腳本已經可以做部署,哪些還需要再做修正或調整,算是上線前的準備作業階段
- 客戶支援與教育訓練:當RPA腳本都部署到70%後,會有一半的時間開始投入教育訓練的準備作業,另外一半時間會持續修復RPA腳本的問題,以確保他的穩定度可以符合一定的標準。
二、我的RPA顧問經驗
跟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一般可以做很大幅度的客製化。
但也因為有了這段的經歷(滿痛苦的XD),也幫助我未來在學習像JavaScript、Node.js程式語言時沒有這麼害怕,也確實幫助我於支援期結束後回到Salesforce執行一些小型的開發項目時,效率上有比之前提升不少,因此這段經驗雖然過程不是令人這麼的愉快,但確實是一段令人滿懷念且寶貴的經驗。
四、結語
由於不同產業中擔任RPA顧問所具備的能力與工作任務可能也會不一樣,因此僅能根據我的自身經驗作分享,不代表所有產業的RPA顧問都是如此。希望此次的分享有幫助大家更了解RPA顧問的角色與任務,以及我自己在擔任RPA顧問時一些體悟,讓未來如果有志投入RPA顧問這個領域的朋友,能夠提早準備,以面對未來的挑戰。