Een Service Level Agreement (SLA) wordt bij vrijwel ieder groot IT-contract gesloten. Na het plaatsen van de handtekeningen lijkt de grootste uitdaging voorbij. Maar is dat wel zo? De wensen van de business veranderen immers continu, evenals het IT-landschap zelf. In het derde deel van onze blogreeks over SLA’s geven wij u dé 5 stappen om een SLA succesvol te implementeren. Zowel voor afnemers als leveranciers.
Allereerst is het belangrijk om te beseffen dat een SLA een document is dat aan de basis ligt van het Service Level Management proces. Als we ons enkel focussen op de SLA, dan missen we het punt.
Alles draait namelijk om het proces.
Hieronder de 5 belangrijkste stappen bij het inrichten van het Service Level Management proces.
Stap 1. SLA met heldere scope
Wellicht een open deur, maar een Service Level Agreement vormt de basis van het verdere proces. Als de initiële SLA niet goed is opgesteld, dan zal het proces dat daaruit voortvloeit ook mankementen vertonen.
Het is van het grootste belang dat de verwachtingen goed gemanaged worden en dat betekent dus een SLA met een heldere scope. Welke services worden verleend, binnen welk tijdsbestek, onder welke garantie en wie is er verantwoordelijk voor?
In de tweede blog in deze reeks leest u welke topics niet mogen ontbreken in een SLA om de uiteindelijke implementatie succesvol te laten verlopen.
Stap 2. Communicatie tussen IT & Business
Een van de belangrijkste succesfactoren bij de implementatie van een SLA is een goede relatie en open communicatie tussen IT en de business. Dit geldt zowel intern bij de afnemer als tussen de leverancier en de afnemer.
De IT-diensten en services worden immers verleend aan de (eind)gebruikers binnen de business. Het is zowel voor de IT-organisatie van de afnemer als voor de leverancier belangrijk om de businessstrategie en -doelen volledig te doorgronden. Alleen zo kan er goede service worden geboden.
Zorg dat u een heldere communicatie- en overlegstructuur optuigt. Intern bij de afnemer tussen de business en IT. Extern tussen de leverancier en de business- en IT-vertegenwoordiger(s) aan afnemerszijde. In deze structuur besteedt u aandacht aan:
tijdstippen of aanleidingen voor overleg;
betrokken personen bij overleg;
verantwoordelijke personen voor de onderlinge relatie;
overzicht van contactpersonen en verantwoordelijken bij escalatie en/of calamiteiten;
standaardformulieren voor onderlinge correspondentie;
wijze van vastlegging van overleggen.
Stap 3. Verantwoordelijkheden en escalatie
Van groot belang is het helder vaststellen van verantwoordelijkheden bij de afnemer en de leverancier.
Wie is verantwoordelijk voor welke dienst en service?
Aan leverancierszijde is er waarschijnlijk een Service Level Manager aangesteld. Is die echter ook verantwoordelijk voor de helpdesk, waar een ticket wordt gestart?
Aan leverancierszijde kan de IT-manager het aanspraakpunt van de leverancier zijn bij een issue. Hij kan echter ook een medewerker naar voren schuiven. Dan is het wel zaak dat deze de juiste autorisatie binnen de organisatie heeft.
Het helder krijgen en vastleggen van de verantwoordelijke personen met de juiste autorisaties is een belangrijke stap bij de implementatie van een SLA. Het voorkomt veel frustraties in de praktijk.
Dat geldt ook voor het opstellen van een escalatieproces. Als een ticket bijvoorbeeld niet op tijd afgehandeld is, dan moet deze geëscaleerd worden.
Wie pakt dit dan op?
Leg de verschillende escalatieniveaus goed vast en wijs bij elk niveau een verantwoordelijke aan, die dit binnen een afgesproken tijdsbestek moet oppakken.
Stap 4. Blijven evalueren
Om te controleren of de afgesproken prestaties worden behaald, is het zaak te blijven evalueren. De geregelde rapportages van de leveranciers vormen de leidraad. Daarnaast is het als afnemer mogelijk om (onafhankelijke) audits te laten uitvoeren bij de leverancier. Dit moet dan wel zijn vastgelegd in de SLA.
Het is ook aan te raden om de eindgebruikerstevredenheid op regelmatige basis te onderzoeken. Uiteindelijk draait het immers allemaal om de ervaring van de eindgebruikers.
Om blijvend te evalueren, legt u in de communicatiestructuur periodieke evaluatiemomenten vast. Tijdens deze gesprekken gaat u ook op zoek naar mogelijke verbeterpunten, die aanleiding kunnen geven om de SLA te wijzigen of te herzien.
Dat brengt ons gelijk bij de vijfde en laatste stap:
Stap 5. Wijzigen en herzien
De behoeften van de business veranderen. Net als de wensen van IT. Daarom is een SLA geen statisch document. Het moet mogelijk zijn om tussentijds wijzigingen door te voeren en/of het gehele document gaandeweg te herzien.
Ook hiervoor is het belangrijk om een proces in te richten. Wie mag bijvoorbeeld een wijziging initiëren en welke situatie geeft aanleiding tot het wijzigen of herzien van de SLA?
Zie een SLA als work in progress. De handtekening is niet het eindstation, maar juist het begin van het samen realiseren van de best haalbare gebruikerstevredenheid.
SLA blogserie: FAQ & inhoud
In onze eerste blog in de SLA-serie bespraken we de meest gestelde vragen over SLA’s. Met een FAQ gaven we antwoord op de 9 meest gestelde vragen over een SLA.
Vorige week kwamen de topics aan bod die absoluut niet mogen ontbreken in een SLA. Met deze blog over implementatie van een SLA ronden we de serie af.
Blijf op de hoogte!
Abonneert u zich nu op onze maandelijkse nieuwsbrief en u hoeft geen blog meer te missen. U ontvangt al onze blogs dan automatisch 1 keer per maand in uw mailbox.