Service level agreement

From Wikipedia, the free encyclopedia

(Redirected from Service Level Agreement)
Jump to: navigation, search
/
wiki/Image:Ambox_c
This article or section is missing citations or needs footnotes.
Using inline citations helps guard against copyright violations and factual
ontent.png inaccuracies. (April 2007)
/wiki/Image:Ambox_
content.png
A service level agreement (frequently abbreviated as SLA) is a part of a service contract where
the level of service is formally defined. In practice, the term SLA is sometimes used to refer to
the contracted delivery time (of the service) or performance.

Contents
[hide]
1 Description
2 Common metrics
3 Typical contents
4 In outsourcing
5 References

[edit] Description
A Service Level Agreement (SLA) is a negotiated agreement between two parties where one is
the customer and the other is the service provider. This can be a legally binding formal or
informal 'contract'(see internal department relationships). Contracts between the service provider
and other third parties are often (incorrectly) also called SLAs — as the level of service has been
set by the (principal) customer there can be no 'agreement' between third parties (these
agreements are simply a 'contract').
The SLA records a common understanding about services, priorities, responsibilities, guarantees
and warranties. Each area of service scope should have the 'level of service' defined. The SLA
may specify the levels of availability, serviceability, performance, operation, or other attributes
of the service such as billing. The 'level of service' can also be specified as 'target' and
'minimum', which allows customers to informed what to expect (the minimum), whilst providing
a measurable (average) target value that shows the level of organisation performance. In some
contracts penalties may be agreed in the case of non compliance of the SLA (but see 'internal'
customers below).It is important to note that the 'agreement' relates to the services the customer
receives, and not how the service provider delivers that service.
SLAs have been used since late 1980s by fixed line telecom operators as part of their contracts
with their corporate customers. This practice has spread such that now it is common for a
customer to engage a service provider by including a Service Level Agreement in a wide range
of service contracts, in practically all industries and markets. Internal departments in larger
organisations (such as IT, HR and Real Estate) have adopted the idea of using service level
agreements with their 'internal' customers — users in other departments within the same
organisation. One benefit of this can be to enable the quality of service to be benchmarked with
that agreed across multiple locations or between different business units. This internal
benchmarking can also be used to market test and provide a value comparison between an in-
house department and an external service provider.
Service Level Agreements are by their nature 'output' based - the result of the service as received
by the customer is the subject of the 'agreement'. The (expert) service provider can demonstrate
their value by organising themselves with ingenuity, capability and knowledge to deliver the
service required, perhaps in an innovative way. Organisations can also specify the way the
service is to be delivered, through a specification (a service level specification) and using
subordinate 'objectives' other than those related to the level of service. This type of agreement is
known as an 'input' SLA. This latter type of requirement has become obsolete as organisations
become more demanding and shift the delivery methodology risk on to the service provider.

[edit] Common metrics

Service Level Agreements can contain numerous service performance metrics with
corresponding service level objectives. A common case in IT Service Management is a call
center or service desk. Metrics commonly agreed to in these cases include:
ABA (Abandon Rate): Percentage of calls abandoned while waiting to be answered.
ASA (Average Speed to Answer): Average time (usually in seconds) it takes for a call to be
answered by the service desk.
TSF (Time Service Factor): Percentage of calls answered within a definite timeframe, e.g.
80% in 20 seconds.
FCR (First Call Resolution): Percentage of incoming calls that can be resolved without the
use of a callback, or without having the caller call back the helpdesk to finish resolving
the case.
TAT (Turn Around Time): Time taken to complete a certain task.
Uptime Agreements are another very common metric, often used for data services such as
shared hosting, virtual private servers and dedicated servers. Common agreements include
percentage of network uptime, power uptime, amount of scheduled maintenance windows etc.
Many SLAs track to the ITIL specifications when applied to IT services.

[edit] Typical contents

