The problem with traditional AMS
Traditional AMS for SAP is a sustaining investment: it keeps the estate running, resolves incidents, applies support packages, and delivers enhancements. Its output is stability. Over a long contract, the cost stays roughly constant while estate complexity grows — meaning AMS cost per unit of value delivered tends to increase over time.
The dual-track model
IOTEK’s managed services engagement runs two parallel tracks. Track one is standard AMS: L1 to L3 incident management (L1 — user support; L2 — configuration changes, enhancements, functional analysis; L3 — technical root cause, ABAP, basis, BTP architecture), enhancement delivery, support package application, and SAP Cloud ALM operations. Track two is the agentic backlog: automation candidates drawn from the incident log, worked down at a rate of one agent per quarter.
How automation candidates are identified
The automation candidates come from the incident log itself. If the same exception type appears in support tickets 20+ times per quarter, it is a candidate for automation. The managed services team identifies it, proposes the design, builds and tests the agent on BTP, and deploys it with the customer’s approval. The next quarter, that exception type no longer appears in the ticket log — or appears a fraction as often.
SAP Cloud ALM as the operations platform
IOTEK manages SAP estates through SAP Cloud ALM’s operations capabilities: Business Process Monitoring, Integration and Exception Monitoring, Job and Automation Monitoring, Intelligent Event Processing, and Real User Monitoring. This gives the AMS team a live operations picture — and a rich data source for identifying automation candidates. Arabic-language user support is included for Saudi Arabia and UAE clients; ZATCA compliance monitoring is part of the GCC operations scope.
The question to ask your AMS provider is not “what is your SLA?” — it is “what is your automation backlog, and how many agents have you deployed in the last 12 months?”