結論：把系統範圍、工作類型、責任、覆蓋時間和驗收條件放進同一張範圍表
僅説“需要SAP支持”不足以形成可靠報價和責任邊界。應共同確認應用與環境、模塊與業務流程、納入的工作、支持層級、服務時間、第三方依賴，以及交接驗收條件。
1. 明確應用與業務流程
- 生產、測試與開發環境，版本、站點、用户和語言
- SAP模塊，例如SD、MM，以及ABAP開發責任
- 接口、批處理、報表、作業、監控與外部系統
- 訂單、交付、採購、庫存等關鍵業務流程
2. 分開運維工作與項目工作
區分事件、問題、服務請求、標準變更、發佈支持、週期性操作和獲批的小改進。重大開發、升級、遷移和數據清理不應默認納入AMS，應單獨定義範圍和批准路徑。
3. 寫清L1、L2、L3與RACI
- L1：受理、信息核實、分類和用户溝通
- L2：在約定功能、配置和運營範圍內診斷解決
- L3：ABAP等專業開發、產品廠商升級或深度工程支持
- 客户：業務優先級、批准、關鍵用户和風險接受
- 共同負責：重大事件判斷、變更排期、發佈批准和改進優先級
4. 根據業務影響定義覆蓋與優先級
分別定義正常時段、節假日、值班、現場到場、語言和時區。7×24不是默認承諾，只有明確系統、交付體制、聯繫人和優先級後才單獨設計；響應和解決目標再按影響及L1至L3職責商定。
5. 用證據管理交接與驗收
- 服務清單、架構、聯繫人樹、運行手冊與已知錯誤
- 權限申請、MFA或VPN、日誌、保密與跨境訪問控制
- 未結工單、計劃變更、技術債、供應商合同和依賴
- 跟班、反向跟班、測試、例外項與驗收負責人
交付實證：日本消費品企業SAP運維支持
自2025年8月起，TAC在保密前提下支持一家知名全球消費品企業的日本業務。6名顧問（1名現場、5名遠程）維護SAP SD、MM與ABAP，並運行L1、L2、L3受理、響應與升級，以及變更、發佈和報告流程。未經確認的工時、SLA和改善比例不對外公佈。
首次採購溝通的9項信息
- 系統和模塊
- 環境與主要接口
- 用户、站點和語言
- 所需服務時間
- 現有團隊和第三方
- 事件、變更與發佈的預期範圍
- 痛點與已知風險
- 計劃開始日期
- 決策人與工作聯繫人
請勿通過網頁表單發送密碼、個人信息或生產訪問資料，首次溝通提供運營概況即可。