SLAs commonly include segments to address: a definition of services; performance
measurement; problem management; customer duties; warranties; disaster recovery; termination
of agreement.[1]

[edit] In outsourcing
Outsourcing involves the transfer of responsibility from an organization to a supplier.The
management of this new arrangement is through a contract that may include a Service Level
Agreement (SLA).The contract may involve financial penalties and the right to terminate if
SLAs are consistently missed. Setting, tracking and managing SLAs is an important part of
Outsourcing Relationship Management (ORM) discipline. It is typical that specific SLAs are
negotiated up front as part of the outsourcing contract and they are utilized as one of the primary
tools of outsourcing governance.
Uptime
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Uptime is a measure of the time a computer system has been "up" and running. It came into use
to describe the opposite of downtime, times when a system was not operational. The uptime and
reliability of computer and communications facilities is sometimes measured in nines (similar to
the unit of metallic purity). "Five nines" means 99.999% availability, which translates to a total
downtime of approximately five minutes and fifteen seconds per year.
\ T
o
Availability per day per month per year
99.999% 00:00:00.4 00:00:26 00:05:15
99.99% 00:00:08 00:04:22 00:52:35
99.9% 00:01:26 00:43:49 08:45:56
99% 00:14:23 07:18:17 87:39:29
It is often used as a measure of computer operating system reliability and stability, in that this
time represents the time a computer can be left unattended without crashing, or needing to be
rebooted for administrative or maintenance purposes. Conversely, long uptime can indicate
negligence, because critical updates can sometimes require reboots.

Contents
[hide]
1 Records and comparisons
2 Determining system uptime
3 See also
4 References
5 External links

[edit] Records and comparisons

The Uptime-Project, collected data on uptimes from users until 1 March 2007, and the current
record for longest uptime is 11 years, 303 days, 20 hours and 57 minutes on a computer running
OpenVMS. Rumours mention in January 2008 that Irish Rail had an OpenVMS machine up for
18 years[1], and was restarted just for Y2K tests.
Netcraft maintains the uptime records for many thousands of web hosting computers.
The uptime of a personal computer is sometimes displayed as a badge of honour on an email
signature or web site/forum. This was especially true in the Windows 9x days[citation needed],
where Windows NT and Windows 2000 users would boast of uptimes of more than 30 days,
whereas many real-world Windows 9x installations crashed more often. In more recent times
very long uptimes for home users with Windows NT and Windows 2000 machines are less
striking because the Windows 9x line has been replaced by the Windows NT-based Windows
XP.

[edit] Determining system uptime

Users of Windows XP Professional, Windows Server 2003 and Windows Vista systems can type
systeminfo at the Command Prompt to display all system information, including the System Up
Time. Windows Vista Business 64bit does not have an "Up Time" variable but rather "System
Boot Time".
C:\> systeminfo | find "Up Time"
System Up Time: 0 Days, 8 Hours, 7 Minutes, 19 Seconds
Service Level Management - ITIL V2
From IT Process Wiki
Jump to: navigation, search
diese Seite auf
Deutsch
ITIL Version: ITIL Version 2 (ITIL V2)
Process-Objective: Service Level Management has the tasks of maintaining the IT
Organisation's Service Catalogue and reaching binding agreements for internal and external
Service Performances. At the interface with the client, Service Level Agreements are agreed. The
Service Level Manager is responsible for the monitoring of the agreed quality parameters and
where necessary resorts to counter-measures. The adequate provision of internal IT Services is
secured via Operational Level Agreements and Underpinning Contracts (OLAs/UCs).
Part of: Service Delivery
Process Owner: Service Level Manager

Contents
[hide]
1 Sub-Processes
2 Involved Roles
3 Related Checklists and KPIs
3.1 Checklists
3.2 KPIs
4 Related ITIL Glossary Terms

[edit] Sub-Processes
/index.php/Image:Overview_slm.jpg

