The Elements of a Good SLA Agreement

 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.

In the previous post we discussed the value of good SLA, the differences between SLA and KPI and the elements that need to be taken into consideration when putting in place a good service level agreement.

In this post we will discuss the 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.