Guidelines for writing foolproof service level agreements (SLAs)

Guidelines for writing foolproof service level agreements (SLAs) Dr. Berg Comerit Inc.

In This Session … Learn how to write effective service level agreements (SLAs) that cement expectations between your company and your partner. Examine what needs to be included in an outsourcing SLA, such as performance targets, system availability, query performance, penalties for non-compliance, termination clauses, upgrade expectations, staffing requirements, and help desk performance criteria. Learn how to create objective measures for performance and compliance. See real examples of successes and failures in outsourcing relationships and understand what a company should expect from its SLA manager. Learn how to include issue resolution, non-compliance escalation processes, and performance bonuses and penalties in your SLA. Identify which KPIs must be included monthly status reports and see real-life examples of SLA reports. Understand what reasonable outsourcing costs are for small, mid-size, and large organizations and explore the different pricing models that exist.

What We’ll Cover … • Background • Creating Objective Measures • The role of the Helpdesk and the SLA manager • System upgrades and maintenance • The Issue log • The Escalation Process • Performance Penalties • Examples of SLA Measures • Outsourcing Pricing Models • Wrap up

The Goal of the SLA • The goal of the SLA is to provide disciplined approach is to establish performance measurement against specific criteria. This include • Procedures • Tools • People • As part of the SLA you have to make sure that you have measures for each of these areas. The SLA is not indented to only measure people performance. It could be that the procedures are not appropriate or that the tools are inadequate

The Internal Assessment Before you start formalizing an SLA should do an internal assessment of the current IT processes and see what you would like to achieve. The SLA should be used to improve the current state of affairs, not merely moving support outside the organization You may want to consider a neutral third party to setup the SLA and do the internal assessment before you start. This is normally a 2-6 weeks effort.

SLA Roles and Responsibilities • You can buy detailed templates for SLA roles and responsibilities on-line. There are several vendors who provide this. • For example ejobdescriptions.com let you download general • SLA job descriptions that you can customize to your • organization. These include: • VP Administration • VP Strategy and Architecture • Director IT Management and Control • Manager Contracts and Pricing • Manager Controller • Manager Metrics • Manager Outsourcing • Manager Service Level Reporting • Metrics Measurement Analyst • Quality Measurement Analyst • System Administrator Unix • System Administrator Windows Source: ejobdescriptions.com, 2011

The Customer also has Responsibilities under the SLA • The customer should also have specific responsibilities under the SLA. These should be spelled out in detail. This include: • All employees must read and sign a formal corporate security policy and enterprise computer usage rules. • Employees will use only specified telephone numbers, web site and email addresses to request support. • Each employee must attend a 2 hours ERP/BI training sessions before receiving a workstation. • Each employee must attend a specific training session on BPC, ER, Xcelsius, SD, MM, FI, WebI (each software package used). It is in both companies best interest in having clearly defined customer responsibilities.

The SLA Main Sections • The SLA sections should include: • Duration of SLA • Party definitions • Communication channels • Roles and Responsibilities • Legal obligations & jurisdiction • Financial obligation & payment terms • Service level definitions • Systems and priorities • Users and priorities • Processes and priorities • Security requirements • Reporting and Escalations • Termination clauses • Contact lists for operations Source: The SLA Toolkit, 2011

Generic SLA Templates are Available from Many On-Line Vendors • Some vendors provide complete toolkits for generic SLA agreements that you can use to ‘fill-in the blanks” • Prices typically range from $199 to $999 Source: www.service-level-agreement.net , 2011 • There are even detailed checklists to assure that you don’t forget to include critical items in your SLA such as legal remedies, jurisdictions, intellectual property rights etc. • Simpler, free templates can be also downloaded on-line at: • www.continuityplantemplates.com/files/it-service-level-agreement-templates.docx Source: www.sla-world.com/check.htm , 2011

Selecting Objective Measures • Measures drives behavior, so be careful when selecting them. They should be: • Simple to understand and easy to calculate • Meaningful and drive the behavior you want to encourage • Controllable and immune to manipulations • Instruments that collect measures must be consistent overtime and as automated as possible Sites such as the free on-line “KPI-Library” as over 6,000 standard measure definitions based on the SEC, API, ISO, FASB, GAAP, IEEE and other organizations