/index.php/Image:O
verview_slm.jpg
Overview of Service Level Management
Maintain Structures for Service Level Management
Process objective: The multitude of documents used within Service Level Management are to
be adjusted in such a manner, that they correspond to the requirements of new or changed IT
Services.
Define Service Requirements
Process objective: Requirements from the client viewpoint with regards to a new or altered
IT Service are to be documented and submitted to an initial evaluation, so that alternatives
may be developed at an early stage for requirements which are not technically or
economically feasable.
Create Service Specification Sheet
Process objective: The requirements of a new or altered IT Service are described in more
detail, and specifications are drawn up as to how the Service is created from an IT viewpoint
and how the invoicing takes place.
Negotiate and agree Contractual Regulations for the Service
Process objective: Finalisation of binding agreements to an IT Service between the IT
Organisation and the client-side, a well as ensuring sufficient Service Levels with internal
and external Service providers, which support the provision of the Service.
Prepare Service Implementation
Process objective: Identification of preconditions, which must be established for the
implementation of the new or altered Service, so that a correspondoing Change Request may
be compiled.
Commission Service Implementation
Process objective: After clearance of the Change, the implementation of the IT Service is to
be planned in further detail; the Service Level Manager subsequently commissions the
technical experts in Application or Infrastructure Management to start the implementation.
Carry out Service Level Reporting
Process objective: It is to be given account of the attained Service quality as well as potential
counter-measures for the correction of infringements to the agreed Service Levels.
Process Complaints and Carry out SLA Reviews
Process objective: Investigation of the agreed Service Levels, in order to ensure that the
SLAs are still adequate for client requirements; processing of complaints and where
necessary, assume corrective measures.

[edit] Involved Roles

Capacity Manager
Client (Contract Partner)
Financial Manager
IT Service Continuity Manager
Service Level Manager
[edit] Related Checklists and KPIs

[edit] Checklists
Checklist Service Level Requirements (SLR)
Checklist Service Specification Sheet
Checklist Service Level Agreement (SLA)
Checklist Operational Level Agreement (OLA)
Checklist Underpinning Contract (UC)
Checklist Service Catalogue
Checklist Service Level Report
Checklist Protocol SLA Review
Checklist Service Quality Plan (SQP)
Checklist Service Improvement Plan (SIP)

[edit] KPIs
Key Performance Indicators "Service Level Management" according to ITIL V2

[edit] Related ITIL Glossary Terms

Service Level Requirements (SLR)
Service Specification Sheet
Service Level Agreement (SLA)
Service Catalogue
Operational Level Agreement (OLA)
Underpinning Contract (UC)
Service Quality Plan (SQP)
Service Improvement Program (SIP)
Service Level Report
Retrieved from "http://wiki.en.it-processmaps.com/index.php/Service_Level_Management_-
_ITIL_V2"
KPIs Service Level Management
diese Seite auf
Deutsch

ITIL Process: Service Delivery - Service Level Management

Key performance Indicator

Definition
(KPI)

Service Elements in SLAs Number of service elements included in SLAs

Service Elements with Number of Service Elements in SLAs which are secured by corresponding
OLAs/UCs OLAs/UCs

Number of monitored SLAs, where weak-spots and counter-measures are

Monitored SLAs
reported

SLAs under Review Number of SLAs which are regularly reviewed

Fulfilment of Service Levels Number of SLA elements where the agreed service levels are fulfilled

Number of shortcomings in the service provision, which are identified and

Number of Shortcomings
addressed in an improvement plan
[edit] Service Level Requirements (SLR)

 The Service Level Requirements document contains the requirements for a

service from the client viewpoint, defining detailed service level targets, mutual
responsibilities, and other requirements specific to a certain (group of)
customers.

Service Specification Sheet

 The Service Specification Sheets lays out in detail how the customer
requirements can be fulfilled from the viewpoint of the IT Organisation.
 In particular, it references the internal IT Service components used to build
