The short answer: put the estate, work, ownership, coverage and acceptance criteria in one scope table
A request to “support SAP” is too broad for a reliable proposal or responsibility model. Define the applications and environments, modules and business processes, included activities, support levels, service hours, third-party dependencies and transition acceptance in one shared scope.
1. Name the applications and business processes
- Production, test and development environments, versions, sites, users and languages
- SAP modules in scope—such as SD and MM—and ABAP development responsibility
- Interfaces, batch processes, reports, jobs, monitoring and external systems
- Business-critical processes such as order, delivery, purchasing and inventory
2. Separate operations from project work
Classify incidents, problems, service requests, standard changes, release support, recurring operations and approved small improvements. Major development, upgrades, migrations and data cleansing should not enter AMS by assumption; give them a separate scope and approval route.
3. Make L1, L2, L3 and the RACI explicit
- L1: intake, information checks, classification and user communication
- L2: diagnosis and resolution within supported functions, configuration and operations
- L3: specialist development such as ABAP, product-vendor escalation or deep engineering
- Customer: business priority, approvals, key users and risk acceptance
- Shared: major-incident decisions, change schedule, release approval and improvement priorities
4. Set coverage and priority from business impact
Separate normal hours, holidays, on-call work, onsite attendance, languages and time zones. 24×7 is not a blanket default: it requires named systems, a delivery model, contact path and priority definitions. Response and resolution targets are then agreed by impact and L1–L3 responsibility.
5. Manage transition and acceptance through evidence
- Service inventory, architecture, contact tree, runbooks and known errors
- Access requests, MFA or VPN, logs, confidentiality and cross-border access controls
- Open tickets, planned changes, technical debt, supplier contracts and dependencies
- Shadowing, reverse shadowing, tests, exceptions and a named acceptance owner
Delivery evidence: SAP support for a consumer-products company in Japan
Since August 2025, TAC has supported the Japan operations of a well-known global consumer-products company under confidentiality. Six consultants—one onsite and five remote—maintain SAP SD, MM and ABAP, with L1, L2 and L3 intake, response and escalation, plus change, release and reporting practices. Unverified effort, SLA and improvement figures are intentionally not published.
Nine items for the first buyer brief
- Systems and modules
- Environments and main interfaces
- Users, sites and languages
- Required service hours
- Current team and third parties
- Expected incident, change and release scope
- Pain points and known risks
- Target start date
- Decision owner and working contact
Do not send passwords, personal data or production-access information through the web form. A high-level operating context is enough for the first discussion.