7 min read

Selecting an SAP Application Management Partner for Global Operations

Selecting an SAP Application Management Partner for Global Operations
Selecting an SAP Application Management Partner for Global Operations
11:43

BEYOND ESSENTIALS

  • Core insight: AMS offers are hard to compare because the scope, not the rate, decides the bill. Define what is inside the fee before you read a single SLA table.

  • Consequence: Four clauses separate a workable contract from an expensive one – severity classification, the measurement point, statutory maintenance, and the exit.

  • Mid-market angle: A company running SAP in several countries with a lean IT team buys coverage it cannot staff. That only works if first level speaks the language of the plant and the transition is documented.

The decision to buy SAP application management rather than build a team is usually the easy one. We have set out the arithmetic behind it, including what a carve-out CFO actually saved and what his team did with the freed capacity.

The harder decision comes next: which provider, on which contract. Three AMS offers for the same landscape can differ by a factor of two, and the difference is almost never the day rate. It is what each one counts as included.

This guide covers the six things to settle before you sign: scope, the SLA mechanics that matter, coverage across time zones, statutory work per country, the transition, and how you would leave. If you are choosing a partner for the whole engagement rather than support alone, start with selecting a global SAP partner.

Settle the scope before you read a single SLA

"Application management" means different things to different providers. Write down which of these are inside the fee and which are quoted separately:

  • Incident resolution – break-fix, by severity, with a defined first and second level.
  • Adaptive maintenance – keeping the system aligned with changing business and regulatory requirements, not just fixing what broke.
  • Release and patch management – SAP notes, support packs, upgrade support, and the regression testing that has to go with them.
  • Statutory change per country – tax, e-invoicing and reporting changes, monitored and implemented.
  • Small enhancements – and the threshold in days above which something stops being an enhancement and becomes a project.
  • User administration and authorisations – small work, high volume, frequently missing from the fee.
  • Advisory – someone who looks at your landscape once a quarter and tells you what to do next, rather than only closing tickets.

The enhancement threshold is the one to argue about. Set it too low and every improvement becomes a change request with its own approval cycle. Set it too high and the provider absorbs work it will price into the fee anyway.

The SLA mechanics that decide the experience

SLA tables all look similar. Four details underneath them do the work.

Response time or resolution time. Most contracts guarantee the first and estimate the second. A one-hour response on a stopped production line is worth very little on its own. Ask for resolution targets by severity, and for what happens when they are missed – a credit note that is smaller than the loss is not a remedy, but it does tell you how seriously the provider takes the number.

Who classifies severity. If the provider decides what counts as critical, the definition will drift downwards over time. Agree the classification rules in writing, with examples from your own processes, and give your side the right to escalate a classification.

Where the clock starts and stops. At ticket creation or at first human contact? Does it pause while the ticket sits with your key user? Does it run outside service hours? Two providers with identical SLA numbers can differ by hours on the same incident because of this clause.

Who reports attainment, and can you audit it. If the provider measures its own performance in its own tool, ask for the raw ticket data alongside the monthly report, and for a standing service review where exceptions get discussed rather than averaged away.

Ask for the pricing model in the same conversation. Ticket-based, fixed fee per scope, or a committed capacity in days each behave differently once volumes change – and volumes always change after a rollout wave.

Coverage, time zones and the language of first level

Define your actual requirement before you compare coverage models. A group with plants in Mexico, Poland and Malaysia needs support during three different working days. A group with one production site and three sales offices does not, and should not pay for it.

Two constructs deliver round-the-clock coverage. A follow-the-sun model hands the queue between teams in different regions, so somebody is always at work rather than on call. A shift or on-call model keeps one team and pays it to be available. Follow-the-sun is usually better for incidents that need real work rather than a restart, because the person picking it up is at their desk with colleagues around them.

First level is where the language question is decided. Second and third level can run in English in most organisations. First level usually cannot, if you want your warehouse staff to report an incident rather than work around it for a week. Ask which languages first level actually covers, in which hours, with how many people – not which languages the provider's website lists. The same reasoning applies here as in projects, where cross-cultural fluency decides more outcomes than technical depth does.

Statutory work is local, and it does not travel

A generalist support desk can open a ticket on an Indian GST requirement or a Brazilian invoicing change. Closing it correctly needs someone who already knew the rules before the ticket arrived.

So ask, per country in scope: who monitors legislative change, how you are told about it, whether implementing it is inside the fee or a change request, and how far ahead of a statutory deadline the work is planned. This is the part of AMS that quietly decides whether your finance team trusts the system, and it is the hardest to retrofit once the contract is signed.

The transition is where the risk sits

Most AMS relationships that go wrong went wrong in the first ninety days. Three things prevent it.

An assessment before the SLA. A provider that quotes an SLA without having looked at your landscape in detail is quoting a template. The assessment is what turns a generic table into targets that fit your system, your interfaces and your custom code.

