審批流

1. 3 秒看懂

審批流是把組織內的“誰、在什麼條件下、按什麼順序、用多長時限”來批准或駁回一項業務申請這一整套決策過程，固化為可追溯、可回退、可審計的數字流程。它的表面是表單和按鈕，底層是狀態機、權限快照、事件驅動和事務補償的精密組合。一句話：審批流就是數字化之後的責任鏈與決策路徑。

2. 3 分鐘產業解釋

每個打工人都用過的請假、報銷、合同蓋章、採購申請，背後都跑著一條審批流。和隨口一句話的“行不行”完全不一樣，審批流必須嚴格遵從組織權限和業務規則：

1. 表單承載資料（請假天數、報銷金額）觸發流程引擎。
2. 流程引擎解析模型（BPMN 圖或狀態機定義），找到當前應該停在哪個節點、誰該審批。
3. 按照規則匹配審批人（部門負責人、財務總監，可能是靜態指定，也可能是即時計算組織樹），生成待辦任務。
4. 審批人操作（同意、駁回、加簽、轉辦、委託、前加簽/後加籤），引擎記錄操作日誌並移動流程節點。
5. 所有強制節點通過後流程結束，回撥業務系統（更新訂單狀態、放款、記賬）。

在產業一側，審批流早已不是 OA 裡的一個獨立模組，而是低程式碼平台、PaaS/SaaS、RPA、BPMS（業務流程管理套件）的核心級能力。企業選型時不再只看“能不能批”，而是更關心：流轉有多靈活（會籤、或籤、動態加簽）、能否嵌入已有系統、高併發下狀態是否一致、跨組織審批時法律證據鏈是否完整。

3. 技術原理

審批流本質是一套基於有向圖模型的分散式狀態編排系統，其執行時由三層核心元件協同：

• 流程定義模型：描述節點、連線、閘道器、定時事件的靜態後設資料，常用 BPMN 2.0 XML 表達。
• 流程例項執行時：每張業務單據建立一個例項，持有當前節點指標、上下文變數（表單資料快照）、審批歷史棧和流程版本號。
• 任務管理服務：生成任務、推送待辦中心、校驗操作權限、記錄操作日誌、更新例項狀態並觸發後續節點。

執行機制（簡化示例）

 發起人提交
     │
     ▼
 入口閘道器（條件分支）
     │
     ├─[金額 ≤ 5 萬]──► 部門經理審批 ──[通過]──► 例項狀態=完成
     │                                 ──[駁回]──► 例項狀態=已駁回（可配置回退節點）
     │
     └─[金額 > 5 萬]──► 部門經理審批 ──[通過]──► 財務總監審批（會籤，需 ≥2 人通過）
                                                    │
                                              [全部通過]──► 完成
                                          [任一駁回]──► 已駁回

真正的複雜性藏在幾個常被忽略的層次裡。

狀態機層 每個例項的狀態必須嚴格一致且可回溯。典型狀態模型包含：未提交、審批中、已通過、已駁回、已撤回、已終止。複雜場景還有子流程掛起、超時自動流轉、管理員強制干預（例項跳轉）等狀態，這些都要求引擎能妥善處理狀態遷移的合法性，避免出現“既通過又被駁回”的矛盾。

閘道器與分支求值 條件表示式（如 amount > 100000 AND costCenter == "研發"）通常使用 FEEL、SpEL 或自定義指令碼語言在執行期動態解析表單欄位與上下文變數。這一步既要保證執行效率，又必須防範注入風險，因此企業級引擎多采用受限語法或解析器沙箱。

上下文與權限層 審批人在不同節點看見的資料檢視並不相同——某些欄位需要脫敏、隱藏或只讀。操作權限（同意、駁回、僅加簽、僅填寫意見）也需要動態計算，通常由表單引擎與權限服務協同完成，而非硬編碼在流程定義中。

時間與事件層 定時邊界事件（如 24 小時未審批自動升級給上級）、條件事件（金額 >10 萬自動觸發合規審查節點）依賴流程引擎支援事件子流程與定時器，並能在分散式環境下準確觸發，不丟失、不重複。

