關閉舊系統前有哪些自動工作要改？建立相依排程盤點表

停用舊系統前，逐項找出仍讀取它的排程、通知與整合，指定新接收位置、核對樣本、安排觀察窗口，並確認沒有殘留觸發。

關閉舊系統前，常被漏掉的不是資料本身，而是仍在讀取資料、寄送通知或啟動下一步的自動工作。盤點時請沿著「誰觸發、讀取什麼、送到哪裡、誰驗證」追蹤每一條依賴，再據此安排切換與停用。

列出舊系統資料出口

關閉舊系統前，先把資料出口拆成一筆筆可追蹤的動作，不要只列系統名稱。找出排程匯出、API 或 Webhook 回傳、資料庫檢視、郵件附件，以及人工下載再上傳的流程；每一筆記下觸發時間、頻率、篩選條件、輸出格式、欄位、收件對象和失敗時的查看位置。若流程只有同事記得，先標示待確認，並請實際操作者對照執行紀錄。

資料出口還要寫清楚來源責任：誰建立檔案、檔名與路徑如何形成、是否覆寫前次檔案、空資料代表正常或錯誤，以及下游靠什麼辨認新版本。盤點從舊系統複製到試算表、共享資料夾或外部平台的中間步驟，因為人工轉傳常被排程清單漏掉。同一檔案若有多個副本，應按觸發方式和接收用途記錄，避免把副本誤認為獨立來源。

假設每晚產生的訂單檔會由營運同事下載，再匯入另一工具，清單就要同時記錄自動產檔與人工匯入，而不是只寫訂單匯出。對照排程設定、近期檔案時間與接收端紀錄，確認任務仍在執行，以及資料確實被使用。若取不到紀錄，寫明缺少哪項證據、由誰補查、何時回報，不要把口述直接標成已驗證。

可用一個完整出口描述來收尾：來源是舊系統的某組欄位，觸發方式是固定排程，輸出後由哪個工作或人員接收，資料用於哪個營運步驟。盤點的完成條件不是欄位填滿，而是每個出口都有明確用途、接收者與可查證的執行證據。遇到用途不明或長期無人確認的出口，先列為待判定，避免在切換時順手保留不必要的讀取權限。

找出排程與通知相依

從資料出口往下追，找出哪些工作會讀取舊系統、舊檔案或舊網址，並記錄完整的觸發鏈。自動工作可能由時間排程啟動，也可能由新資料到達、欄位狀態改變、收到郵件或人工按下匯入引起。每一項都要分別辨認啟動者、讀取來源、執行動作、通知對象與下一個接手流程；只抄排程名稱，無法看出停掉來源後哪些事情會一起失效。

通知也要納入相依清單。提醒可能由舊系統直接寄出，也可能是外部排程定時查詢舊資料，再發訊息給團隊；通知內容即使只含摘要，仍可能依賴舊系統的狀態或收件名單。檢查近期任務紀錄、通知樣本、寄件來源和接收者，並詢問負責人平常看到訊息後會做什麼。若沒有人能指出後續動作，先確認通知是否仍有用途，再決定是否移接或停用。

假設某筆訂單逾期後，舊系統的狀態會讓外部郵件工具發出提醒，這時依賴就不只有一個通知工作。還要記下狀態由誰更新、外部工具何時查詢、寄給誰，以及通知失敗時有沒有替代提醒。若排程每週才執行一次，短時間觀察未必能證明它不再觸發；若觸發頻率不明，就標記未知，安排操作紀錄或實際負責人協助確認。

把每條鏈拆成可獨立驗證的列，並標記上下游關係、相依強度與業務影響。可用高、中、低作為團隊自己的優先級：會影響收款、交付或每日作業的項目優先處理；只供參考的報表則確認使用者和備援方式後安排。這是排序工具，不代表所有高優先級工作都必須搬遷；有些可以停用，但需先由實際使用者確認沒有替代流程依賴它。

指定新接收位置

每項仍要保留的工作，都要明確指定新的讀取來源或接收位置，並把責任交給一位能核對結果的人。目的地可以是新系統中的資料區、受控共享資料夾、外部郵件或訊息工具，也可能是暫時由人員接手；這些是常見選項，不代表每個組織都已具備。記清目的地的名稱、資料格式、必要欄位、存取責任與下游用途，讓執行者能依照清單設定與驗收。

下表是純假設情境，用來示範盤點欄位，不是任何組織的既有設定。新目的地要先確認有人管理且使用者有權限，再測試檔案或訊息如何到達。若目的地尚未準備好，應把該項列為切換阻礙，保留舊流程並標明預定處理責任，不要先關閉來源再等待新端建置完成。

對每個目的地再問三件事：資料會由誰建立或轉送、哪個角色能確認收到、格式或欄位不符時由誰修正。若以人工暫代自動傳送，清單要標出負責人、執行時點和交接方式，避免「先人工處理」變成沒有期限的隱性工作。相反地，若新端尚無明確管理者，先解決責任歸屬再排切換，否則即使設定完成，也可能沒有人察覺資料已中斷。

完成目的地欄位後，將每條工作和預期結果連起來，例如新位置應出現哪種資料、由哪個人或流程使用、何時判定到位。不要只留一個網址或資料夾路徑，還要寫出辨認正確內容的方式。若來源與目的地欄位不同，先列出必須轉換或重新命名的欄位，並請實際接收者確認理解一致，讓後續抽樣核對有共同基準。

