结论：接管成败取决于能否在运营开始前说清谁负责什么
Support与AMS项目更常因边界模糊而失败，而不只是工程师不足。目标系统、责任、访问、第三方依赖、服务时间和验收条件必须明确。首次询价至少应包含以下12项。
1—4：范围与责任
- 目标系统、产品、版本和环境，包括生产与非生产边界
- 支持地点、用户数量、语言以及需要现场到场的地点
- 客户、服务商和原供应商之间的RACI及最终决策人
- 事件、问题、变更、发布和服务请求的分类与责任
5—8：访问、覆盖与依赖
- 账号开通、审批、MFA、VPN、日志和权限撤销流程
- 正常服务时间、节假日、值班及重大事件联系方式与目标
- 云、通信、硬件、软件等第三方合同、权益和支持路径
- 个人信息、机密信息、跨境访问、终端与数据留存限制
9—12：知识、验收与改进
- 架构图、运行手册、FAQ、已知错误、作业、接口和联系人树
- 未结工单、技术债、风险、待处理变更和发布计划
- 并行期、验收测试、签字负责人和退回条件
- 与目标一致的少量指标：响应、解决、积压、复发和变更成功率
人力容量合同不等于托管服务
人力容量合同主要购买可用工时；托管服务在约定范围内承担运营责任、流程、报告和改进。二者没有绝对优劣。变化较多的早期环境适合共同运维，稳定重复工作可纳入托管范围，重大升级与开发应单独立项。
前30天应该看到什么
- 所有相关方使用同一份服务清单与RACI
- 重大事件升级和权限撤销经过实测，而不只是写在文档里
- 未结事项集中在一个带负责人和期限的台账中
- 报告呈现复发、风险和改进行动，而不只是工单数量
TAC按照真实范围与责任模式设计IT服务交付，包括基础设施与用户支持、应用支持、SAP AMS，以及日本现场与亚洲远程专家的协作。我们不会笼统承诺支持所有技术或24×7覆盖，而是在每个项目中确认能力与接管条件。