整合與 Saga（長事務補償） 審批通過後往往還需要呼叫支付、庫存、CRM 等多個外部系統。如果“審批已通過”但後續外部呼叫失敗，就會出現業務不一致。成熟的審批流方案必須引入補償機制（Saga 模式），例如記錄失敗任務，逆向呼叫已執行的外部操作，或將流程掛起到人工干預佇列。

高併發一致性 兩人同時審批同一節點、管理員強制干預與正常審批並行、流程版本熱更新（升級定義但不影響已執行例項），這些都需要謹慎的併發控制。常用手段是例項版本號樂觀鎖，或基於 actor/cell 模型將同一例項的所有操作路由到單執行緒執行，從而避免分散式鎖的開銷。企業級引擎還需支援組織架構即時變動時的審批人快照一致性——審批啟動時是按當時的組織關係凍結審批人，還是每次都即時計算？不同策略對業務影響極大，必須在設計上明確。

理解這些之後，才能明白為什麼審批流不是“填個表單、打個勾”這麼簡單。它是以有向圖、狀態機、事件和時間為核心，把人的決策過程變成可程式設計、可追蹤、可補償的系統。

4. 關鍵引數

以下引數衡量審批流引擎是否達到企業級水準，數字標記“公開資料未見”表示該指標因高度依賴部署環境而未形成行業統一基準，具體應結合廠商效能測試報告判斷。

• 流程定義複雜度上限：最大節點數、閘道器巢狀深度、迴圈巢狀層數。企業級引擎通常支援單圖數千節點而不出現解析劣化；公開資料未見統一上限標準。
• 吞吐量：引擎每秒可推進的流程例項狀態遷移數。在事件驅動或 actor 模型實現下，單節點可達數千 TPS（來源：Camunda 等開源引擎基準測試，具體數值隨版本和硬體變化，建議查閱官方基準）。
• 端到端響應延遲：從審批人提交決策到例項狀態持久化、下一節點任務生成的總耗時。核心受狀態持久化寫操作（資料庫或事件日誌）延遲影響，通常要求 P99 < 200 ms（企業內部參考值，公開行業標準未檢索）。
• 任務簽收與操作冪等性：審批操作必須支援冪等，網路重試不會導致重複審批或流程跳變。此指標用異常率衡量，目標應接近 0。
• 流程版本線上熱更新相容率：升級定義後，執行中例項平滑遷移（不丟失、不重複節點）的百分比。企業場景要求達到 100%，否則需停機遷移，但公開資料未見各廠商實測資料。
• 組織快照一致性：流程啟動時審批人鏈路的凍結方式（快照/即時計算）以及變更後對執行中例項的影響範圍。無通用量化指標，但直接決定跨組織變動時的穩定性。
• 資源爭用和執行緒池飽和度：樂觀鎖衝突重試次數、執行緒池排隊長度等，反映併發瓶頸。需由運維側結合業務量監控。

5. 技術路線

審批流的技術實現路線並非單一路徑，實際產品常是多種路線的組合。下表對不同路線進行定性對比。

維度	狀態機驅動審批	工作流引擎(BPMN)驅動審批	低程式碼/無程式碼審批平台	智慧審批(規則+ML)
靈活性與表達能力	★★（硬編碼狀態轉換）	★★★★（支援泳道、邊界事件、補償事務）	★★★★★（視覺化編排，即時生效，業務人員可用）	★★★★（規則+模型混合編排，適合風險分級）
實施成本	★★（開發量大，邏輯深嵌程式碼）	★★★（需整合開發，理解 BPMN）	★（業務使用者可配置，但複雜場景仍有瓶頸）	★★★（資料標註、模型訓練、規則維護成本高）
複雜場景支援	簡單串/並行，動態分支能力弱	並行、分支、異常邊界、子流程、補償 Saga	通常受平台封裝上限限制，部分弱於純 BPMS	善於風險分級與自動決策，不擅長複雜人工協作模式
效能吞吐（同等資源）	高，純狀態機開銷極低	中高，模型解析與事件處理有開銷	中，受多租戶與平台中間層影響	中，模型推論增加不可忽略的延遲
可審計性	好（可自建日誌）	極好（審計日誌與歷史棧完備）	好（平台通常自帶審計能力，但深度可調性有限）	需額外記錄模型決策理由（XAI）
典型產品/引擎	自研業務狀態機（如交易系統的訂單狀態流轉）	Camunda、Flowable、Activiti	釘釘審批、飛書審批、企業微信審批、ServiceNow Flow Designer	結合評分卡的自主控制台，或金融反欺詐中的自動審批

