Definities in contracten zijn niet alleen handig omdat ze proberen vast te stellen wat partijen onder een bepaald begrip verstaan. Het is soms ook essentieel omdat partijen de neiging hebben om bepaalde gebruikte begrippen vanuit hun eigen perspectief te benaderen. Daardoor wil het nog wel eens voorkomen dat er discussie ontstaat over de uitleg van bepaalde begrippen en bepalingen. Toepassing van verkeerde definities kan ook zeer grote of onwenselijke effecten hebben. Wat zijn veel voorkomende definities in IT-contracten? Hierna volgen een paar voorbeelden. Ook geven we enkele tips bij het opstellen van definities.
De definitie van een definitie
Volgens de Van Dale is de definitie van “definitie”: “beschrijving van wat iets is: per definitie uit de aard der zaak, vanzelfsprekend”. Een beschrijving van wat iets is dus. Veel begrippen hebben vanuit een bepaalde context een zelfstandige betekenis. Zo is voor juristen een “wanprestatie” een tekortkoming onder een overeenkomst die aan een van partijen is toe te rekenen. Voor niet-juristen is een “wanprestatie” een heel slechte prestatie van hun voetbal- of hockeyteam.
Dit is wellicht een beetje een flauw voorbeeld, maar het punt moge duidelijk zijn. Om misverstanden te voorkomen is het van belang om heel duidelijke afspraken te maken over wat beide partijen onder een bepaald begrip verstaan. Zeker in de IT wordt veel gebruikgemaakt van allerlei jargon of veelgebruikte uitdrukkingen die voor de IT-leverancier wellicht volkomen duidelijk zijn, maar voor de afnemer niet. Het is dan wachten op ellende.
Veelvoorkomende definities in IT-contracten die wezenlijk van elkaar verschillen
Enkele voorbeelden van veelvoorkomende definities in IT-contracten die een essentiële verandering teweegbrengen in het gewicht van een bepaalde verplichting of in de verhoudingen van partijen zijn:
Voorbeeld 1: Implementatie
Uit de Arbit 2016 (Algemene Rijksinkoopvoorwaarden voor IT 2016):
“Implementatie: het geheel van handelingen en maatregelen nodig om de organisatie van Opdrachtgever geschikt te maken voor het Overeengekomen gebruik van het Product en/of Programmatuur.”
Uit de Gibit (Gemeentelijke inkoopvoorwaarden voor IT):
“Implementatie: Het geheel van handelingen en activiteiten dat nodig is om alle onderdelen van de ICT Prestatie, afzonderlijk en in onderlinge samenhang, in gebruik te kunnen nemen in de organisatie van Opdrachtgever, zodanig dat alle gebruikers van Opdrachtgever ermee kunnen werken overeenkomstig het Overeengekomen gebruik. Tot de Implementatie behoort tevens de Conversie, het realiseren van de voor het Overeengekomen gebruik noodzakelijke Koppelingen en het uitvoeren van de Acceptatieprocedure.”
Twee definities uit twee willekeurige algemene inkoopvoorwaarden voor IT met een wezenlijk verschil. Onder de Arbit moet de organisatie zich aanpassen aan de software. Onder de Gibit is dit neutraler geformuleerd. Het kan ook zijn dat de software aangepast moet worden aan de werkwijzen van de organisatie. Geen van beide is verkeerd, maar bij het gebruik van de Arbit zul je je dus wel de vraag moeten stellen of dit wenselijk is, en eventueel nadere afspraken moeten maken in afwijking van de hoofdregel.
Voorbeeld 2: Gebrek
In veel leveranciersvoorwaarden wordt een "gebrek" gedefinieerd als:
“Gebrek: Het substantieel niet voldoen van de Software aan de Specificaties.”
Op zichzelf lijkt daar niet veel mis mee, maar lees dan ook even door naar wat “Specificaties” betekent:
“Specificatie: de functionaliteiten zoals vastgesteld in de Documentatie.”
Nog steeds niets aan de hand zou je zeggen. Maar dan de definitie van "Documentatie":
“Documentatie: de gebruikersdocumentatie van de Leverancier.”
In bovenstaand voorbeeld heeft de Leverancier zich gecommitteerd aan het leveren van Software die voldoet aan zijn eigen gebruikshandleiding. Het lijkt nogal evident dat de Software daaraan zal voldoen. Dit wil echter nog niet zeggen dat de Software ook daadwerkelijk voldoet aan het zorgvuldig tot stand gebrachte programma van eisen of specificaties van de afnemer! We noemen dat het onbewust wegcontracteren van specificaties.
Vergelijk bovenstaande definities eens met meer afnemervriendelijke definities:
“Gebrek: Een storing of het niet of niet volledig voldoen van het Systeem aan de Functionele Specificaties, dan wel het anderszins niet geschikt zijn voor normaal gebruik ervan door Afnemer.”
“Functionele Specificaties: De specificaties waaraan het te leveren Systeem en de te leveren Diensten moeten voldoen, zoals vastgelegd in het Programma van Eisen bij de Offerteaanvraag.”
In dit voorbeeld moet de software voldoen aan de eisen van die door de Afnemer gesteld zijn. Een enorm verschil dus.
Tip: Vraag door als je iets niet volledig begrijpt
Gebruik van jargon is bijna niet te voorkomen. Dat is ook niet erg; gebruik van IT-jargon kan (moet) functioneel zijn. Als je niet helemaal zeker bent van het gebruik van een bepaalde term, vraag dan door wat de leverancier er precies mee bedoelt. Dat doen wij ook. Met name als het gaat om de afbakening van de leveringsomvang (“Scope”) van het contract, kan dit zeer relevant zijn. Valt bijvoorbeeld onder het plegen van Preventief of Adaptief Onderhoud bijvoorbeeld ook het doorvoeren van aanpassingen aan veranderende wet- en regelgeving? Of niet? Laat hier geen onduidelijkheid over bestaan.
Tip: Geen actieve afspraken in definities verstoppen
Definities moeten verklarend werken, een betekenis vaststellen aan een bepaald begrip. Waak ervoor dat in definities actieve afspraken worden verpakt waaruit volgt dat een van partijen iets moet doen. Afspraken horen thuis in het lichaam van de overeenkomst, niet in de considerans of in de definities. De lakmoesproef is dat het je het gedefinieerde begrip in een tekst moet kunnen vervangen door de gehele regel van de betekenis.
Dus:
- Als de afspraak is: De leverancier zal Support verlenen.
- En Support is: het ter beschikking stellen van een helpdesk tijdens kantoortijden en het verlenen van gebruikersondersteuning.
- Dan moet de afspraak kunnen zijn: De leverancier zal een helpdesk ter beschikking stellen tijdens kantoortijden en gebruikersondersteuning verlenen.
Tip: In het contract of als bijlage?
Definities horen wat mij betreft in de overeenkomst zelf thuis, niet in een bijlage. Dit omdat de lijst aan definities onlosmakelijk onderdeel uitmaakt van de overeenkomst zelf. Een bijlage kan handig zijn als je verwacht dat de desbetreffende bijlage nog wel eens zou kunnen veranderen. Het punt bij definities is nu juist dat je die in beginsel niet wilt veranderen.
Tip: Bij aanpassen van definities: hele contract doorrekenen!
Het achteraf aanpassen van definities is wel mogelijk, maar kan onbedoeld een groot (nadelig) effect hebben op bepaalde actieve afspraken. Zorg er dus voor dat bij een aanpassing van een definitie, die nieuwe betekenis goed juridisch wordt “doorgerekend” in de rest van het contract. Mocht er dan een onwenselijk effect optreden ergens in de rest van de overeenkomst, dan zul je daarop moeten inspelen. Dit kan door het treffen van een nieuwe voorziening of door de definitie toch maar iets aan te passen.
Tot slot
Het moge duidelijk zijn dat definities van grote invloed kunnen zijn op de inhoud van de overeenkomst en de daarin gemaakte afspraken. Aan het opstellen van heldere definities moet veel aandacht worden besteed. Niet voor niets is het opstellen van een goed contract een ambacht. Zorg er bij het aanpassen van definities voor dat je goed "doorrekent" wat dit in de rest van de overeenkomst doet. Sommige afspraken moeten daardoor ook inhoudelijk worden aangepast. Als je echter heldere definities hebt opgesteld, zul je zien dat de inhoudelijke afspraken veel compacter kunnen worden opgesteld en veel beter leesbaar worden.
Leest u vooral ook de andere onderwerpen uit onze serie IT-contracten en blijf het geheel in samenhang bekijken.
