September 20061 SLA recommendations from the users’ viewpoint October 2006.

September 2006September 2006 11

SLA recommendations from the users’ viewpoint

October 2006


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


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


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.


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


Organisational impact

Source: Quint/KBC


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


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!


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


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


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


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


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.


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)


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?


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?


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.

September 20061 SLA recommendations from the users’ viewpoint October 2006.

Documents

Transcript of September 20061 SLA recommendations from the users’ viewpoint October 2006.