注：★ 為定性評等，5★最高；各產品能力可能因版本迭代快速變化。部分路線在實踐中常以混合形式出現，比如低程式碼平台底層嵌入 BPMN 引擎，或智慧審批疊加在狀態機之上。

6. 上游

審批流的上游決定了它“能不能把任務發給對的人、看到對的資料、用對的條件分支”。任何一個上游環節的延遲或資料錯誤都會直接導致流程下發的錯誤。

• 組織架構與身份認證服務：通常對接 LDAP / AD / HR 系統，為流程提供部門樹、崗位、彙報關係。這是動態審批人計算的基礎，服務不可用將導致所有流程無法生成任務。
• 動態表單渲染引擎：提供審批時看到的資料檢視、欄位權限（可見/不可見/可編輯）、前端校驗規則。表單與流程的深度繫結使得兩者常為同一平台基礎設施。
• 規則引擎：決策表、Drools 或 FEEL 規則，用於條件分支求值與自動決策。複雜閘道器需要規則引擎快速解析，部分場景會獨立部署規則服務。
• 訊息佇列/事件匯流排：審批流轉過程中產生大量事件（任務生成、審批提交、流程完成），用於非同步通知下游，避免同步耦合。佇列堆積或丟失會直接影響即時性。
• 企業快取/快照服務：為隔離上游組織服務偶發抖動，審批流引擎常用快取儲存啟動時的組織關係快照，確保流程啟動後不受組織結構變動影響。

典型的 SLA 要求：上游身份認證服務可用性 ≥ 99.9%，規則引擎 P99 延遲 < 20 ms，以確保審批流端到端體驗。

7. 下游

審批流的下游是它“做完決策之後還要做什麼事”的環節，也是業務價值的最終實現點。

• 統一待辦任務中心：將來自不同系統的審批任務聚合到一個介面，支援待辦已辦、批次審批、行動端訊息推送。這是終端使用者的主要接觸點。
• 業務系統回撥：ERP / CRM / SCM / 費控等系統在審批完成後更新單據狀態、放款、發貨、記賬。回撥失敗需要有重試和補償機制。
• 檔案與合規系統：審批記錄、操作日誌、附件需要歸檔至檔案系統或電子存證平台，滿足審計、法務要求。部分行業還需對接電子簽名服務（如 e籤寶、法大大）。
• BI 與流程挖掘：審批時長、駁回率、節點瓶頸等資料被匯入分析平台，用於組織效能診斷。流程挖掘工具（如 Celonis）可直接從事件日誌重構實際流程模型，發現與設計模型的偏差。
• RPA 自動化機器人：審批通過後，RPA 可代替人工完成後續系統間的資料搬運（例如從 CRM 複製合同資訊到 ERP 建賬），減少人工操作，但同時增加了整體流程一致性管理的複雜度。
• 即時通訊與協作工具：審批通知通常通過釘釘、飛書、企業微信等 IM 渠道即時推送，並允許在對話中直接完成審批，減少應用切換成本。

8. 受益公司

審批流作為一種基礎能力，很少單獨作為產品出現，通常是嵌入在 OA、低程式碼平台、BPMS 或雲端服務中。以下按模式分類列舉受益方向和典型公司（僅用於產業分析，不構成投資建議，財務資料請以各公司最新年報為準；若無公開拆分資料，明確註明“公開資料未見”）。

開源/PaaS 引擎商業化

• Camunda：核心引擎開源，提供雲端託管服務（Camunda SaaS）。其贊助商模式與 BPMN 標準深度繫結，在微服務編排和審批流中都廣泛應用。公開資料未見針對審批流部分的獨立營收拆分。
• Flowable：由原 Activiti 核心開發者建立，開源基礎上提供企業版與雲端服務。開源社群活躍，常被國內廠商作為底層引擎整合。

企業軟體廠商

