辦法只有一本，不是十六本
簽核額度、代理規則與上呈方式只定義一次，就對所有單據類型生效，而不是在每個模組裡重新設定。
為什麼這不是又一個模組
流程不擁有任何一張單據——它讓所有單據動起來。
請假單屬於人力資源，請購單屬於採購，合約屬於合約管理。把流程拆成獨立模組，同一張表單就會有兩個地方在講；哪天兩邊對不上，沒人知道該信哪一個。所以它不是第十七個模組，而是十六個模組共同站立的那一層。
採購模組採購申請
- 草稿
- 待簽核
- 已簽核
- 已下單
流程層
政策關卡 — 誰簽核、到哪個額度、幾輪、多久之內
一經簽核，另一個模組裡等著的工作就自己開了
一張單據的狀態鏈，由擁有它的模組掌管。流程層只咬在那個需要做決定的狀態變更上——所以它不擁有任何單據，也沒有什麼要和模組爭。
跟著組織圖走，不是跟著名單走
簽核路徑讀取人力資源模組中的職稱與所屬單位。有人調動，路徑跟著走，你不必逐條修改辦法。
憑據與單據放在一起
誰陳核、誰核准、什麼時候、在哪一版、依據什麼權限——都留在單據本身，所以稽核一問，不必從頭重建。
一張申請的一生
從有人按下送出，到留下可對帳的憑據。
同一套機制，適用於所有單據。下面是一筆採購申請走完四個階段，以及它此刻停在哪裡。
一筆正在流轉的申請PR-1042v2已走分支 · 超出額度等待簽核人
採購申請
路由超出額度投資、急件其餘情況
管理層額度矩陣依序SLA 48h剩餘 6 小時
並行
財務一人即可SLA 24h
部門主管依組織架構
兩者都完成
直屬主管依組織架構
憑據
稽核紀錄
- 09:12申請人送出申請
- 09:12流程依額度分流
- 11:04會計主管要求補充報價
- 01
提出
有人依公司範本填一張電子表單，或者業務單據在觸及條件時自行提出申請。
- 02
路由
規則讀取金額、單據類型、所屬單位與額度，挑出該由誰簽核——需要多方意見時並行，講究先後時循序。
- 03
簽核
簽核者在工作空間或手機上處理，可要求補件，可在外出時委由他人代決，逾期則由 SLA 往上呈。
- 04
憑據
決定連同完整紀錄直接寫回原單據，下一個業務環節隨之開啟——沒有人需要往另一套系統重新輸入。
此圖是一個具體範例，用來把機制讀清楚；圖中的數字為示意值。 額度、簽核層級與上呈時限依各單位自訂的辦法設定，在導入過程中定案。系統協助辦法落實，不取代辦法。
裡面有什麼
用拖曳設計，在真實資料上執行。
設計與表單
- 無程式碼流程設計器在畫布上拖曳組出流程：步驟、條件、分支與迴圈——不必寫程式。
- 電子表單依公司範本設定欄位、驗證與附件，直接掛在提出環節上。
- 版本與試跑在草稿上修改執行中的流程，試跑之後再公布；在途申請仍依舊版本走完。
路由與簽核
- 條件、額度、代理依金額、單據類型或所屬單位分支；超過額度自動加一層；有人外出則轉給代理人。
- 並行簽核與循序簽核互不相依的單位同時表示意見，後一層需要看到前一層決定時則依序進行。
- SLA 與上呈每一步都有時限；逾期先催辦，再依辦法載明的方式往上呈。
憑據與營運
- 完整紀錄每一次操作都記下人、時刻、單據版本與理由——足以回答兩年後的一個稽核問題。
- 追蹤與瓶頸看得到申請停在哪裡、等誰、等了多久；經常卡住的環節會以數字浮現。
- 跑在所有模組的單據上同一套引擎服務請假單、請購單、合約、出庫單與調整分錄。
與代理人層的邊界
代理人在流程之內行動——它不取代流程。
當企業已經有了代理人，這個問題很合理：既然 AI 能把事做完，還要流程做什麼。正是流程，讓把事交給代理人這件事變得安全。
誰能做什麼，由流程決定
代理人在呼叫它的帳號權限內執行，授權範圍宣告在流程本身之上——沒有繞開流程的捷徑。
需要簽核的事仍然經過人
代理人預先填寫，並寫入被授權寫入的部分；超出這個範圍就停在附出處的建議上，簽核環節依然是簽核環節。
紀錄也載明代理人
軌跡寫明哪個代理人、受誰授權、由誰核准——與人的操作記在同一本紀錄裡。
常見問題
流程層的邊界。
這算又一個模組嗎？
不算，這是刻意如此。模組擁有一類業務紀錄，而流程層什麼也不擁有——它讓另外十六個模組的紀錄動起來。把它拆出去，就會有兩個地方在描述同一張表單。
這與數位行政裡的簽核流程有什麼不同？
數位行政是單據的一個領域：公文收發、印信、檔案保存。流程層是這個領域——以及其他所有領域——賴以運轉的引擎。公文簽核只是用這個引擎組出來的一條具體流程。
不會寫程式的人能改流程嗎？
設計器是在畫布上拖曳，所以懂業務的人不寫程式也能組建與修改流程。誰有權改哪條流程屬於權限設定，在導入過程中定案。
某一步能呼叫外部系統嗎？
一個步驟可以透過 API 呼叫另一套系統，取資料或送出結果。要串接哪些系統、如何驗證依專案定案——整合頁面列出支援的系統類別。