老焦專欄 | 用 RACI 模式梳理業務流程，提高業務釋出的效率

轉載本文需註明出處：微信公眾號EAWorld，違者必究。

最近經常在不同場合說，技術發展已經進入深水區。IT 技術發展已經越來越成熟了，尤其在金融行業，以前是解決從無到有的問題，現在該有的系統都有了，是解決進一步發展的問題。所謂深水區就是用原來單純技術突破的方式不行了。例如有些企業，早年用流程系統解決了無紙化辦公的問題，可下一個階段做什麼呢？

類似問題，在很多客戶那裡都存在，他們希望IT公司能幫助他們面向未來，找到新的發展方向。但是，由於他們自身已經進入深水區，近年來湧現的很多技術，對他們的幫助並不是很直接，很難像當年一樣，某項技術能立竿見影解決問題了。這裡我來比較一下：當年，使用關聯式資料庫立刻解決了大規模資料儲存問題，別的不用想，研究好Oracle/DB2/Sybase/Informix就夠了，而現在懂 Hadoop 的體系結構不夠，你要知道客戶的資料在哪裡、業務如何優化，如何支援決策，這些連客戶自己也說不清；再如，當年使用應用伺服器立刻解決了C/S架構客戶端難以維護的問題，業務可以更好的通過網際網路釋出了，價值清晰可見，但現在微服務/分散式的一系列技術，都是希望用來解決高併發、易維護的問題，做起來卻不是立竿見影產生效果的，一來很多模式需要仔細推敲、設計（比如應用如何拆分等等，設計不好起不到效果），對人的要求高；二來做了類似良好設計後會發現，原來的技術也是可以做到的，用了新的技術好在哪裡。

究其原因，進入深水區後，這些問題會變得離散化、隱形化，解決起來不再立竿見影，而是牽一髮動全身、進退兩難。在我看來，雖然問題更復雜了，但 IT 提高業務效能、適應業務靈活變化、提供決策依據、提高開發效率、提高軟體質量、提高發布效率這些要求並沒有變，這就需要我們更加深入分析問題，提高對業務的抽象能力，從問題中抽象出解決方案。我寫的一些東西也都是類似的一些抽象，希望能從業務中抽象出若干模式，用這些模式解決深水區遇到的問題。

舉一個流程業務抽象模式的例子，希望能夠縮短流程類業務的上線週期。金融業務多是以流程為表現形式，以往我們對流程的設計就是一個接一個環節，順序執行下去，這種方式更多是技術語言、編碼方式，業務和技術的溝通成本很高，資訊傳遞上經常有缺失，導致流程上線效率不高。

RACI，就是在流程應用中抽象出的業務模式。這個詞學過 PMP 的同學都知道，是用來明確組織過程中各個角色及其相關責任的方法，其中：

• 誰負責（R = Responsible）,即負責執行任務的角色，他/她具體負責操控專案、解決問題。

• 誰批准（A = Accountable）,即對任務負全責的角色，只有經他/她同意或簽署之後，專案才能得以進行。

• 諮詢誰（C = Consulted）,擁有完成專案所需的資訊或能力的人員。

• 通知誰 (I =Informed),即擁有特權、應及時被通知結果的人員，卻不必向他/她諮詢、徵求意見。

看一個請假流程，這個流程中 R 可以當作提交申請單的人，各級審批就是 A，行政部門就是 I，C這個型別有點不好理解，其實就是能夠幫助 R、A 完成工作的人，例如審批的時候我可以諮詢一下人事部門某人。

在這一個操作流程中，分清楚R、A、C、I，就可以用一個表格來表示流程，而這個表格是可以生成一個技術上的流程定義：

上述流程，用一張表就可以表述出來，這種方式更容易與業務方進行溝通。如果我們分析一下目前企業的操作流程會發現，絕大多數可以用 RACI 表格模式體現出來，如果是這樣，我們以後可以不再畫上面那樣技術的流程，直接用這種表格方式與使用者溝通需求。

這樣做的好處是：

1. 在大型企業中，這樣的方式業務更容易理解，因為崗位職責清晰，便於確定需求、優化流程、方便審計。本來大企業的流程管理就是用類似的思維在考慮問題，尤其是審計/風控部門，他們就是關注 RACI 和條件的，更加一目瞭然，溝通需求的時間會大大縮短，可以想象一下，把所有流程都寫成 Excel 進行討論、審批，而不是用一張張流程圖，效率會有多高，想達到每天一支甚至多支流程，就是要用這種流程集中梳理討論的方式；

2. 這個表格可以生成技術流程的定義，而不是程式設計師再畫，這樣就可以把一些處理模式固化到翻譯的流程中，提高適應變化的能力。例如上圖中，行政部門歸檔是 I，歸檔方式可能是資料庫插一條記錄，也可能是郵件通知，這都是可以變成 I 處理的固定模式。

RACI這種方式就是我說的業務抽象，把流程的開發與流程的梳理緊密結合起來，提高業務釋出的效率。當然，提高業務釋出效率的手段還有很多，我會陸續分享。

我用這個示例來解釋深水區，未來遇到的問題，往往不夠明確、直接，需要根據業務進行抽象，轉換為簡化的技術實現手段，而不是說直接根據業務需求翻譯成技術實現。如果從單純技術編碼的角度看，這種方式漏洞百出，但從業務視角看，他卻是豐滿的，所以最後要說一下，實在不能滿足的情況，我們還有編碼這樣一個退路，不要求全責備。

關於作者：焦烈焱，普元資訊CTO，致力於技術創新和金融創新解決方案研究。專注於企業技術架構領域，對分散式環境的企業計算、 企業資訊架構的規劃與實踐有著豐厚經驗，帶領普元技術團隊相繼在雲端計算、大資料及移動開發領域取得多項突破，並主持中國工商銀行、中國建設銀行等多家大型企業技術平臺的規劃與研發。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562043/viewspace-2645459/，如需轉載，請註明出處，否則將追究法律責任。