Standardize SLA Performance Measures – Some to Consider • Standard measures exists for SLAs. These include • First-Level Call Resolution (FLCR) • Average Call Answer Time (ACAT) • Percentage Calls Re-opened within Two weeks (PCRT) • Percentage of Training Type Calls (PTTC) • Number of Tickets Escalated to level-2 support (NTE2) • Percent of Tickets Escalated to level-2 support (PTE2) • Number of Tickets per Service Employees (NTSE) • Number of Service Employees per User (NSEU) • Average Service Employees Training Level (ASET) • Percent Service Employees Certified (PSEC) • Turnover Rate of Service Employees (TRSE) • End User Satisfaction Score (EUSS) • Number of System Failures (NOSF) • Number of Critical System Failures (NOCF)

Standardize SLA Performance Measures – 25 to Consider Additional measures include • Mean Time between Failures (MTBF) • Mean Time between Critical Failures (MTCF) • Mean time to Provision (MTTP) • Mean time to Repair (MTTR) • Percent Up-time Per System (PUPS) • Percent Down-Time Per System (PDPS) • Percent Call-back to Customers (PCBC) • Cost per Service Ticket (CPST) • Cost per Service Employee (CPSE) • Cost per Serviced System (CPSS) • SLA Operating Efficiency (SLAOE) • SLA Operating Effectiveness (SLAOF) • Employee Turnover Rate (EMTR) These are a some of the measures you should consider. Pick 10-12 of these initially and add more as the SLA model matures

Support Packages and Different Measures Not all business users, or units need the same level of support or performance measures You can segment the support level by critical processes, organizations and tools. This can result in significant savings Source: supportdesknow.com, 2011 An SLA can be flexible, and support levels can be tailored into different support packages

Formalize SLA Measures in a Tool SLA performance measures are normally recorded automatically in a tool. In your SLA you should be very specific on how the measures are Software: SysAid, 2011 calculated, what are the performance targets and what actions are triggered if the service level is not achieved. The ability to change performance measures should be spelled out in the SLA

The Service Tickets • Service tickets are the primary source of SLA performance information. • Your SLA need to include • When will service tickets be monitored / reviewed? • What are the categories and who will resolve them? • What are the resolution process and timelines? • How are customer and support satisfaction measured? Almost 75% of all issues in system support is due to changes in the environment. Change control and testing is critical!

Defined Response Times under the SLA Response times should be defined for each of the service level priorities. Examples include: • Priority Issue Response Resolution • Critical component outage 15 min Immediately • Critical component degraded 30 min 4 hours • Non-critical issue 30 min 8 hours • Other questions & requests 4 hours 24 hours The issue diagnosis time can be reduced significantly when the IT asset and existing system configuration is known at the helpdesk. The support team has to consists of highly trained individuals.

Include in SLA - The Number of End-Users per Support Staff • The number of end user per support staff has increased over time. • In 1998, each IT support staff had 35.4 users to support (Source: Anderson Consulting, Information Center Resources Mgmt,1998) However, there are significant differences in support within organizations. In a survey of 16 organizations that use SAP we found: • In 2010, each IT support staff had on average 38.8 users to support As employees has become more versed in IT, the number of support staff has decreased by 9.6%

Outsourced Support Vs. Projects You need to separate the SLA Support operations from project work Normally, we find the outsourced support organization under the CIO Without a formal separation between support and projects, there is a risk that future efforts are delayed since the support team also has to be engaged on project activities

Online Help Systems Include anOn-Line Help Systems in the SLA The use of an on-line help system is a must for successful outsourcing of a system. You can require the vendor to tailor-make a system, by simply saving Microsoft Word docs as .htm files and then pick them up in a Web page. If you don’t include this in your SLA, the vendor is unlikely to build and maintain this system.

Online Help Systems — Animations SLA and the On-Line Help System (a real example) In the SLA you can also require the outsourcing partner to build and maintain an interactive ‘demo system’. The vendor can buy cheap software like Snag-it and Camtasia and create demos that show how users can accomplish complex tasks The development & maintenance of the online help system belongs in the outsourced support organization. This is not a one-time task, but a “living” system that is updated based on user feedback, issues, and new development.

SLA and Computer Based Online Training In the SLA you can demand the development and maintenance of an on-line training can be delivered on-demand Over time, this is the best way of delivering casual user training and reduce the number of service tickets. The trick to being successful here is to provide interactivity and common tasks scenarios. Hint: Work with outsourcing partner and use a ‘storyboard’ to develop your on-line training.

