變更請求單（Change Request Form）是專案管理中正式記錄「誰要改、改什麼、為什麼改、影響多大」的標準文件。這篇教學帶你從欄位設計、填寫步驟、審核流程到數位化管理，一次建立可重複使用的變更管理制度。
什麼是變更請求單？
變更請求單（Change Request Form）是一份正式文件，用來記錄專案執行過程中任何偏離原始計畫的需求。它的核心功能是把「誰、要改什麼、為什麼改、影響範圍有多大」這四件事白紙黑字記錄下來，確保每一次變更都經過評估和核准才執行。
很多團隊習慣用口頭溝通或 Email 處理變更需求，但這兩種方式有致命缺陷：口頭溝通沒有紀錄，事後各說各話；Email 散落在不同信箱裡，三個月後根本找不到當初的決策依據。變更請求單的價值就在於——它是唯一可追溯、可稽核的變更紀錄。
舉個我們實際遇過的案例：一家製造業客戶的工程師口頭答應客戶修改產品規格，沒有填寫任何書面文件。結果這個規格變更連帶影響了模具設計和原料採購，等到生產線發現問題時已經延誤交期兩週，額外成本超過 NT$150,000。如果當初有一張變更請求單，PM 在初審階段就能攔截這個影響範圍被低估的變更。
變更請求單適用的場景非常廣泛：工程變更、IT 系統升級、設計修改、產品規格調整、合約條款變更等。在整個變更管理流程中，它是「啟動點」——沒有這張單，後續的影響評估、核准決策、執行追蹤都無從開始。
變更請求單應包含哪些欄位？
一張好的變更請求單，欄位設計決定了它能不能真正發揮作用。以下是我們團隊經過多次迭代後整理出的必填欄位與進階欄位。
必填欄位
| 欄位名稱 | 說明 | 填寫範例 |
|---|---|---|
| 變更編號 | 唯一識別碼，便於追蹤與歸檔 | CR-2025-0042 |
| 申請人資訊 | 姓名、部門、聯絡方式、申請日期 | 王小明／製造部／分機 2301／3月15日 |
| 變更標題 | 一句話描述變更內容 | 產品 A 外殼材質由 ABS 改為 PC |
| 現況描述 | 目前的狀態是什麼 | 現行規格使用 ABS 塑料，厚度 2mm |
| 期望狀態 | 變更後要達到什麼結果 | 改用 PC 塑料，厚度維持 2mm，提升耐衝擊性 |
| 變更原因 | 為什麼需要這個變更 | 客戶端測試發現 ABS 在低溫環境易脆裂 |
| 優先等級 | 緊急／一般／低 | 一般 |
| 影響範圍評估 | 對時程、成本、品質、相關系統的影響 | 模具需修改（+NT$80,000）、交期延後 5 天 |
| 風險評估 | 執行此變更可能產生的風險 | PC 材料成本較高，長期量產成本增加約 12% |
| 審核簽核欄 | 申請人、PM、主管、客戶（視需要） | 各角色簽名與日期 |
優先等級的判斷標準是團隊常常搞混的地方，這裡提供一個簡單的定義框架，你可以根據自己的產業調整門檻值：
| 等級 | 判斷標準 | 審核時限 | 範例 |
|---|---|---|---|
| 緊急 | 影響生產線停擺、系統當機、安全風險 | 4 小時內決策 | 伺服器漏洞需立即修補 |
| 一般 | 影響時程或成本，但不立即危害營運 | 3 個工作天 | 產品材質變更 |
| 低 | 優化性質，不影響現有功能或交期 | 5 個工作天 | UI 配色微調 |
進階欄位（大型專案適用）
對於跨部門或高複雜度的專案，建議額外加入：
- 回滾計畫（Rollback Plan）：如果變更執行後出問題，如何恢復到原始狀態。這在 IT 系統變更中尤其關鍵。
- 相關文件版本號：記錄這次變更影響到哪些文件的哪個版本，例如「規格書 v2.3 → v2.4」、「圖面 DWG-A001 Rev.C → Rev.D」。
我們曾協助一個 IT 團隊導入系統升級，他們的變更請求單缺少「影響範圍評估」欄位，只寫了「升級 ERP 模組 A」。結果上線後才發現模組 A 與模組 B、C 有資料串接，三個子系統連帶出錯，花了整整一週才修復。如果當初表單上有這個欄位，負責人就必須在申請階段就盤點所有關聯系統。
如果你想把這些欄位設計成可重複使用的流程圖，可以先用流程圖工具把審核路徑視覺化，再對應到表單欄位。
變更請求單範本（Word、Excel、PDF 三種格式）
根據團隊規模和使用情境，我們整理了三種格式的範本，各有適合的場景：
Word 格式——適合小型團隊或一次性專案。可以直接編輯欄位內容，排版彈性大，適合需要附加大量文字說明的變更（例如設計變更的理由論述）。缺點是多筆變更難以統一管理。
Excel 格式——適合需要追蹤多筆變更的團隊。內建自動編號公式、下拉選單（優先等級、狀態）、條件格式（逾期自動標紅），可以同時當作變更登錄簿使用。我們團隊在管理中型專案時最常用這個格式。
PDF 格式——適合需要實體簽核的傳統製造業或建築業。列印後由各層級主管親筆簽名，歸檔時作為正式文件保存。如果你的公司還在使用紙本簽核流程，PDF 是最穩定的格式。
👉 下載變更請求單範本（Word 格式） 👉 下載變更請求單範本（Excel 格式） 👉 下載變更請求單範本（PDF 格式）
填寫範例：完整的變更請求單示範
以下是一份填寫完成的變更請求單範例，你可以直接複製格式並替換成自己的內容：
| 欄位 | 填寫內容 |
|---|---|
| 變更編號 | CR-2025-0042 |
| 申請日期 | 2025 年 3 月 15 日 |
| 申請人 | 王小明／製造部／分機 2301／[email protected] |
| 專案名稱 | 智慧家電 X200 量產專案 |
| 變更標題 | 產品 X200 外殼材質由 ABS 改為 PC |
| 現況描述 | 現行規格使用 ABS 塑料（型號 PA-747），外殼厚度 2mm，供應商為台塑。目前已完成試模，預計 4 月 1 日進入量產。 |
| 期望變更 | 改用 PC 塑料（型號 Lexan 141R），厚度維持 2mm，供應商改為 SABIC。需重新開模並完成 3 次試模驗證。 |
| 變更原因 | 客戶端低溫環境測試（-20°C）發現 ABS 外殼出現脆裂，不符合 UL 94 V-0 阻燃標準。客戶要求 4 月 30 日前提供通過測試的樣品。 |
| 優先等級 | 一般（影響時程與成本，但不涉及安全風險或產線停擺） |
| 影響範圍評估 | 成本：模具修改費 NT$80,000＋PC 材料單價較 ABS 高 18%（年增成本約 NT$216,000）。時程：量產日期從 4 月 1 日延後至 4 月 15 日（延後 10 個工作天）。品質：需重新執行落摔測試、阻燃測試、尺寸公差驗證。關聯影響：包裝設計不受影響；產品說明書材質標示需更新（文件 DOC-X200-SPEC v1.2 → v1.3）。 |
| 風險評估 | 1. PC 材料交期 14 天，若供應商延遲將進一步影響量產時程（機率：中）。2. 新模具首次試模良率可能低於 90%，需預留 2 次修模時間（機率：高）。3. 長期量產成本增加約 12%，需與客戶協商是否調整報價。 |
| 因應措施 | 1. 同步聯繫備用供應商（奇美）報價，確保材料供應不中斷。2. 模具廠已確認可在 5 個工作天內完成修模。3. 業務部已排定 3 月 20 日與客戶討論報價調整。 |
| 附件 | 客戶測試報告（TEST-X200-0312.pdf）、SABIC 材料規格書、模具廠修模報價單 |
| 申請人簽名 | 王小明 ／ 2025.03.15 |
| PM 初審 | ☐ 資訊完整，送交影響評估 ☐ 退件，原因：____ |
| 評估結論 | （影響評估會議後填寫） |
| 核准／拒絕 | ☐ 核准 ☐ 拒絕 ☐ 有條件核准，條件：____ |
| 核准人簽名 | _ ／日期：_ |
如果你的團隊同時需要處理工程變更申請單（ECR）和一般變更請求單，建議在 Excel 範本中增加一個「變更類型」下拉欄位（工程變更／IT 變更／設計變更／其他），這樣可以用同一個範本管理不同類型的變更，後續篩選和統計也更方便。
對於需要更完整的專案文件管理，可以參考企劃書的撰寫架構，把變更請求單納入整體專案文件體系中。
變更請求單的標準審核流程（5 個步驟）
有了表單還不夠，沒有明確的審核流程，變更請求單只是一張廢紙。以下是我們建議的 5 步驟標準流程，你可以根據團隊規模調整細節。
Step 1：提交申請
誰可以提？ 原則上任何專案相關人員都可以提交變更請求，包括團隊成員、客戶、供應商。但建議統一由 PM 或指定窗口協助填寫，確保資訊完整性。
透過什麼管道？ 最理想的方式是透過數位表單（後面會介紹工具），次選是 Email 附件，最不建議的是口頭告知後「之後再補單」——根據我們的經驗，「之後再補」有 70% 的機率變成「永遠不補」。
Step 2：PM 初審（確認資訊完整性）
PM 收到變更請求單後，第一件事不是判斷要不要做，而是確認表單填寫是否完整。常見的退件原因包括：
- 影響範圍寫「無」或留空（幾乎不可能真的沒有影響）
- 變更原因只寫「客戶要求」，沒有具體說明
- 缺少優先等級判斷
- 沒有附上相關的技術文件或圖面
初審的目的是確保後續評估有足夠的資訊可以判斷，而不是在評估會議上才發現「資料不夠，下次再議」。
Step 3：影響評估（技術、成本、時程三維度）
這是整個流程中最關鍵的步驟。影響評估需要從三個維度進行：
- 技術可行性：這個變更在技術上能不能做？需要哪些資源？
- 成本影響：直接成本（材料、人力）和間接成本（機會成本、其他任務延遲）
- 時程影響：會延後多少天？是否影響關鍵路徑上的里程碑？
評估會議建議邀請相關部門的技術負責人參加，時間控制在 30 分鐘內。會議結束前必須產出一份書面評估結論，附在變更請求單上。
如果你的團隊在評估優先順序時常常陷入爭論，可以參考艾森豪矩陣的四象限分類法，把變更需求按「影響程度」和「緊急程度」分類。
Step 4：核准或拒絕
根據影響評估結果，使用以下決策矩陣來決定處理方式：
| 影響程度低 | 影響程度高 | |
|---|---|---|
| 緊急程度高 | PM 可直接核准，事後通知主管 | 召開緊急會議，主管＋客戶共同決策 |
| 緊急程度低 | 排入下次迭代或版本更新 | 完整評估後提交變更委員會（CCB）審議 |
核准或拒絕的結果都必須書面記錄在變更請求單上，包括決策理由。這不只是為了存檔，更是為了讓申請人理解決策邏輯——特別是被拒絕時。
Step 5：執行與結案
變更核准後，PM 需要完成以下動作：
- 更新專案計畫：調整時程、預算、資源分配
- 通知相關人員：發出變更通知（這就是「變更通知單」的用途，後面會詳細說明）
- 更新文件版本：所有受影響的規格書、圖面、合約都要更新版本號
- 追蹤執行進度：確認變更已按計畫完成
- 結案歸檔：在變更請求單上記錄實際完成日期和結果
一家建築工程公司在導入這套 5 步驟流程後，變更導致的返工率從 23% 降至 8%。最大的改善來自 Step 3 的影響評估——以前工地主任常常跳過評估直接執行客戶的變更要求，事後才發現預算超支或與其他工項衝突。
不同產業的變更請求單應用差異
變更請求單的核心架構是通用的，但不同產業在欄位設計和審核流程上有明顯差異。以下是四個主要產業的應用重點。
工程／製造業：ECR 與 ECN 的銜接
在製造業中，變更管理通常分為兩個階段：
- 工程變更申請單（ECR, Engineering Change Request）：等同於本文說的變更請求單，用於「申請階段」
- 工程變更通知單（ECN, Engineering Change Notice）：ECR 核准後發出的正式通知，告知所有相關部門「這個變更已經核准，請按以下內容執行」
ECR 和 ECN 是一對一的關係——每一張核准的 ECR 都會產生一張 ECN。ECN 上會包含更具體的執行細節：生效日期、受影響的料號清單、庫存處理方式（現有庫存用完再切換，還是立即報廢）、圖面版次變更紀錄。
IT／軟體開發：ITIL 變更管理
IT 產業的變更管理通常遵循 ITIL 框架，將變更分為三類：
- 標準變更（Standard Change）：風險低、已有 SOP，預先核准即可（例如：新增使用者帳號）
- 一般變更（Normal Change）：需要走完整審核流程（例如：資料庫架構調整）
- 緊急變更（Emergency Change）：系統當機或安全漏洞，可先執行再補審核，但事後必須在 24 小時內完成文件補齊
緊急變更的特殊流程是很多 IT 團隊忽略的重點。「先做再說」不代表「不用記錄」，而是把審核時間從事前壓縮到事後，但文件完整性的要求不變。
設計／創意產業：版本控制是關鍵
設計變更單的最大挑戰不是審核流程，而是版本控制。一個 Logo 設計可能經過 15 個版本，如果變更請求單沒有明確記錄「從哪個版本改到哪個版本」，設計師很容易改錯基底檔案。
建議在設計變更單中增加「基準版本」和「目標版本」兩個欄位，並要求附上視覺對照圖（Before / After）。
建築工程：變更與合約金額連動
建築工程的變更幾乎都涉及合約金額調整。變更請求單必須附上估價單，並經過業主書面同意後才能執行。這個產業的審核層級通常最多——工地主任、專案經理、營造廠主管、建築師、業主，一張單可能要跑五個簽核。
| 產業 | 常見變更類型 | 關鍵欄位差異 | 審核層級 |
|---|---|---|---|
| 工程／製造 | 材質、規格、製程 | 料號、圖面版次、BOM 影響 | PM → 工程主管 → 品保 |
| IT／軟體 | 系統設定、程式碼、架構 | 回滾計畫、測試環境、上線時間 | PM → 技術主管 → IT 經理 |
| 設計／創意 | 視覺、文案、UX 流程 | 基準版本、目標版本、視覺對照 | 設計師 → 設計主管 → 客戶 |
| 建築工程 | 設計圖、工法、材料 | 估價單、合約條款、業主同意書 | 工地主任 → PM → 建築師 → 業主 |
一家半導體設備商同時需要管理 IT 系統變更和工程變更，最初用兩套完全不同的表單，造成跨部門溝通困難。後來他們採用統一範本，加上一個「變更類型」下拉欄位和對應的條件欄位（IT 變更顯示回滾計畫欄、工程變更顯示料號欄），成功用一套系統管理所有變更。
如果你的組織正在推動數位轉型，統一變更管理流程是一個很好的切入點——它的影響範圍明確、成效容易量化、而且每個部門都用得到。
數位化工具推薦：用軟體管理變更請求單
當你的團隊每個月處理超過 10 筆變更請求時，紙本或 Email 管理就會開始失控。常見的問題包括：
- 版本混亂：同一張變更單被不同人修改，不知道哪個是最新版
- 簽核卡關：單子卡在某個主管信箱裡，沒人知道進度
- 追蹤困難：三個月後要查某筆變更的決策紀錄，翻遍 Email 也找不到
數位化工具可以一次解決這三個問題。以下是我們實際測試過、適合台灣團隊使用的工具比較：
| 工具 | 適合規模 | 變更管理功能 | 月費（每人） |
|---|---|---|---|
| monday.com | 5-50 人中型團隊 | 自訂表單＋審核流程自動化＋狀態追蹤 | 約 NT$288 起 |
| ClickUp | 技術導向團隊 | 表單＋自動化＋自訂欄位＋文件版本控制 | 約 NT$230 起 |
| Jira | IT 團隊（ITIL 合規） | Issue 追蹤＋變更管理工作流＋ITSM 模組 | 約 NT$260 起 |
| Notion | 5 人以下小型團隊 | 資料庫＋範本＋關聯資料表 | 免費方案可用 |
| Google Forms + Sheets | 預算極有限 | 基本表單＋試算表追蹤 | 免費 |
| — | — | — | — |
| 免費試用 → | monday.com | ClickUp | Notion |
我們團隊怎麼用 monday.com 管理變更請求
我們團隊實際使用 monday.com 管理變更請求的經驗是這樣的：我們建了一個「變更請求」看板，每一列就是一筆變更，欄位包含申請人、變更類型、優先等級、狀態（待審核／評估中／已核准／已拒絕／執行中／已結案）、負責人、到期日。
最有用的功能是自動化規則——我們設定了「當狀態改為『待審核』時，自動通知 PM」和「當變更逾期未處理超過 2 天，自動通知主管」。這兩條規則在過去半年觸發了超過 40 次，每次都讓卡關的變更在擴大前被處理。以前我們用 Excel 追蹤，平均每筆變更的審核週期是 5.2 天；切換到 monday.com 後降到 2.1 天。
免費方案不需要信用卡，最多可以 2 位使用者，適合先試用看看流程是否順暢。
選擇工具的 3 個判斷標準
不確定該選哪個工具？用這三個問題快速判斷：
- 團隊規模：5 人以下用 Notion 免費版就夠了；5-50 人跨部門協作選 monday.com；技術團隊跑 Scrum 可以考慮 ClickUp
- 審核層級複雜度：如果你的變更需要跑 3 層以上簽核，需要有自動化通知功能的工具（monday.com 或 ClickUp）；IT 團隊需要 ITIL 合規的變更管理流程，Jira 的 ITSM 模組有內建的標準變更、一般變更、緊急變更分類，與前面提到的 ITIL 三類變更直接對應
- 系統整合需求：如果需要與 ERP、CRM 或其他系統串接，monday.com 的 API 和整合生態系最完整
一個 10 人的新創團隊用 Notion 資料庫範本管理每月約 5-8 筆變更，完全夠用。而一家 50 人的製造業公司需要串接 ERP 系統、每月處理 30+ 筆工程變更，他們選擇 monday.com 後，把變更請求表單直接嵌入內部入口網站，員工填完表單就自動建立任務卡片並通知 PM。
建立可重複使用的變更管理工作流程
單張變更請求單只能解決一次性的問題。如果你想讓團隊的變更管理能力持續提升，需要從「填表」升級到「系統化流程」。以下是 4 個關鍵動作。
動作 1：建立變更請求單範本庫
不要只有一個萬用範本。根據你的產業和常見變更類型，建立 2-3 個專用範本：
- 通用版：適用於大多數變更需求
- 工程變更版：增加料號、圖面版次、BOM 影響欄位
- IT 變更版：增加回滾計畫、測試環境、上線時間窗口欄位
把這些範本放在團隊都能存取的位置（共享資料夾或專案管理工具的範本庫），確保每個人都用最新版本。
動作 2：設定審核 SLA
沒有時限的審核流程等於沒有流程。建議設定明確的服務等級協議（SLA）：
- 緊急變更：4 小時內完成決策
- 一般變更：3 個工作天內完成評估與決策
- 低優先變更：5 個工作天內回覆
SLA 不只是對申請人的承諾，更是對審核者的約束。搭配工具的自動提醒功能，逾期未處理的變更會自動升級通知。
動作 3：建立變更登錄簿（Change Log）
變更登錄簿是所有歷史變更的彙總清單，讓你一眼看到專案從開始到現在經歷了多少變更、每筆變更的狀態、累計的時程和成本影響。
基本欄位包含：變更編號、申請日期、申請人、變更標題、優先等級、狀態、核准日期、結案日期、累計成本影響。
如果你用 Excel 管理，變更登錄簿可以是變更請求單工作簿中的另一個分頁，用公式自動彙總。如果你用 monday.com，看板本身就是變更登錄簿，搭配 Dashboard 功能可以即時看到變更趨勢圖。
動作 4：定期回顧與流程優化
每季花 30 分鐘回顧變更登錄簿，分析以下問題：
- 哪類變更最頻繁？能不能從源頭預防？
- 平均審核週期是否符合 SLA？
- 被拒絕的變更佔比多少？拒絕原因是否集中在某些類型？
一家電商公司發現每次大型促銷前都會湧入大量 IT 變更請求（調整伺服器容量、修改結帳流程、更新促銷頁面），建立標準化的「促銷前 IT 變更 SOP」後，審核時間從平均 4.5 天縮短到 1.8 天，縮短了 60%。
定期回顧的頻率建議：每季一次，每次 30 分鐘，產出一份流程優化清單，列出下一季要改善的 2-3 個具體項目。
結論
變更請求單看似只是一張表單，但它背後代表的是一套完整的變更管理制度。回顧本文的核心重點：
- 變更請求單的本質是把口頭需求轉化為可追溯、可稽核的書面紀錄，避免「各說各話」的風險
- 欄位設計決定表單品質——影響範圍評估和風險評估是最容易被忽略、卻最關鍵的兩個欄位
- 5 步驟審核流程（提交→初審→影響評估→核准/拒絕→執行結案）是確保每筆變更都經過充分評估的骨架
- 不同產業需要不同的欄位配置——製造業重視料號與圖面版次，IT 重視回滾計畫，建築業重視估價與合約連動
- 從單張表單升級到系統化流程，需要範本庫、審核 SLA、變更登錄簿和定期回顧四個動作
你的下一步行動：先從本文的欄位清單建立一張適合你產業的變更請求單範本，然後在團隊中試跑一個月。如果你每月處理超過 10 筆變更，建議直接用數位工具管理——在 monday.com 建立變更請求看板，用自訂表單收集申請、用自動化規則推動審核流程，10 分鐘就能建好你的第一個變更管理系統。
變更請求單常見問題
變更請求單和變更通知單有什麼不同？
變更請求單是「申請階段」的文件，用來記錄變更需求並送審。變更通知單（Change Notice）是「核准後」的文件，用來正式通知所有相關人員：這個變更已經核准，請按以下內容執行。簡單來說，請求單是「我想改」，通知單是「確定要改了，大家照做」。在製造業中，這兩份文件分別對應 ECR（Engineering Change Request）和 ECN（Engineering Change Notice）。
小型專案也需要填變更請求單嗎？
不是每個變更都需要正式表單。我們的判斷標準是：如果這個變更影響超過 1 個工作天的時程，或成本超過 NT$5,000，就建議書面化。低於這個門檻的微調，PM 在會議紀錄或問卷中簡單記錄即可。重點不是表單的形式，而是「有沒有留下紀錄」。
客戶口頭要求變更，要怎麼處理？
三步驟處理：第一，口頭確認客戶的需求細節（改什麼、為什麼改、期望時程）；第二，立即補填變更請求單，用 Email 或系統發給客戶確認；第三，取得客戶書面確認（Email 回覆「確認」即可）後才開始執行。絕對不要在沒有書面紀錄的情況下就動手——這是保護你自己也保護客戶的做法。
變更請求被拒絕後，申請人可以怎麼做？
被拒絕不代表永遠不能做。申請人可以：補充更完整的影響評估資料（例如量化效益數據）、調整變更的優先等級或範圍（縮小影響面）、或者申請重審流程。重審時建議邀請不同的評估者參與，避免單一觀點造成的偏誤。
工程變更申請單和一般變更請求單有什麼差別？
工程變更申請單（ECR）是變更請求單在製造業的專用版本。除了一般欄位外，ECR 通常需要額外附上：受影響的料號清單、圖面版次變更紀錄（例如 Rev.B → Rev.C）、BOM（物料清單）影響範圍、成本估算明細、以及庫存處理方式。如果你的公司同時有 IT 變更和工程變更，建議用統一範本加上「變更類型」欄位來區分，而不是維護兩套完全不同的表單。
