SLA recommendations from the users’ viewpoint October 2006
-
Upload
alphonse-meller -
Category
Documents
-
view
27 -
download
0
description
Transcript of SLA recommendations from the users’ viewpoint October 2006
September 2006September 2006 11
SLA recommendations from the users’ viewpoint
October 2006
September 2006September 2006 22
Approach
• Recommendations have been assembled based on the experience of several BELTUG members. These have been completed with comments from other companies, users and service providers, that were formulated during a BELTUG X-change.
• Structure– A few definitions– Organisational impact– Basic questions– Timing– Some templates, parts of existing SLAs, may be used as model– Liabilities – Penalties– Service degradation– Remarks from service providers
Mind that slides are commented oncorresponding notes pages
September 2006September 2006 33
What not to expect?
• BELTUG did not opt for sharing existing SLAs among members• Neither does it present ready-made articles that can be stuck
just like that in an SLA agreement• Why:
– ICT Managers are reluctant to share the details– Sometimes even a non-disclosure agreement (NDA) exists
about the contract– The sum of 3 existing SLAs (contracts) may become
unrealistic & conflicting– Purchasing power determines the relation customer-provider
September 2006September 2006 44
A few definitions
• Service Management refers to the sum of all the necessary processes to provide a service to end users
• Service Level Management handles only a part of the ITIL Framework (see next slide)
• Service Level Agreement refers to the contractual obligations of the provider towards the customer
The provider must deliverdeliver to the customer, accordingto contractual SLAs, …. because the customer hasto deliver in the same way to his internal customers,according to internal SLAs.
September 2006September 2006 55
Organisational impact
• Practical example: Implementation of process-oriented Working Model (IPW tm) at KBC (Quint)
• The importance of the diagram on the next slide – Processes are shown in their mutual relations – Thoroughness: incident management versus problem management =
substantial difference!– ICT domain located between Business domain and Supplier domain– There is quite a difference between planning and operations– Without change mgt there can be no service level mgt
• This exercise is appropriate for any company
September 2006September 2006 66
Organisational impact
Source: Quint/KBC
September 2006September 2006 77
Basic questions
• It all boils down to: Keep it measurableKeep it measurable.• Build out a willingness-openness to work out constructive internal
solutions, together: business, ICT and purchase
• What are the liabilities?– Are the contracts handled by Purchase or ICT or by a mixed team? – Are SLAs part of a formal negotiation track? – Who is in charge of negotiations?– Can SLAs be “reduced” during cost negotiations?– Can it be done without approval from ICT?
• Create clear escalation levels: the watchdogs of your SLA
September 2006September 2006 88
Timing
• The organisation defines what is required + sets reasonable targets • Where is the SLA really mandatory? • Is timing very strict, becoming critical for the project?
– Time required to build the contract with terms & conditions
• Why not include your draft terms & conditions in your RFP ?
• Be prepared to spend months of discussions! Different accesses, different connections…
….all require different SLA!
September 2006September 2006 99
Help Service DescriptionService window The period during which the application will be available without service level guaranties.
Service availability windowThe period during which the application will be available with service level guaranties.The Service Level Agreements (SLA) are only valid during this period.
Allowed downtime per monthwithin service availability window
The maximum period during which the application will be unavailable within the SAW.
Prescheduled downtime within service window
The prescheduled unavailability within the service window.(especially important for 24h environments)
Batch execution windowThe period in which the batchv processing has te bo done. In case of overlap with online, availability and performance have to be guarded.
Cut-off timesThe existance of internally and externally enforced deadlines. Have to be included in the SLA later on.
Batch urgency The urgency of the batch processing.
Recovery point objectiveAfter the calamity, the data are recoverd upto a predetermined moment (RPO).Taking possible manual recoveries and acceptable data loss into account.
Recovery time objective Period (RTO) during which the central application is available again after a a calamity.
Off-site Period during which the user will use the off site location after a calamity.
Per
for
man
ce
Online response time management The importance of online response times and its further follow-up.
Scalability The expected transaction volumes and the expected evolution of these volumes.
Degradability Is a significant capacity-loss allowed ?
Release path The required quality measures for the introduction of changes to an application.
Testability
Cal
l d
esk
Call desk service window The period during which the users can reach an ICT-help desk.
SL
M Reporting The extent to which the delivered service will be reported.
Ava
ilab
ility
Rec
ove
r ab
ility
Cap
acit
yC
han
ge
man
age
men
tTemplates: definitions
September 2006September 2006 1010
Even a well known “availability” requires strongerstronger definitions
Very High High Medium Low
Service window Continuously 7/724h/ 24h 7/7
Continuously 6/7mon 0h - sat 10 p.m.
6 working days:mon-sat: 6a.m.- 10 p.m.
5 working days:mon-fri: 6a.m.- 10 p.m.
Service availability window
Continuously24/24hExcept during prescheduled downtime windows
Branch hours:mon-fri: 7.30a.m. - 7 p.m.+ sat: 7.30a.m. - 1p.m.
HQ hours:mon-fri: 7a.m.-7p.m.
Key hours:mon-fri: 8.30a.m. -4.30p.m.
Allowed downtime per monthwithin service availability window
ZERO downtime 1 h downtimeTake maximal measures
4 h downtimeTake measures
12 h downtimeDo not take special measures.
Prescheduled downtime within service window
none Some windows per year0-12 / year
Some windows per month13 - 52 / year
Some windows per week53 - 365+ / year
LevelSM Requirements template
Av
ail
ab
ilit
yTemplates: definitions
platinum gold silver bronze
Let’s zoom in
September 2006September 2006 1111
Different possibilities for testing
To make testing more specific:
• Do we handle here 1 component or an End-to-End service?
• End-to-end can, furthermore, be seen in a range of:
100% reactive, 100% proactive100% proactive
Register component faults
put probes and monitor
launch dummy transactions
September 2006September 2006 1212
Only penalty-oriented?
Is the SLA strong & very specific towards penalties or …more oriented towards mutual long-lasting relationships (Set mutual expectancies right)?
– This will probably be coupled with the length of the contract +– a strategic partnership or more commodity character of the deal– Win-Win in reality + fast escalation to avoid any diplomatic incident
Risk-averse companies negotiate stronger SLAs with even stronger penalties – But a “SLA” is never replacing a risk-analysis– If business processes are well organised: perform a BIA (Business Business
Impact Analysis)Impact Analysis) to start with, and do it per process
Given the timeline can be very critical, some contracts contain stronger SLAs for the installation schedules than for the monthly charges
September 2006September 2006 1313
Alternatives for penalties
• Penalty
A non-delivery of service compared to the SLA, activates a compensation, to be paid by the service provider via an invoice from the customer.
• Service Credit
No invoice at all, the provider calculates “spontaneously” the agreed credits from the SLA and reduces the monthly charges accordingly.
• Service Fee Reduction
The provider agrees to reduce the monthly charges, as from the incident onwards in a systematic way.
September 2006September 2006 1414
The other party
• Is the SLA for …
– or for an OPERATOR (who can be up to 100% owner of the infrastructure of the concerned service)
– an INTEGRATOR (who might be limited to offer “Helpdesk only” when all the rest is being THIRD PARTY Management under his responsibility, therefore closer to outsourcing and co-sourcing)
September 2006September 2006 1515
Service degradation
Pay attention to service degradation
– Are such SLAs with utmost specifics or rather generic?– Are the metrics & statistics delivered by the provider? – Are the measuring conditions all clearly defined?– Are counter-measurements scheduled? Announced? – Are audits clearly agreed, who calls the shots, who pays, when?
September 2006September 2006 1616
Reporting
Is the reporting of the SLA + the service management + the setup of the meetings covered in the contract?
– Who is the service manager, both at the Service Provider and customer? Who participates in these meetings? Are the functions clearly described?
– Who provides the reports, …since that is a real workload – All the work delivered, in a timely manner?
September 2006September 2006 1717
Concerns of the providers
• SLAs should be part of the commercial negotiations, however many RFP/RFQ only allow for just a number to be filled in, “ X% “ as the absolute guaranteed value! Not even a dialogue,…
• Do customers recognize the SLA as an added value? It will depend on the type of service itself. For some services quality is more important than price… and only then a strong SLA is mandatory
• How will a customer react to an incident? For all providers the consistency & coherence in the reactions of the customers remain very important. Never postpone to make good agreements on incident reporting and incident resolution, certainly not until the first incident is a fact.