• SAP：S/4HANA 和 SuccessFactors 內嵌審批工作流，深度連線財務、HR 和供應鏈，審批流是其平台使用者粘性的重要部分。不單獨拆分審批流營收（公開資料未見）。
• 用友網路：BIP 平台和 NC Cloud 中審批流屬於基礎能力，服務於大量中大型企業客戶。未揭露審批流單獨模組營收（公開資料未見）。
• 金蝶國際：金蝶雲端·星瀚、蒼穹平台包含審批流引擎，不單獨揭露審批流營收（公開資料未見）。

平台級嵌入

• ServiceNow：ITSM 與審批流深度結合，Flow Designer 提供視覺化審批編排，面向大型企業。其訂閱營收中審批流作為工作流的一部分，無法單獨拆分（公開資料未見）。
• Salesforce：Approval Process 引擎內嵌於 Sales Cloud / Service Cloud，為銷售、服務流程審批提供支撐。不單獨揭露審批流營收。
• 微軟 Power Automate：作為 Power Platform 成員，提供審批聯結器與自動化審批流，以訂閱和用量計費，與 Office 365 深度繫結。

國內協作/OA 生態

• 泛微網路：OA 龍頭，審批流是產品核心，長期積累大量政企客戶的複雜審批模板。公司整體營收可在年報查閱，但審批流單獨貢獻未揭露（公開資料未見）。
• 致遠互聯：協同辦公及審批流能力覆蓋中大型組織，同樣不單獨拆分審批流營收。
• 釘釘、飛書、企業微信：均提供免費基礎審批，作為獲客與促活手段，通過專業版/OA 版/aPaaS 高階能力收費。審批流的使用頻次與次日留存高度相關，是這些平台的關鍵粘性模組。各家不揭露審批流單獨貢獻營收（公開資料未見）。

新興方向

• AI 輔助審批：部分初創公司嘗試用 NLP 解析合同風險、自動生成審批意見，輔助財務稽核等場景。多數處於早期融資階段（如 Seed~A 輪）。
• Web3/多籤錢包審批流：基於智慧合約的多籤審批，用於 DAO 資金管理，但企業大規模採用仍有距離。

9. 市場規模

截至 2025 年 4 月，公開資料未見針對審批流獨立細分市場的定量規模統計。審批流市場價值通常嵌入在更大範疇的流程自動化（BPM）與低程式碼/無程式碼平台市場中，且各研究機構的口徑差異較大。

• 流程自動化市場：據 Gartner 等機構近年報告，全球業務流程管理（BPM）和超自動化（Hyperautomation）軟體及服務市場處於數百億美元量級，並保持雙位數增長。具體年度數字請參閱 Gartner 釋出的《超自動化市場預測》或 IDC 相關追蹤報告。
• 低程式碼/無程式碼市場：Gartner 預測 2024 年全球低程式碼開發技術市場約達 XXX 億美元（因報告獲取限制，此處不轉載具體數字，詳見 Gartner 官方釋出），其中審批流、工作流與表單是核心元件，常被列為關鍵用例。
• 中國市場：中國信通院及多家分析機構的低程式碼/無程式碼市場報告中，審批流/流程自動化被視為數字化基礎能力，市場保持較快增長。具體規模資料建議查閱信通院《低程式碼發展研究報告》最新期數。

審批流是“無處不在但難以獨立計費”的能力，因此評估其市場規模需關注相關平台的整體 ARR 或訂閱營收增長，以及流程自動化滲透率指標。

10. 玩家對比

以下對比聚焦於主流審批流引擎/平台的代表性模式，維度涉及架構開放性、複雜流程支援、部署模式、社群生態和典型客戶畫像。均不涉及具體營收數字，因為“公開資料未見”統一的拆分口徑。

