RPA淺談

目錄

1、什麼是RPA

2、RPA能做啥

3、RPA組成

4、一些心得體會

什麼是RPA

        Robtic Process Automation(簡稱RPA),即機器人流程自動化。狹義來看,它就是通過一些自動化手段來實現流程自動化的這類技術或產品的總稱;廣義來看,可以認爲是通過計算機模擬人工操作,解決生產問題的一套自動化解決方案。本文主要從狹義上來簡單談談RPA。

       從名稱上看,Robotic(機器人,就是模擬人),Process(流程,就是要模擬的事),Automation(自動化,就是無人或儘量無人蔘與)。如果只是實現這樣功能的技術,也不是什麼新鮮事情。比如Window 提供的UI Automation、基於WebDriver協議的Selenium、基於DevTools協議的Puppeteer等其實都能實現這一效果,只是以上技術更多的在自動化測試領域大放異彩。而RPA的不同在哪呢?個人認爲是將機器模擬人這種行爲打造成一項能夠向各行各業賦能的服務並最終提升企業人效,正如目前各大RPA廠商打出的口號“數字員工”。

RPA能做啥

      如果諮詢RPA銷售商或查看各大廠商的RPA白皮書,得到的答案可能是:RPA能夠替代員工、降本增效、與AI技術完美融合從而推進企業數智化進程等等。結合將近一年的RPA實戰經驗,就目前來看,個人認爲RPA能完成的事項包括:

     1、重複性的、有既定規則的工作,並且要求目標對象相對穩定。如銀行對賬、財稅業務、證券業務、物流服務、網上購物等

     2、跨平臺數據拉取與整合分析。如,企業內部各平臺之前的數據記錄在不同的數據庫中,直接聯庫查詢有時並不符合實際,這種情況下RPA的優勢就體現出來了,它可以分別登陸到各個平臺獲取數據並結合Redis或excel等做中間數據的緩存落地並最終輸出滿足要求的結果。跨企業之間拉取數據也同樣可行,這裏不展開...

     3、替代接口完成後端相關業務。如公司業務與第三方交互的情況下,通常的操作都是雙方面對接口對接,只要遵守同樣的接口協議。但有些情況下第三方無法提供接口或費用超出預期,亦或是第三方不可控,這時候就可以考慮用RPA來代替接口(當然第三方需要有Web界面供人工操作)。這種情況下,效率會是一個核心問題,但是結合業務特性從策略的角度上可以做優化。

     4、與AI技術結合,解決一些簡單的識別場景。如,驗證碼識別、圖表內容識別(如發票)、語音識別(語音指令)等。一般作爲整個流程中的某個環節。

總的來說,目前整個市場對RPA概念有炒作的嫌疑。但從長遠來看,RPA+AI的概念如果順利落地並更加接地氣,使得中小企業也能從中受惠(AI一般情況下小企業玩不起),RPA還是大有所爲的。

RPA組成

RPA的組成

設計器:流程設計平臺,目前主流的RPA產品均有自己的RPA Studio,只是各有各的優勢,主要基於C#和Python語言。

控制中心:流程調度和機器人管理平臺,包括流程上傳、派發、刪除等管理;機器人調度、分組、定時任務等操作;日誌管理、過程回放、平臺升級等輔助功能。

機器人:執行流程,目前主流RPA都是Window計算機或移動設備。多數情況下,單臺機器人也能滿足使用,也就沒必要購買控制中心(這玩意不便宜)。如果用RPA來代替接口完成後臺服務,那麼多臺機器人的統一管理時必要的,控制中心就是不可或缺的。

(對於RPA技術原理的部分將單獨寫一篇文章分析)

一些心得體會

1、整套RPA環境的購買成本其實並不低,RPA機器人(Licence+雲端服務器租賃)+設計器+控制中心基本都需要收費,而且還是按時間收費並非一次購買終身使用。

2、整套RPA環境的部署和維護成本也不便宜,並非宣傳中所說的7x24小時不間斷工作,替代員工。機器人故障+程序異常都需要人工參與修復並且需要額外的RPA監控運營來及早發現問題並人工介入。所以近期RPA Plus上也有人提出RPA+人工的人機結合模式,這個一方面是解決異常問題,另一方面是讓人工參與決策,以便業務流程符合實際。

3、機器人運行的目標對象(通常爲Web網頁)的穩定性(包括界面和功能),直接影響RPA的使用效果。一個經常調整的網站,如果讓RPA去上面做事情,那就是一種折磨,不是在修復BUG上就是在修復BUG的路上。所以說RPA適合做重複性的有既定規則的工作,並且要求被操作的對象相對穩定。

4、RPA的優勢在於模擬人工、跨平臺優勢,對於被操作對象來說是無侵入式的,所以也很少被識別爲機器人(這個做爬蟲的人是懂的)。它的缺點也是模擬人工,一方面單臺機器人執行效率比較低,按步驟一步步操作;另一方面,既然模擬人工那就得像人一樣去識別驗證碼滿足登錄驗證。說起驗證碼,那就是千奇百怪,一般驗證碼識別功能RPA廠商自身是不提供的或者是另外收費的,亦或者只能滿足簡單的識別。如果哪一天目標網站做了調整,就直接嗝屁了。

5、 不建議把RPA作爲滿足業務的單一技術,它優劣鮮明,就決定了技術組合纔是王道。比如Selenium+RPA 、RPA +AI(當然是公司自研或是額外購買的AI服務)、RPA+BHO等等。

6、RPA流程的開發講究模塊複用,特別是同一類型的業務流程,如何將開發人員所關注的業務強相關模塊剝離出來,通用模塊統一管理,是批量開發RPA流程的關鍵。

7、RPA流程的統一管理和RPA機器人的合理分組是提升資源使用率的重要手段。這裏面故事太多,一言難盡!

8、沒有監控運營的RPA就是在自掘墳墓,如何將不可控的外界環境變爲可控是一個可持續發展必須思考的問題。

9、非開發人員也可以自行設計RPA流程來滿足業務需求,這是一句謊言!

以上是個人的愚見,希望給在尋求RPA解決方中的我們提供一些借鑑的東西!

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章