ERP-contracten beoordelen: onderhoud, SLA en exitafspraken

ERP-contracten beoordelen: waarom onderhoud, SLA en exit apart aandacht vragen

Een ERP-contract bestaat vaak uit meerdere documenten. Je leest ze apart én in samenhang. De SLA vult doorgaans een hoofdovereenkomst aan voor software, cloud-diensten, hosting, managed services of IT-support.

Daarin staat welke diensten worden geleverd. Ook staat erin welke serviceniveaus gelden, hoe storingen worden afgehandeld, welke verantwoordelijkheden partijen hebben en welke prestaties je mag verwachten. In een SLA bij cloud-ERP liggen de rechten en plichten van jou en de ERP-leverancier vast.

Onderhoud, beschikbaarheid en exit grijpen op elkaar in. Geplande onderhoudsvensters bepalen mee hoe uptime wordt berekend. Uitzonderingen wegens overmacht en storingen bij derde partijen zoals Microsoft Azure of AWS bepalen of een gemiste norm meetelt. Afspraken over gegevensoverdracht bepalen of je bij einde contract verder kunt met een ander systeem.

Beoordeel die drie onderdelen vóór ondertekening. Wacht niet tot de eerste storing of beëindiging.

Hoofdovereenkomst, SLA en bijlagen: hoe de afspraken zich tot elkaar verhouden

De SLA is meestal een bijlage bij de hoofdovereenkomst. De hoofdovereenkomst regelt licenties, vergoedingen, aansprakelijkheid en looptijd. De SLA vult aan met operationele afspraken over dienstverlening en prestaties. Beoordeel een SLA-norm daarom nooit los van de hoofdovereenkomst.

Een beschikbaarheidsgarantie in de SLA heeft weinig betekenis als de hoofdovereenkomst aansprakelijkheid voor het niet halen ervan volledig uitsluit.

Controleer eerst de rangorde. Welke bepaling gaat voor bij tegenstrijdigheid tussen hoofdovereenkomst, SLA en overige bijlagen? Zonder voorrangsregel is bij een conflict niet duidelijk welk document wint.

Loop ook na of de SLA verwijst naar documenten die je niet hebt ontvangen, zoals een supportproces, beveiligingsbijlage of exitplan. Controleer of alle onderdelen die de SLA hoort te bevatten daadwerkelijk als bijlage aan het contract zijn gehecht.

Onderhoudsafspraken: welk onderhoud is inbegrepen en wanneer mag de leverancier ingrijpen?

Onderhoudswerkzaamheden horen in de opsomming van wat een SLA beschrijft. Beoordeel of het contract onderscheid maakt tussen correctief onderhoud (het verhelpen van fouten), gepland of preventief onderhoud en functionele updates of upgrades van de ERP-software. Controleer of die werkzaamheden zijn inbegrepen of apart worden gefactureerd.

Zonder dat onderscheid is niet na te gaan waarvoor je betaalt. Ook is niet duidelijk welke werkzaamheden de leverancier zonder aparte opdracht mag uitvoeren.

Geplande onderhoudsvensters beïnvloeden de beschikbaarheidsgarantie direct. De vraag of die uren als downtime meetellen, bepaalt de uitkomst.

Leg vast binnen welke tijdvensters de leverancier mag ingrijpen. Leg de aankondigingstermijn vast. Bepaal of spoedonderhoud zonder voorafgaande aankondiging is toegestaan en wat er gebeurt als onderhoud buiten het afgesproken venster uitloopt.

Maak concreet voor welke ERP-processen onderbreking tijdens een venster acceptabel is en welke niet.

Scope van de SLA: welke software, omgeving en diensten vallen eronder?

Een veelvoorkomende fout is dat onvoldoende is beschreven welke diensten precies onder de SLA vallen. Beschrijf concreet de software of systemen waarop de SLA betrekking heeft, de omgeving (on-premise, cloud of hybride), de supportdiensten, eventuele monitoring, onderhoudswerkzaamheden, beveiligingsdiensten en back-updiensten. Hoe duidelijker de scope, hoe kleiner de kans op interpretatieverschillen.

Loop die opsomming na langs je eigen ERP-landschap. Vallen alle modules die je gebruikt eronder, en ook koppelingen met externe systemen, rapportages en interfaces naar derden? Maak per omgeving expliciet wie waarvoor zorgt.