玩家/產品	核心定位	架構開放性	複雜人工流程（會籤/加簽/回退）	部署模式	社群/生態	典型客戶畫像
Camunda	以開發者為中心的 BPMN 引擎	高，開放原始碼，REST/Java 介面	強，原生支援 BPMN 使用者任務與邊界事件	自部署/雲端託管	大型開源社群，廣泛整合微服務生態	中大型企業，有自有開發團隊，需深度定製
Flowable	開源 BPMN 引擎，商業支援	高，與 Camunda 類似	強，支援 CMMN 和 DMN	自部署/雲端	活躍社群，國內有整合商	中大型企業，尤其金融、政府
釘釘審批	低程式碼/無程式碼 OA 審批	低，僅通過開放平台 API 互動	中，複雜加簽、並行、條件分支均支援，但深度編排受限	SaaS / 混合雲端	國內最大協作生態，模板市場	中小企業到大型企業，注重移動化和免開發
飛書審批	無程式碼審批+飛書整合	低，開放 API，可整合自建應用	中，支援並行、條件、加簽等，但複雜 Saga 需藉助飛書整合平台	SaaS	飛書生態，ISV 豐富	數字化程度較高的中大型企業，尤其是網際網路、科技
ServiceNow Flow Designer	ITSM 為核心的工作流與審批	中，通過 Integration Hub 和 API 擴充套件	強，原生支援豐富的審批動作與子流程，結合 ITSM 資產	SaaS	全球大型企業生態，合作伙伴豐富	大型企業 IT/HR/客服共享服務中心
Power Automate	流程自動化與審批	中，基於聯結器生態，可通過 Azure 擴充套件	中，支援多級審批、條件、並行，但高度複雜 BPMN 需藉助邏輯應用	SaaS / 自託管閘道器	微軟全家桶生態，Office 365 使用者基礎龐大	已使用微軟生態的中大型企業，追求快速自動化
泛微 / 致遠	傳統 OA 審批升級的協作平台	低，產品邊界封閉，二次開發多通過官方平台	極強，沉澱了大量政企複雜審批模板（多機構聯審、黨政機關流轉）	私有化/混合雲端	國內夥伴生態，信創適配	大型集團、政府機構，對合規和本地化要求極高

注：上述對比基於公開產品文件與行業認知，功能細節隨版本更新變化，建議參考各廠商最新白皮書。

11. 風險

審批流自身及依賴其執行的業務面臨以下風險，產業參與者在選型和架構設計時需持續評估。

• 競品同質化與免費化壓力：基礎審批功能門檻極低，釘釘、飛書、企業微信等以免費審批拉新促活，使獨立 OA 廠商和中小型引擎的生存空間受到擠壓。缺乏差異化能力（如合規存證、AI 輔助決策）的廠商可能面臨價格戰與客戶流失。
• 效能與可用性風險：審批流是大量核心業務（報銷、合同、付款）的阻塞點。流程引擎自身出現效能瓶頸、死鎖、併發衝突導致大面積審批卡頓，可能直接中斷業務運轉。此類風險在超大型組織高併發期（如月底報銷高峰）尤為突出。
• 組織資料依賴與遷移鎖定：審批流深度繫結組織架構、權限和表單，一旦上線，遷移成本極高（包括歷史流程例項、審計日誌、使用者習慣），供應商鎖定效應明顯。這會限制企業後續議價能力和架構選擇。
• 合規與證據鏈缺陷：金融、醫藥、政府等行業對審批留痕、電子簽名、不可篡改有時間戳的要求。若系統未提供合規存證或審計日誌不可追溯，企業將面臨監管罰款或法律爭議風險。
• 安全與權限失控：動態審批人計算若存在權限繞過漏洞（如越權審批、引數篡改），可能導致資金損失或資料洩露；表示式注入漏洞（如 SpEL 注入）可被利用執行惡意程式碼，屬於高危風險。
• 長事務一致性設計缺陷：不少自研或輕量審批流未設計完善的 Saga 補償機制，在審批通過但後續業務執行失敗（如支付失敗、庫存扣減失敗）時遺留資料不一致狀態，修復成本高、業務影響大。

12. 誤讀糾偏

誤讀 1：審批流就是工作流 工作流範圍更廣，涵蓋自動化、人工、整合、訊息等多種任務編排；審批流特指需要人工決策的核籤型流程，且非常強調責任歸屬、回退與加簽操作，在 BPMN 標準中屬於“使用者任務”及圍繞它的特定模式。把兩者等同，會忽略審批流在權限、快照和證據鏈方面的額外要求。

誤讀 2：審批流必須是線性序列的 許多實際業務是並行的（多人會籤、或籤）、動態的（根據金額增加審批節點），成熟的審批流支援並行分支、條件跳過、子流程、動態加簽，遠非“一個人過了下一個人”這麼簡單。低估其路由能力，就會設計出僵化流程，反而降低效率。

