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