準備停用一個 SaaS 要先問誰？盤出工作依賴與負責人清單
停用 SaaS 前，從實際工作、資料流與負責角色找出依賴，安排替代方式和逐項停用順序。
停用一個 SaaS，先問每天用它完成工作的同事，再找流程負責人、資料負責人與維護串接的人一起核對。只確認帳號還有人登入，容易漏掉自動通知、報表或例外處理等營運用途。這份盤點從工作怎麼開始、資料去哪裡，到誰能確認替代方式，逐步整理出停用前需要處理的依賴。
記錄平台目前用途
先記下平台名稱、使用部門和目前知道的續約資訊，再用工作動詞描述用途。不要只寫「專案工具」或「行銷平台」，而要說明誰在什麼情境打開它、要完成哪件事，以及結果交給誰。若一個平台同時用來收件、審核和追蹤進度，分成不同用途列出，才看得出其中一項停用後會影響哪些工作。
盤點時先問實際執行者：「最近一次用它完成了什麼？」「如果當時不能登入，下一步會卡在哪裡？」再請流程負責人補上這項工作的目的、交付對象，以及哪些情況必須如常完成。兩種說法都要保留；遇到描述不同，不急著選一個當標準答案，可以記下差異，等比對近期紀錄或再找相關同事確認。
用途最好包含開始條件、主要操作、完成結果和使用對象，例如「收到活動報名後整理名單，通知承辦人並供會議追蹤」，比「活動管理」更容易判斷是否已找到完整依賴。也要註明是每天處理、特定任務才處理，還是偶爾出現的例外工作；若目前不確定頻率，就標為待確認，不要把印象當成已驗證的使用現況。
假設一個報名平台平常用來收資料，承辦人也會從中整理每週會議名單。只記錄「收集報名」會漏掉會議用途。拆列後，可分別記下報名入口、名單整理方式、通知對象和會議使用者，再向兩組執行者確認現在是否仍照這樣工作。這個例子是假設情境，重點是讓每項用途都能對應到一個具體的工作結果。
每項用途附一種可查證的線索，例如最近的通知紀錄、會議使用的匯出檔，或執行者能重現的操作步驟，並記下由誰確認。這不等於要收集整個帳號的資料，也不是先製作權限清單；目的是讓團隊知道盤點描述從何而來。完成時，清單中的每一用途都應有工作說明、受影響對象和一位已確認或待確認的知情者。
列出依賴工作步驟
沿著一項實際工作從開始追到完成，把平台前後的人工操作和自動處理都列出。每一步說清楚誰觸發、帶入什麼資訊、做了什麼、產生什麼結果，以及下一步由誰接手。若同一工作有不同路徑，例如資料不完整時要退回補件，或急件要另行通知，就分開記錄條件與處理方式，避免只盤到最順利的日常流程。
訪談可以請執行者依最近一次任務回想，不必先問抽象的「有沒有依賴」。從第一個訊號開始追問：工作由誰提出？資料從哪裡來？平台做了哪一步？完成後誰知道？中途停住時，現在如何發現並補救？如果系統自動通知、產生待辦或更新其他紀錄，也要把觸發條件和接收結果的人寫下來，不能只留一句「已串接」。
假設一筆新訂單進入團隊的處理流程，工作者先核對資料，再通知負責人安排後續。盤點應逐步確認訂單何時出現、誰核對哪些內容、通知如何到達，以及負責人依什麼訊息繼續。若資料有缺漏，另外寫明由誰追補、補完後是否回到同一流程。這是假設例子；實際流程要由熟悉工作的人依現況確認，不能照例子猜測平台功能。
再標示每一步屬於人工、平台內操作，或依條件自動發生，並記下常見的失敗訊號。需要時可觀察一次工作實際執行，拿觀察結果和訪談記錄互相比對；如果兩者不一致，把差異交給流程負責人釐清。這能避免把舊文件當作現況，也能揭露只有特定同事知道的補救做法。
最後請流程負責人確認步驟順序、例外路徑和停擺時的影響，讓執行者確認細節，而不是由管理者憑產品說明推演。完成判準是另一位熟悉業務的人能照清單說出工作如何開始、在哪些地方依賴平台，以及什麼結果代表任務完成。若還有空白步驟，標記待確認項目和負責查明的人，再進入替代方案評估。
尋找資料輸入輸出
沿每個步驟記錄資料從哪裡進來、在平台內被如何使用，以及結果流向哪個人或工作環節。把來源、輸出形式、接收對象和後續用途分開寫，避免用「資料在雲端」概括所有情況。若同一筆資料會被人工複製、重新整理或用於不同報表，這些動作也要列入；停用風險往往出現在平台之外的使用方式，而不只在平台裡存了哪些檔案。
訪談資料建立者、日常使用者和負責後續處理的人，逐一確認必要欄位、更新時點、格式要求及缺漏時的應對方式。若有人只知道資料如何輸入，不知道誰依輸出採取行動，再找下一個接手角色核對。資料欄位可以用業務語言描述，例如聯絡方式、處理狀態或負責人，不必把它變成完整的資料庫規格；先找出哪些資訊支撐工作決策。
另外確認是否有通知、下載、複製、報表或其他服務接收資料。資料可以匯出，不代表匯出的內容已包含工作所需欄位、關聯和歷程；先選一筆可辨識的日常案例，對照來源紀錄與後續使用結果，確認能否接續工作。若尚未看過實際輸出或無法重現取得方式，就標記為未驗證，不要在清單上寫成已完成備份或可直接搬遷。
也要記錄哪些資料仍會持續新增、哪些只是查閱歷史、哪些必須留給既有工作使用，並由資料負責人確認差別。涉及保存、刪除或客戶承諾時，請依組織適用的要求另行確認，不要自行假定一個通用期限。這份盤點的用途是指出需要誰作決定、需要什麼資料流才能持續工作，並非取代組織的資料治理或法律判斷。
指定流程聯絡角色
每條依賴流程至少指定能確認業務影響的人，以及熟悉日常操作的人。流程負責人說明這項工作為何要做、何時不能中斷，以及誰承接輸出；實際執行者補充真實步驟和例外狀況。兩種角色有時由同一人擔任，有時不同，清單要如實記錄，別因某人是平台管理者就推定他也了解業務用途。
資料負責人協助確認必要資訊、來源與接收方式；維護串接或自動化的人則說明資料如何流動、發生錯誤時由誰發現。若目前找不到技術聯絡人，就把未知的串接點、已知現象和待查事項交給指定負責人追查。財務或採購聯絡人可提供續約與付款背景，但不能代替工作使用者判斷平台停用後，日常任務是否還能完成。
聯絡方式不必只有姓名，也應寫明角色、負責範圍、可確認的事項和替補聯絡人。先約定遇到流程描述不一致時由誰作業務決定、遇到資料不一致時找誰核對、遇到技術問題時由誰調查，讓問題可以到達真正能回答的人。若角色尚未指派，列成待辦並請主管或流程負責人承接；不要用群組信箱或「資訊部」取代具體責任。
例如，某項每週例行報表由營運同事整理，部門主管使用報表排工作，而資料維護者負責追查輸入差異。三者關心的結果不同：執行者能核對產製步驟，主管能判斷中斷影響，資料維護者能釐清來源。這是假設情境，實際清單應填入能聯絡到的角色與確認範圍，並請他們各自核對自己負責的內容。
負責人欄位還要記下確認狀態和日期，讓後續討論能分辨已核實的依賴與待查假設。若工作跨部門，先由各部門各自確認使用方式，再由共同流程負責人整理相依順序和決策人。這會讓停用討論從「誰管帳號」轉向「誰確認工作可接續」，也減少遇到缺漏時把責任推回最熟悉平台、卻未必最了解流程的人身上。
標記替代方式缺口
逐項檢查每個工作結果目前是否有可行的接續方式：停止該工作是否可接受、能否暫時人工處理，或需評估其他市場方案。不要只在清單寫「找替代品」，而要列出必要條件、尚未確認的能力、資料如何到達使用者，以及誰負責驗證。工具名稱相似，不表示能支援同一流程；先用已盤出的步驟與輸入輸出來比較，才能避免只比較介面或功能列表。
人工備援也要具體：誰接收工作、使用哪份已核對的資訊、如何記錄處理狀態、完成後通知誰。再確認預估工作量是否有人承接、容易出錯的地方如何被發現，以及忙碌時是否有能力維持。若只有「必要時手動做」的說法，卻沒有負責者、操作方式或結果回報，就把它標記為尚未形成可執行的替代方案，而非已解決缺口。
評估外部方案時，可以拿代表性流程做小範圍驗證：從真實但適當的輸入開始，走過必要步驟，確認輸出由下一位使用者接收且足以完成任務。事前列出必須保留的資訊、角色交接點和例外處理，再記錄哪些已驗證、哪些仍未知。這是評估市場方案或可整合的外部服務的方式，不表示本文提到的平台類型就是 ZhenheAI 的自有產品或服務。
缺口可以分成幾類：沒有負責人、沒有資料取得方式、輸出不合用、流程例外無處理方式，或暫時人工執行缺少承接者。每項缺口指定查明人、下一步和作成選擇的角色；如果選擇停止某項用途，也記下誰確認該工作不再需要。不要用一句「待評估」掩蓋不同原因，否則團隊無法知道下一個問題該問誰、何時才有足夠依據決定。
決定前逐一回答：哪項工作能接續、由誰接、資料從哪裡來、什麼情況算失敗、如何發現並補救。若答案缺少關鍵角色或尚未經實際使用者確認，就保留為未解缺口，先排出小步驟驗證。這樣可把「應該能換」轉成可檢查的判準，也讓不採用替代工具、先維持人工處理或暫緩停用等選擇都有明確依據。
安排逐項停用順序
把用途清單和依賴步驟轉成逐項順序，不要一次停掉整个平台後才觀察影響。先處理資料來源、下游使用者和工作結果都已查明、替代方式也已確認的用途；有未知欄位、未找到負責人或例外流程未驗證的項目，先安排補查。排序應以工作依賴關係和出錯後的影響為準，帳號數量或部門名稱不能單獨代表停用風險。
每項預定停用的用途，先約定由誰執行、由誰在旁確認、要觀察哪個工作結果，以及遇到什麼情形就暫停下一步。從實際工作中的一個可辨識案例驗證新流程能否收件、處理、交付和回報；若驗證失敗，回到缺口清單，確認是資料、步驟、角色還是替代方式未到位。不要把一次登入成功當成流程已接續，也不要讓驗證只停在負責操作的人自己的確認。
若原平台仍需要供歷史工作查閱，要先問流程和資料負責人怎樣處理未結案件、舊紀錄和正在使用的輸出。記錄哪些用途仍在運作，哪些已切換，哪些尚未到停用條件，並確認相關工作者知道應採用的現行做法。這裡要追的是營運用途的狀態，不是把一般帳號或離職交接清單搬進來；存取和資料處置需另依組織程序確認。
在每次切換後，讓下一位接手者檢查他是否收到正確資訊，並觀察一個完整工作週期或該用途實際發生時的結果。若某用途很少出現，先確定如何辨認它再次發生、由誰啟動替代流程，不要以短期沒有事件推斷它已不再需要。每項工作都設一個清楚的完成條件，例如輸出已由指定對象接收、例外已有人處理，而不是只記下平台設定已關閉。
最後依清單逐項更新狀態、驗證結果、未解事項和下一位負責人，再由流程負責人確認沒有尚未安排的營運用途。下一步可以先開一張盤點表，填入平台、工作步驟、資料流、聯絡角色和替代缺口，從最常發生的一項流程開始核對；如需進一步了解 ZhenheAI，請前往官網。