SLA's bij koppelingen: wat spreek je af over uptime, herstel en verantwoordelijkheid?

Door Clen Mourik

Een storing in je ERP-koppeling kost al snel duizenden euro's per uur. Toch heeft 6 van de 10 MKB-bedrijven geen heldere SLA-afspraken met hun softwareleverancier. Wat spreek je nu eigenlijk af over uptime, hersteltijd en wie de hoofdverantwoordelijke is als het misgaat?

Hoeveel kost het jouw bedrijf als de koppeling tussen je ERP en je urenregistratiesysteem twee dagen uitvalt? Salarissen kunnen niet verwerkt worden. Projecten lopen vertraging op. Medewerkers bellen gefrustreerd. En niemand weet wie verantwoordelijk is: de ERP-leverancier, de urenregistratie-app of de partij die de koppeling heeft gebouwd?

Uit onderzoek van Quocirca blijkt dat Nederlandse bedrijven gemiddeld €84.000 per ICT-storing kwijt zijn. Dat is inclusief stilstand (€60.000) en herstelkosten (€24.000). Voor het MKB ligt de schade tussen de €500 en €5.000 per uur downtime.

Toch spreekt een groot deel van het MKB geen heldere afspraken af in een SLA (Service Level Agreement). Dit artikel legt uit wat je moet afspreken over uptime, herstel en verantwoordelijkheid bij systeemkoppelingen. Geen juridisch jargon, wel concrete handvatten.

Inhoudsopgave

• Belangrijkste punten
• Wat is een SLA en waarom is het bij koppelingen cruciaal?
• Uptime-percentages: wat betekent 99,9% in de praktijk?
• Responstijd versus hersteltijd
• Wie is verantwoordelijk als de koppeling uitvalt?
• Een herstelplan voorkomt chaos tijdens een storing
• Wat kost een SLA voor systeemintegraties?
• Veelgemaakte fouten bij SLA's voor koppelingen
• Veelgestelde vragen

Belangrijkste punten

Wat is een SLA en waarom is het bij koppelingen cruciaal?

Een SLA is een overeenkomst tussen leverancier en klant waarin serviceniveaus, meetmethoden, verantwoordelijkheden en maatregelen bij niet-naleving worden vastgelegd. Het doel is heldere verwachtingen, meetbare prestaties en voorspelbare service.

Bij losse softwarepakketten is dat al belangrijk. Bij systeemkoppelingen wordt het essentieel.

Waarom? Omdat een koppeling afhankelijk is van meerdere systemen en partijen tegelijk. Als je webshop orders moet doorsturen naar je ERP, dan moet de webshop-API werken, de koppeling zelf functioneren én het ERP bereikbaar zijn. Valt één schakel uit, dan ligt het hele proces stil.

In de praktijk zie ik vaak dat bedrijven pas over een SLA nadenken nadat het misgegaan is. Een bouwbedrijf dat twee dagen geen urenstaten kan verwerken omdat de koppeling tussen hun app en AFAS is gebroken. Een groothandel die 150 orders handmatig moet overtypen omdat de synchronisatie met hun magazijnsysteem uitviel.

Die situaties kosten niet alleen geld. Ze veroorzaken ook stress, frustratie en wantrouwen bij je medewerkers. En vaak blijkt achteraf dat er helemaal geen afspraken waren over wie het op moest lossen en binnen welke termijn.

Wat ik in de praktijk zie: bedrijven die €30.000 investeren in een koppeling maar geen €200 per maand over hebben voor een degelijke SLA. Tot de eerste storing, dan is de paniek groot.

Uptime-percentages: wat betekent 99,9% in de praktijk?

Uptime klinkt simpel: het percentage van de tijd dat een koppeling operationeel is. Maar wat betekent 99,9% nou echt?

Volgens de Latency Global Uptime SLA Calculator vertaalt 99,9% uptime zich naar maximaal 43 minuten en 50 seconden downtime per maand. Per jaar is dat ongeveer 8,75 uur.

Dat klinkt misschien acceptabel. Tot je beseft dat die 44 minuten op het verkeerde moment kunnen vallen. Stel: je bent een accountantskantoor dat vlak voor de deadline van de aangifte inkomstenbelasting data moet ophalen uit Exact Online. Als de koppeling dan uitvalt, heb je een probleem.

Of je bent een webshop met 300 orders per dag. Een storing van 2 uur tijdens de avondspits betekent 50 gemiste orders die handmatig moeten worden ingevoerd. Dat kost je minstens 4 uur werk plus het risico op invoerfouten.

Let op: uptime van de koppeling zelf zegt niet alles. Als de API van een extern systeem uitvalt, werkt jouw koppeling ook niet. En vaak staat in de SLA dat uitval van derde partijen niet meetelt. Vraag dus altijd om een end-to-end SLA, of maak expliciet welke componenten wel en niet zijn inbegrepen.

Responstijd versus hersteltijd

Veel ondernemers denken dat een SLA met "responstijd van 2 uur" betekent dat het systeem binnen 2 uur weer werkt. Dat klopt niet.

