Zit er genoeg SLA in mijn SaaS?

Services levels spreek je af in de SLA. Hier lees je meer over in dit artikel. De SLA heeft vanuit de theorie een duidelijke positie binnen de informatievoorziening (IV). In Information Technology Infrastructure Library (ITIL) valt het opstellen van een SLA onder één van de zeventien servicemanagementpraktijken en in Business Information Service Library (BiSL) is het onderdeel van het sturende proces contractmanagement. Beide frameworks bekijken SLA’s vanuit de relatie klant-leverancier, waarbij de organisatie de klant is die een dienst of product (vaak software) afneemt bij een leverancier.  

Veel leveranciers bieden tegenwoordig Software as a Service (SaaS) aan in plaats van on premise oplossingen. Het inkopen van een SaaS-oplossing is het ideale moment om service levels met elkaar af te spreken. Het woord “service” zit immers al verwerkt in het woord SaaS, toch? 

Toch zien wij regelmatig dat services levels ontbreken binnen organisaties, laat staan dat er actief op ze gestuurd wordt. En als services levels wel bekend is, dan zijn deze 9 van de 10 keer overgenomen van de leverancier. Dit laat weinig ruimte voor onderhandelen, want waarom zou de leverancier met jou als individuele klant andere afspraken maken dan met zijn honderd andere klanten?

Heeft een verSaaSde organisatie dan meer afspraken nodig met haar leverancier? Als het kan, dan wel! Maar we mogen ook niet blind zijn voor de huidige positie van leveranciers. Grote spelers kunnen nu eenmaal makkelijk nee zeggen op het leveren van maatwerk. In dat geval kan je beter je energie ergens anders insteken. De reden dat er niet genoeg SLA in jouw SaaS zit is omdat we ons blindstaren op het verkeerde soort SLA. 

Als we SaaS-applicaties, met de bijbehorende services levels, als vaststaand gegeven zien, dan hebben we nog steeds een wereld te winnen. Hiervoor moeten we onszelf niet langer als de klant zien, maar als de leverancier. De applicatie ondersteunt enkel de diensten die jouw organisatie levert aan haar interne- en externe klanten. De leverancier wordt dan een partner die, met zijn services levels, de kaders stelt over de service die jij kunt leveren.  

Door anders naar de SLA te kijken verandert ook de inhoud van de SLA. Het merendeel van de tijd zijn wij namelijk geen softwareleverancier maar een dienstverlener die graag de zorg, het onderwijs of de overheid vooruit helpt. Daar horen ander soort afspraken over services levels bij. Een voorbeeld hiervan is de doorlooptijd van een aanvraag binnen een specifieke afdeling.  

Dit betekent niet dat al jouw oude documentatie over SLA de prullenbak in kan. Er staan namelijk zinnige zaken in waarover je afspraken kan maken. Maar het belangrijkste is je af te vragen waarover je afspraken wil maken. Dat kan natuurlijk niet zonder het benaderen van de klant, want afspraken werken altijd twee kanten op. 

Uiteindelijk wil je genoeg services levels afpreken waaraan de kwaliteit van de dienstverlening getoetst kan worden. Maar kom niet in de verleiding om overal afspraken over te maken. De SLA, en de onderliggende Dossiers Afspraken en Procedures (DAP), zijn vaak lijvige documenten die niet erg uitnodigen om ze te lezen. Maar als de mensen die ermee moeten werken de inhoud niet kennen, hoe kan dan actief op services levels gestuurd worden?  

Overweeg daarom een light-variant die alleen meet wat essentieel is voor goede dienstverlening. Bijvoorbeeld service levels over reactietijden en klanttevredenheid. Stel jezelf dus niet meer de vraag of er genoeg SLA in je SaaS zit, maar of de SLA van de juiste kwaliteit is. Dit voorkomt buikpuin achteraf.