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