Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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] 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
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] 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
Service Elements with Number of Service Elements in SLAs which are secured by corresponding
OLAs/UCs OLAs/UCs
Fulfilment of Service Levels Number of SLA elements where the agreed service levels are fulfilled
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.
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
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
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.
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
Process Trigger
Event Trigger
Time Trigger
Permanent review of service quality
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 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
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
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
Key Concepts
Process
/index.php?title=Image:SLA_management_images_main.gif
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 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"