1 Sap Final Sla Project

8/10/2019 1 Sap Final Sla Project

1/29

ABSTRACT:

This document is intended to serve as a resource for Service Level Agreement and address the

challenges in developing an SLA and lists out the measures and checklists to be followed to de-

velop SLA based on the based practices of Software industry. This project portrays Service Level

Agreement (SLA) as an effective tool for managing the risks associated with technology out-

sourcing and describes practices for measuring and monitoring Service providers performance.

Service Level Management (SLM) provides a constant interface to the business for all service-

related issues. It provides the business with the agreed service targets and the required man-

agement information to ensure that those targets have been met. Where targets are breached,

SLM should provide feedback on the cause of the breach and details of the actions taken to

prevent the breach from recurring. Thus SLM provides a reliable communication channel and a

trusted relationship with the appropriate customers and business representatives.


2/29

Introduction:

Service Level Management (SLM) delivers a steady interface with the business for complete ser-

vice-related issues. SLM offers the organization with agreed service goals and the essential

management information to confirm that the targets have been met. Whether the targets are

breached, SLM must offer a feedback on the root cause of the target breach and information of

the actions to prevent the target breach from repetitive. Thus SLM delivers a consistent commu-

nication channel and a reliable relationship with the right customers and business corporate

representatives.

Agreements in a Software Maintenance Project:

Software maintenance establishes a main part of total cost of the lifecycle of the software appli-

cation. We can argue this can be the most essential fraction of a cost. The additional value of

software maintenance is frequently not observed by the clients/customers. Despite the fact the

introduction of fresh software project definitely shows new income, work done to keep up an

existing application is generally only obvious when the application is break down or minor

changes will be implemented (occasionally may cause nearly downtime). This effects in a nega-

tive opinion of software maintenance section. There is a proposed methodology to turn this in

the opposite direction, to offer the client/customer with details in the activities accomplished by

the software maintenance unit and to come to a precise and final agreement on the results and

opportunities of the activities.

In software maintenance, the Service Level Agreement (SLA) originates from the practice of the

specifications of results found in the contractual agreements of the large computing centers of

the 50s (McBride 1990). Service Level Agreements could be the used by software maintenance

for better managing customers expectations by specifying with the customer what the service

results will be. Until a few years ago, this management practice had been limited to operations

and support services: the literature search about agreements on Software maintenance turned

out some references to Software Maintenance Agreements (for instance Mueller 1994) but

most of the agreements reported were limited to helpdesk support, bug fixes and the distribu-

tion of new releases. No detailed agreements were reported to include the full spectrum of

maintenance services, including the management of the quality of the service.


3/29

Software maintenance versus software development

For the readers without work experience in a software maintenance section there is a need to

clarify how the management of maintenance activities differ from the management of software

project activities. While project management is organized towards the delivery of a product

within a specific time-frame, and a planned project closure date, the maintenance section must

be structured to face the day to day work for its clients with a continuous service and, by defini-

tion, no closure date. Key characteristics in the nature and handling of small maintenance re-

quest have been highlighted in, for example:

Modification requests come in more or less randomly and cannot be accounted for indi-

vidually in the annual budget-planning process;

Modification requests are reviewed and assigned priorities, often at the operational lev-

el most do not require senior management involvement;

The maintenance workload is not managed using project management techniques, but

rather queue management techniques;

The size and complexity of each small maintenance request are such that it can usually

be handled by one or two resources;

The maintenance workload is user-services oriented and application-responsibility ori-

ented.

Priorities can be shifted around at any time, and modification request of application cor-

rection can take priority over other work in progress.

Software Maintenance as a Service

The definition of service in the IT domain has been challenging. It is most pragmatic to say that

an IT service is a combination of a service surrounding an IT-object. When we look at the char-

acteristics of a service in general, it can be seen that there are a number of aspects generally

recognized:


4/29

An emphasis on direct sales to the customer

More direct contact with the customer

Service delivered on demand rather than weeks or months later

Shorter completion time

Output created as it is delivered

The product is not always a physical product

The output cannot always be stored or

transported

Services are less standardized than goods

Concurrency of consumption and production.

Software maintenance can be viewed as a service, for instance shorter completion time (com-

pared to software development projects) and no standardization, but also some differences.

