1. 功能比較完成後，團隊仍要回答哪些決策問題？
院舍比較過數個管理系統後，常見情況是每個部門都覺得某些功能有用，卻未有人能說清楚採用後由誰決定流程、誰確認資料、誰批准權限，以及遇到例外時由誰作最後取捨。這些未決問題會在上線前後回到前線，形成反覆查詢與不同做法。
可把系統採用視為一連串內部決策，而不只是購買一套工具。先用一張流程責任地圖記錄每個決定的提出人、核實人、批准人和知會對象；以下內容屬院舍的建議準備框架，並非任何產品功能、合規認證或交付承諾。
- 範圍：首階段先處理哪一條高頻工作流程，以及暫不納入哪些情況。
- 責任：誰負責整理現況、誰確認例外、誰有權批准改變原有做法。
- 完成標準：甚麼證據顯示前線可以獨立完成，何時需要暫緩擴展。
2. 先畫出現在怎樣做，而不是直接把舊習慣搬入新系統
可選一條每天或每班都會發生、而且至少涉及兩個角色的流程作起點，例如交更後仍有待跟進事項的處理。由實際負責的同事描述起點、資料來源、交接方式、例外和完成標誌；主管則核對哪些步驟屬於院舍既定程序，哪些只是個人習慣。
這個步驟不是要求團隊一次過重寫所有程序。目的在於找出「下一位同事需要甚麼才可接手」的最小資訊。若資料只存在口頭交代、私人筆記或不受控群組，應先決定正式紀錄位置與核對時間，再討論如何在系統內配合。
3. 資料移交要分清必要資料、待核實資料與不應轉移資料
導入前不宜以「先全部輸入」作為唯一目標。可按首階段流程列出必要資料，並標記哪些已有可靠來源、哪些仍待核實、哪些與試點無關。由資料負責人確認來源和更新責任，避免不同同事同時補錄而留下互相矛盾的版本。
示範、培訓和內部演練應優先使用虛構或已去識別化資料。不要把完整病歷、身份證明文件、登入資料或其他不必要的個人資料傳送到一般通訊群組或非正式測試環境。實際遷移範圍、資料欄位及保存安排應按院舍程序和書面方案確認。
- 必要資料：沒有它便無法完成首階段流程的基本資料與負責人資訊。
- 待核實資料：保留來源、負責人與覆核日期，不把猜測當成正式紀錄。
- 不應轉移資料：與試點無關、來源不明或不應在該環境使用的敏感資料。
4. 權限矩陣應從工作需要出發，不以職銜猜測存取範圍
角色名稱相同，不代表每位同事需要相同存取範圍。建議先列出每一個首階段角色要查閱、建立、修改、確認或只需知會的內容，再由指定主管按院舍政策確認。把「可以看見」和「可以修改」分開討論，才能減少以方便為由而給予過大權限的情況。
試點前可用測試帳戶按真實工作情境檢查：前線能否取得所需資料，主管能否完成核對，而不需要該角色的帳戶能做出超出職責的操作。若需要額外設定或人工程序，應寫入待確認清單，而不是默認已具備。
5. 培訓的完成標準，不應只計算出席人數
不同角色看到的畫面和承擔的結果未必相同，因此培訓宜按角色和流程安排。前線代表可練習建立、查閱與交接；主管代表可練習核對例外、檢視待辦與確認責任；指定支援同事則練習收集問題、分流及跟進。
完成培訓後，請代表在受控環境各自完成一次情境，再記下需要提示的地方。出席記錄只能證明已參與，不能證明已能獨立操作。若同一問題在多名同事身上重複出現，先更新指引或安排補練，再決定是否擴展。
6. 分階段上線，先約定擴展條件與暫緩條件
分階段不是把同一套未驗證做法逐批推開，而是每一階段都留下可檢視的決策點。例如先選一個班次處理一類非緊急待辦，確認交接、資料來源、權限和角色培訓均可運作，再決定是否加入另一班次或流程。
每次檢視要同時看已完成與未解事項：哪些情境已由指定角色完成、哪些仍依賴人工補救、哪些問題需由供應商或院舍管理層回覆。上線日期不應取代完成標準；關鍵資訊遺漏、責任不清或權限不符時，應先暫緩擴展並記錄補救安排。
- 可擴展：必要情境已完成、資料來源已確認、指定角色可獨立操作，並有問題回報途徑。
- 應暫緩：關鍵責任無人承接、資料未核實、權限與工作需要不符，或例外處理仍未說清楚。
- 過渡安排：如需暫用原有方法，指定唯一正式紀錄來源、補錄責任與下次覆核時間。
7. 與 ANI 討論前，帶同哪些資料最有用？
準備一條去識別化的工作流程、一張角色與責任表，以及一份首階段必須處理的例外清單。這樣可以讓示範集中於院舍真正需要確認的情境，而不是只瀏覽一般功能畫面。
與 ANI 團隊交流時，可據此討論 ANI System 4.0 的適用方式和試點範圍。實際功能、設定、費用及交付範圍須按示範結果與書面方案確認；本文不預設任何客製流程、資料遷移、整合、權限設定或培訓安排已包含。
“清楚的採用決定，不只是選定系統，而是讓每位同事知道自己何時接手、何時核對，以及何時可以放心擴展。”