the new or changed Service required by the customer (i.e. the necessary
services provided from within the IT Organisation or from external Service
Suppliers).
 This document may also list further consequences related to the provision of
the IT Service, such as required resources and skills.

[edit] Service Catalogue

 A database or structured document with information about all live services,

including those available for deployment.
 The Service Catalogue is the only part of the Service Portfolio published to
Customers, and is used to support the sale and delivery of IT Services.
 The Service Catalogue includes information about deliverables, prices,
contact points, ordering and request processes.

Operational Level Agreement (OLA)

 An agreement between an IT service provider and another part of the same

organization.
 An OLA supports the IT service provider's delivery of services to customers.
 The OLA defines the goods or services to be provided and the responsibilities
of both parties.
  For example there could be an OLA - between the IT service provider and a
procurement department to obtain hardware in agreed times - between the
Service Desk and a support group to provide Incident resolution in agreed times.
 see also: ITIL Checklist SLA - OLA - UC

Underpinning Contract (UC)

 A contract between an IT service provider and a third party.

 The third party provides services that support the delivery of a service to a
customer.
 The Underpinning Contract defines targets and responsibilities that are
required to meet agreed Service Level targets in an SLA.
 see also: ITIL Checklist SLA - OLA - UC

Service Level Report

 The Service Level Report gives insight into a service provider's ability to
deliver the agreed service quality.
 To this purpose, it compares the agreed and actually achieved service levels,
and also includes information on the usage of services, ongoing measures for
service improvement, and any exceptional events.
 A Service Level Report is issued by the service provider for its customers, IT
management and other Service Management processes.
 A similar report is also created by an external service supplier to document its
achieved service performance.
http://www.itil-process-wiki.org/index.php?title=Main_Page

Service Level Management

From ITIL Process WIKI
Jump to: navigation, search

Contents
[hide]
1 Description/Summary
2 Objectives
3 Roles & Functions
3.1 Service Level Management specific roles
3.1.1 Static Process Roles
3.1.2 Dynamic Process Roles
3.2 Service Specific Roles
3.3 Customer Specific Roles
4 Information artifacts
5 Key Concepts
5.1 Service Levels
5.2 Service Quality Plan
5.3 Service Improvement Porgramm
5.4 Cost/ price simulations
6 Process
6.1 High Level Process Flow Chart
6.2 Critical Success Factors
6.3 Performance Indicators (KPI)
6.4 Process Trigger
6.4.1 Event Trigger
6.4.2 Time Trigger
6.5 Process Specific Rules
6.6 Process Activities
6.6.1 SL Design
6.6.2 SL implementation and review
6.6.3 SL cancellation
Description/Summary
Service Level Management (SLM) Process is defining, etsblishing, monotoring and optimizing
service quality and service levels of services agreeed with the customer. Objectives and
framework of the service levels and service quality are defined in the Service Level Management
Process.
Service Level Management in ...
ITIL V3:
COBIT:
ISO/IEC 20000:

Objectives
The purpose of IT Service Level Management Process is to provide quality of service
agreed with the customer and to imporve the service quality as a balance between value of
customer and service quality improvement costs
Service Level Management contributes to an integrated Service Management approach by
achieving the following goals:
Establishing and assuring the ciontracted service quality

Roles & Functions

Service Level Management specific roles

Static Process Roles

See Service Level section, Service Level Management Roles x Person for details
Service Level Management Process Owner
Initiator of the process, accountable for defining the process strategic goals and allocating all
required process resources. See Continual Process Improvement Management for a detailed
description of these activities.
Service Level Management Process Manager (SL Manager)
Manager of the entire process, responsible for its effectiveness and efficiency. Team leader
of the function "Service Level Management Team". See Continual Process Improvement
Management for a detailed description of these activities.
Service Level Management Team
Team associated to the Service Level Management Process.

Dynamic Process Roles

