结论：把系统范围、工作类型、责任、覆盖时间和验收条件放进同一张范围表
仅说“需要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项信息
- 系统和模块
- 环境与主要接口
- 用户、站点和语言
- 所需服务时间
- 现有团队和第三方
- 事件、变更与发布的预期范围
- 痛点与已知风险
- 计划开始日期
- 决策人与工作联系人
请勿通过网页表单发送密码、个人信息或生产访问资料，首次沟通提供运营概况即可。