在上幾篇文章里，我們初步了解了RPA需求幾個重要的評估準則，那是不是需求滿足那些規則后，就可以拿來上手開發了呢？

（直通車--如何評估RPA需求）

（直通車--如何評估RPA需求-補充篇）

且慢，磨刀不誤砍柴工，前期把工作做足了，后期開發才會一路暢通，反之很有可能演變成一趟踩坑之旅。
 

RPA開發前需注意之--識別偽需求

我們在接觸需求的過程中，曾遇到兩類偽需求。

偽需求一：“硬"造功能

系統沒有設計某項功能，用戶卻認為缺失的功能非常重要，系統改不了怎么辦，找到機器人來做。而很多用戶并非專業的產品經理，往往提的需求或功能考慮不周。提出的需求實際意義有待商榷。

比如我們有接觸過這樣一個case，公司的采購系統是有審批機制，一筆訂單采購需要直接領導，采購，財務等多層級審批人審批。如果一筆訂單在某位審批人pending很久未通過也未拒絕的情況下，采購系統會有提醒機制，給相應的審批人發送提醒郵件告知。

但是，我們有需求方希望推進加快整個審批環節的效率，覺得采購系統提醒審批人，這提示功能做得不夠。不僅要提示審批人，還得給提單人發郵件告知，讓提單人再去以各種方式，催促審批人盡快完成采購審批操作。

這個需求表面看起來在理，系統催審批人無果后，再利用機器人催提單人，讓提單人來"追殺"審批，也許整個進程就會快很多。

但事實真的是這樣嗎?真的如需求方所說，需要提醒提單人來催審批人么？

分兩個場景來看，如果提單人很著急，那么別說等24小時了，等一個小時進系統看沒批通過，可能就電話或者人肉就追上去了。這種情形完全不用提醒提單人，人家早早就push 了。

如果提單人不著急呢？即便收到機器人發送提示郵件，會去催嗎？大大的問號，本來就不急，何須催促。

兩個場景分析完，讓機器人去提醒提單人，這個功能的意義就要打上一個大大的問號了。

偽需求二：“硬"造業務量

很多人認為反正是機器人干活，又不是人來工作，于是很多不痛不癢的需求就提了上來，哪怕機器人干十分活，只能人工省半分力氣，他們也樂意。這樣做其實對機器人的資源是很大的浪費，機器人做了很多低效工作，占用其他流程工作時間。

有這么個例子，公司內部發起開票申請流程，其實每天開票的子公司就那么幾家，而公司分子公司數量幾百，需求業務方的擔憂是：今天從不開票的公司，未必明天不開票，為了沒有"漏網之魚"，要求每天三次，幾百家分子公司一家不落，RPA機器人逐個去查。（每一家都需要單獨查詢，無法批量)。

全量去查不是沒有好處，有，可以網住幾個漏魚，但收益真的非常有限，代價是耗費機器人大量時間做很多無用的工作，拿著大炮打蒼蠅，除非這幾個漏網之魚會對業務造成非常重大的影響，否則這樣的需求即便是RPA僅僅只是費電去干活，也并不是很合適。

RPA開發前需注意之--流程驗證

一般來說，我們會把RPA分成三個步驟，input-獲取任務；process-執行任務；output-產生結果。需求方對前兩者并不太在意，但對結果比較關心。然而如果沒有正確的input和process，其結果output會是怎樣不難想象。

我們建議RPA團隊在正式接收需求之前，全盤人工學習執行一遍業務方流程操作，一是排雷業務方指導錯誤。二是熟悉流程。如果有條件，最好用機器人軟件做一個POC來驗證，避免部分軟件出現不兼容的情況。

另一塊可能出問題重災區就在input輸入這塊。比如，發票抵扣機器人流程，用戶給的發票號錯誤。再比如報告自動下載流程，用戶給的報告名稱不對。源頭input出了問題，會導致process執行錯誤或執行不下去，output的結果就可想而知。

還是講講真實的案例吧。我們有個下載銀行流水的機器人流程。幾百個賬戶，用戶人工疏忽維護，個別賬戶維護了錯誤的賬號密碼，那機器人就無法進入系統，自然無法導出流水數據。