These roles are dynamically created during the Service Level Management Process. See the
process-specific or activity-specific rules for details.
Service Level Management Owner
 The attribute in the records contains the value of the Role/Function currently accountable for
the Service (but NOT for the Service Level Management Process). The Service Level
Management Owner can be changed with the help of a hierarchical Escalation. The content
or partner related organization of supply is depending on strategic definition in supply
strategy.
Service Level Management Agent
The attribute in the records contains the value of the Role/Function currently responsible for
the activity or task within an activity of the Service Level Management Management. The
Service Level Management Agent can be changed with the help of a functional Escalation,
if permitted by the rules.

Service Specific Roles

Roles depending on the affected service are found in the Supply Strategy or Policy Definition.

Customer Specific Roles

Customer SL Manager
Person acting as the SL owner for specific customer defined by historic relationship with
customer or sales and distribution strategy

Information artifacts
This section describes information/data required or recorded by the process. Typically the SLA
process is based on the SL specification:
Customer unique ID: Identification of customer
Service: definition of service regarded
Service levels: Service levels agreed for the service
Tolerances: Tolerance levels for the SL defined
Definition of terms: Definition of terms to describe the SL

Key Concepts

Service Levels
Quality of service can be defined my diverse metrics and descriptions. The ideas behind is to
describe the quality of the agreed service. Numerous possibilities for service level definitions are
possible and depend typically of the service content:
Hours of operations for IT operations
Duration of support team issue solution for support teams
Number of bugs per line of code in case of software delivered
Other
Typically this metrics need a reference like time period, number of customer, number of users
etc. E.g. the SL for IT operations of an IT system could be defined as follows:
 24 hours / 7 days operation
99% availability of the system
Non availability only on 2 hours per month
The basic service is described in the Service Agreement, that is defined in the Service Agreement
Management Process.

Service Quality Plan

Plan how to deliver the agreed quality for each service. Steps and actions are defined for internal
and external service suplier.

Service Improvement Porgramm

In case of low service quality an SIP is defined to impeove the quality fo service.

Cost/ price simulations

For the definition of best price of service/ cost of service relation for the customer and the
organization, simulations are often done, involving the review of all costs-related to service and
the price that should be requested from the customer. This simulation is supported by SL Process
with costs, all other variables and the customer negotiations can be supported by CRM Process,
SL Agreement Management Process and Service Design Process.

Process
High Level Process Flow Chart
This chart illustrates the Supply Management process and its activities.
Critical Success Factors
Critical Success Factors (CSF):
Clear defined metrics and processes
Established efficient monitoring process

Performance Indicators (KPI)

Service levels exceeded
Incidents
Customer staisfaction

Process Trigger

Event Trigger

Time Trigger
Permanent review of service quality

Process Specific Rules

every service level agreement has defined service levels
service levels are monitored
service levels are permanently improved
Note: for the different types of rules see Rules.

Process Activities

SL Design
This activity supports the SL Agreement Management process by defining:
technical aspects
internally possible service levels and costs for these service levels
possible new service levels, upgraded service levels, existing service levels
commercial aspects
costs of possible service levels and their combinations
If new service levels or service level combinations are requested, SL Management requests
internal resources and experts for support in definition of costs and efforts.
Activity Specific Rules
provide cost/ SL relations
 set status on "designed"

SL implementation and review

Agreed service levels for services are provided to this activity in the service catalogue. This
activity supports the SL Agreement Management process by monitoring the service quality
reviewing:
issues
problems
customer records
and auditing existing services and service levels. In case of service issues the Issue or Problem
Management are triggered and the CRM management is informed. A SIP is established,
implemented and reviewed.
This activity is provided as long as there is agreement cancellation.
Activity Specific Rules
provide review on agreed service levels
in case service in cancelled:
set status on "end of service", trigger next activity

