老焦專欄 | 用 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 表格模式體現出來，若是是這樣，咱們之後能夠再也不畫上面那樣技術的流程，直接用這種表格方式與用戶溝通需求。

這樣作的好處是：

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

這個表格能夠生成技術流程的定義，而不是程序員再畫，這樣就能夠把一些處理模式固化到翻譯的流程中，提升適應變化的能力。例如上圖中，行政部門歸檔是 I，歸檔方式多是數據庫插一條記錄，也多是郵件通知，這都是能夠變成 I 處理的固定模式。

RACI這種方式就是我說的業務抽象，把流程的開發與流程的梳理緊密結合起來，提升業務發佈的效率。固然，提升業務發佈效率的手段還有不少，我會陸續分享。

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


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


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！