Guidelines for writing foolproof service level agreements (SLAs)

1

http://www.hr2012.com/EUROPE/?u=&s=

© 2012 Wellesley Information Services. All rights reserved.

Guidelines for writing foolproof service level

agreements (SLAs)

Dr. BergComerit Inc.

3

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

5

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

6

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.

7

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 generalSLA job descriptions that you can customize to yourorganization. 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

8

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.

9

The SLA Main Sections

The SLA sections should include: Duration of SLAParty definitionsCommunication channelsRoles and ResponsibilitiesLegal obligations & jurisdictionFinancial obligation & payment termsService level definitions

Systems and priorities Users and priorities Processes and priorities

Security requirementsReporting and EscalationsTermination clausesContact lists for operations

Source: The SLA Toolkit, 2011

10

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

Source: www.sla-world.com/check.htm , 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



12

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

13

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)

14

Standardize SLA Performance Measures – 25 to Consider

Additional measures include

These are a some of the measures you should consider.

Pick 10-12 of these initially and add more as the SLA model matures

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)

15

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

16

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

The ability to change performance measures should be spelled out in the SLA

calculated, what are the performance targets and what actions are triggered if the service level is not achieved.



18

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!

19

Defined Response Times under the SLA

Response times should be defined for each of the service level priorities. Examples include:

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.

Priority Issue Response Resolution1 Critical component outage 15 min Immediately2 Critical component degraded 30 min 4 hours3 Non-critical issue 30 min 8 hours4 Other questions & requests 4 hours 24 hours

20

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)

As employees has become more versed in IT, the number of support staff has

decreased by 9.6%

However, there are significant differences in support within organizations. In a survey of 16 organizations that use SAP we found:

0

10

20

30

40

50

60

70

80

90

100

110

High Support (top-25%) Average Low Support (bottom 25%)

4.2

27.1

52.1

10.6

38.9

102.1

8.6

26.4

79.3

Small Companies

Medium Sized Companies

Large Companies

In 2010, each IT support staff had on average 38.8 users to support

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 sincethe support team also has to be engaged on project activities

Online Help SystemsThe 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.

Include an On-Line Help Systems in the SLA

Online Help Systems — Animations 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 the On-Line Help System (a real example)

SLA and Computer Based Online TrainingIn 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.



26

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

TrainingProject Stack

Break fix and Production stack

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

ERD

ERSERT

ERB ERQ ERPThe 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)

28

System Upgrades

Remember to include in the SLA:When will the system be upgradedHow 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.



30

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 TrialCan 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?

31

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

The benefit of this is tight alignment with the workplans and easy access. The drawback is the complexity of adding issues.

Source: george-treasures.blogspot.com , 2011

32

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.

33

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.

You should specify what tools are to be used to log issues in your SLA

Example: Managing Engine –

ServiceDesk Plus

Many vendors provide software to track the SLA performance.

For instance LiveTime providean operational tracking toolto 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

34

More SLA Software Tracking Tools for Issues

When writing the SLA, you should consider how many are impacted by an issue and operationalize this through the use of service desk tools



36

Escalation Priorities – Low (4) and Important (3)

A priority four service ticket is defined as LOWA 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 IMPORTANTA 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.

37

Escalation Priorities – High (2) and Urgent (1)

A priority two service ticket is defined as HIGHAn 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 URGENTA 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

Excellent

Average

Minimal

Poor

Customer Service

38

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 HelpdeskLevel - 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

39

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

40

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.



42

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.

43

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 minutesEvery calls not performed in this time frame is charged $10

Every system should have a 99% up-time per monthEvery 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


• 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

45

What to Include in a BI SLA between IT support & the Business

1. 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?

2. 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?

3. 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?

4. 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?

46

What to Include in a BI SLA (cont.)5. 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?

6. 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)?7. 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?8. 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?

47

What to Include in a BI SLA (cont.)9. 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



50

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

51

Outsourcing Pricing Models – Variable Fees

Variable fees has also been used. While it sounds good to charge per service issue, there are significant problems with this. This include:

Department discourage opening help tickets and productivity suffers.

There is an incentive for the service partner not to fix systematic issues, but instead fix it for each user.

Upgrades and support packs get applied often and may cause business disruption

Variable fees should only be used as exceptions for non-standard business processes such as disaster-recovery, new conversion, roll-out to new users (i.e. security setup)

52



53

Resources

• Service Level Agreements: A Legal and Practical Guide by Jimmy Desai 120 pages, (Sept. 2010) ISBN-10: 184928069X

Service Level Agreement Best Practices - Templates, Documents and Examples of SLA's in the Public Domain

238 pages, (April, 2010) ISBN-10: 1742443060

• Service Level Agreement: What you Need to Know For It Operations Management by Michael Johnson 244 pages (May, 2011) ISBN-10: 1743042124

• Service Level Agreement 100 Success Secrets: SLA, Service Level Agreements, Service Level Management and Much More by Gerard Blokdijk 176 pages (Jan. 2008) ISBN-10: 0980471613

54

7 points to take home

• Separate your support and your project organization• Size your outsourced support team according to best

practice benchmarks and include this in the SLA• Measure Support team turnover to assure stability• Leverage online training and online help systems to

reduce support costs• Create a formal SLA process with the business

community with realistic performance targets• Make sure you have identified environment owners –

consider a break-fix environment• Require your outsourcing partner to provide career

tracks for the support staff

55

Your Turn!

How to contact me:Dr. Berg

[email protected]

Continue the conversation! Post your questions in the HR Forum on Insider Learning Network*

*bit.ly/HR-Forum

http://bit.ly/HR-Forum

http://bit.ly/HR-Forum

http://bit.ly/yTZkvP

56

DisclaimerSAP, R/3, mySAP, mySAP.com, SAP NetWeaver®, Duet™®, PartnerEdge, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.

Guidelines for writing foolproof service level agreements (SLAs)

Documents

outsourcing sla

sla roles

sla managersystem upgrades

performance measurement

query performance

performance targets

performance bonuses

desk performance criteria