結論：接管成敗取決於能否在運營開始前説清誰負責什麼
Support與AMS項目更常因邊界模糊而失敗，而不只是工程師不足。目標系統、責任、訪問、第三方依賴、服務時間和驗收條件必須明確。首次詢價至少應包含以下12項。
1—4：範圍與責任
- 目標系統、產品、版本和環境，包括生產與非生產邊界
- 支持地點、用户數量、語言以及需要現場到場的地點
- 客户、服務商和原供應商之間的RACI及最終決策人
- 事件、問題、變更、發佈和服務請求的分類與責任
5—8：訪問、覆蓋與依賴
- 賬號開通、審批、MFA、VPN、日誌和權限撤銷流程
- 正常服務時間、節假日、值班及重大事件聯繫方式與目標
- 雲、通信、硬件、軟件等第三方合同、權益和支持路徑
- 個人信息、機密信息、跨境訪問、終端與數據留存限制
9—12：知識、驗收與改進
- 架構圖、運行手冊、FAQ、已知錯誤、作業、接口和聯繫人樹
- 未結工單、技術債、風險、待處理變更和發佈計劃
- 並行期、驗收測試、簽字負責人和退回條件
- 與目標一致的少量指標：響應、解決、積壓、復發和變更成功率
人力容量合同不等於託管服務
人力容量合同主要購買可用工時；託管服務在約定範圍內承擔運營責任、流程、報告和改進。二者沒有絕對優劣。變化較多的早期環境適合共同運維，穩定重複工作可納入托管範圍，重大升級與開發應單獨立項。
前30天應該看到什麼
- 所有相關方使用同一份服務清單與RACI
- 重大事件升級和權限撤銷經過實測，而不只是寫在文檔裏
- 未結事項集中在一個帶負責人和期限的台賬中
- 報告呈現復發、風險和改進行動，而不只是工單數量
TAC按照真實範圍與責任模式設計IT服務交付，包括基礎設施與用户支持、應用支持、SAP AMS，以及日本現場與亞洲遠程專家的協作。我們不會籠統承諾支持所有技術或24×7覆蓋，而是在每個項目中確認能力與接管條件。