SL cancellation
SL Agreement Management informs the SL Management in case of contract cancellations. SL
Management stops the review of SL quality.
Activity Specific Rules
in case of SL Agreement cancellation
stop review on agreed service levels
set status on "cancelled"
Retrieved from "http://www.itil-process-wiki.org/index.php?title=Service_Level_Management"
Service Level Agreement Management
From ITIL Process WIKI
Jump to: navigation, search

Contents
[hide]
1 Description/Summary
2 Objectives
3 Roles
3.1 Service Level Agreement Management Specific Roles
3.1.1 Static Process Roles
3.1.2 Dynamic Process Roles
3.2 Service Specific Roles
3.3 Customer Specific Roles
4 Information artifacts
4.1 Customer Requirement
4.2 The Service Agreement Record
4.3 Service Catalog
4.4 Service Agreement Record attributes mapped to activities
4.5 Additional Information Items
5 Key Concepts
5.1 Status of Service Agreements
6 Process
6.1 High Level Process Flow Chart
6.2 Critical Success Factors
6.3 Performance Indicators (KPI)
6.4 Process Trigger
6.4.1 Event Trigger
6.4.2 Time Trigger
6.5 Process Specific Rules
6.6 Process Activities
6.6.1 Requirements Engineering
6.6.2 SLA Negotiation
6.6.3 SLA Agreement
6.6.4 SLA Monitoring
6.6.5 SLA Expiration
Description/Summary
Service Level Agreement Management is responsible for establishing, reviewing and
cancellation of Service Level Agreements (SLAs) with customer.
Service Level Agreements
are based on Service Design
are negotiated and agreed with the customer
need the Supply Management Process for the supply of services (agreed in supplier
contracts)on service levels (SLAs) from external partners (if needed)
need the Supply Management Process for the supply of services (agreed in UCs) on service
levels (OLAs) from internal partners (if needed)
Service Level Agreement Management in ...
ITIL V2: part of Service Delivery
ITIL V3: part of Service Design
ISO/IEC 20000: part of Service Delivery Processes
COBIT:

Objectives
The purpose of Service Level Agreement Management is to manage Service Level
Agreements in a way that customer requirements are reflected and contracts are
coordinated and harmonized. Basic requirement is to balance the value and quality for the
customer with the costs of service.
Service Agreement Management contributes to an integrated Service Management approach by
achieving the following goals:
Every service provided to a customer is covered by an SLA containing a description of the
guaranteed and agreed service level.
To achieve the service level targets, OLAs and UCs are established in support of the SLAs
by the Supply Management Process.

Roles

Service Level Agreement Management Specific Roles

Static Process Roles

The following roles are deployed within the Service Agreement Management process:
Process Owner: Initiator of the process, responsible for defining its strategic goals and
allocating all require resources
Process Manager (Service Level Agreement Process Manager) Manager of the entire process,
responsible for its effectiveness and efficiency
Process Staff (Service Level Agreement Process Staff) Manager of the entire process,
responsible for its effectiveness and efficiency
Dynamic Process Roles

Service Specific Roles

Customer Specific Roles

Information artifacts

Customer Requirement
Formal standardized document to collect all relevant information on customer requirement for a
commercial and technical feasibility study:
Unique identifier requirement/ customer
Status
Identifier of the service owner
Service concerned (minimum one service should be mentioned) if possible
Detailed requirement description (technical aspects, commercial aspects, other)
Other relevant information

The Service Agreement Record

The service record is the record holding any management-relevant information of a specific
service agreement.
The following attributes must be considered for a service record:
Unique identifier
Status
Identifier of the service owner
Contract partners
Terms and conditions
Service concerned (minimum one service should be mentioned)
Detailed service description
Detailed description of prerequisites to be provided by customer
Links to related Service Level Agreements
Responsible Service Level Agreement Staff
Signatures
Dates of Signing
Rules of cancellation or prolongation
Rules and processes for changes in agreement
 Other rules
Specific rules to be integrated in an agreement resulting from regional legislation

