Onderhoud & SLA

Vier soorten werk die allemaal onderhoud heten

Onder één woord schuilen verschillende dingen. Fouten herstellen die na de oplevering opduiken. De omgeving actueel houden: updates van besturingssysteem, databank en gebruikte bouwstenen, vooral om veiligheidsredenen. Meegaan met de buitenwereld: een bank of overheidsdienst die haar aansluiting wijzigt, een nieuwe versie van een browser of telefoon. En uitbreiden, omdat u een nieuw rapport of een extra stap wilt. De eerste drie houden de software gezond en horen in een vaste afspraak. Het vierde is nieuw werk dat apart begroot wordt, en waarvan u bij maatwerk zelf de agenda bepaalt. Verwarring tussen die soorten is de meest voorkomende bron van discussie over facturen.

Wat een SLA precies vastlegt

SLA staat voor service level agreement: een afspraak over dienstverlening die meetbaar is. Ze beschrijft wanneer u terechtkunt en via welk kanaal, hoe snel er gereageerd wordt op een melding, en hoe dringendheid bepaald wordt. Een toepassing die volledig plat ligt, krijgt een andere behandeling dan een schoonheidsfout in een rapport. Soms staat er ook een beschikbaarheidsdoel in voor de hosting. Let op het verschil tussen reactietijd en oplostijd. Het eerste zegt wanneer iemand aan uw probleem begint, het tweede wanneer het opgelost is. Dat tweede kan een eerlijke leverancier zelden vooraf beloven.

Kies een niveau dat past bij uw risico

Een strenger niveau van dienstverlening kost meer, want er moet iemand paraat staan. Vraag u dus af wat stilstand betekent. Een kassa of een orderportaal dat op zaterdag uitvalt, raakt direct de omzet. Een interne rapportagetool mag gerust tot maandag wachten. Betaal niet voor permanente bereikbaarheid als uw bedrijf alleen tijdens kantooruren draait. Omgekeerd: reken niet op snelle hulp in het weekend als dat nergens afgesproken is. Maak de oefening per toepassing en leg ook vast wat u zelf doet, zoals één aanspreekpunt aanduiden dat meldingen bundelt en duidelijk beschrijft.

Afspraken die vaak vergeten worden

Vraag wie de back-ups neemt en of het terugzetten ooit getest werd. Wie bewaakt of de toepassing draait, en merkt de leverancier een storing op vóór u belt? Draait ze op uw eigen server of in een private cloud, leg dan vast wie de server zelf bijwerkt: uw mensen, uw IT-partner of de bouwer. Hoe worden updates uitgerold: eerst in een testomgeving, en op welk moment van de dag? Zit er een budget in voor kleine aanpassingen of is elk verzoek een offerte? En wat als de samenwerking stopt: krijgt u broncode, documentatie en gegevens mee? Dat lijkt onaangenaam om bij de start te bespreken, maar het is precies dan dat beide partijen er redelijk over kunnen praten.