文件審批工作流程決策樹
文件審批工作流程的決策樹：編輯性修改還是實質性修改、按文件類別而定的必審審閱人、第二審批人，以及發布時的已閱並理解要求。
甚麼是文件審批工作流程決策樹流程
文件審批工作流程，就是介乎一份寫好的草稿和一份正式發布的文件之間的那段審閱與審批路徑。它要回答的問題數目不多：這是一份新文件還是一次修訂，這次修改是否真的改變了別人必須做的事，誰必須審閱，是否還有未了結的意見，是否需要第二審批人或法規審批人，以及發布之後是否要求有人閱讀並簽認。它刻意比文件管制更窄：文件管制還要涵蓋版本編號、發放、分發、收回已作廢的副本以及定期檢討。如果你們要的是帶文件管理員泳道的完整生命周期，請用文件管制流程圖；本頁是嵌在那個流程內部的那棵決策樹。
這兩張圖回答的是不同的問題，值得把你們到底需要哪一張說清楚。跨職能流程圖回答的是接下來會發生甚麼、由誰去做：一串任務由左至右穿過各條部門泳道，最後匯合到同一條終點線。本圖回答的是這份文件走哪條路、由誰作決定：一串八道問題，它們的分支通向五個各不相同的具名結果。一次編輯性更正、一次完整審批、一次退回返工、一次否決，以及一次附帶培訓任務的發布，在這裡是各自獨立的終點——由它們上方那些問題的答案決定去向，而不是同一條順利路徑上的幾個階段。
審批工作流程失敗的原因，通常是判定準則沒有寫下來，而不是少了步驟。人人都同意編輯性修改有一條快速通道，但沒有人寫明甚麼才算編輯性，於是一次實質性修改就當作改錯別字混了過去。關鍵判斷上的註釋承載着這些準則：甚麼令一次修改成為編輯性的，甚麼令一類文件成為受規管的，甚麼會觸發第二審批人，以及甚麼時候確實必須做到已閱並理解。泳道命名的是誰去回答每一道問題，而不是誰去打字，於是這張圖同時也是一份決策權清單：撰寫人、文件負責人、審閱人與審批人，橫跨受理、分類、審閱、審批與發布五個階段。
本流程圖涵蓋的內容
本範本包含
- 八道判斷構成主幹：新文件還是修訂、編輯性修改還是實質性修改、是否屬於受規管的文件類別、審閱意見是否全部了結、撰寫人能否即場解決、是否批准發布、是否需要第二審批人，以及是否要求已閱並理解。
- 分支標籤是答案而不是下一項任務：修訂或新建、編輯性或實質性、受規管或業務、已了結或未了結、已批准、返工或否決、需要或不需要。
- 五個具名終點，而不是一條共同的終點線：作為輕微編輯性更新發布、經完整審批後發布、發布並同時指派培訓、退回撰寫人返工，以及否決並結案。
- 編輯性捷徑：只有修訂才可以歸類為編輯性，編輯性更正經記錄後即可發布，無須強制審閱或審批；而任何新文件都要走完整路徑。
- 按文件類別選定審閱人：受規管的文件在收集意見之前先加入品質與法規審閱人，業務文件則只送交指定的流程審閱人。
- 未了結的審閱有兩個出口：撰寫人即場可以關閉的意見回到重新審閱，無法關閉的意見則以退回返工結束本輪；此外，審批人亦可以把一份本已完備的草稿退回返工，而不是直接否決。
何時使用本範本
- 你們的文件管制程序列出了步驟，卻從來沒有說明哪些修改可以略過完整審閱，於是改一個電話號碼和發布一條新的安全關鍵作業指引一樣要走六個星期
- 審批停滯，因為沒有人講得出是否需要第二審批人或法規審批人，答案由當時在場的人逐份文件臨時決定
- 你們正在文件管理系統中設定審批路由，需要先把分支條件作為成文準則達成共識，再由人把它們做成規則
- 審核員問過你們如何判定一次修改屬於編輯性，或者如何判定一次發布需要已閱並理解，而目前的答案是憑個人判斷，而不是一條成文準則
- 你們在帶新的文件負責人或審批人上手，希望他們看到這些問題、每一道問題背後的準則，以及每一個答案確切通向哪裡
運作方式
把泳道改成你們真實的決策權
這四條泳道命名的是誰去回答每一道問題：撰寫人、文件負責人、審閱人與審批人。把它們換成你們自己的角色，按角色而不是按人名命名，這樣圖才經得起人員離職和組織重組。如果你們的品質經理既是文件負責人又是審批人，就把這兩條泳道合併，而不是扮作這個決定是分開作的。如果技術審閱和法規審閱由不同的人回答，就把審閱人這條泳道一分為二。
用一句話寫清編輯性的判定準則
「編輯性修改還是實質性修改？」是最容易被濫用的一道判斷，因為它是唯一一條略過審閱與審批的路徑。寫一條人人都套用得到的準則：如果讀者會因為這次修改而做出任何不同的動作，它就是實質性的。然後把可以接受的編輯性情形逐一列明，例如改正錯別字、調整排版、部門易名以及修正交叉參照，並寫明由文件負責人而不是撰寫人去作這個判定。
按文件類別固定必審的審閱人
把「是否屬於受規管的文件類別？」做成一張短表，令你們的文件登記冊可以憑一個欄位而不是憑記憶去回答。對每一種類別，寫明哪些審閱人必須簽署、哪些是可選的。受規管通常代表該文件落在某個管理體系、某項牌照或某份安全論證的範圍之內；如果你們無法從登記冊的條目判斷一份文件屬於哪一類，這道判斷一定會被不一致地作出。
訂定第二審批人的觸發條件
第二次審批應當由文件本身的某項屬性觸發，而不是由不安感觸發。常見的觸發條件是受規管的文件類別、涉及法律或安全的承諾，以及超出第一審批人授權範圍的文件。把觸發條件記在判斷旁邊，並寫明由哪個角色提供這第二次審批，這樣圖告訴大家的就不只是「還要再找一個人」，而是應該送給誰。
確定返工在甚麼情況下結束本輪
「撰寫人能否即場解決？」這道判斷的作用，是不讓草稿掉進一個沒有盡頭的審閱迴路。約定本輪之內可以關閉的是甚麼，通常是措辭、澄清與排版；不能關閉的是甚麼，通常是任何需要新內容、新資料，或者需要撰寫人無權作出的決定的事項。凡屬第二類，一律作為返工退回撰寫人，由受理重新進入流程，而不是原地打轉。
定下已閱並理解的規則，並把證據存好
當修改改變了某人在安全關鍵、受規管或面向客戶的步驟中實際必須做的事時，要求已閱並理解；只涉及排版或措辭時則不要求。在發布之前就決定簽認紀錄存放在哪裡、保存多久，因為證明大家是按現行版本工作的，正是這條紀錄，而不是審批本身。
常見問題
甚麼是文件審批工作流程？
它是一份草稿由寫完到發布之間所走的路徑：為這次修改歸類、選定必須過目的審閱人、了結他們的意見、取得審批，並決定這次發布要求別人做甚麼。它是一個決策結構，而不是一張任務清單，因為真正值得關心的不是「有沒有審閱」，而是「進行的是哪一種審閱、誰有權作決定」。一個對每份文件都套用同一條路徑的工作流程，並不是工作流程，那是排隊。
它與文件管制流程圖有甚麼分別？
分別在範圍和形態。文件管制流程圖是一張跨職能流程圖，涵蓋完整生命周期，包括版本編號、向受控位置發放、收回已作廢的副本以及按計劃進行的定期檢討，它回答的是接下來會發生甚麼、由誰去做。本頁只是審閱與審批這一段的決策樹，它回答的是一份文件走哪條路、由誰作決定。如果你們正在編寫一份程序文件，很可能兩者都需要：用流程圖描述生命周期，用本圖作為其審批階段內部的路由規則。
一次修改在甚麼情況下可以按編輯性批准並略過完整審閱？
只有在含義沒有改變時。改正錯別字、調整排版、部門易名以及修正交叉參照是合資格的；任何改變了一個人必須做甚麼、按甚麼次序做、受甚麼限值約束或對照甚麼驗收準則的修改都不合資格，無論那處改動看上去有多小。有兩道防線令這條路徑保持誠實：只有對現有文件的修訂才可以歸類為編輯性，而且由文件負責人而不是撰寫人去作這個判定。要把歸類結果記錄下來，因為那是審核員最先要查的東西。
一份文件需要兩位審批人嗎？
沒有任何標準把兩位審批人定為通行規則。ISO 9001:2015 第 7.5.2 條要求成文資訊在發放之前經過審閱和批准，以確認其適宜性和充分性，但並沒有規定由多少人去做。行業規則在特定情形下更嚴格，例如藥品生產要求由品質部門批准生產與工藝控制的相關程序。實務上的做法是按文件屬性觸發第二審批人或法規審批人，例如受規管的文件類別、涉及法律或安全的承諾，或者超出第一審批人授權範圍的文件。
電子審批算不算簽署？
在多數商業場景中，一條可審核的審批紀錄只要寫明審批人、版本和日期就夠了。在受 FDA 規管的場景中，21 CFR Part 11 提出了具體條件：一份經簽署的電子紀錄必須顯示簽署人的姓名全稱、簽署的日期與時間，以及簽署的含義，例如審閱或批准；而且簽署必須與其紀錄相互關聯，令它無法被刪除、複製或轉移。在假定按一下按鈕就足夠之前，先確認適用的是哪一套規則。
QueryChart 如何追蹤各輪審批之間改了甚麼？
每張圖都設有變更日誌與比較版本檢視，兩者都是免費並且預設開啟，因此你們無須進行任何設定，就能準確看到這一輪意見與上一輪之間改動了甚麼——運作方式見 /features/version-control。/guides/how-to-track-process-changes 以同一張圖為例，帶你們走過幾輪審閱，示範實際做法。這屬於版本歷史，不是合規審計軌跡：一份經簽署並保留、記錄誰批准過甚麼的紀錄，是另一項獨立的付費功能，免費的變更日誌與比較版本檢視並不包含它。