One of the key differences is the tangibility of the output as perceived by the end user. The re-

sult of software maintenance (a new release) can be inspected and tested before it is intro-

duced to the customer. This is where the challenge lies to create awareness on the positive

business contributions of software maintenance activities. The SLA might just be the best in-

strument for that purpose.

General IT Service Failures:

1) Strategic FailureIs biggest failure, but every organizations are keen on this at least at

startup.

2)

Operational FailureObvious, there are certain issues which are bound to raise, during

the maintenance of project. To deal with this kind of events, incidents and changes Ser-

vice Delivery organizations (SDO) need to have agreements which details the procedure

to deal with the issues. And this agreement deciding the service delivery is called Service

Level Agreement (SLA).


5/29


6/29

Service Level Agreement:

Heres the formal 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 Service Level Management (SLM) mission statement is to plan, coordinate, negotiate,

report and manage the quality of IT services at acceptable cost. Additional ly, improvement is

integral to any SLA. [Ref: Wiki]

Service Level Agreements (SLAs) are contractually binding clauses documenting the perfor-

mance standard and service quality agreed to by the bank and service provider. The SLA is a key

component in structuring a successful outsourcing contract. The SLA ensures that the institu-

tion receives the services it wants at the expected performance standard and price. As such, the

SLA is a key component in managing the financial and operational risk involved with outsourc-

ing contracts. It also can be one way to help mitigate risk. By specifying the measurement unit

and service range for the selected category, the risk of poor service may be diminished because

it becomes an area of focus and is designated as the service providersresponsibility.

The SLAs primary purpose is to specify andclarify performance expectations, as well as estab-

lish accountability. Therefore, balancing the need for precise measurement standards with suf-

ficient flexibility is important. A common pitfall is excessive oversight or micromanagementof

the provider responsible for the service, which can also burden the bank employees charged

with supervising the service provider relationship and monitoring the SLAs.


7/29

A well-designed SLA will recognize and reward, or at least acknowledge, good service. It will al-

so provide the measurement structure or performance metric to identify substandard

service and trigger correction or cancellation provisions as warranted. In todays outsourcing

environment, incentives or penalties in the SLA can be an effective tool for managing service. If

services received do not measure up to expectations, direct consequences, such as reduced

levels of compensation or a credit on future services, would result.

Service Level Management:

Service Level Management (SLM) negotiates, agrees and documents appropriate IT service tar-

gets with representatives of the business, and then monitors and produces reports on the ser-

vice providers ability to deliver the agreed level of service. SLM is a vital process for every IT

service provider organization in that it is responsible for agreeing and documenting service level

targets and responsibilities within SLAs and SLRs, for every activity within IT. If these targets are

appropriate and accurately reflect the requirements of the business, then the service delivered

by the service providers will align with business requirements and meet the expectations of the

customers and users in terms of service quality. If the targets are not aligned with business

needs, then service provider activities and service levels will not be aligned with business ex-

pectations and problems will develop. The SLA is effectively a level of assurance or warranty

with regard to the level of service quality delivered by the service provider for each of the ser-

vices delivered to the business. The success of SLM is very dependent on the quality of the Ser-

vice Portfolio and the Service Catalogue and their contents, because they provide the necessary

information on the services to be managed within the SLM process.

SLA expectation with examples:

One of these guidelines is to know the parties dealing with the service. Additionally SLA should

clarify the expectations/requirements of each service. In the context of an internal agreement

on

Software maintenance services between the maintenance section and their customers the fol-

lowing list of expectations and requirements have been observed:


8/29

Example A):

A customer wants to concentrate on his business and expects a homogeneous service from his

IT organization. The result of this homogeneous service for the customer is the ability to work

with a set of information systems. The way this service and these systems are composed are of

less interest to the customer. This attitude should be reflected in the agreements made with

the customer by the IT organization, so the performance and quality of information systems

should be described not the quality of the components.

Example B): The maintenance section wants to give the customer a realistic image of what he

should expect and, in the rare case of an SLA where there is a notion of bonus/penalty; they

want to make sure that commitments are met. This means insights are required on the services

to be provided and the quality of the object, which has to be serviced. Hardware manufacturers

