有關RPA項目方面的一些問題

寫在前面：

最近在自我總結的時候，總是感覺可能從客戶或諮詢顧問的角度，對RPA的理解以及自身角色和價值方面有一些誤區。不知道這篇文章能被誰看到，但願能得到業內同僚或是前輩的指點吧。

RPA這個概念國外早已產生多年，但差不多直到去年初國內才由四大開始熱炒起來，到現在不論行業或是企業規模，大家都開始如火如荼的實施相關項目，或者準備開始以及研究相關技術。我身在乙方，去年有幸加入RPA項目實施大軍，今年更是有機會參與了一些項目初期溝通、招投標甚至是POC的過程當中。以下是我思考而不得的一些問題：

1、 有關RPA技術本身

「RPA技術是萬能的」這個誤區早已有所耳聞。RPA技術到底是什麼這裡就不說了，隨手百度或者看新聞比比皆是。我不知道這個觀點是由誰發起的，或是由誰宣傳的，但顯而易見沒有任何一種「單一」的技術是萬能的，之所以流程自動化現在在市面上如此玄乎，並不是因為RPA技術本身有多麼的發達與成熟，而是因為第三次工業革命之後至今，互聯網時代加強了各行各業的信息互聯，也就造就了各種各樣解決單一獨立需求的工具的誕生和飛速發展。

「進項稅發票處理機器人」包含了紙質增值稅發票的掃描與識別、發票信息的歸納整理、發票查驗以及ERP系統的數據錄入這幾個常見步驟，甚至還包括了最終機器人運行結果的報送。該機器人本身的脈絡是RPA，這是沒錯，但是這裡面除了RPA，沒有OCR、非結構化數據處理、「人工智慧」的驗證碼識別平台、各式各樣的國稅局發票信息API這些單獨技術模塊的任何一個，該機器人的功能就是不完善的，用客戶的語言來表述就是「不能滿足我們的需求」，若一個業務流程做了自動化之後，還是有很多步驟需要人機交互，還是有很多錯誤需要人工複核，那麼是不是自動化的意義就很小了呢？人家的需求明明就是輸入一批紙質發票，輸出ERP系統內的會計憑證以及發票真偽的統計數據，為什麼使用了RPA，還是需要人工去敲驗證碼？為什麼發票時不時地會經常驗不出內容？雖然我們可以解釋說這是因為國稅局的驗證碼設計就是為了防機器人批量查詢，OCR技術的發展現今就是有一定的局限性，這些鍋可不能由RPA來背，可是歸根結底，和客戶接觸的人都是RPA項目的實施顧問，不該背的鍋也得自己來背了。這種情況，真的是進退兩難啊。

2、 有關RPA諮詢顧問的價值

之前在做SAP ERP財務模塊實施顧問的那兩年多里，每個項目組裡面的方案顧問、業務顧問、技術顧問各司其職，大家分工明確，我也從那時起建立了自己IT諮詢項目的基礎知識體系架構。傳統ERP實施項目的架構發展這麼多年穩定至今是有它一定的道理的，之所以諮詢顧問要拆分為方案顧問、業務顧問和技術顧問，是因為三者職責、能力和經驗是完全不同的，方案顧問行業經驗豐富，更擅長從全局角度指定企業藍圖，更加了解市場發展趨勢和同類客戶的需求痛點，業務顧問更了解詳細的業務流程和業務需求，也更加了解ERP系統內的模塊功能點和系統配置，而技術顧問更了解ERP系統底層架構、編碼工具和系統維護，三者各司其職方能保證項目正常運轉，客戶與顧問關係健康發展。

但後來在參與RPA項目實施的過程當中，這個概念卻被弱化了，很多時候都是要擅長編程的人去與客戶溝通業務流程，要更了解業務需求而不擅長編程的人去撓頭苦寫代碼。有些人要說，UiPath、Blue Prism或者Automation Anywhere這些主流RPA平台不需要寫代碼啊，而且不是說只要在前台用這些軟體把實際業務流程操作下來錄一遍，簡單改改就可以作為一個流程自動化機器人來用了嗎？另外，這些平台都是有現成的activity可以拖拽拼裝實現自動化的，不應該那麼困難和複雜吧？

這些話，諮詢顧問們聽了簡直要背過氣去。現在RPA平台興起，各個平台均鼓吹自己的上手有多麼簡單容易，編碼量多低，殊不知「錄一遍就出來」的業務流程是極其單一，毫無邏輯分支和異常處理機制在的，絕大多數情況下這個錄製功能只是為了方便技術人員編寫過程中少走些彎路，甚至是為了在不知道應該用哪一個開發的activity的時候錄一遍來看看系統默認使用的是什麼，為自己提供思路。那麼在此基礎上，是不是說RPA平台的開發代碼量很低，就應該讓技術背景薄弱的業務顧問去自行編製機器人了呢，或者讓技術顧問去了解業務需求呢？這樣不是就可以一個顧問完成一整件事了嗎？我認為完全不應該，甚至通過這麼多項目實施過程感覺這樣會有很大的問題。首先業務顧問的長處是與客戶溝通多年的經驗和知識儲備，在RPA項目中更擅長業務流程梳理、流程設計和測試，因為他們更了解客戶需求，更明白預期效果，但他們沒有編碼基礎，不知道這些主流RPA平台用的.Net是什麼，VBA怎麼寫，怎樣寫JSON文件來實現巨複雜的後台實現功能，讓他們來做RPA流程，基本上都只是前台的操作的簡單實現，後台的複雜邏輯處理甚至是工具整合完全兩眼一抹黑。在這樣的基礎上，長期以往業務顧問在做RPA項目時會畏首畏尾，並且做出來的機器人也根本達不到效率最優化的目的。而讓純技術背景的人去寫機器人，雖然沒有這些方面的顧慮，但是由於技術顧問缺乏業務知識和實戰經驗，很多時候客戶習以為常的業務常識沒有提到，技術顧問在設計流程時可能就不會想到，而且更多時候是客戶解釋實際業務怎樣做，技術顧問就怎樣做，完全不做業務邏輯的優化、流程的改造，這都是因為缺乏業務知識和相關經驗造成的現象。

