RPA的流程怎么來評估承接吧？

為什么要評估？

雖然RPA學習門檻低，簡單到圖形界面就可以開發。雖然RPA開發效率，拖拖拽拽就可以完成流程開發。但開發畢竟是要投入時間和精力的，除非是學習和練習為目的，否則都要評估這個流程開發的價值。

舉個不恰當的例子，為了吃魚這個目標，先包下個池塘，再慢慢養魚，最后將魚撈上來再烹飪。且不說整個過程實現的時間周期過長，投入的資金成本也是巨量的。與之相比，去菜市場買一條魚來烹飪要簡單經濟并效率得多。

同理，RPA雖然開發起來是極快的，但依舊需要找到對應的工作包，需要參數配置，需要邊開發邊測試。這樣一套工作下來，比起一次性手工勞作依舊更費時費力的。為了一年1次或幾次的工作造一套流程一般是不提倡的。

此外，RPA雖然好，但并不是所有工作都適合RPA來完成的。（妄想RPA幫你寫論文，畫PPT的朋友們可以一邊歇著去了)RPA的工作需要有明確的規則，任何模糊的規則都會使RPA運行錯誤，甚至壓根開發不下去。具體問題接下來會展開來分析。

評估RPA關鍵詞--高度重復的工作

如小標題所示，高度重復的工作（工作僅電腦端，上篇有提，此處不贅述）是RPA最佳實踐。具體到我們團隊來說，一套流程至少每月一次運行頻率，低于這個頻率的需求幾乎不考慮。這個其實很好理解，如果一套流程開發完，一年都運行不了幾次，那其開發的工作量很大程度會高于人去執行的工作量，通俗來說就是虧本買賣。

重復，不僅僅指一個流程每天、每月、每年會運行多少次，還要評估單次流程的重復率。怎么理解呢，我們有不少流程，每個月雖然只運行一次，但每一次運行的工作量特別的大，而對于開發的流程來說，只需寫一套完整循環即可，這樣的流程也是比較推崇去開發RPA的。

舉個例子，我們有一套流程需要下載財務系統Oracle-EBS的資產負債表及利潤表。單單是這樣兩個表的下載，每個月運行一次，是很不值得去開發的。但是，Oracle-EBS并沒有批量導出的功能，而集團的分公司，子公司加起來好幾百家。

↑重復量幾百條的RPA工作清單（涉公司信息，模糊處理）

---------------------------------------------------------

標準且唯一的操作方式就是一家一家的公司主體去系統中錄入參數，提交報告申請，再等系統報告運行完成后，下載報告。注意是每一家，意味著雖是3分鐘的工作，但要乘以幾百的倍數。每月僅這一項流程，一次運行即可幫人工節省幾十個小時。

同樣是因為幾百家分公司和子公司這大山壓著，稅務團隊編制報告異常痛苦，每個月雖然只出一份，無奈基數太大，此外稅務報告這里還有一個重點，時間緊張，每月有嚴格的報稅deadline。人不能不睡覺，但RPA機器人可以，流程開發完成后，我們每月指定一天RPA連軸運行近20多個小時完成巨量而又緊張的稅務報告工作。

對于高度重復的工作，只要單次重復的工作量夠大，甚至是不是一個月運行一次或幾次都變得不那么重要。我們就開發過一次性流程，沒有看錯，就是為了運行一次而開發的流程。

當時是有這樣一個項目背景，公司的Oracle-EBS系統需要升級，同樣升級的還有財務的COA科目，不熟悉財務的朋友可以理解為比方說原來是1-10來計數，后來改成ABCD-XYZ這樣方式了，可見影響有多大，整個財務科目都要大換血整理一套嶄新的出來。

不僅僅是EBS系統，與之配合的采購系統，也需要跟著“換血”，新的業務還好，直接按照新的科目走流程即可。既有的業務要通過映射規則，把業務舊的科目轉換成新的科目。如果采購系統是自家管理，倒也能刷一版數據庫，輕松完成。但恰恰這采購系統是外購的SAAS服務（Coupa）。供應商的云平臺可不會給你刷他們家數據庫的權利。

所有既有業務科目變更換血，必須前臺頁面來完成，一條一條的"選",一條費用選出來，A 科目改成什么，B科目改成什么，C科目改成什么，D科目改成什么。。。。。。僅一條費用科目得改10條參數，幾萬條費用*10，近千小時的工作量，7天的調整期限，幾萬次的高度重復，這已經不是通宵加班的問題了，手點殘，鼠標鍵盤點廢也難以完成。

最終我們RPA團隊接下這項任務，通過幾個小時的開發，配置幾臺機器人后，讓機器人連軸轉了四天"輕松"完成了任務，當然，這套流程任務完成后就沒有價值了，即便如此，一次性的收益相比開發任務，也是遠超票價的。
 

評估RPA關鍵詞--清晰明確的規則