ServicePacks and Fixes • In the SLA you should also include: • How should software fixes be applied? • Who can approve changes to the system? • When will service packs, SAP Notes, and fixes be applied? • Who pays for it? • Who is responsible for testing them? • Who overseas impacts other modules (BOBJ, portal, security etc.) The SLA is for the overall system performance. This periodic enhancements and fixes aligned with SAP’s release strategy

Splitting Projects & Outsourced Support Environments By Introducing a Break-Fix (ERB) environment, the support team can correct break-fixes and move code into the Testing environment (ERQ) and Production environment (ERP) without impacting the project team Transports can be captured in the buffer and moved to the Development environment (ERD) on a periodic basis Break fix and Production stack The Break-Fix and production stack as well as the training environment is owned by the outsourced support team. The company project teams own the development & sandbox environments (ERS & ERD) ERP ERB ERQ Project Stack Training ERD ERT ERS

System Upgrades • Remember to include in the SLA: • When will the system be upgraded • How is the pricing determined? • Who can approve an upgrade? • Who pays for it and who is responsible for testing? • How long can the system be off-line? • What are backup rules and procedures? • Who approved shadow systems and switchbacks? SLAs should spell out any how upgrades and compatibility issues should be handled.

The Issue log and Audit Trail in the SLA • All SLAs should require that an Issue log is kept to monitored performance and to identify areas that can be improved upon. • Critical questions should be answered such as: • What issues must be logged? • Who owns the log? • Do you have access? • The Audit Trial • Can entries be updated, or must an audit trail be preserved? • Do we track who changed the log and when it occurred? • Do we have automatic action items included when nothing happens?

The Issue log – Using Microsoft projects The Issue log can be tied to the workplan and each task using Microsoft projects through a custom view Source: george-treasures.blogspot.com , 2011 The benefit of this is tight alignment with the workplans and easy access. The drawback is the complexity of adding issues.

The Issue log – Using SAP Solution Manager The Issue log can also be kept is SAP Solution manager. This provides close integration with vendor support tickets. The SAP terminology is Messages for internal SLA tracking and Issues for items between the outsourcing provider and support group at the SAP company. The interface is the same.

The Tracking Tool Service Tickets needs to be aligned to the service level agreement. There are a substantial number of tools that can do this for you. Example: Managing Engine – ServiceDesk Plus You should specify what tools are to be used to log issues in your SLA

More SLA Software Tracking Tools for Issues Many vendors provide software to track the SLA performance. For instance LiveTime provide an operational tracking tool to map performance to SLA Contracts. Most advanced tools also take Into consideration how many users are impacted and what business processes are affected. Taking sales orders right now, may be more important than scheduling shipments next month When writing the SLA, you should consider how many are impacted by an issue and operationalize this through the use of service desk tools

Escalation Priorities – Low (4) and Important (3) • A priority four service ticket is defined as LOW • A general usage question or recommendation for a future product • enhancement or modification. There is no impact on the quality, • performance or functionality of the product. • A priority three service ticket is defined as IMPORTANT • A medium-to-low impact problem which involves partial non-critical functionality loss. One which impairs some operations but allows the client to continue to function. • This may be a minor issue with limited loss or no loss of functionality or impact to the client's operation and issues in which there is an easy circumvention or avoidance by the end user. This includes documentation errors.

Escalation Priorities – High (2) and Urgent (1) • A priority two service ticket is defined as HIGH • An issue where the client's system is functioning but in a severely • reduced capacity. The situation is causing significant impact to • portions of the client's business operations and productivity. • The system is exposed to potential loss or interruption of service. • A priority one service ticket is defined as URGENT • A catastrophic production problem which may severely impact the client's production systems, or in which client's production systems are down or not functioning; loss of production data and no procedural work around exists Make sure you have formal ticket classifications and definitions in your SLA

The Levels Of Escalation • Not all items can be fixed by the helpdesk. Sometimes you have to involve other parties. We refer to this as Escalation levels (different than service ticket priorities). • The most common escalation levels are: • Level - 1 Escalation – Standard Helpdesk • Level - 2 Escalation – Subject Matter Expert (SME) • Level - 3 Escalation – Software or Hardware Vendor Involvement Spell out all details of all responsibility levels in your SLA and make sure that it is backed up with formal procedures that triggers action

Escalation process What will happened if an issue cannot be resolved by the Internal IT department/vendor and your Business SLA manager? What are the steps needed to terminate the SLA contract and are there any payments/fault payments or budget recourse? The more details you put into the contract up front, the easier it will be to measure and the more likely you are to have a successful relationship

