Häufig gestellte Fragen
What is an SLA – Service Level Agreement?
A Service Level Agreement (SLA) is a contractual arrangement between a service provider and its customer that makes measurable quality characteristics of a service binding. Typical metrics are system availability, the response time for incidents and the time to resolution, as well as the consequences if these targets are missed. In the ERP context, an SLA mainly concerns the ongoing operation of the software, particularly in cloud and SaaS models where the customer largely outsources operations to the provider. Unlike a general service description, an SLA defines concrete, verifiable values and thus creates an objective basis for managing service quality.
What does an availability of 99.9 percent mean in hours of downtime?
A committed availability of 99.9 percent mathematically allows only very little downtime: around 44 minutes per month, or roughly 8.8 hours calculated over a full year. At 99.5 percent, the permissible downtime already rises to around 3.6 hours per month, while at 99.99 percent it falls to only about 4.4 minutes per month. The reference period is decisive, because 99.9 percent as an annual average can permit a single longer outage, whereas a monthly calculation significantly limits the maximum duration of a single outage. When comparing offers, it is therefore worth checking carefully whether the figure refers to the month or the year, and to calendar time or only to the agreed service hours.
What is the difference between response time and resolution time in an SLA?
The response time indicates how quickly the service provider gives a first qualified reply after an incident is reported — for instance accepting the ticket and starting to work on it. The resolution or recovery time, by contrast, is the deadline by which the problem is actually fixed or operations are restored. A fast first reply therefore says nothing about when the actual problem will be solved, which is why both values should be defined separately and clearly in the SLA. Response and resolution times are usually tied to priority classes, so that a complete system outage carries considerably shorter deadlines than a single faulty function.
What are penalties or service credits in an SLA?
Penalties or service credits are the consequences agreed in the SLA for cases in which the provider fails to meet committed targets such as availability. In practice, these are usually tiered credits on the monthly or service fee, with the amount depending on how far the agreed value was missed. Importantly, such service credits generally do not compensate for lost revenue or any further consequential damages, but only offset part of the fee paid. A penalty clause only becomes meaningful once it is also defined how compliance is measured, documented and reported, and how the customer claims a credit.
What does a typical SLA look like with ERP cloud providers?
For cloud-based ERP systems, the committed availability levels frequently range between 99.5 and 99.9 percent, complemented by response and resolution times tiered by severity as well as service credits for non-compliance. SAP, for example, raised the availability commitment for the S/4HANA Cloud Public Edition from the previous 99.7 to 99.9 percent with release 2408 in August 2024, while a standard value of 99.7 percent continues to be cited for the Private Edition. Planned maintenance windows are usually announced in advance and excluded from the availability calculation, which affects the actually usable time. However, the specific targets, exceptions and calculation methods differ considerably by provider, plan and contract, so a close look at the respective SLA documents is necessary.
What should you look for when comparing ERP SLAs?
A high availability figure alone says little if extensive maintenance windows or narrowly drawn definitions of incident and outage distort the calculation. It is therefore important to clarify whether the commitment refers to calendar time or only to the agreed service hours, and which period it covers, as this strongly changes real operational reliability. Likewise, response and resolution times should be clearly separated, priority classes unambiguously defined, and the measurement and reporting methods transparently documented. It makes sense to anchor the desired operational quality as a requirement in the requirements specification from the outset, so the SLA does not have to be negotiated after the fact, and to insist on substantive rather than purely symbolic penalty clauses.