Responstijd is hoe snel de leverancier reageert op een melding. Een bevestiging dat ze ernaar kijken. Hersteltijd (ook wel MTTR: Mean Time To Repair) is hoe lang het daadwerkelijke herstel duurt.

Een leverancier kan binnen 30 minuten reageren met "we onderzoeken het" maar pas na 24 uur met een oplossing komen. Als alleen responstijd is vastgelegd, is er geen contractuele basis om sneller herstel af te dwingen.

In een goede SLA staan beide tijden expliciet benoemd, opgesplitst naar prioriteit. Bijvoorbeeld:

• P1 (kritiek): volledige uitval van de koppeling, orders kunnen niet worden verwerkt. Responstijd: 1 uur. Hersteltijd: 4 uur op werkdagen, 8 uur buiten kantooruren.
• P2 (hoog): gedeeltelijke uitval, sommige data worden niet gesynchroniseerd. Responstijd: 4 uur. Hersteltijd: 1 werkdag.
• P3 (normaal): kleine afwijkingen of bugs zonder directe impact. Responstijd: 8 uur. Hersteltijd: 5 werkdagen.

Leg ook vast wat de escalatieprocedure is als een hersteltijd wordt overschreden. Wie belt er dan naar wie? Komt er een technisch specialist bij? Zijn er compensatiemaatregelen?

Wie is verantwoordelijk als de koppeling uitvalt?

Dit is misschien wel het lastigste onderdeel van een SLA voor systeemintegraties: het bepalen van verantwoordelijkheid.

Bij een koppeling zijn altijd meerdere partijen betrokken. Een voorbeeld: je hebt een groothandel met een webshop (WooCommerce), een ERP-systeem (Exact Online) en een koppeling die beide met elkaar laat praten. Als de synchronisatie uitvalt, kunnen drie partijen wijzen:

• De webshop-bouwer zegt: "De webshop werkt prima, het ligt aan de API van Exact."
• Exact zegt: "Onze API is operationeel, het ligt aan de koppeling."
• De koppelingspartij zegt: "Beide systemen werken, het is een configuratieprobleem aan jullie kant."

Wat ik in de praktijk zie: iedereen verwijst naar de ander. Niemand voelt zich eigenaar. En ondertussen staat je bedrijf stil.

De oplossing is een RACI-matrix in de SLA: wie is Responsible (doet het werk), Accountable (eindverantwoordelijk), Consulted (geraadpleegd) en Informed (geïnformeerd) bij een storing?

Bij een project voor een installatiebedrijf bleek na een storing dat drie leveranciers elkaar twee dagen de schuld gaven. Uiteindelijk was het een verkeerde instelling in de OAuth-authenticatie. Twee dagen omzet verlies voor iets wat in 10 minuten op te lossen was.

Mijn advies: benoem één partij als "regie-eigenaar" of "hoofdaannemer" voor de totale softwarestack. Die partij coördineert bij storingen, ook als het probleem bij een ander ligt. Dat voorkomt verlamming. En ja, die partij mag daar extra voor rekenen. Het is het waard.

Meer over hoe wij dit aanpakken vind je op onze pagina over systeemintegraties.

Een herstelplan voorkomt chaos tijdens een storing

Wat doet je team als de koppeling tussen je ordersysteem en je boekhouding uitvalt? Wachten tot het opgelost is? Handmatig invoeren? En wie communiceert naar klanten als orders vertraging oplopen?

Bij veel MKB-bedrijven is er geen plan B. Dat leidt tot improvisatie, fouten en paniek.

Een herstelplan beschrijft vooraf:

• Welke handelingen medewerkers handmatig kunnen uitvoeren als de koppeling uitvalt (bijvoorbeeld: orders exporteren naar CSV en importeren in het ERP)
• Wie de escalatiecontactpersoon is bij de leverancier
• Hoe je klanten informeert over mogelijke vertragingen
• In welke volgorde systemen worden hersteld (eerst de koppeling of eerst het onderliggende systeem?)
• Waar backups staan en hoe je die terugzet

Klinkt dit overdreven? Denk eens terug aan de laatste keer dat je software uitviel. Wist iedereen wat te doen? Of was het chaos?

Bij Retrii staat beschreven hoe zo'n plan eruitziet voor maatwerksoftware. De kern: je werkt scenario's vooraf uit zodat je bij een echte calamiteit niet hoeft te improviseren.

Voor bedrijven met kritieke koppelingen (denk aan productie, logistiek, zorg) adviseer ik om het herstelplan jaarlijks te testen. Simuleer een storing en kijk of iedereen weet wat te doen. Dat klinkt misschien overdreven, maar een uur oefenen bespaart je dagen ellende als het echt misgaat.

Wat kost een SLA voor systeemintegraties?

De kosten van een SLA voor een koppeling liggen doorgaans tussen de 10 en 20 procent van de oorspronkelijke bouwkosten per jaar. Bij een koppeling die €20.000 heeft gekost, betaal je dus €2.000 tot €4.000 per jaar.

Waar betaal je dan voor?

