1.2　RPA的九大主要特征

為了更清晰地說明RPA的主要特征，我們將使用一個完整的業務流程作為分析示例。這個例子是某企業采購部門員工的一個日常工作場景，如圖1-2所示。

圖1-2　采購部門員工日常工作場景的關聯應用系統

員工A上班之后，首先要在辦公系統（Ⅰ）中登錄，簽到打卡，以表明自己按時到崗上班，然后給自己泡上一杯茶，準備開始一天的工作。他打開自己的郵件系統（Ⅱ），檢查是否收到了昨天供應商提出的采購請求的郵件，爾后在新郵件清單里發現確實收到了這封郵件，隨后打開郵件檢查對方的請求信息是否正確，核對無誤后，便打開了公司的采購系統（Ⅲ），一項一項地將郵件中的請求信息復制粘貼到系統請求的頁面中。錄入過程中發現，有一項關于供應商的社會信用代碼需要錄入到系統中，他又不得不打開國家工商行政管理總局的信息網站（Ⅳ）查詢到該供應商的信用代碼，再次復制粘貼到系統中。

最終，他一項一項地錄入了全部信息，但是過程中由于操作不熟練，導致幾次將信息錄入到錯誤位置，不得不停下來進行更正。而這還不是全部完成，因為他需要把這個采購請求發送給他的同事B進行復核，B需要打開原始郵件系統（Ⅱ），再打開采購系統（Ⅲ）查詢到A所提交的信息，與A填寫的信息進行逐項核對無誤后，反饋回A，A才能在采購系統中正式提交請求生效，生成這筆采購訂單。然后A需要將訂單打印好，并將這筆訂單信息同步記錄到他自己電腦的Excel表（Ⅴ）中，以作后續的備查和統計使用，再將訂單生成的反饋信息通過郵件系統（Ⅱ）回復給供應商。最后，A再將打印好的訂單快遞給庫管部門。以上這樣的業務處理過程對于企業的一線員工最熟悉不過了，而且可能一天要重復很多次。

我們來統計一下上面的操作過程，從a到o共計15個步驟，從Ⅰ到Ⅴ共計5個應用系統、網站或桌面軟件程序，在一個系統中頁面打開、關閉、查詢、錄入、核對、復制、粘貼、提交的次數就更多了。那么，我們來看看RPA的處理過程，如圖1-3所示。

圖1-3　采購部門員工日常工作場景中識別的自動化環節

員工A上班后的第一件事情是啟動電腦里的RPA機器人，我們暫且把它稱為Bot-A。Bot-A會根據員工A所提供的待辦事項清單（To-do list）逐一完成工作。Bot-A在桌面系統中自動打開辦公系統（Ⅰ）的登錄頁面，輸入已經配置好的員工A的用戶名和口令，并點擊“登錄”自動完成簽到操作。當Bot-A完成第一項工作后，即在員工A的桌面上顯示已完成簽到的狀態。Bot-A依據工作順序，執行郵件檢查工作。

Bot-A自動打開郵件系統（Ⅱ），登錄后按照預制好的規則檢查郵件的發件人、標題和時間信息，篩選出符合條件的郵件逐件處理。Bot-A自動打開那封關于供應商提出的采購請求的郵件，按照規則檢查郵件內容是否完整和正確。如果不正確，Bot-A自動回復一封標準的退回郵件；如果正確，則自動打開采購系統（Ⅲ）將郵件信息填入進去。Bot-A按照錄入規則判斷，如果發現缺少了信息，則又自動打開國家工商行政管理總局的信息網站（Ⅳ）查詢，查到后抓取信息自動回填到采購系統中，并自動提交這筆訂單（l1），發送到打印機進行打印。

Bot-A繼續打開Excel自動錄入信息，并自動將相關信息寫入反饋郵件回復給原發件人。當自動化完成上述所有工作后，Bot-A會在員工A的桌面上顯示一條“已完成×××××訂單”的提示信息。這時，員工A只需要到打印機前取回打印好的訂單（l2），再快遞給庫管部門，全部工作就完成了。

