Jouw bedrijf draait op software. De facturatie, de planning, het klantenbeheer: zonder die systemen staat alles stil. En toch kopen veel zaakvoerders software op basis van een goed gesprek, een mooie demo en het gevoel dat de leverancier te vertrouwen is. Dat gevoel kan duur uitkomen. Software is kritieke infrastructuur geworden, vergelijkbaar met stroom of internet. Als ze uitvalt of fouten produceert, betaal je de prijs. Niet de leverancier. De vraag is dus niet of je een leverancier vertrouwt, maar of die leverancier betrouwbaarheid ook kan aantonen.
Vertrouwen is een goed begin, maar geen contractuele bescherming. Als een softwaresysteem uitvalt en jouw orderverwerking daardoor twee dagen stilvalt, is de schade voor jouw rekening. De leverancier verwijst naar de kleine lettertjes.
Computable wijst erop dat software steeds vaker de rol van kritieke infrastructuur overneemt en dat toenemende complexiteit en geopolitieke factoren de urgentie vergroten om leveranciersrisico’s actief te beheren.
Wat betekent dat concreet? Betrouwbaarheid is meetbaar en aantoonbaar, of ze bestaat niet. Een leverancier die zegt ‘wij hebben nog nooit problemen gehad’ geeft je geen bewijs; die geeft je een verkoopargument. De vraag die je als zaakvoerder moet stellen, is niet ‘vertrouw ik deze leverancier’ maar ‘kan deze leverancier me bewijzen dat zijn software doet wat hij belooft, ook als het misgaat’.
Dat onderscheid maakt je kwetsbaar of weerbaar. En het goede nieuws: je hoeft geen IT-expert te zijn om de juiste vragen te stellen. Het gaat om inkoop, niet om techniek.
Niet elk stuk software verdient dezelfde aandacht. Een tool voor interne planningslijsten is iets anders dan het systeem waarmee je klanten factureert of voorraden beheert. De zwaarte van het bewijs dat je vraagt, moet in verhouding staan tot de impact als het misgaat.
Drie basisvormen van bewijs zijn voor elke kmo haalbaar:
Voor bedrijfskritische software mag je meer vragen: een onafhankelijke auditverklaring of een penetratietest (een gesimuleerde cyberaanval om zwaktes in de software te ontdekken). Dat is niet altijd standaard, maar een professionele leverancier weet dat dit een legitieme vraag is.
Het overzicht hieronder helpt je bepalen welk bewijniveau past bij jouw situatie:
| Impactniveau | Wanneer toepassen | Voorbeelden van bewijs |
|---|---|---|
| Laag | Beperkt proces, korte verstoring mogelijk | SLA, release notes, uptime-afspraken |
| Middel | Meerdere gebruikers of kernprocessen | Testrapporten, gebruikersacceptatietests, incidentenoverzicht |
| Hoog | Bedrijfskritisch, financieel of juridisch gevoelig | Third-party audit, penetratietest, onafhankelijk auditrapport |
Leg die afspraken ook contractueel vast. Een mondelinge belofte heeft geen waarde als het misgaat.
De tabel hierboven geeft een richting, maar in de praktijk twijfel je soms. Hier zijn vier signalen dat je meer zekerheid moet eisen, ook als de leverancier zegt dat het niet nodig is:
In die gevallen is het redelijk om te onderhandelen. Vraag om een pilotperiode van dertig tot zestig dagen met duidelijke acceptatiecriteria, voor je het definitieve contract tekent. Vraag om jaarlijkse rapportage van incidenten en updates.
Maak ook de omgekeerde afweging: als een leverancier weigert om ook maar één vorm van bewijs te delen, zegt dat iets over hoe ze omgaan met transparantie. Dat is een risico-indicator, geen detail.
Bij Clear IT bekijken we soms samen met klanten welke criteria relevant zijn voor hun specifieke situatie en welke vragen ze het best stellen bij een contractherziening.
Software kopen op goed vertrouwen is een gewoonte die kmo’s zich niet langer kunnen veroorloven. De afhankelijkheid is te groot, de risico’s te reëel. Gelukkig vraagt het geen technische kennis om de juiste dingen te eisen: SLA’s, testrapporten, een incidentenoverzicht. Begin klein en pas het toe op jouw meest kritieke systeem. Als een leverancier die vragen niet kan beantwoorden, heb je jouw antwoord al.
Een service level agreement (SLA) is een schriftelijk contract waarin staat wat de leverancier belooft op vlak van beschikbaarheid, reactietijd bij storingen en hoe snel problemen opgelost worden. Zonder SLA heb je geen houvast als de software uitvalt. Met een SLA kun je de leverancier aanspreken op concrete, vooraf vastgelegde afspraken.
Voor software met een lage of gemiddelde impact is een externe audit inderdaad vaak niet nodig. Een goede SLA, testrapporten en een incidentenoverzicht zijn voor de meeste kmo’s voldoende. Vraag een externe audit alleen voor systemen waarbij een storing grote financiële of juridische gevolgen heeft.
Dat is een belangrijk signaal. Ga na of de weigering gaat over commerciële gevoeligheid (dan kun je vragen om een samenvatting of een certificering) of over een gebrek aan documentatie. Als een leverancier echt niets kan tonen, overweeg dan alternatieven of versterk minstens jouw contractuele bescherming.
Je hoeft niet te wachten op een nieuwe aankoop. Gebruik een contractherziening of verlengingsmoment om alsnog SLA-clausules en rapportageverplichtingen in te voegen. De meeste leveranciers zijn bereid om dat te bespreken, zeker als je een langdurige klant bent.
