版本控制與變更控制的分別
版本控制追蹤哪個修訂現行、改了甚麼；變更控制則決定一項擬議變更應否獲准發生，以及誰要先批准它。
運作方式
在你自己的流程裡，把兩個問題分開
在畫任何東西之前，先決定甚麼屬於變更控制（申請、分類、審閱、審批），甚麼屬於版本控制（識別碼、修訂編號、歷史、還原）。點名這條界線，是大部分流程圖都略過的設計步驟。
先分類，才評估
在評估開始之前，把每一項申請都送經一個小改／大改判斷，就像第 4 列那樣。一次措辭上的小修正，跟一次要求上的大改動，不應該走同一條審閱路徑，預先決定哪個是哪個，能阻止每一項變更都被套上最重的審視。
把版本控制步驟，放在審批真正結束的地方
只在通過審批關卡之後，才遞增版本號、設定生效日期並更新分發清單，絕不能更早。如果你的圖表在那個決定之前就更新版本，就等於描述了一個連被駁回的草稿都會版本化的流程。
給變更控制它自己的審閱人，而不是文件負責人
一位變更審閱人，評估完整影響並記錄它對相關文件及表格的影響，跟申請變更的人分開，這正是「已批准」這個字有意義的原因。在示例裡，這一步坐落在分類與審批決定之間，不是併進其中任何一個。
變更控制決定之後，讓版本控制自行運作
一項變更獲批之後，發布、通知分發清單持有人與回收已作廢的副本，都是機械性的——這是圖表裡版本控制的那條尾巴，也正是 QueryChart 的變更日誌與比較版本畫面，已經替你處理好的那一半，見 /features/version-control。
常見問題
版本控制跟變更控制是同一回事嗎？
不是。版本控制是識別並記住文件連續狀態的機制——一個修訂編號、一份誰改了甚麼的歷史，以及比較或還原較早版本的能力。變更控制則是決定一項擬議變更是否獲准發生、由誰審閱、獲批之前甚麼條件必須成立的管治流程。一份文件可以有嚴謹的版本控制，卻完全沒有變更控制：每一次修改都被儲存，卻沒有人決定它應不應該被做出來。
應該先建立哪一個？
版本控制，因為它通常已經在你底下運作：QueryChart 為每一張圖表自動保留一份帶欄位級差異的變更日誌，附有比較版本畫面，見 /features/version-control。變更控制則是你必須刻意設計的部分——類別、一位審閱人、一個審批關卡——這正是為甚麼它是一個值得畫成流程圖的流程，就像本頁這一張。
這跟修訂控制有甚麼分別？
實際上，「修訂控制」與「版本控制」是同一套機制的不同名稱，兩者關心的都是識別並追蹤文件連續的狀態。變更控制才是不同的那一個：它管治的是一項變更一開始是否獲准，通常在獲批之後以一個新版本結束。如果你要解決的具體是修訂控制／版本控制這個命名問題，見 /yue/guides/修訂控制與版本控制的真正分別。
文件管制在這兩者之間，坐落在哪裡？
文件管制是三者之中最廣的一個：一份受控文件的完整生命周期，由申請經起草、審閱、審批、發布，到最終撤回或退役。變更控制與版本控制都是它的其中一塊——變更控制管治單一項擬議修改，版本控制追蹤那次修改所產生的識別碼與歷史。要看整個生命周期，而不只是變更／版本這條界線，見 /yue/templates/文件變更控制流程，或者較廣的 /yue/guides/如何建立文件管制流程。