所以，是不是不同背景的顧問本應該做不同的事情，大家相互配合才能夠達到效率和結果的最優呢？

從另一個角度來看，RPA諮詢項目和顧問的價值難道就在使用現成的工具，使用熟練地編碼技術去把手工的業務流程變成機器人嗎？難道不應該是在了解業務流程後去深究根本需求，以解決需求為目的優化流程甚至改造流程，再去進行自動化嗎？乙方諮詢的核心不應該是各行業海量諮詢項目的知識積累、各種客戶業務痛點需求和相關解決技術工具的了解，能夠為客戶提供最適合的解決方案嗎？

如果諮詢顧問和諮詢項目如此簡單，只要會寫代碼編流程就可以了，那麼只要會.net的人客戶自己招兩個去學學平台知識自己開發不就行了？何必招諮詢顧問來寫代碼，而這幫諮詢顧問除了寫代碼以外，客戶說怎樣就怎樣寫，還比自己員工貴上許多，何苦呢？

3、 有關POC的目的

最近參與了一個客戶的POC，客戶幾乎拿出了自己的所有業務需求來讓一大堆的廠商挨個做一遍，最終彙報的時候，我們在講到增值稅發票查驗這個流程時，客戶質問了我們兩個點，一個是最初統一講解業務需求的時候，我們這邊表示國稅局驗證碼自動錄入的功能可以實現，可是我們為什麼最終沒有選擇這種方法完成這個POC流程，為什麼使用的是第三方API來自動獲取發票信息。

這裡面，以我的看法，我覺得可能現在大家對POC、對RPA項目的流程實現上，都有一些誤區。POC顧名思義，Proof of concept，目的是驗證RPA這個技術，甚至是我們使用的RPA平台，能不能滿足實際業務的需要。如果以此為目的，是否真的有必要在POC階段拿出所有十幾個業務流程需求讓所有廠商用不同的工具挨個做一遍，而且還限制在一周多一點的時間內呢？難道不應該是同類型的核心痛點業務需求拿出來就可以推演到整體業務需求的實現可行性嗎？POC現在在國內，似乎變成了免費實施某些核心業務流程自動化，或者是不同乙方諮詢公司打擂台比誰做得好做的快了，我倒覺得與其這樣，還不如不叫POC了，舊瓶裝新酒，沒什麼意義吧。

另外，在上面客戶質問我們的問題中，我們是這樣解釋的，首先我們的理解，客戶的需求核心是校驗這張發票的真偽，而不是「掃描發票-登錄某網站-錄入驗證碼-回傳信息整理-比較-輸出結果」這一個很詳細很詳細的流程。能夠達到檢驗發票真偽這個目的的途徑有很多種，這些方法中，最快的方法就是使用成熟可靠的API來直接獲取發票數據，免去了前台系統網站登錄、錄入驗證碼和回傳信息整理這三大步驟的時間，從業務效率上來說是最優化的，最終也是能夠完全達到需求的目的的，為何要糾結於一定要錄入驗證碼這件事情呢？如果客戶完全不信任任何第三方API，那麼也好，我們可以去市面上買驗證碼的API，現在市場上有很多「打碼賺錢」的網站，這些網站一個驗證碼只要不到一分錢，只需要不到兩秒的時間網上就有人手工去幫你識別錄入，回傳結果了，不論你的驗證碼是圖片、文字還是有顏色要求或者其他干擾，人眼總歸是能識別出來的，能夠保證最終結果的準確性。我們也可以推薦使用這種工具，一萬張發票的查驗也就不到100塊錢，成本極低。如果POC階段非要我們開發驗證碼識別的代碼，我們需要專業的技術顧問去分類篩選驗證碼的種類和可能性，針對每種不同可能性去設計不同的識別演算法，最終還要完成編碼、封裝、測試、整合進RPA這幾個步驟，試問短短一周多的時間何以實現。而且就算我們加班加點趕出來了，這又與驗證RPA技術的可行性有何關係，未來出現新的驗證碼種類，比如拖拽滑塊，完成拼圖等，我們是不是又要修改驗證碼程序了？技術顧問的人天也是不便宜的，讓一個技術顧問寫出一個成熟的驗證碼識別模塊，人天的諮詢費用加起來可以用上面的人工打碼工具識別幾百上千萬個驗證碼了，是不是撿了西瓜，丟了芝麻呢？

不知道以上這些問題，是我自己的問題，還是市場上的共性問題呢？