我們再來統計一下，利用RPA技術可以全自動化或半自動化地實現從a到o其中的13個步驟，除了步驟b和o，因為這兩個步驟都屬于員工在現實世界的純物理行為，而且與系統操作無關，所以RPA無法處理。在整個操作過程中，員工A幾乎不需要參與整個處理過程，只是通過接收Bot-A的反饋消息，監督Bot-A的執行。

基于上面的例子，我們再來總結一下RPA有哪些主要特征，依據這些特征可以看到概念之外的細節情況。

1.2.1　模擬人類操作行為的系統，讓用戶“眼見為實”

例如，在a、c、f、g、m等步驟中，Bot-A的操作過程和操作行為幾乎和人一模一樣。員工A打開什么界面，Bot-A就打開什么界面；員工A怎么錄入信息，Bot-A就怎么錄入信息；員工A點擊“提交”按鈕，Bot-A就點擊“提交”按鈕。整個處理過程從后端系統看，是沒有辦法分辨員工A和Bot-A的區別的。另外Bot-A的整個模擬過程，對于用戶是可見的，即用戶可以看到Bot猶如魔法一般快速操作各類應用軟件的整個過程。

這不單只是追求炫目的視覺效果，其實是在更深層面讓用戶對計算機產生了某種信任感，拉近了IT和用戶的心理距離。由于傳統應用軟件的運行情況對于用戶來講就是個黑盒子，再加上用戶缺乏對軟件編程的足夠了解，經常會出現用戶不知道后端系統在做什么的情況，一旦出現系統響應延遲、不斷報錯等問題，用戶就會抱怨。如果一個IT系統能夠讓最終用戶眼見為實，會給這項技術加分不少，這也是為什么更多的計算機仿真和模擬程序不斷出現的原因。

1.2.2　基于既定的業務規則來執行

例如Bot-A在d、e、f等步驟的處理中，需要依據事先已經預設好的規則來執行，比如預設郵件篩選的規則，包括選取什么時間段、由哪個郵箱地址后綴發出來、郵件標題中含某字段標識或是某種更加特殊的標志。篩選規則可以是簡單的，利用腳本程序直接實現；也可以是復雜的，利用規則引擎來實現。如果是人工查找一封郵件，會先按照發件人或者時間排序，然后用目光進行搜索，找到那個熟悉的關鍵字后，再仔細看郵件的標題是否符合要求。

如果我們靠機器人和規則來實現，那么就不能再簡單地模仿人的行為，而是需要讓計算機明白那些業務規則。所以說，RPA模擬的只是人的行為，而不是人的思維，只會執行人類預先設計好的邏輯規則，而不會自己去思考如何工作。而人類的思維需要靠人工智能來“模仿”，這部分內容在3.4節詳細描述。

1.2.3　帶來確定的執行過程和執行結果

如例子中從a到o的所有步驟，RPA會按照確定的順序來執行，且不會隨意調整，這也與人類的行為習慣存在很大差別。雖然目前一些企業中已經有明確員工行為的規程或操作手冊，但是由于無法做到細致的監督和管控，所以在真正的業務運行環境中，員工還是可以隨意調整操作步驟的，因為人們通常覺得只要自己最后交付的成果是有效的就可以，過程并沒有那么重要。但是很多生產問題恰恰是與操作順序有關的。

例如辦理“個人定期存款到期轉存”業務時，銀行柜員應該按照“先借后貸”的順序，先辦理個人定期存款到期銷戶業務，再辦理新開戶。如果柜員顛倒操作過程，一旦出現客戶遺忘密碼等不能正常取款的情況，就會產生銀行墊款等風險隱患。所以，利用RPA來固化員工的業務操作順序，也是一個重要的考慮因素。

另外，因為RPA的操作過程中不會出現任何人類常犯的一些錯誤，如敲錯鍵盤、選錯位置、點錯按鈕等，所以當同一邏輯、同一規則的RPA腳本執行完以后，處理結果都是相同的。如果對比上述例子中人工和自動化兩個處理過程，就會發現在RPA的處理環節中少了i和j步驟，而這兩個步驟就是我們通常所說的業務復核。業務復核是業務流程中最為常見的一種做法，其實就是希望復核人員能夠再一次檢查錄入人員的錄入結果，避免不必要的錯誤發生。甚至在一些特別重要的信息輸入環節，很多企業還采取了“兩錄一校”的處理方式，即雙人錄入、一人校驗的方式。但是我們可以發現，由于RPA執行帶來的一定是確定性結果，并不需要再用一個機器人來加以校驗，也就避免了復核環節。這項能力對于業務的效率提升以及人力成本的節省都是非常明顯的。