如果說重復率是RPA的黃金指標，那清晰明確的規則就是RPA的鐵律。這個如何來理解呢？

機器的工作和人的工作區別在于，機器是聽指令干活，人是按照自己的思想來干活。機器人的工作原理很簡單，接受指令，執行指令，簡單且明了。而到了人這邊呢，首先人要去準確的理解收到的指令。正確理解后，還要考慮做或不做，整體的不穩定性比較高。

舉個不太正經的例子：

機器人收到指令，把桌面一個銷售數據分析報告發送到老板郵箱。

機器人按照既定指令去工作了。選中指定報告，打開outlook郵箱，新建郵件，粘貼附件，輸入老板郵箱地址，發送。

同樣的事，人工怎么做呢？

員工收到指令，把桌面一個銷售數據分析報告發送到老板郵箱。

在雜亂的電腦桌面好不容易找到報告，打開outlook郵箱，新建郵件，粘貼附件，輸入老板郵箱地址，發送按鈕點下之前，回想起上個月因為遲到幾次被老板扣了好多工資，還當著全部門點名批評。

怒從心中起，惡向膽邊生，鼠標指向右上角那個X，咔嗒點下。。。

↑圖為作者對人機工作的理解，若有錯誤，歡迎拍磚

---------------------------------------------------------

舉這個例子并不是想diss說人工多么不靠譜，而是想說明機器人是絕對靠譜的。即便有不少朋友和我探討說RPA機器人不太穩定性的問題，但這些case詳細分析之后，更多的原因是寫入的參數存在一些問題，有些范圍指定過死或者過松。

具體如何過死或者過松就聊遠了，抱歉關于這個點我要挖一個坑，后續有機會，單開一個話題把坑填上。總之，大家要相信機器人是非?？孔V的就可以了。

機器人的靠譜，源于機器人是嚴格執行既有指令來完成的，不會由于心情好不好，窗外刮風還是下雨而影響運行過程和結果。但是，問題又又又來了，機器人的指令是誰寫的？人。如果人都不靠譜，那人寫出來的機器人運作指令能靠譜嗎？這真是一個直擊靈魂的問題。

我們的最終目標是：靠譜的結果
 

↑圖為作者對人機工作的理解，若有錯誤，歡迎拍磚

---------------------------------------------------------

如果要靠譜的結果，前提是需要有靠譜的機器人流程，靠譜的機器人流程的前提是要有靠譜的RPA開發，靠譜的RPA開發過程得需要有靠譜的業務需求規則。

靠譜的業務需求規則，就是本小結的標題：清晰明確的規則。（繞了這么大一圈，終于點題了,各位看官辛苦了)

清晰明確的規則，看似簡單，但真正去做的時候很容易被忽略?；氐竭@個小標題下面的例子吧：

給老板發一份報告。一句話，這只是一句人話，非清晰明確的規則，更非RPA機器人可以執行的指令。人可以理解，但機器人不行。

如果是清晰明確的規則，這一句話應該怎么展開呢？

↓

在桌面找到銷售數據分析報告這份pdf文檔，發送郵件給到老板，老板的郵箱地址為：boss_laoban@abcd.com。

如果是RPA機器人可以執行的指令，這句話又要怎樣去編譯和細化呢？

↓

運行軟件：Outlook

動作組件：發送郵件（通過outlook）

發件人：郵箱默認發件人

收件人：boss_laoban@abcd.com

抄送：無

暗送：無

郵件主題：銷售數據分析報告

郵件正文：老板好，請查收附件，有任何問題請聯系XXX.

附件地址：C:\Users\admin\Desktop\銷售數據分析報告.pdf

↑圖為作者對人機工作的理解，若有錯誤，歡迎拍磚

---------------------------------------------------------

通過這個例子，不難看出清晰明確的規則是多么重要，如果附件地址錯了，發的附件可能變成別的文件；收件人地址錯了，可能一不小心重要報告就送給競爭對手；郵件正文黏貼錯了，可能就不小心把跟同事發的牢騷一并亮給老板看了。。。

小結

至此，評估RPA需求的兩大因素就和大家介紹完了，這兩大評估關鍵字務必牢記。

RPA黃金指標：重復率

RPA鐵律：清晰明確規則

除了這兩條，其實還有流程應用對象穩定性評估等一些前提條件，后續會發文慢慢補充。歡迎大家繼續關注。


特別聲明：

文章來源：RPA機器人學習交流小幫手

作者：張倍銘

原文鏈接：https://mp.weixin.qq.com/s/Gnj0ymQHAMVi7yz0BFgBBw

RPA中國推薦閱讀，如有侵權，請聯系刪除

 

繼續閱讀：流程自動化   RPA需求評估

未經允許不得轉載：RPA中國 | RPA全球生態 | 數字化勞動力 | RPA新聞 | 推動中國RPA生態發展 | 流 > 如何評估RPA需求