have done this for years in the form of warranties and service contracts on their products.

However, hardware components tend to have a higher degree of standardization making

maintenance easier. There is more empirical information on breakdown of components and

replacement is easier. Furthermore during the development of software the focus tends to be

on functionality rather than stability and maintainability.

A good SLA addresses:

What service(s) are being made available to what customers?

What level of service or quality of service should the customer expect?

What are the costs to provide this level of service?

How will the service be delivered?

Who will measure delivery and how?

What happens if the provider fails to deliver as promised?

How the SLA will change over time?


9/29

SLAs build on the legal contracts that set the framework for IT service and enable more opera-

tional 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.

Traditional approach of SLA is similar to the below process:

Figure 1: Traditional approach of SLA

NOTE: IT teams can have multiple SLAs based on different service criteria and different custom-

er 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.

In addition to SLAs 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 an-

other 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


10/29

SLM and it concepts

SLM is the name given to the processes of planning, coordinating, drafting, agreeing, monitor-

ing and reporting of SLAs, and the ongoing review of service achievements to ensure that the

required and cost-justifiable service quality is maintained and gradually improved. However,

SLM is not only concerned with ensuring that current services and SLAs are managed, but it is

also involved in ensuring that new requirements are captured and that new or changed services

and SLAs are developed to match the business needs and expectations. SLAs provide the basis

for managing the relationship between the service provider and the customer, and SLM pro-

vides that central point of focus for a group of customers, business units or lines of business.

An SLA is a written agreement between an IT service provider and the IT customer(s), defining

the key service targets and responsibilities of both parties. The emphasis must be on agree-

ment, and SLAs should not be used as a way of holding one side or the other to ransom. A true

partnership should be developed between the IT service provider and the customer, so that a

mutually beneficial agreement is reached otherwise the SLA could quickly fall into disrepute

and a blame culture could develop that would prevent any true service quality improvements

from taking place.

SLM is also responsible for ensuring that all targets and measures agreed in SLAs with the busi-ness are supported by appropriate underpinning OLAs or contracts, with internal support units

and external partners and suppliers. This is illustrated in below Figure shows the relationship

between the business and its processes and the services, and the associated technology, sup-

porting services, teams and suppliers required to meet their needs. It demonstrates how im-

portant the SLAs, OLAs and contracts are in defining and achieving the level of service required

by the business.

An OLA is an agreement between an IT service provider and another part of the same organiza-

tion that assists with the provision of services for instance, a facilities department that main-

tains the air conditioning, or network support team that supports the network service. An OLA

should contain targets that underpin those within an SLA to ensure that targets will not be

breached by failure of the supporting activity.


11/29

Figure 2: Service Level Management between individual teams

Value to the business

SLM provides a consistent interface to the business for all service-related issues. It provides the

business with the agreed service targets and the required management information to ensure

that those targets have been met. Where targets are breached, SLM should provide feedback

on the cause of the breach and details of the actions taken to prevent the breach from recur-

ring. Thus SLM provides a reliable communication channel and a trusted relationship with the

appropriate customers and business representatives.


12/29

Service Level Management activities

The key activities within the SLM process should include:

Determine, negotiate, document and agree requirements for new or changed services in

SLRs, and manage and review them through the Service Lifecycle into SLAs for opera-

tional services

Monitor and measure service performance achievements of all operational services

against targets within SLAs

Collate, measure and improve customer satisfaction

Produce service reports

Conduct service review and instigate improvements within an overall Service Improve-

ment Plan (SIP)

Review and revise SLAs, service scope OLAs, contracts, and any other underpinning

agreements

Develop and document contacts and relationships with the business, customers and

stakeholders

Develop, maintain and operate procedures for logging, action and resolving all com-

plaints, and for logging and distributing compliments

Log and manage all complaints and compliments

Provide the appropriate management information to aid performance management and

demonstrate service achievement

Make available and maintain up-to-date SLM document templates and standards.

Although Figure below illustrates all the main activities of SLM as separate activities, they

should be implemented as one integrated SLM process that can be consistently applied to all

areas of the businesses and to all customers.


13/29

The interfaces between the main activities are illustrated in the below figure.