SLA Service Termination • You need to formally define the actions if you cancel the SLA. The key questions to address include: • Who owns the data and service history? • If you switch vendors, who owns the log data? • How will you get access to the data? Do you get full insights to all? • Who, of the vendor’s employees, gets access to your data? Can they share it with your competitor? You should write this part of the SLA as if the relationship is ‘doomed-to-failure’ and you want to shield your organization.

Performance Monitoring Dashboards can be Required in an SLA SLA performance measures should not be collected monthly. Interactive dashboards can tell how the services are being performed on a daily basis Source: Metricus Enterprise Software, 2011 Access to the same service performance data makes the relationship easier to manage. However, you have to request this in your SLA.

Performance Penalties • Performance penalties should be clearly defined and assigned to each measurable offence. Examples include: • 95% of all calls should be answered within 60 seconds. • Every service call that are late after this is charged $3 • Every service ticket should get call-back within 30 minutes • Every calls not performed in this time frame is charged $10 • Every system should have a 99% up-time per month • Every 0.1% below this is charged $5,000 unless pre-approved Building in performance penalties can help motivate the right behaviors of your partner, but only if the penalties are significant

What We’ll Cover … • Background • Creating Objective Measures • The role of the Helpdesk and the SLA manager • System upgrades and Maintenance • The Issue log • The Escalation Process • Performance Penalties • Examples of SLA Measures • Outsourcing Pricing Models • Wrap up

What to Include in a BI SLA between IT support & the Business When must data stores be loaded by (time) What will happened if a persistent problem occurs (“swat” teams)? Who is responsible for fixing process chains and who pays? Do you get a discount for each DataStore that is not loaded in time? How should software fixes be applied When will service packs, SAP Notes, and fixes be applied? Who pays for it? Who is responsible for testing them? When will the system be upgraded When will upgrades occur, how is the pricing determined? Who pays for it and who is responsible for testing? How long can the system be off-line? Minimum uptime and target uptime What is uptime defined as (data store loaded vs. queries available vs. security fixes applied vs. portal uptime vs. third-party reporting tool uptime vs. network uptime, etc.)? What are the penalties (money) for missing the uptime requirements?

What to Include in a BI SLA (cont.) Issues log What issues must be logged? Who owns the log? Do you have access? Can entries be updated, or must an audit trail be preserved? Backup and disaster recovery What is included in the backup and when is it taken? When will restore abilities be tested? How fast must restore occur, and what data stores and users will first have access (priority list)? Who owns the data If you switch vendors, who owns the data? How will you get access to the data? Do you get full insights to all? Who, of the vendor’s employees, gets access to your data? Can they share it with your competitor? Service tickets When will service tickets be monitored? What are the categories and who will resolve them? What are the resolution process and timelines? How are customer and support satisfaction measured?

What to Include in a BI SLA (cont.) Escalation process Male sure that there is a formal process and approvals at each step of the way Include resolution processes, review meetings and actions that can be taken at each step of the way. Finally, include a legal remedy clause. The more details you put into the contract up front, the easier it will be to measure and the more likely you are to have a successful outsourcing relationship

Reasonable BI and DW SLA Performance Some examples of reasonable performance include: • 90% of all queries run under 20 seconds • System is available 98% of the time • Data loads are available at 8am — 99% of the time • User support tickets are answered within 30 minutes (first response) • User support tickets are closed within 48 hours — 95% of the time. • System is never unavailable for more than 72 hrs — including upgrades, service packs, and disaster recovery • Delta backups are done each 24 cycle and system backups are done every weekend

Outsourcing Pricing Models – Fixed Fee • Some outsourcing deals are structured around a fixed fee for specified services. In your outsourcing contract, you can specify: • Fixed fee per ERP end-user supported per month (i.e. $150 per user) • Fixed fee per ERP Power-user supported per month (i.e. $190 per user) • Fixed fee per BI end-user supported per month (i.e. $199) • Fixed fee per BI Power-user supported per month (i.e. $299) • Fixed fee per Dashboard supported per month (i.e. $249) • Fixed fee per ERP System supported per year (i.e. $450,000) • Fixed fee per BI System supported per year (i.e. $275,000) • Fixed fee per Organizational Unit per year (i.e. $250,000 for Sales) • Fixed fee per Module supported per month (i.e. $2,350,000 for SCM) Fixed fee pricing models are very popular, but there is an incentive for the outsourcing partner to skimp on support staff, so SLA measures has to be aligned to this strategy

Guidelines for writing foolproof service level agreements (SLAs)