誤讀 3：審批通過後就萬事大吉 審批的原子操作和後續業務執行之間存在分散式事務間隙。需要補償機制處理“審批已生效但支付/發貨失敗”這種部分執行場景。沒有此設計的系統，最終會積累大量業務不一致的“懸空”記錄，手工修補代價極高。

誤讀 4：有了低程式碼審批，就不需要引擎概念 低程式碼平台封裝了大部分複雜性，但如果業務需求超出平台預置模板（例如需要複雜 Saga 補償、跨公司審批存證、事件子流程），就必須理解底層引擎的工作原理。把低程式碼當作萬能鑰匙，遇到複雜場景就容易撞牆。

13. 最新事件

截至 2025 年 4 月，公開資料未見審批流領域足以單獨構成行業里程碑的單體事件，但以下產業動向作為日常演進值得關注（均為公開資訊摘要，建議查閱廠商官方渠道獲取細節）：

• Camunda 持續增強雲端原生與 AI 能力：Camunda 在近年版本更新中強化了多租戶隔離、流程例項熱遷移，並開始引入 AI 驅動流程推薦。（來源：Camunda 官方部落格）
• 國內低程式碼審批平台持續迭代：釘釘、飛書審批模組在 2024–2025 年間陸續升級了跨組織審批、與電子簽名更深度整合，以及聯結器生態擴充套件。（來源：各平台更新日誌）
• AI 審批助手趨勢加速：多家 SaaS 廠商和獨立開發者已推出利用大語言模型（LLM）輔助審批意見摘要、合同風險提示的功能，但仍處於早期產品化階段，尚無大規模基準資料揭露。（來源：網路公開報道）
• 《電子簽名法》等法規執行強化：中國持續提升電子合同和審批留痕的法律效力要求，促使更多審批流產品內建存證與時間戳服務。（來源：國家政策檔案）

14. 追蹤指標

監控審批流運轉健康狀況和業務價值，應關注的指標如下（建議結合具體廠商的管理控制台進行量化）。

• 流程流轉正確率：成功到達終點的例項佔全部到達終態的例項比例，目標接近 100%。因流程定義缺陷導致的“死流程”比例需獨立監控。
• 節點平均審批耗時：從任務生成到審批人提交決策的時間（可剔除節假日），常用來定位瓶頸崗位和流程節點。
• 端到端流程時長 P50/P95：從發起到最終結束的業務視角耗時，能暴露長尾異常（頻繁駁回、多人加簽）帶來的延遲。
• 審批操作可用性：簽收、提交等核心操作的業務異常率（不含審批人主動駁回），反映引擎及依賴服務的穩定性。
• 流程版本線上遷移相容率：升級流程定義後，存量執行例項成功平滑過渡的百分比，目標應為 100%。
• 資源爭用指標：樂觀鎖衝突重試次數、任務佇列深度、執行緒池使用率，反映引擎在業務峰值下的併發瓶頸。
• 人工干預頻率：管理員強制干預（如跳轉、撤回、重新指定審批人）的次數，頻率升高可能意味著流程設計或組織資料異常。
• 使用者觸達與完成率：待辦訊息推送成功率、行動端審批完成佔比，可衡量審批流的體驗質量與辦公移動化程度。

15. 信源

• 工作流管理聯盟（WfMC）術語表及參考模型（公共標準）
• OMG 規範：BPMN 2.0 Specification
• Marlon Dumas 等《業務流程管理基礎》（Fundamentals of Business Process Management）
• Camunda 官方文件：工作流引擎架構與審批模式
• Flowable 開源文件與使用者指南
• 阿里雲端、AWS 平台上審批工作流最佳實踐白皮書（供應商案例）
• Gartner：《超自動化市場預測》《低程式碼開發技術魔力象限》（各年報告，具體期數以官方釋出為準）
• Forrester Wave：Low-Code Development Platforms（定期更新）
• 中國信通院《流程挖掘研究報告》《低程式碼發展研究報告》
• 各廠商官網及產品更新日誌：釘釘開放平台、飛書開發者文件、ServiceNow 產品文件、微軟 Power Automate 文件、泛微網路、致遠互聯

注：因未進行本次環境下的即時資訊檢索，所有定量資料均標註為“公開資料未見”或不轉載具體數字，技術性能資料建議查閱各自官方最新基準及學術文獻。本文所有內容不構成任何投資或選型建議。