• Updates als één van de systemen een nieuwe API-versie uitbrengt
• Beveiligingspatches en bugfixes
• Monitoring en alerting bij storingen
• Support binnen de afgesproken respons- en hersteltijden
• Documentatie en kennisoverdracht

Hoe meer koppelingen je hebt, hoe hoger het percentage richting de 20% kan uitvallen. Dat komt omdat elk systeem zijn eigen update-cyclus heeft. AFAS brengt bijvoorbeeld elk kwartaal updates uit. Exact Online doet dat maandelijks. Als jouw koppeling met beide systemen praat, moet die dus regelmatig worden bijgewerkt.

Sommige bedrijven proberen te besparen door geen SLA af te sluiten. Dat werkt totdat de eerste storing komt. Dan betaal je urenloon voor spoedherstel, vaak tegen een tarief van €150-€200 per uur. Bij een storing van 8 uur ben je dus €1.200-€1.600 kwijt. Eenmalig. Terwijl een jaarlange SLA vaak goedkoper uitpakt én je zekerheid geeft.

Kijk ook naar wat er in een SLA zit voor ondersteuning bij API-veranderingen. Het AFAS-ecosysteem heeft ruim 250 koppelingen, maar elke connector moet worden bijgehouden bij platformwijzigingen. Dat werk moet iemand doen.

Veelgemaakte fouten bij SLA's voor koppelingen

Hieronder de fouten die ik het vaakst tegenkom bij SLA's voor systeemintegraties:

1. Geen onderscheid tussen responstijd en hersteltijd
Zoals eerder uitgelegd: responstijd is hoe snel de leverancier reageert, hersteltijd is hoe lang het daadwerkelijke herstel duurt. Als alleen responstijd is afgesproken, heb je geen harde afspraak over wanneer het weer werkt.

2. Verantwoordelijkheid is niet belegd
Bij koppelingen wijst iedereen naar de ander. Zonder RACI-matrix of regie-eigenaar ontstaat het "niemandsprobleem": een storing blijft open omdat niemand zich verantwoordelijk voelt.

3. Uptime geldt alleen voor de koppeling, niet voor onderliggende systemen
Een koppeling kan 99,9% uptime hebben, maar als de API van Exact Online uitvalt, werkt hij alsnog niet. Veel SLA's sluiten uitval van derde partijen uit. Lees de kleine lettertjes.

4. Geen meetmethode afgesproken
Hoe meet je uptime? Per maand of per jaar? Telt gepland onderhoud mee? Wie meet het: de leverancier zelf of een onafhankelijke tool? Als dit niet is vastgelegd, kun je achteraf moeilijk bewijzen dat de SLA is geschonden.

5. Geen herstelplan of fallback
Wat doet je team als de koppeling uitvalt? Wachten? Handmatig werken? Communiceren naar klanten? Zonder plan B ontstaat chaos.

Meer tips over het opzetten van betrouwbare koppelingen vind je in onze kennisbank of op de pagina met populaire integratiecombinaties.

Veelgestelde vragen

Wat is het verschil tussen een SLA en een onderhoudscontract?

Een onderhoudscontract dekt updates, bugfixes en kleine aanpassingen. Een SLA bevat daarnaast concrete afspraken over uptime, responstijd, hersteltijd en verantwoordelijkheden bij storingen. Een SLA is dus breder en strikter.

Moet ik een SLA afsluiten bij elke partij afzonderlijk?

Dat kan, maar dan loop je het risico op het niemandsprobleem bij storingen. Beter is om één partij aan te wijzen als hoofdverantwoordelijke die de regie houdt over alle koppelingen, ook als het probleem bij een ander ligt.

Wat betekent 99,99% uptime in euro's voor mijn bedrijf?

Dat hangt af van je omzet en kosten per uur downtime. Voor een MKB-bedrijf met 20 medewerkers à €40 per uur is elk uur downtime minstens €800 aan loonkosten, nog los van gederfde omzet. Bij 99,99% uptime mag je maximaal 52 minuten downtime per jaar hebben, dus minder dan 1 uur totaal.

Hoe weet ik of mijn leverancier de SLA nakomt?

Spreek af dat uptime en responstijden worden gemeten via een onafhankelijke monitoringtool (bijvoorbeeld UptimeRobot, Pingdom of StatusCake). Vraag om maandelijkse rapportages. Zonder objectieve meting is een SLA een holle belofte.

Wat zijn redelijke hersteltijden voor een koppeling in het MKB?

Dat hangt af van de kritikaliteit. Voor niet-kritieke koppelingen is 1-2 werkdagen acceptabel. Voor bedrijfskritieke koppelingen (orders, productie, salarisverwerking) wil je maximaal 4-8 uur op werkdagen en 24 uur buiten kantooruren. Voor 24/7-bedrijven zijn snellere tijden nodig.

Als je twijfelt welke afspraken passen bij jouw situatie, neem dan gerust contact met ons op voor een vrijblijvend adviesgesprek. We helpen je graag met het opstellen van heldere SLA-afspraken die passen bij je bedrijf.