Figure 3: SLM Main Activities


14/29

Designing SLA frameworks

There are various reference measures that can be used while designing SLA. The SLAs struc-

ture is entirely defined in its management literature which describes the services for all of its

customers. There are various frameworks which defines this needs and are stated as under: -

Service-based SLA

The service based SLA can be described as providing the service to all of their associated clien-

tele. Lets say for example the student information system provides an accessibility to all of

the customers that has been associated with that. Here the professor, student and the admin-

istration can access the services based on what they are allowed to. Herein the professor is

having an access to his emails, uploading grades, assignments and many. In similar way, stu-

dents are having an access to their emails, grades, assignments and many more. So generally

this service based SLA could be developed for the entire organization providing the service

which was agreed upon and documented for example: - email-service. Implementing such a

system as service based SLA is quite difficult for the entire organization with changing needs.

Herein for the student information system, establishing an email service is quite a tough job.

As for most of the customers we need to decide and grant the access for which they are sup-

posed to have. Well for the same information system providing the same service and if the

requirements differ for each of these customers then it becomes somewhat difficult to imple-

ment for each of those customers .Generally theres some reasoning while providing the ser-

vices to these customers. Lets say the customers here are connected by various means such

as LAN and WAN. The administration and professors workstation are connected via a high-

speed LAN while that for students accessing the terminals from different locations across the

campus are usually connected to low-speed WAN. In addition there are various difficulties,

such as providing such access to each of them and also who will be signing these agreement.

There are variety of services from which one can choose such as full access services (gold),

partial access to services (silver), an access to service without any modification in it (bronze).


15/29

Customer-based SLA

The customer based SLA totally defines all the services that are been used by the customers of

the organization. Lets say for an example an agreement may be submitted to an HR depart-

ment in the organization where they usually sorts out the candidates who needs to be calledfor the interviews, the accounts department for providing the reimbursement to the candi-

dates, the finance department, the payroll system and any other system they use while man-

aging the accounts of the organization. Usually, the customers needs such a document which

consists of all the information that provides the service. The entire document consists of the

agreement that the customer needs and agrees upon and they are usually written in a single

document. A signature is mandatory for all of the agreements stated in the document.

Multi-level SLAs

Majority of the organization choose to opt for a multi level SLA that provides the service

across various the organization as and when called off. These multi-level SLAs are generally

categorized into three levels:-

Corporate Level

Customer Level

Service Level

Corporate Level: - The corporate level SLA includes the issue pertaining to every customer re-

spondent to the organization. Herein the information across the organization does not

change frequently, so they are less updated SLAs.

Customer Level: - The customer level SLA mainly covers all the issues of the management that

focuses on the customer group or the business organization.

Service Level: - The service level SLA mainly covers all the issue of the management that fo-

cuses on the service pertaining to a specific of that kind. Here one for each of those services

are covered by the SLA.


16/29

A multi-level SLA is depicted in the figure which shows a hierarchy of the SLA. The advantage

of such an SLA is to keep the service agreements transparent which avoid the repeated work

and allows to make quick updates on such agreements.

Figure 4:Multi-level SLAs

The business organization usually uses Multi Level SLA which allows to help producing

standards for the system. These standards or the template is the base starting point for all the

service level agreements (SLA) as well as SLRs and OLRs. In each of these SLAs it is necessary

to detail as how to deal or cope up with each of these services. These standards and tem-

plates developed figure out what was important and are these SLAs developed in the order

that was needed? These standards and templates will minimize the error failure in the system

and will ease their use for operation and management.

These SLAs should be clear and should be easy to understand. These SLAs must be written in

pure textual language which is easy to understand every details of the system accurately. A

proof read of these agreement is indeed needed and it should be carried out by the person


17/29

who is not involved while writing the agreement. In addition these SLAs needs to be so effi-

cient that

Developing SLA

There are four major steps in developing a SLA and they can be rendered as the hierarchy of

the agreements. To develop an SLA, one need to follow a four-step process as described un-

der:

Four-Step Process

The four step process of developing an SLA says all about determining objectives, defining re-

quirements, setting the requirements and establishing accountability. These process allows us

to determine the peer requirements of the service and translates those sort of services into