還有一種情況是賬號密碼都正確，但不同的賬戶，系統里配置的權限是不一樣，少量賬戶并沒有開通機器人需要執行的那個權限，需要業務方去協調申請，否則同樣會造成部分結果失敗。

怎么解決這些問題呢？為了整體流程能順利運行，則需要人工模擬機器人的方式全流程走幾遍。若希望整體成功率更高，則需input每一條工作清單都去驗證相關權限，當然，后者可以放在流程開發完畢后，正式交付前的全量測試中進行。

RPA開發前需注意之--流程分析

RPA機器人是通過學習和模擬人工的方式，幫人們解放勞動力，但學習和模擬不代表全盤接受，拷貝不走樣。雖說條條馬路通羅馬，但尋求最短路線最快路徑對RPA來說是很有必要的。畢竟RPA自帶屬性就是高度重復，如果一個單流程步驟簡化，節約半分鐘，重復個兩三百的倍數，那就是好幾個小時。一起繼續來看例子吧。

原始步驟：

有一個需求，財務部門需要每個月把所有賬務明細數據都從系統里導出來，范圍涵蓋集團公司下所有分公司子公司。原來是怎么做的呢？

如圖所示，相關業務同事會先在財務系統中提交A公司報告申請，等待一會系統運行，待系統準備好數據后，點擊下載報告。然后B公司報告同樣操作，C公司。。。直到所有公司都執行一圈。

人工之所以提交一家，稍等一會，下載一家，這樣的模式是因為重復的工作量很大，混合操作容易“亂”。每次提交報告后，系統會提示一個報告id。對于員工來說，記住三五條還好，若是幾十個上百個，除非是世界級記憶大師可以精確記憶，準確匹配,否則只能one by one這樣操作。

步驟優化：

誠然，如果這項工作計劃由RPA機器人來完成，是可以全盤照搬人工的報告下載流程來進行，但這樣的操作步驟似乎效率太低。RPA用的是電腦而非人腦，準確記憶（記錄）就是強項。“one by one ”可以變得不是那么必須。

我們基于原有的流程，進行了一些小改造。

如圖所示，我們安排機器人先按步驟把各家報告申請都提交，后臺記錄下各個報告的id,當提交完所有報告申請后，最早提交申請的報告系統早已運行完畢可供下載。機器人再通過記錄把報告從系統中翻出來進行下載。

這樣的模式有兩個優勢，1 瀑布式工作，不用頻繁切換模塊，效率更高。 2 充分利用等待時間去提交其他報告，幾十乃至幾百份報告運行所需等待的時間節約下來。

升級版優化：

隨著對業務和系統更深入的了解，我們發現每一家分子公司報告格式是完全一致，數據內容也有一列標注了數據所屬公司code，而財務系統本身也是支持全量下載報告的。之所以人工沒這樣操作是基于超大電子表格，去拆分各家公司小表格手工操作過于麻煩。當然，拆分表格對機器人來說，完全不是問題。

如圖所示，我們又進行了機器人流程改造，直接發起了一個全量公司報告申請，等待十幾分鐘后，將全量數據下載至本地，再安排機器人依據公司code作為區分維度，拆分數據至不同的小表格作為不同公司自己的報告。

這個升級版方案除了等待財務系統準備全量公司報告比單家操作時間略長，拆分報告動作相比每一家公司去提交下載機械工作相比，單輪效率直接從分鐘級工作效率優化到秒級，乘上個幾百的倍數，效率的提升非常可觀。

小結

今天我們通過不少例子聊了聊RPA開發之前需要注意的問題點。RPA的編寫也是一種開發，開工之前務必做好事前準備，整個流程實施起來才會更加的順利。

 

特別聲明：

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

作者： 張倍銘

原文鏈接：https://mp.weixin.qq.com/s/-eW2Tf3S-u0OY0zxTbXUcw

繼續閱讀：流程自動化   RPA

未經允許不得轉載：RPA中國 | RPA全球生態 | 數字化勞動力 | RPA新聞 | 推動中國RPA生態發展 | 流 > RPA開發之前需注意的問題