A documented handover. Whether you are moving from an internal team, from a previous provider, or straight out of a rollout, the transition needs written documentation, named counterparts, and an overlap period where both sides are present. A carve-out makes this sharper, because there is no internal team left to absorb what the handover missed.

Named people, and what happens when they change. Ask who your service manager is, who the lead consultants are, how rotation is handled, and how knowledge is retained when someone leaves. Continuity of people is worth more than a decimal place on availability.

Proactive, demonstrated rather than claimed

Every provider says it works proactively. Ask what that produces in evidence:

  • Monitoring that covers the whole landscape, with alert thresholds you can see and change.
  • Automated regression testing tied to release cycles, so patches ship without a manual test marathon.
  • A ticket trail you can audit, with ownership visible at every step.
  • A quarterly review that names the three things to fix next, and a record of what the previous one produced.

If the last one does not exist, the service is reactive whatever the contract calls it.

And how you would leave

Nobody enjoys negotiating the exit at the start, which is why it is usually the weakest clause in the contract. Agree now: notice periods, what documentation you receive and in what format, who owns custom code and test scripts, how long the provider supports a transition to a successor, and at what rate. A provider that writes a clean exit clause is telling you it expects to be kept for reasons other than switching cost.

Where UNITED VARS fits

UNITED VARS is a strategic alliance of more than 70 hand-picked SAP partner companies and the only SAP Platinum Partner alliance worldwide. More than 11,000 SAP consultants have delivered over 10,000 SAP implementations in 100+ countries.

For application management, the model answers the coverage and the statutory question with the same structure. Support runs 24/7 on a follow-the-sun basis across member companies in different regions, so the country layer is handled by people who work in that market and know its rules. The engagement starts with an assessment of the existing landscape and ITIL-aligned SLAs, followed by a documented handover, then continuous monitoring and optimisation. Our service page sets out what is covered day to day, from adaptive maintenance and ticketing to automated testing and advisory.

CATENSYS is the reference to look at if your situation involves a carve-out: SAP support across eight sites in seven countries, unified under one global AMS model, with no large internal SAP department.

If you are comparing AMS offers now, take the scope list and the four SLA clauses into the next provider call. Our customer references show how the model works across industries and country scopes, and you can put your own scope in front of us directly.


Mid-sized companies should go global without losing speed or local identity. UNITED VARS brings together hand-picked local market leaders with real people on the ground in 100+ countries to remove legal, cultural, and language barriers. As a strategic alliance, UNITED VARS provides clear accountability from start to finish. UNITED VARS is the world's only SAP Platinum Partner alliance, delivering end-to-end SAP services for the mid-market.

stronger than one.


FAQ

How do I choose between SAP application management providers?

Compare scope before price. Write down which services sit inside the fee – incidents, adaptive maintenance, releases and regression testing, statutory change per country, small enhancements, user administration, advisory – then compare offers on that same list. After that, four SLA clauses decide the experience: who classifies severity, where the clock starts and stops, whether resolution as well as response is committed, and who reports attainment.

What should an SAP AMS service level agreement contain?

Severity definitions with examples from your own processes, response and resolution targets per severity, service hours and what happens outside them, the measurement point for the clock, a monthly report with auditable ticket data, a standing service review, and an exit clause covering notice, documentation and support for a transition to another provider.

What does 24/7 follow-the-sun SAP support mean?

Support teams in different regions hand the queue on as their working days begin and end, so an incident is always picked up by someone at their desk rather than on call. It suits organisations with sites in several time zones. A shift or on-call model with a single team can be adequate for a group operating in one region.

Should SAP support be delivered locally or centrally?

Split it by level. Second and third level can run centrally in English. First level works better locally, in the language people on the shop floor speak, because incidents that are awkward to report tend not to be reported. Statutory work also belongs locally, since tax, e-invoicing and reporting rules do not transfer from one country to the next.

How long does it take to transition SAP support to a new provider?

Plan it in three stages rather than as a date: an assessment of the landscape that produces the SLA, a documented handover with named counterparts and an overlap period where both sides are present, and a hypercare phase with a defined exit into regular service. Skipping the assessment is what produces a template SLA that fits someone else's system.

Selecting a Global SAP Partner for Mid-Sized Enterprises

1 min read

Selecting a Global SAP Partner for Mid-Sized Enterprises

BEYOND ESSENTIALS Core insight: Most shortlists compare capability. What decides a multi-country programme is accountability – who answers for...

Read More
SAP Managed Services: The Real Math Behind Skipping an In-House Team

1 min read

SAP Managed Services: The Real Math Behind Skipping an In-House Team

BEYOND ESSENTIALS Core insight: Recruiting, onboarding, and retaining a full internal SAP team costs more than most mid-market budgets show on...

Read More
SAP Customer Stories: How CATENSYS Kept SAP Running Through a Global Carve-Out

1 min read

SAP Customer Stories: How CATENSYS Kept SAP Running Through a Global Carve-Out

BEYOND ESSENTIALS Core insight: A carve-out can leave a company with full ownership of its SAP systems and no team to run them. Consequence: A...

Read More