企業發展初期，會制定一堆制度，來規范企業管理，然而更多是獎勵和懲罰的作用，不能提升管理和業務效率，這時便需要搭建企業流程中心。那么，如何搭建呢？本文作者對此進行了分析，一起來看一下吧。
企業發展初期，會制定一堆制度，用來規范企業管理，但制度更多是獎勵和懲罰的作用，并不能提升管理和業務效率。
比如，我們開車走高速的時候，超速會扣分、會罰款，這是交通局制定的制度，但用戶開車的時候還是會不經意超速，不能很好地解決問題；而流程則是規范用戶行為，能指導用戶把事情做對做好，比如前面說的超速，地圖軟件就是流程的應用，通過地圖軟件全程的指引，用戶開車時就很清楚地知道什么時候該減速，從而降低了很多超速的行為。
一個成熟的企業，員工是不需要了解制度的，企業通過各種流程和工具把制度落地，潛移默化中規范了員工行為和管理，而且員工體驗更好。
既然流程這么重要，但很多企業在信息化建設初期，為快速滿足業務需求，各自都會為某一項業務搭建一套流程，從而產生了很多系統和流程，各流程之間是斷層的，數據之間沒有打通，需要人工線下再整理和匯總，這種流程并不連貫，這時候就需要搭建一個企業級的流程中心。
流程中心作為一種與業務較為獨立的系統，應做到以下三點：
1）開發成本
最大程度的與業務系統的解耦，最大程度減少開發資源的浪費與重復造輪子的問題，方便業務系統快速接入，并提供不同的接入方案。
2）整合性
流程中心需建立統一待辦、統一發起、統一后臺管理，方便員工集中處理流程、提升用戶審批與流程處理的效率。同時，流程中心需要與人力資源系統、用戶中心、消息中心、主數據平臺、財務系統等整合，流程可快速實現上下游對接，如審批時需要使用人力系統的員工、匯報關系等，訂單業務流轉完成后最終需寫入財務系統等，需實現業財一體化。
3）擴展性
流程中心屬于企業公共服務產品，所有業務系統都可接入，每個系統又可以獨立進行管理；流程中心同時需要具備極強的橫向擴展性，如增加一項審批操作駁回、抄送等，版本升級后所有接入的系統都可升級，同時又可兼容舊版本。例如流程引擎版本升級，為了不影響核心業務系統流程，先灰度在內部獨立的系統上應用，待運行穩定后業務系統再升級。
這里需要說明一下，目前大部分企業流程中心的定位只是OA的審批流，這個與BPM還是有很大區別，BPM核心解決的是業務流程打通，確保數據的閉環。比如AlphaFlow BPM。
流程中心包括三大核心：流程引擎、流程管理和流程應用。
整個產品框架如下：
1. 流程引擎
目前比較成熟用得比較多的流程引擎是：AlphaFlow、Activiti、Flowable、flowable實際是activiti的升級版，是同一個架構師。
需要注意的是大部分BPM系統流程引擎和表單引擎是一個整體的（如AlphaFlow、釘釘、飛書等），但我覺得這種完全整合并不太好，因為大部分業務系統都有自己的表單，交互也比較復雜，靠表單引擎搭建并不能滿足業務需求，交互體驗也比較差；所以我建議表單引擎只是作為流程中心的補充，流程中心也可以接其他系統的表單。
業務系統接入流程中心時，復用待辦中心、審批消息、審批操作、審批意見、流程分析等，但表單內容與數據流轉仍由業務系統實現，流程中心將審批結果回傳給業務系統。
2. 流程管理
流程管理是流程中心產品設計最復雜的部分，流程管理員可以流程進行分類、繪制流程圖、對流程進行測試和監控等，產品設計時有以下幾個點需要考慮：
1）流程分類和編碼需統一規劃
企業發展到一定規模后，會有幾十甚至幾百個流程，這時候就需要對流程進行分類，方便員工查找，很多企業在流程分類上比較隨意，比如有的創建分類為人力行政類與考勤類，運營類與業務類等，這種會導致員工在發起申請時就已經很迷茫，找不到對應的流程，且容易申請錯誤。
所以我們在流程分類一定要認真思考，就像知識庫一樣，要分類簡單清晰（這里建議大家看一下流程分層相關的書籍，根據價值鏈分析，對流程進行分層管理）；另外，分類最好是有人統一管理。
同時，流程的編碼也一定要統一規劃，流程編碼決定了流程單號，單號是唯一的，如果編碼不規范，就會導致產生重復的流程單號，對上下游單據都會產生較大影響；這里建議有些流程編碼的行業縮寫一定不要更改，比如PO是指 Purchase Order 采購訂單。
2）流程需要版本管理
流程需求不斷調整和優化，每次調整就會產生新的版本。發布新版本后，已經運行中的流程仍然用舊版本，新發起的流程才使用新版本，這樣可以保證運行中的流程不容易出錯，能正常流轉。
3）流程的權限要靈活
流程權限包括后臺管理權限、用戶發起權限等。有些企業不同部門是不同的流程管理員，所以需要根據流程設置管理員，流程管理員只能管理他負責的流程，包括進行流程發布、節點配置、流程監控、統計分析等。流程發起權限應用的場景很多，需要與人力資源系統或業務系統打通，如指定部門、指定職位、指定角色、指定員工、指定職級等。
比如，我所負責的流程發起權限包括如下：
4）對接不同系統需要有補償機制
前面講到BPM與OA最大的區別就是BPM解決的是業務流程閉環，OA解決的是審批流；BPM在與各業務系統對接時，需要調用不同的服務，為了確保流程正常流轉和體驗，有些服務會采用異步方式，同時還要考慮流程駁回、干預、拒絕等場景，同一流程單號需要確保每次調用業務系統可靠、準確且不重復，出現異常需要有補償機制。
5）要有流程測試功能
流程調整后管理員和業務方都希望能自動測試和驗證，避免發布后出現問題，所以需要能模擬自動測試的功能，這個大部分流程平臺都沒有該功能。自動測試需要把流程中使用的條件和變量根據不同業務場景填寫相關值，然后開始自動測試，看流程是否能正常流轉，所有場景測試通過后就才可以發布該流程。
3. 流程應用
流程應用時一定要建立統一待辦中心，并統一大家對審批操作的認知，很多系統原來就有自己的待辦或者已經定義好的操作按鈕，已經先入為主占領用戶的一些的認知，這時候統一會有一些難度，但可以從整體流程效率和產品體驗上可以慢慢培養，讓用戶一步步接受。
這還有個前提，操作按鈕的定義一定要與各部門流程管理員一起先共識。我在推動建立流程中心時，公司曾使用云之家、K3 Cloud、飛書審批以及自研審批等，每個系統都有各自的一些定義和特殊操作，為統一操作花了不少時間。
以下是我這邊最終共識操作按鈕定義：
【撤回】：提交或審批后，撤回重新操作，如果下一步審批人已審批不能撤回
【撤銷】：撤銷申請，流程終止
【催辦】：對當前節點未審批的人員發送催辦消息，每個流程實例每天每人只能催辦一次
【復制】：復制流程申請表單，單號不復制
【評論】：對流程進行評論，可在不同審批意見節點評論
【打印】：對表單按定義的打印格式進行打印
【保存】：流程發起時暫存表單
【同意】：審批通過，流程往下流轉
【確認】：對表單內容確認，會彈窗對內容進行二次確認，確認后流程往下流轉
【拒絕】：審批不通過，流程終止
【駁回】：流程駁回給發起人，提交后回到當前審批節點
【退回】：包含退回上一步和退回發起人兩種選擇，退回發起人流程退回申請節點，提交后重新走審批流程
【轉交】：將流程轉交他人審批
【加簽】：前加簽，加簽他人審批后回到當前審批節點
【抄送】：將流程抄送給他人，抄送人僅查看
這里我只是對流程中心整體產品框架做了介紹，后續還會發布具體產品功能的設計，我之所以想寫出來，主要發現流程平臺大部分是技術分享，產品分享的很少，因為這個還是太偏向于技術底層。
版權聲明：本文章文字內容來自第三方投稿，版權歸原始作者所有。本網站不擁有其版權，也不承擔文字內容、信息或資料帶來的版權歸屬問題或爭議。如有侵權，請聯系contact@econage.com，本網站有權在核實確屬侵權后，予以刪除文章。
