SAP is critical to your business success, you can’t afford downtime. Does your service level agreement (SLA) reflect that? do you even have one?
It’s 3:30 a.m. on Sunday. The phone rings. Your upset CTO is on the line yammering at you as the weekend shift stopped production due to a system failure.
Just before falling asleep again, you realize: This was not a prank call PRODUCTION IS DOWN.
You are wide awake now. Production can’t be down, your boss (and his boss, and his boss) will kill you.
You look for your managed service providers phone number, eventually you find it in some old email. You dial..it rings and then you get a voicemail message “ our operation hours are 9am to 6pm Eastern time, Monday through Friday, please leave a message and we will call you back during service hours”
What did you just learn? your service level agreement (SLA) is horrible (do you even have one?), and to add to it, your managed service isn’t properly monitoring and alerting on your systems..
So let’s refresh what a SLA is.
What Is an SLA?
Simply put, an SLA is an agreement between a provider and a customer, either external or internal, that delineates the services to be provided, the expected responsiveness, and performance measurement.
Beyond services, SLAs can also include important security and compliance measures. In a way a good SLA is like a good insurance policy. When failures do occur, however, SLAs can be incredibly valuable - for both parties.
Is There a Difference Between a KPI and SLA?
The SLA is the contract that defines the relationship and how it will work going forward. Key performance indicators (KPIs) are the specific metrics by which the performance is gauged against the agreed upon standards.
For instance, an IT service desk contracts to provide technical support for a broad array of devices in an organization with guarantees for elements such as first-call resolution, uptime, and time-to-recovery after outages. The KPIs are the metrics selected to track the fulfillment of those guarantees.
This should streamline the process, although occasionally IT teams encounter some challenges.
To be effective, an SLA must have the following key principles in place:
KPIs and metrics are critical factors in an SLA. Ineffective or deficient KPIs may result in a service falling into disrepute. In other words, without appropriate measurements, it becomes easy to blame the system for any problem that arises. KPIs should accurately and objectively reflect the perceptions and expectations of both the provider and customer.
To manage these provisions, you need:
Highlighting Service Level Agreements for SAP
With the SAP cloud migration market expansion propelled by adoption of SAP HANA and the ubiquity of public cloud providers such as AWS, Microsoft Azure and Google cloud, many companies are reviewing the capital expense to upgrade on-site hardware that supports new applications. With this evolution, enterprise-level IT managers face the challenge of how to manage, monitor, and optimize SAP apps across multiple cloud environments and in many cases hybrid environment. The result is hyper-complexity in appropriately configuring scalable infrastructure, causing many of them to consider the use of a Managed Service Provider (MSP).
This has put the spotlight onto SLAs.
SLAs have always been key factors; however, today it is important to have an SLA related to SAP performance in addition to the underlying infrastructure.
Key Metrics for SLAs
Elements of SLAs to seek out include metrics like Disaster Recovery and Incident Response Time, Recovery Point Objective, SAP Application Response Times, SAP Application Availability, and Infrastructure Availability. Now, sophisticated IT managers are placing higher priorities on an application-specific SLA with guarantees written into the contract and giving lower priorities to how a cloud service provider manages DR.
For example, Amazon’s AWS offers SLAs at the infrastructure level and nothing that addresses the applications running on it. In comparison, a SAP partner with a cloud platform built for SAP HANA will now typically provide an application SLA along with dedicated support in addition to infrastructure.
When effective, SLAs work well to align providers and customers, minimize friction, and eliminate finger-pointing. As a customer, it is critical to insist on useful SLAs. You want to hold the provider accountable, and you want to objectively address inferior performance if it occurs.The Elements of a Good SLA Agreement
Take a look at the most critical elements to include in an SLA.
As a key element of your vendor relationship, the SLA should define expectations to ensure that your provider and managed services model meet your business needs. However, the SLA will be most useful when in alignment with your approach to SLA management. If you fail to properly vet your vendor and its portfolio or chart your needs in detail, you may risk performance degradation and other expensive disruptions.
SLAs Must Support Technical and Business Needs
A major challenge being in SAP operations is aligning the technical implementation with the overall business objectives. For instance, if a user needs a specific output from an app, but the cloud storage or networking is too slow, a robust SLA will not change that. Data will remain bottlenecked due to slow storage. A strong SLA will synthesize stakeholder requisites from each level to ensure an SLA that meets the requirements of your business.
Support SLAs With Good Testing and Visibility
In practice, even the most robust SLAs will not pay enough compensation in response to a breach of contract. If your business suffers a major disruption and the disaster recovery plan fails to meet objectives, your business will endure a major hit, experience higher customer churn, and face potential compliance violations, regardless of the compensation the SLA requires.
This is why your SLA management must be supported with deep vetting. You must take into consideration the vendor’s visibility and monitoring, their frequency of system testing, the audit record, and other critical factors that verify reliability. You cannot be too careful when conducting a mission-critical SAP migration. Your provider’s interests should always align with your requirements.
Having a single managed services provider will streamline your SLA process, making it easier to frame and enforce with a higher level of reliability. You will have only one relationship to manage, a single set of expectations to establish, and (in case of disruption) only one provider to hold accountable.
The Prevalence of SLAs Will Continue to Grow
As more organizations move to the cloud, SLAs will become ubiquitous and prevalent. Providers of cloud services and cloud applications will find their clients becoming well versed in SLA metrics and demanding more useful SLAs, more penalties, and stricter enforcement. Ultimately, this benefits both sides of the equation.
MSPs now must focus more on providing SAP-focused managed services outlined in the SLA and are expected to provide both transparent visibility to the service level as well as SLA reports. Using Xandria, MSPs can offer real-time dashboards as well as automating SLA reporting creation and distribution.