A Practical Guide to Implementing SLAs
1 like568 views
This white paper provides a comprehensive guide on implementing Service Level Agreements (SLAs) in IT services, defining SLAs as formal documents that outline service commitments between providers and customers. It emphasizes the objectives and benefits of SLAs, including improved communication, clear expectations, and the ability to adapt to changing business needs. Key steps for creating effective SLAs are outlined, focusing on aspects such as performance metrics, responsibilities, and conditions for service delivery.
A Practical Guide to Implementing SLAs
- 1. TechExcel White Paper A Practical Guide to Implementing SLAs The Task If you are reading this, then you’ve probably decided or been asked to implement an SLA. Questions are starting to run through your head like “What’s all the fuss about? How is this going to help the company, our employees, and our team? Realistically, what are the downsides and how do we avoid them?” Well, you’re in luck. This whitepaper lays out everything you need to know about SLAs. By the time you finish reading this, you will be able to successfully plan, implement, report, improve on your SLAs, and reap the associated benefits. 1 A Practical Guide to Implementing SLAs
- 2. A Practical Guide to Implementing SLAs First things first – what is a Service Level Agreement? Here’s the “official” definition: a Service Level Agreement (SLA) is a formal document outlining a service commitment provided by an IT service provider to one or more customers. According to ITIL®, the most widely adopted approach for IT Service Management in the world, the Service Level Management (SLM) mission statement is to “plan, coordinate, negotiate, report and manage the quality of IT services at acceptable cost”. Additionally, SLAs should also include an improvement element that you should actively manage through a Continual Service Improvement Program. SLAs build on the legal contracts that set the framework for IT service and enable more operational flexibility between the two parties. This allows SLAs to be updated or changed based on your business conditions and how relationships develop within your organization. Normally written in a language more relevant to the day-to-day aspects of service delivery, SLAs must be transparent to your employees because they are your stakeholders. The traditional SLA process looks something like this: NOTE: IT teams can have multiple SLAs based on different service criteria and different customer needs and expectations, BUT the goal is to minimize the number of SLAs and definitively AVOID offering one SLA for every permutation of customer and service criteria. This paper is primarily focused on SLAs, but there are two additional concepts in the same family that you might want to be aware of: • Operational Level Agreement (OLA) – an agreement between an IT service provider and another department from the same organization, governing the delivery of infrastructure service • Underpinning Contract (UC) – a formal contract between an IT service provider and an external provider of an IT or infrastructure service Why should I implement an SLA? The objectives of an SLA are to implement a framework that adapts to changing business priorities and service levels, define clear goals to shape the service offered by the provider, and avoid the back and forth associated with service level disagreements. After all, without an SLA, the only legal remedy is a “breach of contract” claim which is often a lengthy and difficult endeavor. SLA benefits include open communication and the ability to manage the customers’ expectations. IT organizations also benefit from a clearer picture of what the users need, the ability to balance and adjust their resources to meet those expectations, as well as explicitly detail the costs associated with any given level of service. 2 A Practical Guide to Implementing SLAs
- 3. A Practical Guide to Implementing SLAs If, you want to improve you and your department’s image. IT can leverage this opportunity to set realistic user expectations which will result in higher user satisfaction and high IT team morale. Internally, SLAs dictate what is important to your customers and your IT team, offering clear indicators on how technicians should spend their time and how their performance will be judged. Transparent performance metrics along with the appropriate incentives motivate IT teams to achieve high service levels. Simply put — clear goals and incentives lead to better performance. For an external IT provider offering services to multiple customers, SLAs have additional benefits — they demonstrate services provided and therefore act as proof of high quality services. IT providers can also use their historical SLAs as marketing tools for apples-to-apples comparisons with their competition to attract new customers. New customers mean more revenue and potentially higher performance bonuses. A comprehensive SLA addresses these key questions: • What is the provider promising? • How will the provider deliver on those promises? • Who will measure delivery and how? • What happens if the provider fails to deliver as promised? • How the SLA will change over time? When designing your SLAs remember these key points! If you do not outline WHO you support, then you support EVERYONE. If you do not outline WHAT you support, then you support EVERYTHING. If you do not outline WHEN you support, then you support AROUND THE CLOCK. If you do not outline WHERE you support, then you support EVERY LOCATION. The SLA clock STARTS when the service goes down, NOT when a ticket is logged or when customer first reports it! How do I create an SLA? A well-written SLA ensures the responsibilities for both parties are clearly stated — you want everyone to be on the same page and to get their buy in. The building blocks of an SLA are: 1. Assess current situation and service levels Investigate the current situation. What have you achieved to date and, more importantly, is this where the business wants to be tomorrow? Create a realistic plan describing what level of service should be provided based on critical feedback from business units, customers and the service provider. 3 A Practical Guide to Implementing SLAs
- 4. A Practical Guide to Implementing SLAs 2. Define the service level Make sure to include all relevant information including purpose, scope (what to include and exclude), dependant business processes and the impact of loss of service. 3. Record the terms of the agreement Outline the roles and responsibilities for both the customer and the service provider including definitions of terms like contract duration, locations and service times. For example: • Duties of the service provider • Duties of the customer • Responsibilities of service users (e.g. with respect to IT security) • IT Security aspects to be observed (if applicable, references to relevant IT Security Policies) Do not forget to define EXCEPTIONS to service times such as weekends and public holidays as well as regular maintenance downtime. 4. Identify performance levels Set out both minimum and expected performance levels for the service as well as conditions under which the service is consid- ered to be unavailable or limited. For example, the expected and minimum service levels might be 95% and 85% on schedule. The key here is that the “expected level” is what the customer is actually paying for and the “minimum level” is what the customer would consider poor, Read: borderline unacceptable service. An insight to availability can be considered in “9’s”: 99.9% equals 8 hours 99.99% equals 53 minutes 99.999% equals 5 minutes 5. Outline escalation procedures Define the steps to be taken when service levels do not meet the expected and agreed upon standards. This may involve deter- mining fault for missed measures, reporting, and problem resolution within a specified time. Also, when the problem still isn’t resolved within a specified time, senior management from both the customer and service provider sides must intervene. 6. Define metrics Define the service metrics and be certain to track them over time. Items to include are conditions when the service is consid- ered to be unavailable/limited, availability targets, reliability targets, time-to-restore service and maintenance downtime. Commonly used metrics include: MTBF – Mean Time Between Failures MTBSI – Mean Time Between Service Incidents MTRS – Mean Time to Restore Service TAT – Turn Around Time Uptime 4 A Practical Guide to Implementing SLAs
- 5. A Practical Guide to Implementing SLAs 7. State fees and conditions For external IT providers, write out any additional fees that may apply and the exact circumstances under which they apply. The clearer conditions are stated, the lower the likelihood for disagreement. This will result in higher customer satisfaction and more prompt payment. 8. Delineate costs and penalties Write out the costs for the service provision and the rules for penalties. For example: Financial credits / Root Cause Analysis / Corrective Action Plan • Normally penalties are a percentage of monthly recurring fees that scale up with failure severity • Penalties are often capped at 50 to 100% of monthly fees • Penalty caps may be cumulative across all SLAs • Contract termination may be a defined option for recurring or very severe issues — for example x consecutive months or y months within any z consecutive months • Contract termination may also be triggered by extreme individual failures SLA exclusions You need to detail and provide a list of exclusions in which time is exempt against the overall SLA measurement. Common exclusions are scheduled and emergency maintenance which may involve anything from upgrading equipment, to reboots, to backups. Some may exclude SLA provisions for failure of a third party which the service provider does not directly control. It may also be used against software vendors for defects in the code base, which require the software vendor to fix themselves. • “Emergency maintenance” – MUST be covered. • “Force majeure” – if not defined and must be consistent among the vendor’s vendors and suppliers. • “Reasonable efforts” – this shifts the burden to the customer when the vendor’s efforts are not sufficient. • Scheduled maintenance – must be clearly defined. When is the system “down”? • Key definition: any problem that effectively renders services unusable by the customer. Examples: • The “obvious”: server is not responding. • Major functionality is not working (i.e. major bugs). • A significant number of users cannot log in. • Excessive latency – i.e. too slow to use effectively. The SLA checklist: Does the agreement cover? • Service objectives • Parties included • People responsible for the agreement • Coverage period • Definition of terms • Procedures for updating/changing/amending the agreement 5 A Practical Guide to Implementing SLAs
- 6. A Practical Guide to Implementing SLAs Does the agreement include the following service factors? • Definition of the service(s) • Service hours and dates • Service exclusions Does the agreement detail coverage of customer / service provider factors? • Procedures for adding or changing services • Arrangements for service interruptions • Escalation procedures • Customer / service provider responsibilities Does the agreement cover communication channels? • Contact points included for both customer and service provider • Communication channels and methods • Does the agreement state what and how performance monitoring will occur? • Service targets, both expected and minimum levels • How to monitor and report on performance • Frequency of reporting • Auditing of reports and monitoring • Quality assurance measurements • Complaints Management Does the agreement delineate service costs and penalties for substandard performance? • Service cost and financial penalties 6 A Practical Guide to Implementing SLAs
- 7. A Practical Guide to Implementing SLAs Conclusion A well-written SLA will help your organization to promise what is possible to deliver and deliver what is promised. With this practice guide you are now ready to create your first service level agreement and although it can be a daunting task to write an SLA, remember that introducing SLAs is not a commitment to deliver the impossible. A service level agreement can be as informal as a performance target or as rigid as a committed time to restore systems backed by penalties. In either case, the SLA serves as a basis for establishing a shared understanding of the service relationship. When properly developed, SLAs offer a win-win situation for both the service provider and the customer. Additional Resources TechExcel – www.techexcel.com Helpdesk Institute (HDI) – www.thinkhdi.com itSMF - www.itsmfi.org ITIL® Homepage - www.itil-officialsite.com 7 A Practical Guide to Implementing SLAs
- 8. TechExcel White Paper TechExcel Headquarters Address: 3675 Mt. Diablo Blvd., Suite 200, Lafayette, CA 94549 Phone: 925 / 871-3900 (toll free 800 / 439- 7782) Fax: 925 / 871-3991 Website: www.techexcel.com TechExcel East Coast (Sales/Support) Address: 6350 Quadrangle Drive, Suite 120, Chapel Hill, NC 27517 Phone: 919 / 402-1385 Tech Support: 919 / 402-1386 Fax: 919 / 402-1414 TechExcel China Address: Suite 9A, Building 1, Huihuang International Plaza, Shangdi 10th Avenue HaiDian District, Beijing, 100085, P .R.China Phone: +86-10-59713111 Fax: +86-10-59713699 TechExcel UK Address: Crown House 72 Hammersmith Road London W14 8TH, UK Phone: +44 (0)20 7470 5650 8 A Practical Guide to Implementing SLAs