Setting the right SAP SLA to ensure business continuity

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.

Now what?

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.

1. Provider: An SLA benefits the provider by ensuring the correct levels of service and guarantees are set. Performance will be assessed objectively and the provider has incentives in place to offer superior service.
2. Customer: An SLA benefits the customer by delineating objective criteria and protections against inferior service.

To be effective, an SLA must have the following key principles in place:

• Measurable
• Attainable
• Repeatable
• Meaningful
• Mutually accepted

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:

• Service metrics that reflect the user experience accurately
• Process metrics that keep customer and provider informed on effectiveness and efficiency of key activities
• Technology metrics at the component level to enable identification of potential disruptions and improvement opportunities

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.

1. General Overview: this section will include names of parties, starting dates, and a broad introduction of the services to be rendered.
2. Description of Services: Each service must be delineated in this section with all potential circumstances and turnaround times with defined details. This should describe systems supported, maintenance, dependencies, processes, technology, and applications.
3. Exemptions and Exclusions: This should specify everything not offered and be described clearly to avoid assumptions made by either party.
4. Service Performance Level: You should ensure that KPIs are clearly defined with quantifiable data here. Look for Disaster Recovery (DR) and Incident Response Time, Recovery Point Objective, SAP Application Response Times, SAP Application Availability, and Infrastructure Availability. Both parties need to reach mutual agreement here. Also define the event that triggers the DR.
5. Customer and Service Provider Responsibilities: Defining responsibilities will avoid confusion and costly results of miscommunication.
6. General Security Measures: Each client must be assured of the highest integrity of data, and MSPs must demonstrate that exceptional security measures are in place. Anti-poaching, non-disclosure, and IT security should be included in the section.
7. Disaster Recovery Process and Problem Management: It happens. Problems may occur, and the SLA should clearly define the disaster recovery mechanism and robust problem management process in place. In addition, the length of the restart process should be addressed, including alerts and manual restarts.
8. Service Tracking and Reporting: The customer holds every right to track service performance and levels. Ideally, a customer should be able to compare performance before/after a migration. These will be based upon terms that are mutually discussed and agreed upon, intervals, and reporting structure. In addition, stakeholders should be comprehensively defined in this section.
9. Change and Periodic Review Process: An SLA should be a dynamic document, especially with a HANA migration, as the innovations will advance rapidly. Elements of the SLA may be upgraded based upon certain external factors such as work environment has changed, client needs have changed, or better processes and tools have become available. The review period and process of change should be defined for future use by either party.
10. Commercial Coordinates: Ensure that all commercial coordinates and the corresponding prices are here, including the price of every service offered, all possible variations, method of calculation, and payment terms.
11. Termination of Agreement Process: At some point, you may wish to terminate an MSP. The circumstances that allow for a termination or expiration must be clearly delineated in the SLA in addition to the notice period required from either party.
12. Signatures: Authorized individuals and relevant stakeholders from both sides should sign the document to agree to each detail listed in it. Both parties abide by the agreement as long as it remains valid.

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.