開篇：出差審批靠群消息，找審批人靠問
一家約200人的製造企業，年後第一次出差申請是這樣走完的：員工在群裡@主管，主管看到後回個「OK」，員工截圖保存；財務月底要做差旅報銷時，按截圖挨個對照預算；HR年底統計「員工出差天數」，結果發現截圖不全、跨部門的數據沒對齊。
這並不是個別現象。審批這件事在國內大量公司裡是這樣流轉的：
- 找人靠問：新員工入職第一週，最常問的就是「我請假找誰批？我報銷誰審？」
- 群消息當憑證：微信或者釘釘群裡「@老闆 已批」當作審批通過，事後無法審計。
- 跨部門數據對不上：銷售部認為客戶拜訪已經批了，市場部認為沒批，財務按銷售部的截圖付了款。
- 權限靠口頭：某經理離職，權限沒收回，新人來了不知道原經理審批的合約在誰手裡。
這些問題的根源不在「審批這件事有多複雜」，而在審批流程沒有落進系統。群消息、口頭、截圖都是臨時媒介，缺的是結構化、留痕、可追溯的載體。OA系統（辦公自動化系統）就是把這件事結構化：把「誰、什麼事項、什麼時候、找了誰、按什麼規則批、批完之後數據怎麼沉澱」全部沉澱到一條審批流程裡。
01 業務怎麼拆：審批流程的三層結構
把審批這件事拆開，其實是三層：
- 事項層：員工發起「出差、請假、報銷、合約、用印、採購」等具體事項，每項裡都帶金額、天數、附件、關聯業務對象（出差申請關聯銷售訂單、報銷關聯發票）。
- 流程層：事項從一個節點流向下一個節點，節點的審批人是動態算的（按部門、級別、金額、品類），不是寫死的。
- 數據層：審批通過或駁回後，數據要回寫到業務系統（HR、財務、銷售、合約庫），不能只停在審批流程裡。
三層的關係是：事項是入口，流程是主幹，數據是出口。做OA系統如果只做了流程沒做數據出口，審批流程就成了孤島；只做事項沒做流程，就退化成「填表系統」。
02 怎麼設計：動態節點、權限矩陣、留痕三件套
節點設計：審批人不是寫死的
很多OA一上來就把審批人寫死：「出差申請 → 部門經理 → HR → 總經理」。結果部門經理換崗、HR併入行政部、總經理外出，系統全部錯亂。
正確做法：審批人由規則動態算出來。規則維度通常有四個：
- 部門維度：申請人所在部門對應到該部門當前負責人（按組織樹實時查）。
- 級別維度：金額、天數、合約金額對應不同區間，對應不同審批層級。
- 角色維度：合約金額超過50萬，法務必須介入；員工出差到海外，安全合規必須會簽。
- 代理人維度：審批人請假或者出差，自動轉給代理人，代理人由組織關係或者HR設定。
把這四個維度組合成「規則表達式」，流程引擎按規則實時算節點，不寫死審批人姓名。換崗、組織調整都不需要改流程模板。
權限設計：菜單、數據、字段三級
權限不是「能不能進系統」，而是三級：
- 菜單級：能不能看到這個模塊（普通員工看不到「組織架構管理」）。
- 數據級：能不能看這條數據（銷售一部只能看本部門員工的報銷，看不到銷售二部）。
- 字段級：這條數據的某些字段能不能看（普通審批人看不到申請人薪資字段，但HR能看到）。
三級權限拆開之後，OA系統就能支撐複雜的組織結構：集團-分公司-部門-小組，跨級數據要按「我能看到我自己這條線 + 我是這條線的負責人」兩條規則並行控制。
留痕設計：審批日誌的七要素
每次審批操作必須留七要素：
- 操作人：誰點的。
- 操作時間：精確到秒。
- 操作動作：同意、駁回、轉交、加簽、撤回。
- 操作意見：駁回意見必填，同意可空。
- 節點位置：當前是流程的哪一節點。
- 關聯數據快照：審批時業務對象的字段值（金額、附件）原樣保存，不允許事後修改業務對象而審批記錄沒變。
- 設備和IP痕跡：從哪台設備、哪個IP發的（合規審計用）。
這七要素缺一項，審計時都會扯皮。常見坑是「操作意見可空」，結果駁回沒有理由，員工反覆重提，審批流程拉長。
03 怎麼開發：流程引擎、表單引擎、消息總線三件套
開發OA的核心是三個引擎，不是N個頁面：
流程引擎
流程引擎不寫代碼，靠配置就能跑流程。要支持的特徵：
- 串行、並行、會簽、或簽：四類基礎流，轉正申請是串行（HR → 主管 → CEO），採購會簽是並行（財務和採購主管同時審）。
- 條件分支：按金額、品類、申請人級別分流，5000元以下走簡易流，5000到50000走部門加財務雙審，5萬以上加CEO。
- 回退和駁回：駁回到申請人、駁回到任意節點、駁回到上一節點，三類駁回都要支援。
- 加簽和轉簽：審批人能把任務轉給同事（轉簽），也能拉一個同事一起審（加簽）。
- 撤回和作廢：申請人能撤回未審批完的事項；管理員能作廢異常事項。
流程引擎做出來之後，新增一類審批不用寫代碼，畫個圖、配個表單就能上線。這是 OA 区別於「審批外包開發」的關鍵。
表單引擎
表單要「零代碼設計」：字段類型（文本、數字、日期、附件、關聯業務對象）、校驗規則、必填選填、顯隱條件，全部可視化拖拽配置。這樣 HR 調整報銷字段、銷售增加合約字段，不用 IT 排期。
表單引擎要支援：
- 字段級權限：同一張表單，不同審批人看到的字段不一樣（普通審批看不到申請人手機號）。
- 字段聯動：選了「合約類型 = 服務合約」，自動展開服務合約特有的字段。
- 資料回寫：審批通過後自動回寫到業務系統（合約狀態、HR 考勤、財務憑證）。
消息總線
審批通過或者駁回，申請人、相關業務系統（HR、財務、銷售）都要即時收到通知。消息總線統一發：
- 系統內通知：站內信加待辦。
- IM 通知：企業微信、釘釘、飛書 webhook，推送到對應群或個人。
- 郵件和短訊：重要節點備份通知（合約審批、海外出差）。
- 業務系統消息：審批通過後，寫一條消息到業務系統的待辦（財務收到報銷待辦、HR 收到入職待辦）。
消息總線不是「裝飾」，是審批流的「打迴路」——沒有消息通知，申請人不知道下一步該找誰，整個流程就卡住了。
收束：落地的順序、風險與指標
OA 系統上線分三步：
- 第一期（1 個月）：上請假、出差、報銷三件高頻事項，覆蓋全員。先把微信群裡的審批搬進系統，哪怕只搬這三件，跨部門數據就立刻對齊了。
- 第二期（2-3 個月）：上合約、用印、採購、付款四件中等頻次事項，接財務系統。這一期要打通資料回寫（合約審批通過自動歸檔到合約庫）。
- 第三期（按需）：上績效、晉升、轉正、招聘、離職等人事全流程。這一期是 HR 主導，要打通 HR 主數據。
常見風險：
- 規則過於靈活：審批流配置太自由，結果誰都不知道下一步是誰。原則：流程模板不要超過 30 個，多了就失控。
- 代理人漏配：審批人出差沒配代理人，流程卡 3 天無人審。系統檢測「流程掛卡超過 24 小時」自動報警。
- 資料沒回寫：審批通過了，但 HR 系統裡考勤沒更新，財務系統裡沒憑證。回寫要「雙寫校驗」，OA 寫完主動調業務系統的接口確認收到。
檢驗項目成不成的指標：
- 審批平均完成時長：上線前群里走 3 天，上線後系統裡 1 天內閉環。
- 跨部門資料一致性：HR、財務、銷售三套口徑的對賬差錯率下降 80% 以上。
- 審計可追溯率：隨機抽 20 條歷史審批，七要素齊全率 100%。
把審批從微信群裡搬到系統裡，不是為了「上系統」，而是把「找人」這件事從依賴人變成依賴規則。規則一旦寫下來，誰離職、組織怎麼變，審批都不會亂。