Service Catalog
Service catalog provides the range of services provided. Each service within the catalog typically
includes:
Service description
Existing SLAs for the services
Service owner, sponsor, staff
Costs/ Prices
Other operating procedures

Service Agreement Record attributes mapped to activities

For icon descriptions see Record attributes X activities or refer to the "mouse-over" explanations.

Additional Information Items

Service Level Agreement (SLA)
See Service Level Management Process

Key Concepts

Status of Service Agreements

Service Agreements may have different status, depending on the life cycle of the agreement:
planned: agreement planned, no agreement defined
under negotiation: draft version of agreement written, agreement in progress but not valid
under review: draft version of agreement written, agreement in progress but not valid
signed: end version of agreement signed, agreement valid regarding te agreed time periods of
validation
canceled: agreement cancelled, not valid
not active: agreement out of validation time period, agreement not valid

Process

High Level Process Flow Chart

This chart illustrates the Service Agreement Management process and its activities as well as the
status model reflected by the service record evolution.
/index.php?title=Image:SLA_management_images_main.gif

/index.php?title=Image:SLA_management_images_main.gif

Critical Success Factors

Well defined process and roles
Clearly defined responsibilities for design and signing of agreements on both sides
Will to agree
All agreement details should be part of the written agreement

Performance Indicators (KPI)

Process Trigger

Event Trigger
Process is triggered by new agreements or agreements required to be changed. Process is
triggered by customer request or request from CRM Process.

Time Trigger

Process Specific Rules

Process Activities
Requirements Engineering
Service Level Agreement Staff forms together with the CRM Staff a team and decide on who is
the requirements engineering agent. This agent gets in contact with the customer and defines
customer requirements. This person needs to be an expert concerning the service offered by the
company, to match customer requirements with existing services or to define if required services
are possible to be delivered in commercial and technical view. A close cooperation with the
Service Design Process, CRM and all Operation Processes is necessary.
The final regiments need to be written and agreed with the customer. An requirement document
is provided.
Activity Specific Rules:
define requirement with customer
check requirement with internal processes if
technical deliverable
commercial feasible
support a business case definition together with CRM process
set status on "engineered"

SLA Negotiation
Requirements are prices and then discussed with the customer. Different options of service
delivery are discussed. In addition for each service a service level is defined, proceed and
discussed. This pricing of diverse service levels is supported by the Service Level Management
Process.
A final agreement version is distributed and discussed between all involved parties.
Activity Specific Rules:
trigger Service Level Management Process for price information on diverse Service level of
Service to customer
combine all information to offer/ agreement
discuss with customer
if final version agreed - provide final contract version to all parties for signing
set status on "negotiated"

SLA Agreement
Final version of the contract is checked by all parties including now the check layer. Final
version is distributed, signed and documented in the contract/ agreement data base (see CRM
Process).
Activity Specific Rules:
Provide final check of agreement including check by law
Sign contract
Document contract by providing is to the CRM Process
Set status on "agreed"
SLA Monitoring
Existing agreements need to be monitored:
All aspects NOT involving the service quality are monitored by the CRM process
All service quality concerning aspects are monitored by Service Level Management Process
Activity Specific Rules:
monitor quality of service -> trigger Service Level Management Process for monitoring,
recive and anlyse information
monitor all other contract aspects -> trigger CRM Process, recive and analyse information
monitor agreement for end of service (based on date, conditions or customer request)
if end of service
set status on "end of service"
continue with next activity

SLA Expiration
Contract cancellation is done in the CRM Process due to complete legal situation in case of
contract cancellation. Service Level Agreement Management is triggered by CRM process and
the monitoring of a agreement is stopped.
Activity Specific Rules:
stop monitoring of agreement on trigger from CRM process
set agreement on "expired"

Retrieved from "http://www.itil-process-wiki.org/index.php?

title=Service_Level_Agreement_Management"