Bij een on-premise installatie is de leverancier voor een deel afhankelijk van jouw infrastructuur. Bij een cloud- of hybride omgeving verschuift een deel van de verantwoordelijkheid naar leverancier of hostingpartij.

Staat een onderdeel niet in de scope, dan valt het ook niet onder de prestatieafspraken.

Beschikbaarheid en uptime: percentage alleen is niet genoeg

Beschikbaarheid wordt in SLA's uitgedrukt in percentages, bijvoorbeeld 99,5%. Niet het percentage zelf is het belangrijkst, maar hoe het wordt berekend. Let op de meetperiode (maand of jaar), geplande onderhoudsvensters, uitzonderingen wegens overmacht en storingen bij derde partijen zoals Microsoft Azure of AWS.

Een uptime-garantie zonder duidelijke meetmethode heeft weinig juridische waarde.

Vraag naar de rekenregels achter het percentage. Welk onderdeel van de keten wordt gemeten? Hoe wordt gedeeltelijke uitval meegewogen? Welke gebeurtenissen worden van de meetperiode uitgesloten?

Leg vast dat je de onderliggende meetgegevens kunt opvragen. Zo kun je bij een geschil reconstrueren of de norm is gehaald.

Zijn de uitsluitingen zo ruim dat vrijwel elke storing buiten de meting valt, dan zegt het percentage weinig over de beschikbaarheid die je feitelijk krijgt.

Incidenten, prioriteiten en reactie- en oplostijden

Niet iedere storing heeft dezelfde impact. Professionele SLA's werken daarom met prioriteitsniveaus. Gangbaar is: prioriteit 1 (kritiek) voor volledige uitval van bedrijfskritische systemen; prioriteit 2 (hoog) wanneer belangrijke functionaliteit niet werkt; prioriteit 3 (normaal) bij beperkte impact; prioriteit 4 (laag) bij kleine fouten en cosmetische issues. Door prioriteiten vooraf vast te leggen is de ernst van meldingen duidelijk.

Toets of die classificatie aansluit op je ERP-processen. De definitie van prioriteit 1 is alleen werkbaar als in het contract staat welke systemen en processen als bedrijfskritisch gelden. Zonder die lijst kan de leverancier een storing lager indelen.

Maak onderscheid tussen reactietijd (de tijd waarbinnen de leverancier een melding oppakt) en oplostijd (de tijd waarbinnen hij de storing verhelpt of een werkbare oplossing levert). Leg vast wat er gebeurt als de oplostijd niet wordt gehaald.

Verantwoordelijkheden, contactpersonen en rapportage

Een SLA beschrijft welke verantwoordelijkheden partijen hebben. Bij ERP-SLA's horen ook contactpersonen tot de vaste onderdelen. Leg vast wie namens jou en namens de leverancier contactpersoon en escalatiepunt is.

Leg ook vast via welk kanaal storingen worden gemeld en hoe escalatie verloopt als een melding niet binnen de afgesproken norm wordt opgepakt.

Neem je eigen verplichtingen mee: welke medewerking, testcapaciteit of informatie moet jij leveren? Wat zijn de gevolgen als je dat niet doet?

Spreek af welke rapportage je periodiek ontvangt — overzichten van meldingen, prioriteiten en gehaalde versus gemiste normen. Spreek ook de vorm af.

Zo kun je die rapportage gebruiken voor je eigen toetsing in plaats van er alleen kennis van te nemen.

Meetbare normen en toetsing: hoe controleer je of de leverancier presteert?

De overeenkomst moet meetbare normen voor dienstverlening bevatten. Alleen dan kun je nagaan of de leverancier voldoet. Formuleer de afspraken SMART. Vermijd normen die alleen in algemene termen iets zeggen over kwaliteit of inzet.

'De leverancier spant zich voldoende in' is niet toetsbaar. Een norm met een concreet meetpunt, meetperiode en meetmethode is dat wel.

Maak toetsing onderdeel van de contractcyclus. Leg vast dat je de meetgegevens van de leverancier ontvangt. Leg vast dat je die zelf mag verifiëren. Bepaal wat de consequentie is als een norm in een periode niet wordt gehaald — bijvoorbeeld een gesprek, een verbeterplan of een financiële correctie.

Zonder aan de norm gekoppelde consequentie blijft de afspraak een intentieverklaring.

Exit en gegevensoverdracht: bruikbare data bij beëindiging

