Service Level Agreements (SLA) zijn een belangrijk onderdeel van IT Service Management (ITSM). SLA's zijn overeenkomsten die bepalen wat gebruikers en klanten van de IT-services mogen verwachten; ze definiëren doelen voor leveranciers en ze voorzien leveranciers, klanten en belanghebbenden van regelmatige informatie over hoe de diensten aan deze verwachtingen voldoen.
De SLA kan een fysiek of elektronisch document zijn. Personen van beide partijen met een passende bevoegdheid moeten het document ondertekenen.
SLA’s zijn belangrijk omdat:
Een Service Level Agreements beschrijft de services die het omvat, de reikwijdte van de services; de kenmerken van de service, inclusief de uren waarop deze beschikbaar is en de uren die worden ondersteund; de doelstellingen voor deze services (ook wel serviceniveaus genoemd) en de verantwoordelijkheden van beide partijen, inclusief verantwoordelijkheden voor beoordeling en onderhoud van de inhoud.
Het kan ook een prijsmodel bevatten, met eventuele kosten voor het gebruik van de service en boetes die moeten worden betaald voor het niet voldoen aan de serviceniveaus. De SLA moet worden geschreven vanuit het standpunt van de klant, om begrip te vergemakkelijken.
SLA's kunnen nuttig zijn wanneer er behoefte is aan een formele overeenkomst tussen twee partijen, met gedetailleerde informatie over het verwachte serviceniveau en de bijbehorende verantwoordelijkheden. ITSM heeft traditioneel gezien alleen IT-services opgenomen in SLA’s, inclusief de servicedesk. Serviceniveaus en de bijbehorende overeenkomsten moeten echter in feite voor elk type service worden gebruikt. Dit kunnen onder meer arbeidsgerelateerde diensten zijn, zoals het bieden van consultancy; ondersteunende diensten, zoals het leveren van verbruiksartikelen en technische, niet-IT-diensten, zoals ondersteunende brandalarmsystemen. SLA's kunnen ook worden gebruikt voor procesgerelateerde activiteiten waarbij de naleving moet worden gedefinieerd, bewaakt en gemeten. Dit kan bestaan uit het bijwonen van formele vergaderingen, streefdoelen voor het reageren op klachten en het halen van deadlines voor het indienen van facturen.
De klant is de persoon of organisatie die de diensten gebruikt. De klant kan intern of extern zijn aan de organisatie. Zelfs als het voor externe klanten niet praktisch is om een overeenkomst formeel te ondertekenen, moeten er toch SLA's worden gemaakt, omdat ze een duidelijke en nauwkeurige beschrijving geven van wat de klant kan verwachten en omdat ze verbeteringen van de servicekwaliteit stimuleren.
Het is een goede gewoonte voor een organisatie om één SLA per leverancier te hebben, die alle diensten omvat die de leverancier levert. Dit vereenvoudigt de totstandkoming van de overeenkomst, aangezien de algemene vereisten hetzelfde zijn en de diensten vaak dezelfde serviceniveaus hebben. De SLA kan vervolgens worden bijgewerkt om nieuwe services toe te voegen of oude services te verwijderen. Er is geen limiet voor het aantal services in één overeenkomst.
Een SLA met meerdere niveaus is een structuur die wordt gebruikt om duplicatie te voorkomen en de frequentie van updates van de SLA's te verminderen, terwijl het de flexibiliteit biedt om ze aan te passen aan specifieke klanten en diensten. Het gebruik van een SLA-structuur met meerdere niveaus is typisch voor het documenteren van serviceniveaus wanneer de leveranciers zich binnen dezelfde organisatie bevinden.
Een typische SLA-structuur met meerdere niveaus bestaat uit drie niveaus:
Dit heeft betrekking op alle vereisten die elke klant binnen een bedrijf gemeen heeft. Een voorbeeld is een SLA voor elke gebruiker van een e-mailsysteem, waarbij wachtwoorden elke 30 dagen gewijzigd kunnen worden.
Dit heeft betrekking op betrekking heeft op vereisten die specifiek zijn voor een bepaalde klant of een verzameling klanten binnen een bedrijf, inclusief alle diensten die eraan worden geleverd. Een voorbeeld is een standaard servicebeschikbaarheid voor alle diensten die aan één klant worden geleverd.
Dit heeft betrekking op vereisten voor specifieke diensten. Dit is het laagste niveau en kan worden gebruikt als een specifieke dienst andere eisen en serviceniveaus heeft dan de standaard voor het bedrijf of een klant.
Bekijk de voordelen van een SLA
Het is belangrijk om de details van de SLA-overeenkomst consistent te gebruiken en toe te passen. Serviceniveauprestaties moeten worden gerapporteerd en beoordeeld tussen de klant en de leverancier. Als er niet wordt voldaan aan de overeengekomen serviceniveaus, bestaat de mogelijkheid om deze open te breken, of wanneer een van de partijen hun in de SLA gedocumenteerde verantwoordelijkheden niet is nagekomen, moeten ze een overeenstemming bereiken over de maatregelen die moeten worden genomen.
Als er sancties zijn voor mislukking, moeten deze routinematig worden toegepast. Dit omvat onder meer het opstellen van rapporten in het overeengekomen formaat en deze leveren volgens de planning, en het toepassen van boetes wanneer deze veroorzaakt worden door schendingen. Verder in dit artikel praten we meer over sancties.
Een SLA is een overeenkomst tussen de dienstverlener en de klant, waarin de verschillende aspecten van de verleende dienst worden vastgelegd.
Een OLA, of Operational Level Agreement is een interne overeenkomst, waarin staat vastgesteld hoe de medewerkers binnen een organisatie de SLA gaan naleven.
Een Underpinning Contract beschrijft een contract tussen een klant en een leverancier, inclusief SLA's voor de geleverde diensten. Het UC zal ook contractuele clausules bevatten die niet rechtstreeks verband houden met de serviceniveaus, zoals het gebruik van onderaannemers, technische normen die vereist zijn van de leverancier en wie de intellectuele eigendomsrechten voor de services bezit.
Voor elke vereiste in een contract is het een goede gewoonte om aan te geven wat er zal gebeuren als niet aan de vereiste wordt voldaan. Dit kan doelen omvatten voor het indienen van wijzigingsverzoeken binnen een bepaalde tijdsperiode, het bijwonen van servicebeoordelingsbijeenkomsten en het naleven van beleid voor kennisoverdracht.
Het gebruik van SLA's biedt een hoger profiel voor eventuele storingen en kan leiden tot financiële sancties als deze zijn gedefinieerd.
Goed ontwikkelde en geïmplementeerde Service Level Agreement kunnen de klant, de gebruikers en de leveranciers, inclusief interne IT, ten goede komen. Deze voordelen worden het best gerealiseerd door zorgvuldig ontwerp, geplande implementatie, actief gebruik en voortdurende verbetering. Enkele voordelen van SLA's zijn:
Een Service Level Management (SLM) is het proces dat onderhandelt over SLA's tussen de klant en de leverancier en erop gericht is dat deze worden nagekomen. Een SLM moet ervoor zorgen dat alle andere processen die worden gebruikt in ITSM-ondersteuning de overeengekomen serviceniveaus bereiken. Dit omvat het controleren of alle SLA's de overeengekomen serviceniveau-doelen kunnen ondersteunen, inclusief die in OLA's en UC's. Service level management bewaakt en rapporteert over de serviceniveaus die zijn vastgelegd in de overeengekomen SLA's, voert regelmatig servicebeoordelingen uit met klanten en leveranciers, identificeert de vereiste verbeteringen en rapporteert vervolgens over verbeteracties. SLM moet worden uitgevoerd bij zowel de klant als de leveranciers.
Het behalen van elk serviceniveau dat in de overeenkomst is vastgelegd, moet worden gecontroleerd en gerapporteerd. Hoe dit wordt bereikt, hangt af van de precieze aard van het serviceniveau. De methode en de frequentie van monitoring moeten worden gedefinieerd en gedocumenteerd in de SLA.
Rapporten moeten automatisch worden geproduceerd op basis van de gegevens die tijdens de monitoring zijn vastgelegd, omdat dit een nauwkeurig beeld geeft van de werkelijke SLA-prestatie. Er moeten vaak genoeg rapporten worden opgesteld om trends in SLA-prestaties te herkennen en benadrukken voordat er fouten optreden en ook om vertrouwen in het proces te wekken.
Tijdens de vroege stadia van een service kan er een wekelijkse rapportage worden gebruikt om te controleren of alle processen, systemen enz. werken zoals verwacht. Het rapporteren aan klanten kan worden teruggebracht tot een maandelijks interval en zelfs driemaandelijks als het vertrouwen wordt gewonnen in zowel de diensten als de leverancier.
Wanneer SLA's zijn opgenomen in een onderliggend contract met leveranciers, is het standaardpraktijk om boetes op te nemen voor services die niet volgens de overeengekomen niveaus worden geleverd. De boete kan een vast bedrag zijn voor elke storing of een variabel bedrag afhankelijk van hoeveel het doel is overtreden. Het is erg belangrijk om de boetes in te stellen op een niveau dat geschikt is voor de impact van de niet-naleving op het bedrijf. Het instellen van te hoge SLA-boetes kan ertoe leiden dat leveranciers de overeenkomst niet ondertekenen of vragen om het contract vroegtijdig te beëindigen.
Om dezelfde reden moeten partijen overeenkomen een sanctieplafond vast te stellen wanneer een variabel bedrag voor sancties is opgenomen. Wanneer het totaal van de boetes gedurende een periode dit plafond bereikt, worden er geen boetes meer opgelegd. Dit kan er echter toe leiden dat de leverancier niet wordt gestimuleerd om de storingen te verhelpen wanneer de limiet is bereikt. Dit kan worden verholpen door een "herhaal-faal"-mechanisme in de SLA, waarbij de financiële sanctie wordt verhoogd als de limiet gedurende twee of meer opeenvolgende perioden wordt bereikt.
Gebruikers verwachten te weten welk serviceniveau ze zullen ontvangen. Ze zijn misschien pas geïnteresseerd als ze problemen ondervinden, maar het is nog steeds een goede gewoonte om dit in een SLA op te nemen, zodat de inhoud wordt gepresenteerd op een manier die gebruikers kunnen begrijpen. SLA's helpen een bedrijf om zijn leveranciers te beheren door hun verwachte prestaties vast te stellen. Er is een risico voor een bedrijf dat zijn SLA's aan externe klanten publiceert zonder ervoor te zorgen dat aan de serviceniveaus kan worden voldaan. Klanten beschouwen deze serviceniveaus als beloften en worden snel ontevreden als er niet aan voldaan wordt. Zelfs één fout kan al leiden tot een afname van klantloyaliteit.
Wanneer een bedrijf dezelfde onlinediensten aanbiedt aan meerdere individuele klanten en gebruikers buiten de organisatie, bijvoorbeeld een financiële instelling die online bankdiensten aanbiedt, is er meestal één SLA voor alle klanten, met een beschrijving van de diensten en doelen die zij zullen ontvangen. Het zal niet mogelijk zijn om van al deze klanten toestemming te krijgen, dus wordt een SLA van dit type doorgaans overeengekomen met een vertegenwoordiger, zoals de interne producteigenaar in het bedrijf voor die diensten.
Als er een gebruikersgroep is voor de diensten, moet deze worden geraadpleegd over de vereisten voor de serviceniveaus; het kan echter een uitdaging zijn om consensus en overeenstemming over de definitieve SLA te verkrijgen.
Leveranciers die diensten via de cloud aanbieden, moeten nog steeds SLA's gebruiken, omdat deze hun klanten een garantie bieden voor het serviceniveau dat ze kunnen verwachten.
De meeste cloudproviders bieden alle klanten dezelfde standaard SLA met gemeenschappelijke serviceniveaus. Sommige bieden verbeterde ondersteuningsniveaus in gelaagde "Gouden/Zilveren/Bronzen" SLA's, waarbij de klant betere serviceniveaus ontvangt als de klant een hogere vergoeding betaalt. Klanten die cloudservices kopen, moeten over het algemeen de aangeboden serviceniveaus accepteren. Het is onwaarschijnlijk dat een cloudleverancier een SLA speciaal voor hen aanpast.
Sommige organisaties richten zich meer op het serviceniveau van hun individuele IT-services dan op de service die klanten daadwerkelijk ontvangen. Dit leidt vaak tot het zogenaamde 'watermeloen'-effect, waarbij de SLA-statistieken laten zien dat alles goed is ('groen'), maar de klant is niet tevreden ('rood'). Een typisch voorbeeld is wanneer servicerapporten aantonen dat aan alle serviceniveaus wordt voldaan, ook al hadden de services tijdens de werkdag ongeplande downtime. Dit komt meestal omdat de serviceniveaus zijn ontworpen vanuit een IT-perspectief, kijkend naar één IT-service tegelijk. Dit kan worden voorkomen met een techniek die bekend staat als 'Outside in'.
SLA's moeten in eerste instantie worden ontworpen vanuit het perspectief van de klant, kijkend naar de services die ze gebruiken en de zakelijke vereisten voor een goede service. De serviceniveaus voor de IT en aanverwante services, zoals de servicedesk, moeten vervolgens worden ontworpen om aan deze zakelijke vereisten te voldoen. Dit resulteert in serviceniveaus die zowel de klantervaring als de individuele IT en andere services weerspiegelen die de ervaring creëren.
SLA’s kunnen je helpen om te voldoen aan de wetgeving inzake gegevensbescherming, zoals de AVG. Naast het specificeren van doelen voor traditionele ITSM-serviceniveaus, zoals beschikbaarheid, moeten SLA's ook doelen bevatten voor andere soorten vereisten, waaronder beveiliging. Met een doel kunt je de naleving meten. Dit kan zo simpel zijn als een serviceniveau om te reageren op verzoeken om toegang tot een onderwerp, bijvoorbeeld wanneer een persoon de opgeslagen gegevens over zichzelf wil weten. Dit is vooral belangrijk als je externe leveranciers gebruikt om uw zakelijke diensten te verlenen.
De inhoud van een SLA zal evolueren vanuit de Service Level Requirements (SLR's) die zijn gemaakt tijdens het eerste ontwerp van een service. Deze inhoud moet ondubbelzinnig zijn en geschreven in een makkelijk te begrijpen stijl. Hoewel ze deel uitmaken van een contract als de leverancier extern is, moeten ze het gebruik van juridische taal en terminologie vermijden. Er zijn verschillende stappen om een SLA te maken:
De klant moet definiëren wat hij of zij nodig heeft in een verzameling SLR's, inclusief de servicegebruikers; belang voor gebruikers en de organisatie; beschikbaarheidsuren van de service; uren voor serviceondersteuning; kritieke periodes; maximale uitvaltijd; beveiligings- en gegevensbeschermingsvereisten; rapportagevereisten; en alle verplichte wettelijke, beleids- of normvereisten. Eerder overeengekomen SLA's kunnen als uitgangspositie worden gebruikt.
De leverancier moet definiëren wat hij kan leveren, inclusief de systemen die hij van plan is te gebruiken, ondersteuningsregelingen, uren van beschikbaarheid en ondersteuning, hoe toegang te krijgen tot ondersteuning, doelen voor foutoplossing, beschikbaarheid en prestaties, beschikbare rapporten, regelingen voor noodherstel en beveiligingsregelingen. Een leverancier heeft waarschijnlijk een standaard SLA die hij wil gebruiken.
Een facilitator, zoals een service level manager, moet worden gebruikt om de klant en leverancier uit te nodigen voor een workshop. Het doel is dat beide partijen begrijpen wat er nodig is en wat mogelijk is voordat de SLA wordt opgesteld. De facilitator moet opmerken waar er een sterke match is. Als er verschillen moeten worden opgelost, moet de facilitator discussies aanmoedigen om een oplossing te vinden.
Iemand die bekwaam en ervaren is in het ontwerpen van SLA’s moet de SLA, leverancierscapaciteiten, de aantekeningen uit de workshop en de eigen ervaring gebruiken om concept-SLA's te maken. Alle openstaande items moeten worden toegevoegd aan een actielijst.
Vertegenwoordigers van de klant en de leverancier moeten bijeenkomen om de SLA af te ronden, inclusief het onderhandelen over eventuele openstaande punten voor een onderlinge overeenkomst. Deze overeenkomst moet de definitie bevatten van alle rapporten, inclusief de productiefrequentie en hoe ze zullen worden gepubliceerd.
Als er over een punt geen overeenstemming kan worden bereikt, moet de kwestie voor bespreking en overeenstemming worden geëscaleerd naar beide organisaties. Een SLA moet niet ondertekend worden totdat beide partijen het eens zijn met de volledige inhoud.
Beide partijen moeten de overeenkomst formeel ondertekenen. Vervolgens moet het worden gecommuniceerd aan iedereen binnen beide organisaties die hiervan op de hoogte moet zijn, en beschikbaar worden gesteld voor toekomstige verwijzing en herziening.
Het heeft geen zin om overeenstemming te bereiken over SLA's die dan niet worden gebruikt. Wat is afgesproken moet gebeuren. Daarom moet beide partijen de SLA's jaarlijks herzien, aangezien de eisen van klanten en de capaciteiten van leveranciers kunnen veranderen.
Een organisatie gebruikt normaal gesproken een standaardsjabloon voor alle SLA's. Dit faciliteert gemeenschappelijk begrip bij degenen die de serviceniveaus in ITSM, IT en de organisatie van de klant moeten begrijpen. Het maakt vergelijking van SLA-prestaties tussen verschillende dienstverleners ook mogelijk. Een standaardsjabloon is wellicht niet mogelijk bij leveranciers die goederendiensten leveren waarbij de klant het formaat moet accepteren dat de dienstverlener gebruikt. Een typische SLA bevat de volgende items:
Namen van diensten: De naam (namen) waaronder de dienst(en) bekend is/zijn, plus eventuele unieke referentiecode(s) die deze verbindt met de servicecatalogus/CMDB
Goedkeuringsinformatie: Handtekeningen ter goedkeuring van de klant en de leverancier en de datum waarop de SLA ondertekend is
Gerelateerde contractuele informatie (niet vereist voor OLA’s): Gerelateerde contractnummers, start-, einde- en beoordelingsdatum en de regels voor vernieuwing en beëindiging van de overeenkomst, inclusief vroegtijdige beëindiging
Korte omschrijvingen van diensten: Een omschrijving over welke diensten de klant kan verwachten, de zakelijke activiteiten die door de dienst(en) en de SLA ondersteund worden en wie de diensten gebruikt.
Gewenste resultaten van de SLA: Een beschrijving van wat de SLA probeert te bereiken, inclusief de beoogde resultaten. Deze kunnen 'zacht' zijn, zoals gedragsveranderingen, maar ook 'hard', zoals altijd beschikbare services
Communicatie: Geef aan wie de contactpersoon van de klant is, inclusief contactgegevens. Procedures voor de omgang met uitzonderingen, escalaties, klachten en aanpassingen, procedures voor servicebeoordelingen voor de services die deze SLA omvat, en de vereisten en procedures voor tevredenheidsonderzoeken voor de services
Servicerapportage: Aard en frequentie van rapporten, die prestaties tonen ten opzichte van SLA serviceniveaus
Servicebeoordelingen: Aard en frequentie, vereiste aanwezigen, en voorzitter van de servicebeoordelingen. Procedures voor servicebeoordelingen voor de services die deze SLA omvat
Kriticiteit: Hoe kritiek de service(s) zijn voor het bedrijf, alle kritieke bedrijfsfuncties die ondersteund worden door de service(s), en alle kritieke asset(s) die de service(s) gebruikt/gebruiken
Veiligheid: alle veiligheidseisen voor de service(s) en de SLA
Servicetijden: Geef je openingstijden aan, inclusief uitzonderingen zoals bijvoorbeeld feestdagen.
Servicetijden: Tijden waarop de service(s) beschikbaar moeten zijn en specifieke uitzonderingen zoals nationale feestdagen
Ondersteuningstijden: Tijden waarop ondersteuning beschikbaar is voor de service(s) en specifieke uitzonderingen zoals nationale feestdagen
Ondersteuningsvereisten: Waar incidenten gemeld moeten worden en alle andere vereisten voor specifieke locaties of gebruikersgroepen
Doelen voor serviceniveaus: Doelen voor beschikbaarheid, oplossingstijd, prestaties, beveiliging, servicerapportage en alle andere doelen
Uitsluitingen: Vermeld hier uitsluitingen, zoals onderhoudsvensters en toegestane downtime.
Servicecontinuïteit: Vereisten voor servicecontinuïteit, inclusief een doel voor de benodigde tijd om de service te herstellen en de benodigde tijd om terug te keren naar gebruikelijke serviceniveaus
Technische standaarden: Verplichte technische standaarden en alle technische interfaces
Verantwoordelijkheden: De verantwoordelijkheden van de klant, de gebruiker en de leverancier
Prijsmodel: Definieer hoe de prijs berekend wordt en wat de sancties zijn het geval van het niet naleven van de SLA.
Wijzigingshistorie: Versiegeschiedenis van de SLA met data en goedkeurders
Gerelateerde documenten: Verwijs hier naar gerelateerde informatie die niet in de SLA vermeld staat.
Woordenlijst: Omschrijving van de in het document gebruikte woorden
Stel een SLA-beleid in dat past bij je servicedeskbehoeften om SLA-naleving te verbeteren
Houd de prestaties van de servicedesk bij, neem weloverwogen beslissingen en verbeter de dienstverlening met vooraf gedefinieerde en aangepaste rapportagemogelijkheden via de servicedesk.
Ontdek alles over het ITIL raamwerk, de ITIL levenscyclus, ITIL processen, ITIL richtlijnen en hoe te beginnen met de nieuwste versie van ITIL.
Sorry, our deep-dive didn’t help. Please try a different search term.