今天談下RPA機器人流程自動化，因為RPA這個概念在我腦子里面轉了快2年了，一直沒有深入去分析下具體的應用場景和解決的問題。在我看數字化轉型的很多文章和技術的引入的時候，很多都會談到通過RPA機器人來實現自動化和智能化。
因此有必要專門寫篇文章來談下PRA機器人。
RPA機器人流程自動化概述
首先還是看下百度百科對RPAd的一些標准定義和說明。
機器人流程自動化（RPA）系統是一種應用程序，它通過模仿最終用戶在電腦的手動操作方式，提供了另一種方式來使最終用戶手動操作流程自動化。
在傳統的工作流自動化技術工具中，會由程序員產生自動化任務的動作列表，並且會用內部的應用程序接口或是專用的腳本語言作為和后台系統之間的界面。機器人流程自動化會監視使用者在應用軟件中圖形用戶界面（GUI）所進行的工作，並且直接在GUI上自動重復這些工作。因此可以減少產品自動化的阻礙，因此有些軟件可能沒有這類用途的API。
機器人流程自動化工具在技術上類似圖形用戶界面測試工具。這些工具也會自動地和圖形用戶界面上互動，而且會由使用者示范其流程，再用示范性編程來實現。機器人流程與自動化工具的不同點是這類系統會允許資料在不同應用程序之間交換。例如接收電子郵件可能包括接收付款單、取得其中資料，輸入到簿記系統中。
流程機器人（RPA）軟件的目標是使符合某些適用性標准的基於桌面的業務流程和工作流程實現自動化，一般來說這些操作在很大程度上是重復的，數量比較多的，並且可以通過嚴格的規則和結果來定義。
成功部署企業RPA帶來以下好處：
- 更高的運營效率：節省時間並釋放員工的能力
- 增強准確性，可審計性，監視，跟蹤和控制業務流程執行
- 可擴展且靈活的增強型“虛擬”員工隊伍，能夠快速響應業務需求
- 協作和創新的文化，使我們的業務人員和IT人員可以一起工作
實際上上面百度對RPA的定義說明已經相當清楚，即RPA是通過機器人來模擬人，將人在一個應用系統或多個應用系統間的可重復操作自動化掉。
RPA使用場景進一步分析
當我們在談RPA機器人的時候，一定要重點關注一個核心要素，即RPA本身對已有的應用系統無侵入，類似一個模擬人操作的外掛。理解了這個點我們才好開始討論RPAd的一些應用場景。
對於應用場景，我們仍然選擇一些有代表性的場景進行討論和說明。
場景一：應用系統不受你控制或調整
這個是RPA應用很主要的一個場景，即你使用的應用系統並不受到你的控制，或者會完全滿足你的需求而調整。比如一個企業每月都需要進行報稅操作，但是報稅的內容以及完全整理在一個Excel文件里面。
這個時候你肯定是希望有一個功能能夠直接批量一次性導入Excel文件完成報稅操作。但是報稅系統往往並不會提供這種功能。即使你報稅的過程如此繁瑣和重復，但是也需要人工去完成，你也無法推動系統進行變更。
那么這種場景下使用RPA機器人是合適的。也就是說通過機器人來模擬人完成上述動作，只要我能夠將規則定義清楚，讓操作步驟完全可重復，那么一定就可以自動化。
場景二：應用的UI級自動化測試
說實話，當我第一次看到RPA機器人的時候，馬上就會類別當當前的自動化UI測試工具。或者說是規則(Python腳本)+自動化UI測試工具。
RPA機器人完全就是一個支持規則靈活配置和定義的UI自動測試和驗證工具。
那么當然RPA機器人就可以應用到當前的自動化系統測試中，比如常說的UAT測試，完全可以通過RPA機器人來完成在UAT階段的各種回歸測試操作。
場景三：類似按鍵精靈的所有場景
對於RPA機器人應用的發展源頭，實際上往往就是兩類。一類就是前面談的基於規則的UI自動化測試工具。還有一類就是類似按鍵精靈的模擬鼠標，鍵盤動作並自動化錄制和執行的工具發展而來。
兩種場景都是為了解放人，讓工作自動化執行。
但是本身兩種場景產生的背景又有明顯的差異，對於第一類場景重點是單人執行多步的業務流程和操作並通過流程來自動化。而對於場景二往往則是在多人制定簡單重復操作上。
當你清楚這個后才清楚按鍵精靈這種更多的是使用在了你有多個應用或手機終端下執行簡單重復操作上，類似秒殺搶購，掛活躍在線用戶，僵屍粉等的評論，點贊等操作上面。也就是說有了類似按鍵精靈，你一個人操作100台手機都沒有問題。
場景四：多個已有應用系統間的協同
這個場景實際上是場景一的擴展。即當要完成一個操作的時候，你發現需要在多個業務系統中進行操作和協同，但是這些操作本身是有規律可以尋找，並且在提取規則后可以重復和自動化的操作。
我們舉一個例子來說明：
一個企業上SaaS化的報銷平台，實現了差旅費和日常費用的報銷。但是SaaS應用本身在報銷完成后，還需要手工將憑證數據錄入到內部的類似金蝶等財務管理軟件中。如果一天要處理100個報銷單，那么就需要完成100次數據的錄入。
這個過程本身沒有復雜的規則，完全可以考慮將在兩個系統間做的事情自動化掉。這個自動化本身應該是兩個業務系統間通過接口來完成集成的事情，但是由於你無法推動，導致你需要通過類似RPA技術來實現自動化。
再舉一個例子：
一個企業每個月要開一次會，在會上都需要對企業的經營情況進行匯報。但是匯報數據往往需要查詢ERP，合同，采購，報賬等多個業務系統的數據，然后再整理到Excel中，最后再通過Excel出最終的報表或圖表展現。
整個過程本身也是有章可循，也是重復性工作，那么我們同樣可以考慮通過RPA機器人來實現自動化操作。
RPA只是一個臨時外掛
首先我要表明自己的一個觀點，即：
RPA僅僅是數字化轉型或企業信息化建設過程中的一個臨時外掛，而非終極解決方案。RPA存在的原因是我們在無法推動應用重構和優化中所做出的妥協。
臨時方案還是最終方案？
在幾年前，我們上線的一個應用系統出現了一個問題，即應用系統大量產生應用日志，不斷地將磁盤寫滿。而對於這個問題，我們在前期采取的思路是編寫了一個類似RPA的自動化呈現，定時地去將日志文件進行處理，僅僅將日志中涉及異常部分保留，其它全部刪除掉。同時對於日志文件進行壓縮處理並釋放磁盤空間。
而在去年我們徹底進行了大的優化和重構，即對應用系統中日志管理部分邏輯進行改造，通過應用自動去清理和壓縮日志，同時自動將歷史日志從本地磁盤遷移到NFS分布式存儲中。
上面兩個方案，第一個是臨時方案，第二個是徹底解決。
而對於RPA機器人整體感覺即是一種解決問題的臨時方案而不是終極方案。
存在需要RPA的場景我在前面也談到了，即你無法去推動業務系統去優化和變更，特別是當你使用外部系統的時候。
比如你通過銀行去發員工工資，但是這個銀行本身就沒有代發工資或批量轉賬發工資的功能。你雖然整理好了Excel工資表，你還需要一個個的手工去處理。那么這個問題臨時方案是RPA，而更好的方案是銀行提供批量發工資的功能。
其次，就是RPA幫助你去解決了多個系統間的集成問題，這個集成問題本身應該是兩個系統通過接口進行集成，但是你無法去推動，或者說集成本身成本和代價很大，因此你采用了類似RPA的解決方案來處理。
還是接着上面的例子進一步說明
企業本身實施了報賬系統，在報銷系統中按道理員工的報銷單審批完成后，應該自動形成應付發票或憑證，基於憑證就應該自動和銀行連接來完成報銷打款操作。這個時候你無法去集成和協同兩個系統，因此采用了RPA機器人。但是更好的方式是實現報銷系統和銀行系統間的接口集成，類似我們常說的銀企互聯，最終完成整個流程的自動化操作。
建設總結就是本應該是兩個業務系統經過底層API或接口集成來完成協同的事情，有由於成本或無法推動的原因，你選擇了RPA方案來解決。
為何不建議RPA？
前面已經談到了臨時方案和最終方案的差別，如果條件允許一定是采用最終方案來從根本上解決問題，而不是選擇一種臨時方案。
RPA通過機器人自動化，但是本質還是模擬的人。一個好的自動化方案和提升效率的方案一定是應用底層邏輯的自動化和批量化，應用系統間的自動化接口和數據協同。這往往才是最高效的。
當你使用RPA的時候，你還面對如下問題需要解決。
其一是人員技能水平，一個RPA真正的價值往往並不是完全簡單的可重復，而是通過抽取規則后變得可重復，而規則的抽取和定義，往往就偏技術知識和技術思維，對人員的IT技術要求會增加，這個不是一般的業務人員能做到的。
如果不是給一般業務人員用，而是給IT人員用，那么又出現一個悖論，你會覺得有開發經驗的IT人員會去使用RPA解決問題嗎，這個估計還沒有自己寫點Python自動化的腳本來的快。
當然如果真在業務人員有自動化思維，估計在沒有RPA之前自己也已經將Excel工具，宏錄制和自動化等用得滾瓜爛熟了。這些使用起來完全可以起到類似RPA的作用。
其二是應用本身的變更容忍度，由於應用系統對你不可控，因此你采用了RPA的外掛來解決問題，那么自然你對應用系統的變更也不可控。那么應用功能一旦出現變更，你會發現你原來錄制的腳本和規則都要進行修改。
那么可以看到應用變更越頻繁，錄制腳本和維護腳本的工作量也就越大。這個工作量投入往往並不比你重復錄入數據小，對於頻繁變更的應用自動化本身就沒有價值。
其次就是應用雖然變更不頻繁，但是對於規則要求極高，那么通過RPA機器人自動錄入一些數據進去你能夠做到完全放心嗎？是否還會出現RPA幫你處理完成后，你還得去做重復檢查的情況。
我們再把上面的場景擴展一下。
一個企業在某個業務場景下引入了RPA機器人給業務人員用，那么如果業務人員采用RPA機器人后導致了應用系統中的數據出現了錯誤，這個時候的責任人究竟是誰？公司領導是去找RPA機器人的麻煩還是業務人員的麻煩。
你自己通過一些excel或python腳本實現一些自動化，公司領導不關心，因為最終系統中數據正確性的負責人還是你自己。但是公司層面去引入RPA機器人，為了是減輕員工重復處理的工作量，還要為最終應用數據正確性擔責，我想沒有哪個領導願意去做這個事情。
多系統集成和持久化場景是關鍵
在前面談了RPA的應用場景，再次強調下對於RPA解決方案，涉及到的多個業務系統間的自動化集成和協同往往才是一個關鍵的需求點。
這類場景由於涉及多個系統，推動的難度最大，因此采用RPA方案是一個可行的選擇。
同時要看到當你處理多場景協同的時候，一定存在中轉和數據的暫存，一個好的RPA方案一定需要提供數據的持久化處理機制。比如數據導出到Excel 或寫入到數據庫，再比如RPA可以自己去定義中間的數據對象存儲等。
典型的場景就是類似前面談到的在報銷系統中先查詢中已經報銷審批完成的單據，然后將單據導入到ERP系統中去。如果要實現這個完整過程，實際上需要對中間報銷單據進行暫存，以方便中間的處理和數據清洗。
如果沒有這種暫存和數據持久化能力，那么RPA就變成了獨立兩段操作，沒有意義。
數字化階段需要的是底層真實連接
最后再次總結下，在數字化階段我們一直在強調連接，強調萬物互聯。這個連接需要的一定是物和物，人和人，人和IT系統之間的真實連接。同時進一步的期望是將人和IT系統間的連接轉變為底層自動化數據采集和自動連接，轉變為底層IT系統之間的自動化接口對接。
對於RPA，如果是在解決傳統企業IT架構，傳統應用間業務和流程協同的問題，那么RPA確實是一個好的解決方案。但是在數字化階段，我們對連接的理解已經發生了根本改變，這個連接絕對不是靠機器來模擬人完成的。
靠機器模擬人來解決自動化問題，往往讓你進一步忽視了對事物本質問題和根源的探索，讓你很難從底層系統構建邏輯去解決該有的問題。
簡單來說RPA本身是反數字化思路的，只是將人和物，人和IT系統之間的一些連接自動化掉了，而不是從本質上去解決問題。
一個核心的數字化邏輯應該是連接本身就應該是底層自動化技術來解決掉，而不是通過機器人模擬人來自動化掉。其次，數字化下的流程本身就應該是自動化協同，而非是通過RPA才能夠完成自動化協同。
任何通過RPA才能夠完成的自動化協同流程，都不是一個好流程。