Het recht op dataportabiliteit is nieuw voor Nederlandse bedrijven. Onder de AVG moeten bedrijven gegevens beschikbaar stellen aan betrokkenen. Die informatie moet in bruikbare vorm worden aangeleverd.

Dat recht ziet op betrokkenen wier persoonsgegevens worden verwerkt. Het is iets anders dan jouw recht als klant op teruglevering van je eigen bedrijfsgegevens.

Voor exit uit een ERP-contract moet je daarom zelf contractueel regelen wat je bij beëindiging meekrijgt.

Leg in het contract vast in welk formaat en volgens welke structuur je gegevens worden teruggeleverd. Leg de termijn vast. Leg vast welke medewerking de leverancier verleent bij migratie naar een ander systeem en tegen welke kosten.

Regel ook wat er daarna met de gegevens gebeurt. Onder de AVG hebben betrokkenen recht op verwijdering van hun gegevens. Dat raakt aan hoe lang data in het oude systeem blijven staan.

Maak daarnaast afspraken over het moment waarop de dienstverlening stopt en over de periode waarin je nog toegang houdt.

Juridische toets en financiële risico's

Veel SLA's bestaan vooral uit technische termen. Daardoor is niet altijd duidelijk welke rechten en verplichtingen partijen daadwerkelijk hebben. Een goede SLA is meer dan een lijst met responstijden.

Het document vormt de basis voor de verwachtingen tussen leverancier en klant. Het voorkomt discussies bij storingen, beveiligingsincidenten of beschikbaarheidsproblemen.

Laat de SLA juridisch controleren. Betrek daarbij het beperken van financiële risico's. Ga bijvoorbeeld na hoe de normen zich verhouden tot aansprakelijkheidsbepalingen in de hoofdovereenkomst.

Een wettelijk gecontroleerde en goedgekeurde SLA elimineert effectief de mogelijkheid van een verkeerde interpretatie van het contract.

Sinds 25 mei 2018 is de AVG van toepassing in de hele Europese Unie. In Nederland is dat de Algemene verordening gegevensbescherming, die de Wet bescherming persoonsgegevens verving.

In Nederland worden de belangrijkste regels aangevuld door de Uitvoeringswet AVG. De Autoriteit Persoonsgegevens houdt toezicht op naleving van de AVG.

Verwerkt je ERP persoonsgegevens, dan horen de afspraken daarover — en wat er bij beëindiging met die gegevens gebeurt — in de contractstukken te staan.

Checklist voor de beoordeling van je ERP-contract

Structuur: controleer of de SLA een aanvulling is op de hoofdovereenkomst. Controleer welke documenten als bijlage zijn gehecht. Zoek de voorrangsregel bij tegenstrijdigheid. Lees SLA en hoofdovereenkomst in samenhang op aansprakelijkheid. Verifieer dat elke bijlage waarnaar wordt verwezen, ook daadwerkelijk is ontvangen.

Scope: loop de opsomming na op software en systemen, omgeving (on-premise, cloud of hybride), supportdiensten, monitoring, onderhoudswerkzaamheden, beveiligingsdiensten en back-updiensten. Streep aan welke modules, koppelingen en interfaces daar buiten vallen.

Onderhoud en beschikbaarheid: ga na welk onderhoud is inbegrepen en welk apart wordt gefactureerd. Controleer welke onderhoudsvensters en aankondigingstermijnen gelden. Ga na hoe uptime wordt berekend (meetperiode, uitzonderingen, storingen bij derden). Bepaal of de garantie zonder die rekenregels juridische waarde heeft.

Incidenten: controleer of de prioriteitsniveaus P1 tot en met P4 zijn gedefinieerd. Controleer welke systemen als bedrijfskritisch gelden. Controleer of reactietijd en oplostijd apart zijn benoemd met een consequentie als de norm niet wordt gehaald.

Governance en meting: leg contactpersonen en escalatiepad vast. Bepaal welke rapportage je ontvangt. Maak normen SMART en toetsbaar. Spreek af dat je de meetgegevens kunt verifiëren.

Exit en juridisch: regel het terugleverformaat, de termijn, de medewerking en de kosten bij beëindiging, plus verwijdering van persoonsgegevens. Laat de SLA en de hoofdovereenkomst juridisch controleren met het oog op interpretatieverschillen en financiële risico's.