Wat hoort in een SLA?

Vrijwel elke SLA opent met een percentage beschikbaarheid. Dat klinkt hard maar zegt weinig, want de definitie bepaalt alles: telt gepland onderhoud mee, wordt er gemeten op de server of op de dienst zoals uw gebruiker die ervaart, en over welke periode wordt gerekend.

Een maandelijkse meting waarin gepland onderhoud niet meetelt, kan een percentage van 99,9 opleveren terwijl uw mensen elke week een halve ochtend niet kunnen werken.

Reken het percentage een keer om naar minuten, dan wordt het gesprek concreter. Negenennegentig procent klinkt hoog en betekent ruim zeven uur uitval per maand. Negenennegentig komma negen betekent drie kwartier. Het verschil tussen die twee is in de praktijk het verschil tussen een leverancier met een storingsdienst en een leverancier zonder, en dat is een gesprek dat u beter kunt voeren dan het percentage.

• Een indeling van storingen naar ernst, met voorbeelden in plaats van abstracte omschrijvingen.
• Reactietijd én hersteltijd per categorie, met het verschil daartussen duidelijk benoemd.
• Wie bepaalt in welke categorie een melding valt, en wat u doet als u het daar niet mee eens bent.
• De tijden waarbinnen dit geldt: kantoortijden, of ook 's avonds en in het weekend.
• Wat er gebeurt bij herhaalde overschrijding, en of dat verder gaat dan een creditnota.

Een reactietijd zegt hoe snel er iemand reageert, niet hoe snel het opgelost is. Dat onderscheid wordt vaak vervaagd en het is precies het punt waar frustratie ontstaat: er is binnen een uur gereageerd, en drie dagen later werkt het nog niet.

Spreek daarom naast een reactietijd ook een oplostijd of een terugkoppelfrequentie af. Dat laatste is realistischer: een leverancier kan niet garanderen dat een onbekende storing binnen vier uur verholpen is, maar wel dat u elke vier uur hoort waar hij staat. Voor uw eigen communicatie naar uw klanten is dat vaak meer waard.

En koppel de tijden aan prioriteitsniveaus die u samen definieert met voorbeelden erbij. Zonder voorbeelden discussieert u bij elke storing over de categorie in plaats van over de oplossing.

Wat is een storing? Als een functie werkt maar tergend traag is, is dat dan een storing? Als één afdeling er niet in kan en de rest wel? Als de koppeling met een ander systeem het begeeft en dat andere systeem niet van uw leverancier is?

Leg die grensgevallen vast met voorbeelden uit uw eigen praktijk. Dat voorkomt de discussie die anders altijd op het slechtste moment plaatsvindt.

De meeste afspraken gelden van maandag tot vrijdag tijdens kantooruren. Dat is prima voor een systeem dat alleen dan gebruikt wordt, en het is een probleem voor een systeem waar uw klanten in het weekend op zitten. Controleer dit expliciet, want het staat vaak in een bijlage die niemand leest.

Als u buiten kantooruren dekking nodig heeft, vraag dan hoe die is georganiseerd. Een telefoonnummer dat naar een voicemail leidt is geen storingsdienst. Wat u wilt weten is: hoeveel mensen zitten er in de wachtdienst, wat kunnen ze zelfstandig oplossen, en wanneer wordt er opgeschaald.

Reken erop dat dekking buiten kantooruren geld kost. Dat is redelijk: er staat iemand paraat. De fout die vaker gemaakt wordt, is het niet afnemen en er wel op rekenen.

Een korting op de maandfactuur compenseert uw schade niet als uw dienstverlening een dag stilligt. Bovendien geeft een boete uw leverancier een prikkel om te discussiëren over de categorie in plaats van om te herstellen.

Nuttiger zijn afspraken over wat er gebeurt na een incident: een schriftelijke analyse, maatregelen met een datum, en het recht om op te zeggen bij structurele overschrijding.

Een boete per overschrijding levert kleine bedragen op en verandert zelden gedrag. Wat wel werkt, is een escalatiepad met gevolgen die oplopen: bij structureel tekortschieten volgt een verbeterplan met termijn, en als dat niet leidt tot resultaat ontstaat er een tussentijds opzegrecht.

Dat opzegrecht is het instrument dat er werkelijk toe doet, juist omdat u het zelden gebruikt. Een leverancier die weet dat aanhoudende problemen tot beëindiging kunnen leiden, geeft uw dossier een andere prioriteit dan een leverancier die weet dat u vastzit.

Combineer dat met een periodiek gesprek over de rapportage. Structureel tekortschieten wordt zelden in één keer duidelijk; het blijkt uit een patroon dat u alleen ziet als u er met enige regelmaat naar kijkt.

Begin niet bij het document maar bij de vraag wat er in uw organisatie gebeurt als het systeem een dag uitligt. Wie kan er dan niet werken, welke klanten merken het, en wat is het alternatief. Die drie antwoorden bepalen welke afspraken u nodig heeft.

Vaak blijkt uit dat gesprek dat de zwaarte per onderdeel verschilt. Het bestelsysteem mag geen uur uitliggen, de rapportagemodule een week. Een afspraak die dat onderscheid maakt, is goedkoper en realistischer dan één norm voor alles.

• Welke processen bij ons vallen stil als uw systeem eruit ligt?
• Hoe merken wij het, en hoe merkt u het? Wie belt wie?
• Wat doet u in de eerste dertig minuten van een storing?
• Hoe vaak is dit het afgelopen jaar bij uw andere klanten gebeurd?

Een afspraak zonder meting is een intentie. Spreek af wie meet, hoe vaak u rapportage krijgt en wat er precies in staat: aantal meldingen, reactietijden, oplostijden en beschikbaarheid. Zonder die rapportage merkt u pas dat er iets structureel misgaat als het al een tijd misgaat.

Laat de rapportage bij voorkeur ook de meldingen bevatten die niet onder de SLA vielen. Dat geeft u zicht op wat er werkelijk speelt, in plaats van op wat er formeel geteld werd.

Plan tot slot een gesprek per kwartaal of halfjaar waarin u de rapportage doorneemt. Niet om te controleren, maar omdat de patronen die daaruit komen — steeds dezelfde storing, steeds dezelfde vraag — vaak wijzen op iets dat u met een kleine aanpassing definitief kunt oplossen.

• Het onderhoudscontract
• Meldplicht bij een incident
• Software in beheer nemen

Wilt u eerst weten of het idee werkt voordat u groot investeert? Bij OneDayBuild laat u in één dag een werkend prototype bouwen.