accountable requirements that could be easily maintainable and traceable. The list view of

four-step process is shown under:-

Determining objectives.

Defining requirements.

Setting measurements.

Establishing accountability.

Determining Objectives

The first step in developing an SLA is to determine the objectives of the system that has been

aimed to achieve the goals of the system. Lets say for example the banking service provider

needs to consider all the objectives of the bank before developing an agreement such as cash

advances, cash deposits, cash rendering and many more. The organization needs to consider

all the interdependencies with the outsourced party including each and every functionality of

the system. Based on these notions, the objectives of the organization are well understood

and helps in determining the criticality of the functionalities that are taken wrong into the

consideration. For every minute details described in the system, there should be a clear scope

as what functions and areas would lead the system to a success by analyzing all the objec-

tives.


18/29

Defining Requirements

The most important step in developing an SLA is to define the requirements. The requirements

of a particular organization could be achieved by sub dividing the objectives of the organiza-

tion into specific activities to achieve goal. The objectives defined in the SLA drives all the way

to define the success which originates from the objectives.

Setting Measurements

In formulating an agreement, the bank can identify specific measurements that indicate if the

prescribed requirements are being met. The measurements - or metrics - that correspond to

the performance requirements represent tangible or quantifiable deliverables that bank man-

agement can monitor and discuss with the service provider, as appropriate. Target metrics

should be objective and clearly linked to the banks business needs and risk management re-quirements. Metrics should be established based on specific tolerance levels and the minimum

acceptable levels of service. A minimum acceptable level of service also should be set to define

the point of significant failure.

The first objective pertains to system security and may be appropriate for an outsourced activi-

ty involving sensitive data or applications. The second objective addresses certain reliability and

availability needs that may be associated with an outsourced system that processes or stores

information essential for bank employees or customers. The corresponding performance re-

quirements and measurements provide the means to quantify and document service provider

performance.

Establishing Accountability

Clear definitions of accountability are important to ensure that both the bank and the service

provider understand their roles and responsibilities for each service level requirement. Howev-

er, beyond simply designating a role or activity, accountability should also be established by

specifying the consequences if a given service level is not met. Incentives and penalties can play

a key role in establishing accountability.

Incentives can be used to motivate a service provider to meet or exceed specified service levels

by offering a reward. Rewards should generally be attractive enough to motivate the provider,


19/29

but less than the actual financial value provided by the service. Penalty clauses also should be

considered and bank management should have the right to exercise these penalties for any de-

fined service delivery failures. When negotiating incentives and penalties into an

SLA, it is helpful to consider:

The importance of the performance measure to the bankthis will help the bank deter

mine how to weight the associated incentives/ penalties as well as the frequency for

monitoring performance.

Each partys expectations for quality and consistencythese factors, coupled with prior

experiences, may help the bank determine the best method for motivating the provider

toward desired performance.

The severity of the consequences to the bank if key performance measures are not

met the effect on the institution should be a motivating factor for the institution

when determining whether compensation clauses or other remedies should be provid-

ed.


20/29

SAMPLE SERVICE LEVEL AGREEMENT

Purpose:

This agreement is between Buyer and Vendor. This document outlines the service level roles,

responsibilities, and objectives of Buyer and Vendor in support of the given functional area.

Scope of Services:

Vendor will house, manage, and operate all hardware and software necessary to provide Inter-

net banking applications to Buyer.

Service Category:

This SLA addresses application availability.

Acceptable Range of Service Quality:

The Internet banking application shall be available at least 99.5% of each week.

Definition of what is Being Measured:

Availability will be measured as the percentage ofminutes each day that the Internet banking

application will be able to receive and respond to messages from the Internet. The servers abil-

ity to receive messages will be ascertained using time-check availability software.


21/29

Formula for Calculating the Measurement:

System availability shall be measured as the number of minutes per day that the Buyers Inter-

net banking application is capable of receiving and responding to messages from the Internet

divided by 1,440 (the total number of minutes in a day).

A 30-minute period from 2:00 AM to 2:30 AM shall be excluded from the calculation because

Vendor will be performing system maintenance at this time each day.

Relevant Credits/Penalties for Achieving/Failing Performance Targets:

If Vendor is unable to provide this service level to Buyer, Vendor will provide priority support to

Buyer until performance levels are met. Service below the prescribed level will result in a re-

bate of 50% of the monthly fee for the month in which the exception takes place.

If Vendor fails to provide the agreed upon service level for more than two consecutive months,

buyer shall have the right to renegotiate the contract and/or terminate this agreement.

Frequency and Interval of Measurement:

The systems availability shall be measured daily by Vendor using the time-check availability

software. Vendor shall submit monitoring reports generated by this program to Buyer on a

weekly basis.

Buyers Responsibilities:

Buyer shall review all monitoring reports and advise Vendor of any deviations from this agree-

ment in a timely manner.


22/29

(Include any other items that Buyer will need to do so that Vendor may perform its tasks.)

Vendors Responsibilities:

Vendor shall assume responsibility for customer communications at the point that customer

messages leave the Internet service provider.

Vendor shall ensure that all messages are processed in a timely fashion. (Be sure to define the

specifics of timely standards.)

Vendor shall ensure that the system shall be able to accept and respond to 1,200 inquiries per

minute. (Include any other items that Vendor will need to do to provide the prescribed level of

service to Buyer.)

Escalation Guidelines:

In the event that Vendor is unable to meet the terms of this agreement, the CIO of Buyer and IT

Manager of Vendor shall discuss resolution of the situation. If Vendor will be unable to provide

service for more than two hours, Vendors contingencyoperating plan shall be invoked.

Renegotiations:

Authorized representatives of Buyer and Vendor must mutually agree upon changes to this SLA.

All changes must be made and agreed to in writing. Either party may request review of this SLAat any time. Each party will review the SLA annually and advise the other party of any desired

changes.


23/29

SLA Check List

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

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


24/29

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 handling

Does the agreement delineate service costs and penalties for substandard performance?

Service cost and financial penalties


25/29

Case Study Service Level Agreement

Below is the case study we have developed based on the SLA developing steps mentioned above for IT

support. SLAs vary for each department and tasks.

S.no Activity Service Level Agreement

1 Name the Parties Between:

IT Service Organization and Client/Customer

2 Define the time

period

For:

Jan 1, 2014 through Dec 31, 2014

3 Services to be pro-

vided

Services to be provided by the IT Service Organization:

Provides first, second and third-level support for standard software

applications and hardware.

Resolve all Service Incidents.

Meet SLAs of each incident, 95% of all incidents need to be met.

Root Cause Analysis need to be uploaded in Known Error Database.

4 Hours that ser-

vices are provided

Hours of Operation (Central Time):

Regular Business Hours:

7:00 a.m. to 7:00 p.m. Monday through Friday (non-holiday)

After-hours support via On-call Support ( Resolution time is doubled)

7:00 p.m. to 7:00 a.m. Monday through Friday (non-holiday)

24 hours Saturday and Sunday

24 hours holidays

5 Service Access Service Access

Telephone: 312/555-1500

E-Mail: [email protected]

On-Call: 312-555-0220


26/29

6 Customer Respon-

sibilities

Customer Responsibilities:

Ticket need to be raised whenever the issue is found.

Customer is responsible to provide sufficient information of the application (

screenshots if available )

Customer is aware of application process

Each customer must read and accept in writing the Corporate Security Policy

and Corporate computer Usage policy.

7 Resolution and

ponse Time

Severity Response time Resolution Time

S-1 15min99% 4 hours95%

S-2 30min95% 8 hours95%

S-3 2 hours95% 2 working days95%

S-4 1day -95% 7 WD90%

8 Escalation Proce-

dures

Escalation Procedures

Level Escalate when Call Phone/Pager

1

Agreed response Incident Manager 312/555-1234

time not met 312/555-0050

2

No response 2 Project Manager, Operations 312/555-1255

hours after Level 312/555-0077

1 escalation

3

No response 3 V.P. Operations 312/555-1233

hours after Level 312/555-0010

3 escalation


27/29

9 Reporting Proce-

dures

Reporting

Weekly/ Monthly/ Quarterly Reporting

Distribution:

Project Manager,

V.P. Operations

Content:

Number of Incidents

Incident breakdown based on average response and MTTR

Percentage of SLA met

