如何評估RPA需求，RPA需求的模型

大家都知道 學習門檻低，用簡單到圖形介面就可以開發大部分業務流程。雖然RPA開發效率高，拖拖拽拽就可以完成流程開發，看起來比較簡單。但開發畢竟是要投入時間和精力的，除非是學習和練習為目的，否則這個流程可能給企業帶來不了什麼價值。舉個不恰當的例子，為了吃魚這個目標，先包下個池塘，再慢慢養魚，最後將魚撈上來再烹飪。且不說整個過程實現的時間週期過長，投入的資金成本也是巨量的。與之相比，去菜市場買一條魚來烹飪要簡單經濟並效率得多。

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

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

評估RPA關鍵詞–高度重複的工作

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

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

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

標準且唯一的操作方式就是一家一家的公司主體去系統中錄入引數，提交報告申請，再等系統報告執行完成後，下載報告。注意是每一家，意味著雖是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詳細分析之後，更多的原因是寫入的引數存在一些問題，有些範圍指定過死或者過鬆。

具體如何過死或者過鬆就聊遠了，抱歉關於這個點我要挖一個坑，後續有機會，單開一個話題把坑填上。總之，大家要相信機器人是非常靠譜的就可以了。

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

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

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

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

清晰明確的規則，看似簡單，但真正去做的時候很容易被忽略。回到這個小標題下面的例子吧：

給老闆發一份報告。一句話，這只是一句人話，非清晰明確的規則，更非...詳細請參考原文

原文連結：