1.2.4　提供全程操作行為記錄

企業的管理者一直都希望能夠了解和獲取真實的業務運營情況，包括人員服務效率、事務周轉率、各項作業時間等，基于此來衡量企業內部的作業成本、服務效率等。目前在數字化轉型的趨勢下，大多數企業主要通過信息系統中的數據分析來獲取這些信息，但其中存在兩個制約因素。

第一，由于運營流程中通常會涉及多個系統，流程中相關的運營數據也就散落在各個系統中，而且由于數據標準和質量的問題，很難將這些數據完整地串接和拼裝成運營流程的全貌。

第二，即使拿到了系統中的數據，仍不能獲取業務人員辦理業務時真正的耗時情況，因為信息系統只能記錄業務人員提交業務信息，即點擊“提交”按鈕那一時刻的時間，而并不清楚業務人員是從什么時候開始辦理這項業務的，以及在各個環節中的耗時情況。

RPA替代人工完成了相應的操作，所以在自動化處理過程中也順便留下了所有的操作痕跡，即操作日志。通過這些日志信息，管理者可以了解某項業務是什么時間開始、結束或者中斷的，中間過程都與哪些信息系統或桌面軟件做了交互，操作了幾個軟件，每段操作的耗時如何，并可以反向推導出業務人員的勞動效率、不同人員之間的協作效率、流程是否遇到瓶頸等問題，同時也為企業的內控合規人員和內外部審計人員提供了數據支持。

1.2.5　為企業帶來流程優化和再造

從上面例子的一個細節對比中我們可以發現：在原來的人工流程中，員工A是提交這筆訂單后就去打印訂單，然后操作Excel表，發反饋郵件，最后寄快遞。順序是l→m→n→o。在機器人流程中，Bot-A是提交這筆訂單后即發送打印機，繼續操作完Excel表，發送反饋郵件；員工A再去取打印好的訂單，最后寄快遞。順序是l₁→m→n→l₂→o。

所以在Bot-A的處理過程中，并不是一味模仿人類的流程，而是在流程優化和再造的基礎上再來實現自動化。雖然例子中前后兩個流程之間的差別很細微，也是很小的一件事情，但從側面體現了RPA的特征，即原來流程中的某項任務可能會被重新拆解，分成機器人完成和人工兩部分，比如打印訂單這件事情，分解成機器人發送文件到打印機和人工取走打印文件兩個環節。

自動化流程中，還可以將某角色同類的操作進行歸并，減少不同主體之間的交互頻率和時間。例如，將員工A取打印文件和寄快遞這兩個操作一起完成，可以減少來回奔波的時間，優化一下，甚至可以讓快遞員自己取打印文件。Bot-A將它要做的功能一起做完，再反饋給人類員工，也減少了人與機器人的交互次數。

所以，一般RPA實施過程中都會伴隨著一定的流程優化和再造，并不是簡單地模仿原有流程來實現自動化處理。這既優化了效率提升，也扭轉了人們傳統思維方式。更加詳細的內容請參考6.6節。

1.2.6　符合人類的工作組織特征

這一特征主要由RPA軟件設計機制所決定。大多數RPA軟件都會提供一個基礎的技術運行平臺，該平臺支持所有的底層技術實現，如模擬操作、屏幕抓取等技術。RPA到底需要具體做什么樣的工作不是由平臺決定的，而是由運行于平臺之上的自動化腳本來決定，這些腳本定義了自動化流程的處理步驟、業務規則和異常控制等處理要求，由腳本在驅動平臺上進行技術實現。一套能連續執行的腳本被稱為一個自動化任務（Task）。一個獨立的小的運行平臺，也是操作系統中的一個進程，可被稱為一個機器人，也就是前面提到的Bot。

