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

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

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

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

RPA開發(fā)前需注意之--識別偽需求

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

偽需求一：“硬"造功能

系統(tǒng)沒有設(shè)計(jì)某項(xiàng)功能，用戶卻認(rèn)為缺失的功能非常重要，系統(tǒng)改不了怎么辦，找到機(jī)器人來做。而很多用戶并非專業(yè)的產(chǎn)品經(jīng)理，往往提的需求或功能考慮不周。提出的需求實(shí)際意義有待商榷。

比如我們有接觸過這樣一個case，公司的采購系統(tǒng)是有審批機(jī)制，一筆訂單采購需要直接領(lǐng)導(dǎo)，采購，財(cái)務(wù)等多層級審批人審批。如果一筆訂單在某位審批人pending很久未通過也未拒絕的情況下，采購系統(tǒng)會有提醒機(jī)制，給相應(yīng)的審批人發(fā)送提醒郵件告知。

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

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

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

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

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

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

偽需求二：“硬"造業(yè)務(wù)量

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

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

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

RPA開發(fā)前需注意之--流程驗(yàn)證

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

我們建議RPA團(tuán)隊(duì)在正式接收需求之前，全盤人工學(xué)習(xí)執(zhí)行一遍業(yè)務(wù)方流程操作，一是排雷業(yè)務(wù)方指導(dǎo)錯誤。二是熟悉流程。如果有條件，最好用機(jī)器人軟件做一個POC來驗(yàn)證，避免部分軟件出現(xiàn)不兼容的情況。

另一塊可能出問題重災(zāi)區(qū)就在input輸入這塊。比如，發(fā)票抵扣機(jī)器人流程，用戶給的發(fā)票號錯誤。再比如報(bào)告自動下載流程，用戶給的報(bào)告名稱不對。源頭input出了問題，會導(dǎo)致process執(zhí)行錯誤或執(zhí)行不下去，output的結(jié)果就可想而知。

還是講講真實(shí)的案例吧。我們有個下載銀行流水的機(jī)器人流程。幾百個賬戶，用戶人工疏忽維護(hù)，個別賬戶維護(hù)了錯誤的賬號密碼，那機(jī)器人就無法進(jìn)入系統(tǒng)，自然無法導(dǎo)出流水?dāng)?shù)據(jù)。

還有一種情況是賬號密碼都正確，但不同的賬戶，系統(tǒng)里配置的權(quán)限是不一樣，少量賬戶并沒有開通機(jī)器人需要執(zhí)行的那個權(quán)限，需要業(yè)務(wù)方去協(xié)調(diào)申請，否則同樣會造成部分結(jié)果失敗。

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

RPA開發(fā)前需注意之--流程分析

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

原始步驟：

有一個需求，財(cái)務(wù)部門需要每個月把所有賬務(wù)明細(xì)數(shù)據(jù)都從系統(tǒng)里導(dǎo)出來，范圍涵蓋集團(tuán)公司下所有分公司子公司。原來是怎么做的呢？

如圖所示，相關(guān)業(yè)務(wù)同事會先在財(cái)務(wù)系統(tǒng)中提交A公司報(bào)告申請，等待一會系統(tǒng)運(yùn)行，待系統(tǒng)準(zhǔn)備好數(shù)據(jù)后，點(diǎn)擊下載報(bào)告。然后B公司報(bào)告同樣操作，C公司。。。直到所有公司都執(zhí)行一圈。

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

步驟優(yōu)化：

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

我們基于原有的流程，進(jìn)行了一些小改造。

如圖所示，我們安排機(jī)器人先按步驟把各家報(bào)告申請都提交，后臺記錄下各個報(bào)告的id,當(dāng)提交完所有報(bào)告申請后，最早提交申請的報(bào)告系統(tǒng)早已運(yùn)行完畢可供下載。機(jī)器人再通過記錄把報(bào)告從系統(tǒng)中翻出來進(jìn)行下載。

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

升級版優(yōu)化：

隨著對業(yè)務(wù)和系統(tǒng)更深入的了解，我們發(fā)現(xiàn)每一家分子公司報(bào)告格式是完全一致，數(shù)據(jù)內(nèi)容也有一列標(biāo)注了數(shù)據(jù)所屬公司code，而財(cái)務(wù)系統(tǒng)本身也是支持全量下載報(bào)告的。之所以人工沒這樣操作是基于超大電子表格，去拆分各家公司小表格手工操作過于麻煩。當(dāng)然，拆分表格對機(jī)器人來說，完全不是問題。

如圖所示，我們又進(jìn)行了機(jī)器人流程改造，直接發(fā)起了一個全量公司報(bào)告申請，等待十幾分鐘后，將全量數(shù)據(jù)下載至本地，再安排機(jī)器人依據(jù)公司code作為區(qū)分維度，拆分?jǐn)?shù)據(jù)至不同的小表格作為不同公司自己的報(bào)告。

這個升級版方案除了等待財(cái)務(wù)系統(tǒng)準(zhǔn)備全量公司報(bào)告比單家操作時(shí)間略長，拆分報(bào)告動作相比每一家公司去提交下載機(jī)械工作相比，單輪效率直接從分鐘級工作效率優(yōu)化到秒級，乘上個幾百的倍數(shù)，效率的提升非?？捎^。

小結(jié)

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

 

特別聲明：

文章來源：RPA機(jī)器人學(xué)習(xí)交流小幫手

作者： 張倍銘

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

繼續(xù)閱讀：流程自動化   RPA

未經(jīng)允許不得轉(zhuǎn)載：RPA中國 | RPA全球生態(tài) | 數(shù)字化勞動力 | RPA新聞 | 推動中國RPA生態(tài)發(fā)展 | 流 > RPA開發(fā)之前需注意的問題