如何追蹤流程的變更
如何追蹤流程的變更：QueryChart 的變更日誌會點名是誰改了一條決策規則或門檻、這個欄位改動前後的值，令沒有人需要憑記憶重建一次修改。
追蹤流程的變更，即是準確記錄哪一個欄位改了、是誰改的，以及它取代了甚麼值——不只是記錄有一個新版本存在。
簡而言之
- 修改一列決策的門檻——由「超過 5,000 美元需要第二位審批人」調升到「超過 10,000 美元」——會成為一條變更日誌項目，點名是誰改的，以及取代了甚麼值。
- 每一次修改都有歸屬：是誰做的、哪個欄位、改動前的值、現在的值，加一個時間戳，不只是「圖表已更新」。
- 當兩個版本之間改動的東西，多過單一條變更日誌項目所覆蓋的，比較版本會給你較完整的差異。
- 還原一個舊版本，會直接撤銷那次修改，而不是要求某人憑記憶重新打入舊規則。
- 追蹤變更不同於管制變更：這是一次修改留下的紀錄，不是它應否發生的審批關卡。
誰動過那個門檻，何時動的
一位流程負責人把一列決策上的金額，由 5,000 美元調高到 10,000 美元——一個欄位、一次修改，幾秒鐘內儲存好。三個星期後，一張 7,000 美元的發票在沒有第二位審批人的情況下過了關，問題不在於規則有沒有改，而在於是誰改的、何時改的，以及舊數字實際上是多少。沒有人在圖表以外的任何地方寫低這件事，因為那條規則本來就住在圖表裡。
QueryChart 會自動保留這份紀錄。圖表的每一次修改——改一個決策的標籤、搬動一條分支、改一個門檻——都會寫下一條項目，點名是誰做的、動了哪個欄位、改動前的值，以及現在的值。打開變更日誌看上面那次修改，讀到的正正就是：門檻由具名的某人，由 5,000 美元改成 10,000 美元，並記下時間。沒有人另外手動維護一份 changelog，也沒有人需要相信自己對規則舊貌的記憶。完整機制見 /features/version-control。
追蹤一項變更，不等於管制一項變更。本頁講的是流程被修改之後，QueryChart 保留的那份紀錄——一個事後的事實。變更控制則是決定一次修改應否發生的流程，通常帶有一項申請與一個審閱步驟；那套機制見 /yue/guides/如何建立變更控制流程。而如果討論的對象，是一份成文程序而不是一棵決策樹，同一套變更日誌仍然適用，只是示例走一遍的內容不同——那個版本見 /yue/guides/如何追蹤sop的變更。
審批決策樹，被修改又被追蹤
一棵二十列的文件審批決策樹，由受理到發布分階段展開，中心正是第二位審批人的門檻——正是上面示例改動的那條規則。
一次修改由哪裡開始
圖表由「文件提交審批」開始，然後問「是新文件還是改版？」，若是改版再問「是編輯性修改還是實質性修改？」，之後分岔成「登記今次編輯性更正」，或者完整的「是否屬於受規管的文件類型？」查核——這個分支決定一項變更在任何人審閱之前，會受到多大程度的審視。
把分歧暴露出來的審閱循環
第六到第九列跑的正是審閱本身：「加入品質與法規審閱人」、「收集審閱意見」，然後「所有審閱意見是否都已處理？」——如果未處理，會問「作者能否即時解決？」，再循環或轉去返工。每一次走過這個循環，都會另存為一個版本。
本頁示例改動的那個門檻
「審批人審閱最終稿」帶到「是否批准發布？」，然後到達上面示例所講的那一列：「是否須要第二位審批人？」，答「是」就會走到「取得第二位審批」。調高這一列的門檻，變更日誌會準確記下這次修改。
發布，以及它留下的紀錄
「發布」泳道以三種方式結束這棵樹——「作為小幅編輯性更新發布」、「經完整審批後發布」，或者在「是否須要「已閱讀並明白」確認？」之後「發布並已指派培訓」——另加「退回作者返工」與「已否決並關閉」。每一條把文件送去其中一個結果的規則，都坐落在一個比較版本可以打開的版本裡。
運作方式
修改之後打開變更日誌
每一次儲存都會寫下一個新版本，變更日誌會按次序列出。從圖表的歷史面板打開它，就能看到哪個版本改了、是誰儲存的——你不需要事先知道有一個門檻動過。
讀那條項目：誰改的、哪個欄位、改動前後的值
點進一個版本，它的項目會點名是誰改的、動了哪個欄位——一列的標籤、一條分支的條件、一條泳道的指派——以及它之前的值對比現在的值。這就是誰改了第二位審批人的門檻、舊值是甚麼的完整答案，不用打開任何一條電郵串。
當單一條項目不是全部故事時，用比較版本
單一次修改的項目雖然精準，卻很窄。如果你信任的版本，跟眼前這個版本之間有好幾列都動過，就改用比較版本，把兩者並排讀——同一套機制，只是擴展到所有有差異的欄位。
如果一次修改要撤銷，就還原之前的版本
如果一個調高了的門檻，結果是錯誤而不是刻意的，就還原它之前的版本。還原會直接用那個修訂取代現行圖表，而不是要求某人憑記憶重新打入舊規則。
點名那條規則，不只是分支，令差異保持可讀
圍繞實際的觸發條件去寫一列決策的標籤與它的分支標籤——例如「是否須要第二位審批人？」答「須要」或「無須」——而不是單純的是與否。一條點名了具名欄位的變更日誌項目，遠比一條只說某個未命名方框動過的項目有用得多。
應避免的錯誤
靠聊天記錄與記憶追查一條被改動的規則
沒有變更日誌，一個調高了的門檻只能靠 Slack 訊息與某人對舊數字的記憶重建，而兩者很少一致。每一次欄位級修改其實已經被歸屬並記下日期——這正是 QueryChart 設計來令這種重建變得不必要的原因。
把一次已記錄的修改，誤當成一次已獲批的修改
一條變更日誌項目證明門檻改了、是誰改的——並不證明有人批准了那個新數字。如果一條這樣的規則理應在生效前經過審閱，那個關卡應該放進流程本身，就像 /yue/templates/變更控制流程 那種，而不只是放在版本歷史裡。
假設審計軌跡已經開啟
QueryChart 內建的版本歷史——變更日誌、比較版本與還原——是免費的，並在每一張圖表上無須設定就已在運作。一份對應 ISO 27001、SOC 2 或 HIPAA 控制項的雜湊鏈審計軌跡，是一項獨立的付費功能，需要機構主動開啟；並不是每一張圖表，單單因為修改被追蹤了，就已經自動帶有的東西。
追蹤你自己的流程變更
由文件審批示例開始，修改一列決策的門檻，看着變更日誌準確點名改了甚麼。
相關指南
常見問題
流程改動時，變更日誌準確記錄了甚麼？
每一次修改，都有一條項目點名是誰做的、改了哪個欄位——一列的標籤、一條分支條件、一條泳道的指派——以及那個欄位改動前對比改動後的值。把第二位審批人的門檻由 5,000 美元調高到 10,000 美元，會產生一條準確寫明這件事、有歸屬也有時間戳的項目，不需要任何人另外維護一份紀錄冊。完整機制見 /features/version-control。
追蹤流程變更等於變更控制嗎？
不等於。追蹤一項變更，是修改發生之後 QueryChart 自動保留的紀錄——誰、哪個欄位、舊值、新值。變更控制則是決定一次修改應否發生的流程，通常帶有一項申請、一個審閱步驟與一條回滾路徑。兩者都重要，但回答的是不同的問題；後者的機制見 /yue/guides/如何建立變更控制流程。
這跟追蹤 SOP 的變更有甚麼分別？
變更日誌本身完全一樣——同樣是誰做的、哪個欄位、改動前後的值——因為一棵決策樹與一份成文程序，在同一套版本歷史底下都是圖表。分別在於通常改動的內容：像本頁這樣的流程，改的多是分支條件與路由；SOP 則更常改動步驟文字與職責。同一項功能的那個版本，見 /yue/guides/如何追蹤sop的變更。
我可以看到兩個版本之間改動的一切，不只是一次修改嗎？
可以——打開比較版本，而不是單一條變更日誌項目，它會把兩個版本並排顯示，並標出每一個有差異的欄位。這正是用來處理一條經過幾次小改動、而不是一次明顯改動而慢慢漂移的規則的工具。
還原一個舊版本，會刪除那次改動門檻的修改嗎？
不會。還原只是令一個較舊的版本重新變成現行版本，但門檻改動的那個版本仍然存在於圖表的歷史裡——它的變更日誌項目不會被抹去，所以誰調高了它、何時調高的紀錄，會在還原之後繼續存在。