某個Bot在某個時點只能運行一個任務，就像人一樣，在一個特定的時刻只能做一件事情，但是當Bot完成這個任務后就可以繼續下一個任務，當然也可以一直循環做同一個任務，這其實是由這個任務所要處理的業務量和每筆處理耗時情況來決定的。所以，當有多項自動化任務的時候，通常需要為Bot配置工作日程表，如9點到10點做財務核算工作的5個任務，10點到11點做新員工入職流程的3個任務，總之在滿足業務流程的前提下，讓機器人做的事情越多越好，時間安排越緊湊越好。

另外，為了保證更大規模的自動化業務并發量，企業只利用一個機器人按順序執行任務是不夠的，需要同時擁有多個機器人，再分別為這些機器人配置好工作日程表。（它們的日程表可以相同，也可以不同）。除此之外，企業還需要讓不同的機器人在任務安排上做好銜接，不能產生業務上的沖突。這就如同你擁有了一支機器人軍隊。通過RPA監控管理平臺來監督這些機器人的執行情況，就如同機器人軍隊有了一個作戰指揮中心。

目前在一些大規模機器人應用的實踐案例中，這個作戰指揮中心被稱為“自動化指揮中心”（Automation Command Center）或者“自動化運營中心”（Automation Operation Center），而整個運營機器人的管理組織被稱為“卓越中心”（Center of Excellence，CoE）。詳細內容可參見5.8節和6.7節。如此解釋完之后，你是否覺得“機器人流程自動化”中“機器人”的叫法真的很貼切呢？

1.2.7　滿足24×7×365的不間斷執行

首先需要明確一個問題，雖然機器人的操作速度快，但也是需要處理時間的。如圖1-4所示，我們把人工操作信息系統的時間分成兩部分：第一部分是人工信息輸入或檢查操作用戶界面的時間（T1），第二部分是系統響應人工請求后的處理時間和信息反饋時間（T2），原來的總處理時間就是T1+T2，雖然通常T2遠遠小于T1，但也不能忽略不計。由于機器人鍵盤鼠標操作的迅捷性，主要節省的是T1，并不會影響T2。通常機器人的操作時間是人工操作時間的10%～20%，甚至更少，我們稱這個比例為η。實際上，機器人流程的處理時間是T1×η+T2。

圖1-4　RPA流程處理時間計算方法

如果不能100%達到自動化，還需要把T1分割成必須由人工執行的部分T1_m、其他可以由機器人替代的執行部分是（T1-T1_m）×η，以及額外多出來的人機協作時間T1_c，那么最終機器人流程的處理時間是（T1-T1_m）×η+T1_m+T1_c+T2。

雖然看起來機器人執行仍然需要時間，但好處是它可以不間斷地執行，達到每周7天、每天24小時、一年365天的持續無休，與人類員工每周5天、每天8小時的工作時間相比，相當于機器人的可工作時間比人類員工擴大了4.2倍（（24×7）/（8×5））。但需要注意的是，真實的運行情況并沒有那么樂觀，機器人的處理時間會受制于以下兩種情況。

第一，機器人的運行需依賴于所要操作的應用系統，那么應用系統的運行時間反過來就會影響機器人的可處理時間。因為企業中一些傳統的應用系統可能在晚間有停機休息的情況，那么機器人在這段時間里也就不能運行。如果機器人的處理流程中涉及多個應用系統的操作，那么機器人只能在那些應用系統同時運行的時間段運行。

第二，對于那些需要人工來配合執行的自動化流程，即有人值守機器人，其運行時間依賴于人的工作時間，人上班了，機器人才能上班，人下班了，機器人也就不得不下班。

總結一下，機器人的運行時間既依賴于系統又依賴于人，很難做到上面說的完全不間斷運行。

但值得慶幸的是，我們可以通過機器人運行機制的巧妙設計來實現其處理時間的最大化。

首先，可以安排那些無人值守的且不依賴于外部系統運行時間的自動化任務在晚間運行，例如在外部網站搜集一些資料，處理Excel和Word文件等。

其次，安排那些無人值守的但依賴于系統運行時間的自動化任務在人們下班之后、后端系統停機維護之前執行，比如自動生成報表、校驗業務信息等。

