Streefdatum
In IT-overeenkomsten wordt over het algemeen een streefdatum opgenomen. De streefdatum wordt doorgaans aangeduid als “Go live date” of “release date”. Als een leverancier een softwaresysteem na het verstrijken van de streefdatum nog niet heeft opgeleverd, schiet hij in principe niet direct tekort in de nakoming van de overeenkomst. Niettemin kan bij een aanzienlijke termijnoverschrijding worden aangenomen dat de leverancier alsnog tekortschiet. Zo werd bijvoorbeeld in een uitspraak van de Rechtbank Rotterdam[1] geoordeeld dat een termijnoverschrijding van ruim een jaar onredelijk is. Deze leverancier kreeg een termijn om de ‘onvolkomenheden in het softwaresysteem’ (oftewel bugs) alsnog te verhelpen, op straffe van een dwangsom.
Custom made softwaresystemen
Vooral bij de implementatie van ‘custom made’ softwaresystemen zijn meestal streefdata terug te vinden in IT-overeenkomsten. Implementatietrajecten van dit soort softwaresystemen zijn doorgaans complex; voor een succesvolle implementatie is immers medewerking en input vanuit de afnemer vereist. Door deze complexiteit zijn vertragingen voorzienbaar en dient u hiermee als afnemer rekening te houden.[2] Van een fatale termijn (zie hierna) is dan ook niet zo snel sprake.
Tip 1: Oorspronkelijke streefdatum overschreden? Spreek een nieuwe fatale termijn af
Goed contact met de leverancier is belangrijk. Inventariseer tezamen wat de mogelijke gevolgen van een vertraging kunnen zijn. Als eenmaal sprake is van vertraging is het aan te raden een nieuwe (fatale) opleveringstermijn overeen te komen. Te lang ‘doormodderende’ implementatietrajecten werken immers niet bevorderlijk voor het vertrouwen in het softwaresysteem en de leverancier.
Fatale termijn
Het alternatief van de streefdatum is de fatale termijn. Indien een leverancier een fatale termijn overschrijdt, schiet hij automatisch tekort. In dit geval kunt de overeenkomst met de leverancier in principe beëindigen (d.m.v. ontbinding) en mogelijk aanspraak maken op schadevergoeding, zonder dat eerst nog gelegenheid moet worden geboden voor herstel. Voor zover de prestaties niet ongedaan gemaakt kunnen worden, moeten in plaats daarvan vergoedingen worden betaald.
Tip 2: Benoem expliciet het karakter van de opleveringstermijn
Indien u wenst een fatale termijn in een IT-overeenkomst op te nemen, dan is het raadzaam dit expliciet in de overeenkomst te benoemen. Zonder nadere toelichting wordt een opleveringstermijn in een IT-overeenkomst immers doorgaans als streefdatum aangemerkt. Ter illustratie kan een bepaling met daarin een fatale termijn als volgt worden geformuleerd:
“Het softwaresysteem zal op datum X worden opgeleverd. Deze opleveringstermijn betreft een fatale termijn, ofwel een uiterste opleverdatum. Na het verstrijken van deze opleveringstermijn is de leverancier van rechtswege, zonder voorafgaande ingebrekestelling, in verzuim.”
Waarschijnlijk zal alleen de leverancier van een simpele SaaS-oplossing, een softwaresysteem dat doorgaans in standaardpakketten wordt geleverd, akkoord gaan met een fatale termijn. Oplevering van een SaaS-oplossing is namelijk vergeleken een ‘custom made’ softwaresysteem vele malen eenvoudiger, omdat de SaaS-oplossing over het algemeen in standaardpakketten aan de afnemer wordt geleverd (denk bijvoorbeeld aan het officepakket Office 365, Hosted Exchange of het CRM-pakket Exact Online).
Tip 3: Verbindt consequenties aan het overschrijden van een fatale termijn
Als een leverancier een fatale termijn overschrijdt, dient u hier consequenties aan te verbinden. Anders vervalt uw recht om de overeenkomst te beëindigen en het recht om schadevergoeding te eisen.[3] Dit komt met name voor in situaties dat de leverancier steeds opnieuw de kans krijgt volledig na te komen en het implementatietraject daardoor te lang blijft ‘doormodderen’ en het fatale karakter van de opleveringstermijn vervalt.[4]
_________________________
[1] Rb Rotterdam op 14 augustus 2017, ECLI:NL:RBROT:2017:6180, r.o. 4.3.
[2] Hof ’s-Hertogenbosch op 3 november 2015, ECLI:NL:GHSHE:2015:4428 r.o. 3.7.1.
[3] Hof Amsterdam op 24 januari 2017, ECLI:NL:GHAMS:2017:200, r.o. 3.3.
[4] Rb Den Haag op 24 december, ECLI:NL:RBDHA:2014:16568, r.o. 4.20.