Incidents re-opened

SLA Breaches

10 Signatures Signatures:

_______________________________________

Manager, Help Desk

_______________________________________

Manager, Operations

_______________________________________

Manager, Marketing

_______________________________________

V.P.


28/29

Challenges & Risk Handling

Who owns the Service?

Senior management for cost & output

Team membersuses the services are interested in Responsiveness & usability and Reliability

When no past monitored data is available

Leave agreement in Draft format for initial period

Negotiate a timeframe for realistic targets

SLAs signed after re-negotiation in most cases

Address incidents during initial SLA

Service providers cover all corporate level issues at the time of initial SLA

SLA Awareness

Steps must be taken to advertise the existing and new SLAs to Support engineers

It is import that IT staff are committed to SLM process.

Bypassing the use of SLM process ( Postpone the task, as there is enough resolution time)

Service providing mangers must analyze the MTTR of similar incidents and explain the im-

portance to gain the trust of customer


29/29

Conclusion

A good SLA will help your organization to promise what is possible to deliver and deliver what is prom-

ised. Now you are ready to create your first service level agreement and although it can be a daunting

ask to write an SLA, remember that introducing SLAs is not a commitment to deliver the impossible. Aservice level agreement can be as informal as a performance target or as rigid as a committed time to

restore a system to operation backed by penalties.

In either case, the SLA serves as a basis for establishing a shared understanding of the service relation-

ship. When properly developed, SLAs offer a win-win situation for both the service provider and the cus-

tomer.

References

http://www.cio.com/article/2438284/outsourcing/sla-definitions-and-solutions.html

http://www.nkarten.com/ExcerptSLAHandbook.pdf

https://www.fdic.gov/news/news/financial/2014/Tools-to-Manage-Technology-Providers.pdf

http://www.mitsm.de/service-level-agreement-management-en

https://measure2improve.econtrack.co.uk/Documents/Document.ashx?2370

http://www.cio.com/article/2438284/outsourcing/sla-definitions-and-solutions.html

http://wiki.servicenow.com/index.php?title=ITIL_Service_Level_Management

http://www.teamquest.com/resources/itil/service-delivery/service-level-management/
http://www.cio.com/article/2438284/outsourcing/sla-definitions-and-solutions.htmlhttp://www.cio.com/article/2438284/outsourcing/sla-definitions-and-solutions.htmlhttp://www.nkarten.com/ExcerptSLAHandbook.pdfhttp://www.nkarten.com/ExcerptSLAHandbook.pdfhttps://www.fdic.gov/news/news/financial/2014/Tools-to-Manage-Technology-Providers.pdfhttps://www.fdic.gov/news/news/financial/2014/Tools-to-Manage-Technology-Providers.pdfhttp://www.mitsm.de/service-level-agreement-management-enhttp://www.mitsm.de/service-level-agreement-management-enhttps://measure2improve.econtrack.co.uk/Documents/Document.ashx?2370https://measure2improve.econtrack.co.uk/Documents/Document.ashx?2370http://www.cio.com/article/2438284/outsourcing/sla-definitions-and-solutions.htmlhttp://www.cio.com/article/2438284/outsourcing/sla-definitions-and-solutions.htmlhttp://wiki.servicenow.com/index.php?title=ITIL_Service_Level_Managementhttp://wiki.servicenow.com/index.php?title=ITIL_Service_Level_Managementhttp://www.teamquest.com/resources/itil/service-delivery/service-level-management/http://www.teamquest.com/resources/itil/service-delivery/service-level-management/http://www.teamquest.com/resources/itil/service-delivery/service-level-management/http://wiki.servicenow.com/index.php?title=ITIL_Service_Level_Managementhttp://www.cio.com/article/2438284/outsourcing/sla-definitions-and-solutions.htmlhttps://measure2improve.econtrack.co.uk/Documents/Document.ashx?2370http://www.mitsm.de/service-level-agreement-management-enhttps://www.fdic.gov/news/news/financial/2014/Tools-to-Manage-Technology-Providers.pdfhttp://www.nkarten.com/ExcerptSLAHandbook.pdfhttp://www.cio.com/article/2438284/outsourcing/sla-definitions-and-solutions.html