RPA機器人流程自動化 — ROM-Part 2
此篇我們將繼續介紹BP ROM的運作基礎:
治理與傳遞管道(Governance and pipeline), 交付方式(Delivery Methodology), 服務模式(Service Model), 人員(People), 技術(Technology)。
治理與傳遞途徑
在此一ROM運作基礎中分為兩個部分。第一個是流程探索(Process discovery)，流程探索方法可幫助我們建立一致且穩健的流程機會(processes opportunity)管道。 這一過程中我們會學到如何確定自動化流程的優先順序，並確保我們獲得最大的業務效益。
第二部分是治理(governance)與控制(controls)，主要是確保安全與合規的機器人運作。
流程探索(Process discovery)
其主要工作是評估組織內所有的流程，而組織的每一個業務流程都是組織的資產。所以選擇最適合(能得到最大的業務效益)的流程優先自動化，並且建立穩健的自動化流程管道(pipeline)。
哪甚麼是流程管道(pipeline)呢?
其實就是流程資產管理，它像一個管道(水管)控制著可以被自動化的業務流程(見下圖-流程探索管道)。流程資產管理可以被視為建立RPA基礎，以實現組織每個業務流程可能自動化的機會的有效程序或組合管理。 它也是可以完成業務流程評估報告的平台，以確保我們的自動化程序的價值傳遞到組織的業務(business)。更多詳情可以參閱BP的 Managing pipeline。
流程探索是一種用於客觀的識別、分析、限定、優先排序和調度自動化業務流程構建的方法。這些過程在形成需求管道(pipeline)的流程資產中被記錄和追蹤。BP 的ROM 主張組織必須定義流程探索方式。
流程探索在整個ROM中扮演重要的角色，因為它關乎到組織在實行RPA的過程中:
- 減少流程探索花費的代價(例如:參與的人力)
- 加速自動化流程上線的時間
- 流程探索的標準可以擴及到整個組織
- 持續性的ROI
進行流程探索的常見陷阱
我們在維護我們的機會管道(pipeline)時需要注意可能會遇到以下陷阱:
- 沒有足夠的機會管道。也就是目前的業務流程自動化的可能性或效益不高。
- 該流程還沒準備好或不適合自動化
- 該業務流程在流程探索的後已經變動，自動化已變得效益不高
- 探索階段就造成的業務執行中的瓶頸(bottleneck)
流程探索框架
為了克服上面提及到常見的流程探索陷阱，我們需要一個框架來克服這些問題。
要為我們的管道創造組織各業務流程自動化的可能，重要的是確定目標範圍、限定潛在業務流程自動化的機會並確定何時交付這些機會的優先順序。 流程探索框架分為三個關鍵階段：流程分類(Process Triage)、流程評估(Process Assessment)和流程分析(Process Analysis)。(如下圖)
其核心原則是:
- 儘早帶入良好的治理(governance)是將風險探索方式一致性的關鍵，並將幫助我們降低 RPA 專案中的風險
- 管理可能被自動化流程的機會表列可以查看正在過濾的業務流程內容來接受、拒絕或暫停該業務流程是否自動化
- 良好管理的管道(pipeline)允許定義和管理計畫時間表，因此過程不會出現瓶頸
- 應該強調在自動化之前需要一些改進該業務流程作業的機會，從而在設計階段之前留出更多時間
流程探索框架階段一: 流程分類(Process Triage)
- 對組織進行 RPA的教育，並強調自動化的能力
- 確定適合自動化的潛在候選業務流程
- 自下而上的方法 — 辦研討會、展示簡易的自動化流程等
- 自上而下的方法 — — 讓高階管理者參與、部門熱圖等
- 有潛力的候選業務流程將向前推進以進行進一步評估
流程探索框架階段二:流程評估(Process Assessment)
- 對候選業務流程進行詳細的審核，通常是通過與該業務流程的SME(Subject Matter Expertise)進行討論
- 紀錄該業務流程過程的複雜性、頻率和數量
- 考量該業務流程自動化的潛力、是否易於實施、機會收益和評估會使用到的應用程式
最後決定是否要將該業務流程進入到下一個階段
流程探索框架階段三:流程分析(Process Analysis)
- 與該業務流程 SME 合作，進一步深入分析流程，確定流程自動化的優先級別，並確保沒有潛在的阻礙因素
- 提交文件提交治理委員會（如果有的話）批准
- 將流程分析的結果提交給治理委員會或 RPA 負責人（如果不存在董事會）以供最終核准
而流程分析可用的工具有: 衝擊分析範本，BP的 流程探索工具，初始分析(IPA- initial Process analysis)範本。
治理(governance)與控制(controls)
RPA的治理是為了創造一個可控，安全與容易管理的機器人勞動力環境。而這樣的環境可以為我們在組織內的整個RPA生態系除了兼顧安全之外還能具有大規模運作與可靠的機器人勞動力運作。
主要重點在於
治理:
如何通過引入治理委員會來治理和控制自動化與必須採取的控制措施以確保自動化按預期運行。有兩個關鍵角色有助於推動 ROM 的標準化、最佳實踐和治理。一個是治理委員會，另一個是設計單位。
安全:
BP的軟體與主要元件是如何被存取的。
重要的資料如何被保護。
BP平台提供的通訊與驗證的方式。
變更管理:
當自動化流程開始運作時，如果要開始做流程異動如何將衝擊減到最小。
治理委員會
治理委員會的主要任務是為組織的RPA制定策略，並依據該策略交付RPA。委員會將由組織內RPA的最高負責人與IT和業務部門代表所組成。委員會將會優先考量組織內自動化流程的需求來討論。詳情可查看這裡。而委員會的主要責任如下圖所示
治理委員會主委的責任
主委的責任是確保所有的RPA治理都能夠被實施，並確保所有的控制(control)也能被實行，例如資料處理政策(能夠被記錄，歸檔，備份等)。
主委通過實施交付標準和設計機構來確保整個RPA交付生命週期的政策和治理得到執行，同時也能實行對機器人員工的控制。
資訊安全
資安應該被內化在組織的流程與政策中，為了保護整個BP的RPA平台是安全。而定義資訊安全政策的關鍵是"確保主要風險已經獲得某種程度的控制，並且達到組織可接受的標準"。而BP為此定義了四種存取模型(Access Model)，分別對應不同的標地。詳情如下圖，而有關於更多的BP資訊安全方面的訊息可參考此文件。
變更管理
在自動化中，對變更是很免感的故變更管理也是非常重要的一環。若變更管理沒有做好可能會對組織的營運產生衝擊，以下兩個方面若沒有做好變更管理，風險與影響就可能產生:
業務面的變更
- 不正確的業務決策
- 潛在的營收損失
- 潛在的組織名聲損失
- 潛在的客戶流失
IT面的變更
- 機器人會罷工
- 機器人會不按程序亂操作目標程式
- 會有一大堆的錯誤需要人類員工來修正
- 會讓組織對其客戶的SLA(Service Level Agreement)不達標
為了將變更的衝擊與風險降至最低，強大的變更管理流程必需存在。當在執行變更管理時下圖的四個考量點都需要被考慮進去。
- 優先順序(prioritization)
- 時間表(schedule)
- 衝擊分析(impact assessment)
- RPA治理委員會(RPA Governance board)
而我們在上圖中看到變更有主動式與回應式的。主動式的通常為組織的各單位有RPA的需求產生，主動式變更通常通要循正常的需求管道。而回應式通常是該自動化流程已經存在，而是因為業務流程有異動或相關的IT系統有異動才會有變更。
而我們在主動式變更的考量點會有以下表列，以確保這些變更的風險達到最小
- RPA控制中心分類其流程，而流程控制人員會根據操作手冊調查流程故障
- 每個自動化流程的 RPA都會有其事件(incident)管理流程和業務持續方法(也就是BCP/BPM)
- 用於管理 RPA 特定事件的專用資源
- 專門的“失敗修復”團隊，負責處理低工作量的錯誤修復和失效
- 需要有應用程式異動運作狀況的檢查流程
- 積極參與變更討論會議
最後在RPA治理中，控制(control)除了我們提到的安全性之外我們尚有需多方面需要納入考量。例如
交付方式(Delivery Methodology)
主要定義組織對RPA最佳的交付方式並且將此交付方式寫在組織的政策中。這樣在實行RPA時就能達到以結構化、可控和可重複的方式快速與具有效能的自動化。在這一個基礎中，我們可以建立可重複使用，具彈性與大規模性的 RPA資產。這些特性可以減少我們交付的工作量與具有長期價值的服務。
BP的RPA交付方式其實與一般組織的軟體交付方式非常相似。基本上會有六個階段: 定義(Define)，設計(Design)，建置(Build)，測試(Test)，用戶驗收測試(UAT)，佈署(Deploy)。
定義(Define)
- 了解此業務流程的手動方式(由人類員工操作)是如何運作與組織裡的那些業務會參與到此流程
- 詳細記錄這些手動作業流程以此來訓練機器人，這類文件在BP稱為PDD(Process Definition Document)
- 要有完整的FRQ(Functional Requirement Questionnaire)來獲取到整個流程中的關鍵細節(例如該流程是要能夠判斷某些狀況)
- 與該流程的SME來詳細審核PDD與FRQ
設計(Design)
這個階段最重要的是了解如何設計才能達到業務的需求，認知並核准提議的自動化可能會改變整個企業的營運方式。向整個組織清楚地解釋該自動化流程和手動流程之間的任何差異，因為它不一定是精確的複製品。
第二個目的是計畫如何的建置與交付RPA的解決方案。隨著時間的推移，越來越多的RPA流程上線代表著越來越多的元件可以被重複利用。流程設計師將能夠找到這些能重複被使用元件的優勢。這個階段的要點為
- 記錄所建議的解決方案設計的 SDD(Solution Design Document)並且完成它
- 與該業務流程 的SME 一起演練新設計以確認方式的變更
- 與業務單位確認設計的協議和核准
建置(Build)與測試(test)
在這兩個階段BP的開發人員在開發過程中的的主要精神就是: “儘早測試並經常測試”。每一個元件(越標準越好，且不要有太多步驟)的精神是: "快速失敗"，以免當把所有元件組合在一起成為整個業務流程時除錯會耗時耗力，這樣就能減少這種耗時耗力的風險。在這個階段應該注意的事項為:
- 在組合之前檢查流程中的每個部分 — 這很重要，因為把沒測試過的元件組裝上去到整個流程在除錯上會很困難
- "快速失敗"以降低整個流程的不同部分無法作為一個整體結合在一起的風險
- 在控制中心進行測試，以證明元件或流程在全速的在流程圖表中作業的
- 以生產線交付方式與發展成為更工業化的集體性的集體合作
用戶驗收測試(UAT)
此階段有三個重點:
- 整個業務流程不是只有BP的軟體與平台來完成。
整個流程所涉及到的操作程式(例如SAP GUI)，機器人所運行的作業系統(跑在甚麼樣的電腦)，會看到的資料，業務邏輯規則等等。這些都是整個RPA自動化流程中的一部分，而這些也都需要被測試。這些涉及到的相關元件如果在開發/測試/正式環境中若有不一致，一定需要被釐清與計畫如何應對。 - 目標是讓機器人員工操作實際的程式
整個業務流程的所有元件應該使用真實的資料。機器人員工不是被用來測試在一些開發中的程式，應該在真實的環境中來測試。需要就控制引入實時數據的測試策略達成一致 - UAT必須由業務單位來進行而不是交付團隊
在定義和設計階段，業務單位必須準備驗收計劃，以證明該自動化解決方案滿足要求和一開始協議好的範圍
佈署(Deploy)
最後就是進入到佈署階段，在這一過程需要注意的有:
- 打包並發布自動化流程解決方案，以及如何將其部署到生產環境中的說明
- 創建有關如何在 BAU 操作中運行解決方案的說明 —就是 操作手冊
- 開發強健的服務模型 — — 運行 BAU 應該被視為提供給業務單位的服務
設計單位(Design Authority)
流程設計單位的主要目標是指導RPA的交付團隊，就解決方案設計應如何考慮安全和風險管理、交付方法、測試方法、實施策略、BAU 運營和維護等方面提出建議。 流程設計單位可以且應該參與整個交付週期。
理想中的設計單位應該要參與整個交付週期，並且確認隨著團隊的成熟能夠加強其標準化作業。最初該角色可以由獨立專家執行，但隨著 CoE 的發展，設計單位的職責應由一群 RPA 專家分擔。
而設計單位的主要責任為:
- 主持定期會議以支援交付實施計劃
- 審查所有設計和後續開發，以確保滿足組織設定的標準和最佳實踐還有BP所推薦的標準和最佳實踐
- 維護所有的RPA資訊，並為交付團隊提供存取權限並建議如何使用這些資訊