最后，安排那些既依賴于人工處理又依賴于系統運行時間的任務在日間人們的工作時間執行。

合理安排機器人的運行時間，就像是合理安排一名員工的工作時間，只不過機器人會比人類員工更聽從指揮。

1.2.8　提供非侵入式的系統表層集成方式

ERP或CRM這樣傳統的應用系統，如果出現了問題，通常需要通過修改接口或修改底層程序代碼、數據庫的方式完成系統改造，甚至直接替換原有系統。但這些大型的應用系統的功能非常復雜，中間經歷了多次升級，已經根深蒂固地深入企業的各個層面，這種方式的改造就會帶來巨大實施風險，不但是程序功能之間會相互影響，也會導致業務中斷這種高度破壞性的運營風險。所以一般IT部門在系統改造問題上都會持有謹慎的態度，而且時間越久、功能越復雜的系統，升級和改造的風險越大。

而RPA的實現方式是像人一樣通過操作應用系統的用戶界面來執行任務，既不需要更改應用系統的底層代碼，也不需要更改應用系統的服務或接口，而是通過這種非侵入式的集成方式或修補方式，使得RPA實施過程對原有系統的影響最小，帶來的風險最小。當RPA部署上線后，后端系統也不必中斷或停止，這是傳統系統上線切換后不太可能做到的。而且，RPA軟件提供了可視化的自動化流程設計工具，讓開發者只需要少量代碼甚至不需要代碼就可以編制自動化腳本，所以一些業務人員在培訓后也可以快速上手，而不必完全依賴專業的IT開發人員，這也是傳統系統難以做到的。

這種快速敏捷的特征也讓RPA項目的實施周期遠低于傳統的系統改造項目，所以有人將RPA比作醫用繃帶或者創可貼，繃帶的作用就是從外面牢固傷口，而不需要介入人的身體內部進行治療。雖然繃帶不能解決所有問題，但至少給我們提供了一種新的技術手段和方式。

1.2.9　支持本地和云端各種靈活的部署方式

相對來說，RPA的本地部署比較好理解，即RPA的執行機器人Bot和RPA的監控中心系統都部署在企業的內部網絡中，運行在企業自己提供和負責維護的服務器或PC上。而RPA的云端部署模式顯得更加復雜一些，與我們熟知的IaaS（基礎設施即服務）、PaaS（平臺即服務）、SaaS（軟件即服務）以及BaaS（業務即服務）這幾種云模式都不一樣，甚至可以采用RPA as a Service（RPAaaS）或Robot As a Service（RaaS）這些新名詞來重新定義RPA云服務模式。

現在的公有云經常為中小企業提供服務，RPAaaS也一樣。當一家企業不能負擔RPA的采購和運行維護成本時，可以采用云服務的租用模式來實現自動化。RPAaaS的方式有兩種。

第一，機器人部署在公有云端來為企業服務。由于RPA機器人替代員工操作時是需要訪問企業已有IT系統的，所以這種模式下首先需要解決如何從外部訪問企業內部系統的問題。當然VPN（虛擬專用網絡）是一種選擇，但是由于安全性問題，很多系統仍然不能通過VPN訪問，而必須采用遠程桌面的訪問方式，如Citrix。好在目前一些主流的領先的RPA工具已經實現Citrix的自動化處理。這樣，企業就不需要自己購買RPA軟件來實施RPA項目，完全可以租用云端RPA機器人的方式來為自己服務。這其實也是一種傳統業務外包服務（BPO）的變形。

第二，將機器人的管理和控制部署在公有云端來為企業服務。由于數據安全和訪問安全的問題，企業不愿意讓機器人部署在公有云上，那么可以讓RPA的運行機器人部署在企業內部的服務器上，而將RPA的監控中心部署在公有云上。機器人運行在企業內部保證了數據安全性，監控中心運行在公有云上則提供了RPA的管理、運行、監控和維護的便捷性。

在第二種方式下，企業除了需要購買機器人軟件外，沒有增加任何額外的工作量，因為機器人在企業內部自動運行，它們的控制和管理都由云端來提供。關于云原生RPA解決方案的詳細內容可以參考6.3節。