用樣本核對執行結果

切換前先定義一筆可比較的樣本，記下舊來源的識別值、必要欄位和預期接收端結果，再依相同條件執行新流程。核對至少涵蓋資料有沒有到、欄位是否對應、格式是否可讀、通知是否送到正確對象，以及重跑後會不會多出重複資料。測試樣本應由流程負責人確認具有代表性；若涉及個人或敏感資料，使用經核准的測試資料或遮蔽後資料，並遵守團隊既有存取規範。

假設一筆測試批次預期包含十二筆紀錄，接收端實際也看到十二筆，這只能支持筆數相符，不能單獨證明每一筆內容都正確。還要抽查識別值、日期、狀態、空值和收件對象；確認同一筆資料沒有漏欄、錯欄或重複。這個數字只是操作示例，不是建議的固定樣本量。若流程資料量或風險不同，應由負責人選擇足以檢查關鍵情況的樣本。

把執行前後的證據放在同一筆盤點紀錄裡，例如來源截取時間、輸入筆數、接收時間、輸出筆數、欄位差異、執行紀錄位置和檢查人。若通知是驗收重點，也保存一則測試通知的內容與實際收件確認；若沒有可查的成功紀錄，就不要只憑「畫面看起來正常」結案。發現差異時，記錄預期與實際、重現方式、處理者和再次核對結果，讓修正後的證據取代舊結果。

還要測一次失敗或重跑的處理方式：缺少來源檔時會停止、提示哪位負責人，還是悄悄產生空報表？重試會接續處理，還是再次建立相同通知？只有在可控且不會觸發真實外部作業的條件下才測例外；否則用過往紀錄和設定檢視確認處理規則。測試通過的定義應事先寫清楚，包含允許的差異、必須修正的差異，以及誰有權接受剩餘風險。

安排停用與觀察窗口

停用安排要跟著工作頻率和業務節奏走，不要只選一個方便操作的時間。先確認每項工作多久執行一次、是否有月底或週期性批次、下游使用者何時會檢查，以及失敗後能否在可接受時間內恢復。觀察窗口至少要足以看到關鍵工作完成一輪；低頻工作如果尚未到下一個執行週期，就不能只因平日沒有錯誤訊息而判定安全。

把切換前、切換當下和觀察期間的責任人寫清楚。切換前由來源負責人確認最後一次資料輸出，接收者確認新端準備妥當；切換當下由執行者按清單逐項更新，記錄完成時間與未完成原因；觀察期間則由指定人員核對資料、通知與下游作業。假設某工作每週才跑一次，就把觀察安排到能核對一次預期執行的時點；若時間安排做不到，應延後停用或準備明確的人工替代步驟。

切換前先保留必要的設定紀錄、目的地資訊、執行依據與復原步驟，並標明哪些項目暫時維持可恢復狀態。這不是要求永久保留舊系統資料，而是確保遇到漏送、錯誤通知或報表缺值時，有人能依既定方式回到安全狀態。若復原仰賴未確認的密碼、權限或外部供應者協助，這些條件要在排定停用前查明，不能到出錯時才發現無法操作。

預先設定觀察期間的判斷條件：哪些紀錄代表新流程正常、哪些差異要立即暫停、誰能決定延長觀察，以及什麼情況需要回復舊流程。觀察結束時，由資料提供者與接收者共同核對清單，逐筆標記完成、停用或仍待處理，並記下剩餘依賴與下一次追蹤時間。若有高影響工作尚無負責人、目的地或驗證證據，就把停用日期視為未達成條件，不要用整體進度掩蓋單一未解項目。

確認沒有殘留觸發

完成切換後，再按盤點時使用的來源名稱、網址、檔案路徑、欄位名稱和任務關鍵字，檢查可能保存舊連線資訊的位置。範圍可包括排程設定、通知規則、外部整合、腳本、試算表公式、共享資料夾捷徑和人工作業說明。各處是否能直接查到會因工具與權限不同而異；清單應記下實際檢查的位置、檢查人和結果，無法查看的地方標為未確認，交由該工具的管理者補查。

殘留依賴不一定會每天觸發。某個月度報表可能直到月底才讀取舊欄位；舊通知地址也可能只在異常時才被使用。逐項對照執行紀錄和排程週期，並請下游使用者確認目前工作方式是否已改接。對已停用項目，確認觸發不再執行、通知不再送往舊收件位置、外部端沒有持續查詢舊來源；若缺少紀錄，就保留未確認狀態，而不是把沒有收到抱怨當成證明。

確認再無依賴後，依組織的權限管理程序處理舊連線、存取權與憑證，並記錄由誰核准及何時完成。若同一組連線資訊仍供其他工作使用，就先確認影響範圍並為仍需保留的工作安排替代存取；不要只為求清乾淨而一併移除仍在使用的權限。之後若監控或使用者回報出現舊來源呼叫，記下觸發時間、來源位置和受影響工作，再回到相依清單定位負責人。

現在可先選一項仍讀取舊系統的排程，填上來源、觸發方式、接收位置、驗證責任和停用條件，再與執行者及接收者共同核對，從一條依賴開始建立完整清單。若想進一步了解品牌目前公開的資訊，可查看 ZhenheAI 首頁，再依實際需要判斷下一步。