Home > IT Recht > Zorg ervoor dat het contract aansluit bij de praktijk en voorkom verloren procedures
Zorg ervoor dat het contract aansluit bij de praktijk en voorkom verloren procedures

Zorg ervoor dat het contract aansluit bij de praktijk en voorkom verloren procedures

Het komt bij IT-projecten nogal eens voor dat een contract niet altijd de aandacht krijgt die het verdient. Soms wordt er snel iets in elkaar gezet, wordt een bepaald standaarddocument ondertekend of wordt het (eenzijdige) contract van de leverancier aanvaard, terwijl dat helemaal niet past bij wat partijen eigenlijk gaan doen. Een arrest van het Gerechtshof Amsteram van 29 april j.l. laat zien hoe zich dit tegen partijen kan keren.

Overeenkomst tot ontwikkeling software

Tussen de partijen is een overeenkomst gesloten tot de ontwikkeling van software. In de overeenkomst was vastgelegd dat de software diende te voldoen aan het functioneel ontwerp versie 1.0, zoals opgenomen in bijlage A van de overeenkomst. In de overeenkomst was verder een acceptatieprocedure opgenomen, die binnen twee weken doorlopen diende te worden na het opleveren van de programmatuur. Daarbij was bepaald dat het niet tijdig klagen over gebreken automatisch leidde tot acceptatie van het programma.

Eerste versie opgeleverd en in gebruik

De leverancier gaat na contractering aan de slag met het ontwikkelen van de software. Ongeveer een jaar na contracteren wordt een versie van de software opgeleverd. Deze wordt door de opdrachtgever getest en naar aanleiding daarvan past de leverancier de software aan. Kennelijk is de software op een bepaald moment goed genoeg, want uit het arrest blijkt dat de opdrachtgever ongeveer een half jaar later de software voor 8 klanten in gebruik heeft.

Geschil over de software

Niettemin ontstaat er ongeveer 8 maanden later een geschil. De opdrachtgever laat weten dat hij graag toe wil naar de eerste officiele oplevering van de software. De leverancier reageert dat de software reeds is opgeleverd en in gebruik is en dus (kennelijk) is goedgekeurd. Daarna volgt nog wat correspondentie over en weer, waarop de leverancier vervolgens aankondigt op 23 december 2011 de software op te zullen leveren conform de overeenkomst. De leverancier wijst er daarbij op dat vervolgens de acceptatieprocedure dient te worden doorlopen.

De opdrachtgever laat ruim een week later weten dat de applicatie niet wordt geaccepteerd omdat er (a) geen functioneel en technisch ontwerp is, (b) testen binnen twee weken niet realistisch is, (c) er gebreken zouden zitten in de software en (d) acceptatie van de software en de hosting omgeving los zou moeten staan van elkaar. De leverancier reageert enkele dagen later door aan te geven dat (a) het functioneel ontwerp al in bezit is van opdrachtgever en over het technisch ontwerp nooit afspraken zijn gemaakt en (c) dat van gebreken geen sprake zou zijn.

Hof: schriftelijke afspraken leidend

Het Gerechtshof overweegt allereerst dat de schriftelijk gemaakte afspraken leidend zijn:

3.4. Het hof volgt [A B.V.] in haar standpunt dat voor de beoordeling van haar verplichtingen ter zake de applicatie de licentieovereenkomst tussen partijen leidend is.

Hof: nieuwe versie functioneel ontwerp irrelevant

Ongeveer twee weken na het ondertekenen van het contract stuur de leverancier versie 1.2 van het functioneel ontwerp aan de opdrachtgever. De opdrachtgever had voor het Hof betoogd dat deze versie van de software opgeleverd diende te worden. Het contract vermelde echter alleen versie 1.0. De leverancier had zich verweerd met de stelling dat de software (dus) alleen aan versie 1.0 van het FO diende te voldoen. De leverancier krijgt hier van het Gerechtshof gelijk:

Volgens de licentieovereenkomst heeft [A B.V.] zich tegenover[appellant] slechts verplicht tot de oplevering van applicatieprogrammatuur conform het functioneel ontwerp versie 1.0 (bijlage A bij die overeenkomst) (…)  [A B.V.] heeft echter op dit punt onvoldoende weersproken betoogd dat de wijzigingen in de applicatieprogrammatuur met name zien op het roosterplan en op verzoek van[appellant] onverplicht zijn aangebracht (en daarom hebben geleid tot wijzigingen neergelegd in een functioneel ontwerp versie 1.2), maar dat dit aan de licentieovereenkomst (en functionaliteit van het ontwerp – het hof begrijpt: zoals vastgelegd in bijlage A van die overeenkomst, zijnde het functioneel ontwerp versie 1.0 – ) verder niet afdoet. Op grond van het voorgaande moet derhalve worden geoordeeld dat [A B.V.] op grond van de licentieovereenkomst applicatieprogrammatuur conform het functioneel ontwerp versie 1.0 diende op te leveren.

Hof: acceptatieprocedure doorlopen, onvoldoende bewijs dat onmogelijk was

Het Gerechtshof overweegt verder dat de opdrachtgever gehouden was de contracuteel opgenomen acceptatieprocedure te doorlopen. Het verweeer van de opdrachtgever dat testen onmogelijk was, verwerpt het Hof als (a) onvoldoende onderbouwd en (b) bovendien onwaarschijnlijk (omdat de applicatie al in gebruik was). In de woorden van het Hof:

3.7. Dat de opgeleverde applicatie in het geheel ondeugdelijk of onbruikbaar was en aan testen in de weg stond, zoals wellicht uit de stellingen van[appellant] kan worden afgeleid (wanneer hij bijvoorbeeld opmerkt dat deze ernstige rekenfouten vertoonde), is onvoldoende onderbouwd en overigens ook niet aannemelijk geworden nu [A B.V.] onvoldoende weersproken heeft gesteld dat[appellant] de applicatie al geruime tijd vóór de oplevering van 23 december 2011 bedrijfsmatig in gebruik had genomen en tegen betaling aan diverse klanten ter beschikking stelde. Daarnaast kan uit zijn brief van 20 december 2011 aan [A B.V.] worden afgeleid dat[appellant] slechts vond dat [A B.V.] in gebreke was (en dat dit aan het uitvoeren van tests in de weg stond) omdat hij nog geen berichten van oplevering van de Dedicated Hosting Service en de applicatie had ontvangen, er diverse documentatie (m.b.t. het functioneel ontwerp, het technisch ontwerp en de handleiding) ontbrak en op het punt van “Design en Navigatie” de snelle opbouw van pagina’s kennelijk te wensen overliet. Soortgelijke verwijten formuleert[appellant] in zijn brief van 2 januari 2012. Gelet op de stellingen van [A B.V.] dat de opgeleverde applicatie wel degelijk voldeed aan de opleveringseisen en gereed was om te testen, zijn die omstandigheden echter, ervan uitgaand dat aan de opleveringseis op 23 december 2011 is voldaan, zonder nadere onderbouwing die ontbreekt, evenmin aanleiding om aan te kunnen nemen dat deze in de weg stonden aan het uitvoeren van de acceptatietests. Daarbij is van belang dat[appellant] de beschikking had over het functioneel ontwerp versies 1.0 en 1.2, dat hij (zoals hiervoor overwogen) de applicatie al bedrijfsmatig in gebruik had genomen en exploiteerde, terwijl niet gesteld of gebleken is dat beschikbaarstelling van die documentatie (het technisch ontwerp) of aanpassing daarvan (het functioneel ontwerp), volgens de licentieovereenkomst tot de verplichtingen van [A B.V.] behoorde. Ook is onvoldoende onderbouwd dat een en ander onmisbaar was om tot de acceptatietests over te kunnen gaan. Met betrekking tot het technisch ontwerp heeft[appellant] daarover immers slechts gesteld dat dit hem zou helpen bij de analyse van eventuele problemen. Overigens was in de offerte op dit punt alleen vermeld dat een functioneel en technisch ontwerp zou worden vastgesteld in verband met het tijdschema voor de verschillende werkzaamheden. Grotendeels hetzelfde geldt voor de aanvullende wensen die[appellant] richting [A B.V.] heeft geformuleerd ten aanzien van informatie over beveiliging en licenties, alsmede de aanpassing van het roosterplan. Onvoldoende is onderbouwd dat de omstandigheid dat aan de wensen van[appellant] op die punten niet was voldaan, in de weg stond aan zijn mogelijkheden om na de oplevering van de applicatie tot uitvoering van de acceptatieprocedure over te gaan.

Hof: korte tijd doorlopen acceptatieprocedure komt voor eigen risico

De opdrachtgever had verder aangevoerd dat het testen praktisch onmogelijk was, omdat de leverancier bestaande testgegevens had verwijderd en het niet mogelijk was om in de korte testperiode nieuwe testgegvens in te voeren. Het Hof gaat ook hierin niet mee.

Het Hof stelt eenvoudigweg vast dat de overeenkomst de leverancier niet verplichtte om de applicatie met testgegevens op te leveren. Sterker nog, het Hof stelt juist vast dat uit de overeenkomst volgt dat de opdrachtgever de testgegevens zelf moest invoeren. Ook het verweer dat de testperiode onredelijk kort zou zijn, wordt door het Hof verworpen. Het Hof stelt vast dat partijen deze consequentie van het contract bij het contracteren onder ogen hebben gezien:

3.8. Resteert het verwijt dat [A B.V.] de vóór 23 december 2011 in het systeem aanwezige testdata heeft verwijderd en dat dit (mede) reden was niet tot de acceptatieprocedure over te gaan. Vooropgesteld wordt dat niet is gesteld, noch is gebleken dat de licentieovereenkomst tussen partijen [A B.V.] verplichtte tot oplevering van de applicatie met inbegrip van de testdata die gedurende de (voorafgaande) testperiode waren ingevoerd. Uit die overeenkomst (in het bijzonder artikel 3.1 en 3.2) moet daarentegen worden afgeleid dat het uitsluitend aan[appellant] was de applicatie te voeden met gegevens (testgevallen), nadat het tot oplevering was gekomen. Dat de applicatie in de testperiode voorafgaand aan de oplevering reeds gegevens bevatte die (klanten van)[appellant] had(den) aangeleverd maakt dat niet anders.[appellant] heeft voorts bij de comparitie van partijen in eerste aanleg erkend dat er in december 2011 wel degelijk getest kon worden. In hoger beroep heeft hij dit in zoverre genuanceerd dat gelet op de korte periode van de acceptatieprocedure (twee weken) dit praktisch onmogelijk was omdat het invoeren van data veel meer tijd dan die twee weken zou kosten. Aangenomen moet echter worden dat partijen de consequenties van de duur van de acceptatieperiode bij het sluiten van de overeenkomst onder ogen hebben gezien. Het tegendeel is door[appellant] niet betoogd. Verder staat vast dat[appellant] überhaupt geen poging heeft ondernomen om met de acceptatietests en de invoer van data een aanvang te maken. Onvoldoende is onderbouwd dat dat gelet op de termijn van 2 weken op voorhand zinloos was. Voor zover[appellant] met een en ander heeft willen betogen dat (de redelijkheid en billijkheid meebrengen dat) hij niet tot de acceptatietests hoefde over te gaan, moet dat standpunt dan ook van de hand worden gewezen omdat dat wel degelijk van hem verwacht had mogen worden.

Hof: applicatie moet geacht te zijn geaccepteeerd

De conclusie ligt vervolgens wel voor de hand. Na de overweging dat de opdrachtgever had moeten testen en geen excuus heeft dat dit niet is gebeurd (zie hiervoor), komt het Hof tot de conclusie dat de software op grond van het contract geacht moet zijn te zijn geaccepteerd:

3.9. De omstandigheid dat [A B.V.] van[appellant] na de oplevering op 23 december 2011 niet binnen vijf dagen na afloop van de daaropvolgende acceptatieperiode van twee weken schriftelijk bericht heeft ontvangen dat de acceptatietests zijn onderbroken wegens fouten in de geleverde applicatieprogrammatuur, leidt er derhalve vervolgens toe dat conform artikel 3.7 van de overeenkomst de applicatieprogrammatuur geacht wordt door[appellant] te zijn geaccepteerd.

Hof: voor hosting omgeving geldt hetzelfde

Voor de acceptatie van de hosting omgeving komt het Hof tot dezelfde conclusie:

3.10. Dezelfde argumenten gelden de Dedicated Hosting Service, die in grief V aan de orde wordt gesteld. De conclusie moet luiden dat nu deze bij meergenoemde brief van 23 december 2011 eveneens is opgeleverd, terwijl niet is gesteld of gebleken dat[appellant] (conform artikel 5 lid 4 van de hostingovereenkomst) binnen 3 dagen na de afloop van de acceptatieperiode van 5 werkdagen een schriftelijk bericht heeft verzonden dat deze niet of onvoldoende functioneerde, ook de Dedicated Hosting Service geacht wordt door hem te zijn geaccepteerd.

Slotopmerkingen

Het heeft er, het arrest lezend, alles van weg dat hier sprake is van totaal verschillende percepties van beide partijen op het project. Dat de leverancier enkele dagen na contracteren versie 1.2 van het FO toezendt aan opdrachtgever, lijkt bij de opdrachtgever de verwachting te wekken dat hij deze versie van de software geleverd gaat krijgen. Daar kan ik me ook wel iets bij voorstellen overigens. De status van dit document is echter kennelijk nooit echt duidelijk vastgesteld, waardoor het is gaan “zweven”. Dat keert zich tegen de opdrachtgever, nu in het contract alleen versie 1.0 van het FO is vermeld.

Verder heeft de opdrachtgever zich kennelijk niet gerealiseerd hoe de in het contract opgenomen acceptatieprocedure zich tegen hem zou kunnen keren. Een acceptatieperiode van maximaal twee weken is nu eenmaal niet zo lang. Ook de aanname dat het uitblijven van bezwaren acceptatie impliceert is niet gunstig voor de opdrachtgever. Het is echter wel opgenomen in het contract en je moet dus van ver komen om met succes voor de rechter te kunnen betogen dat die contractsbepaling vanwege de onredelijkheid of op grond van onvoorziene omstandigheden buiten toepassing dient te blijven. Het staat er toch immers niet voor niets?

Wat het meest tegen de opdrachtgever lijkt te werken is echter dat de applicatie al in de praktijk in gebruik was. De overeenkomst leek uit te gaan van een eenvoudige volgorde: eerst maken, dan pas gebruiken. In de praktijk ontstond echter een hele andere volgorde: gedurende het maken al in gebruik nemen van de software. Wellicht lagen aan dat alles wel (nadere) afspraken ten grondslag, maar dat kon kennelijk niet goed voor het Hof worden bewezen. Het lijkt er ook op alsof er bij/vanwege dat gebruik ook allerlei nieuwe wensen op kwamen voor functionaliteiten. Wellicht dat hierover wel met de leverancier is gesproken, maar ook dit kon dan kennelijk niet worden bewezen.

De grote lijn die uit de uitspraak volgt is dan ook: bedenk vooraf goed wat je in een contract zet, houd je vervolgens aan het contract en documenteer eventuele overeenstemming over wijzigingen op het contract zeer zorgvuldig.

  • LinkedIn
  • Facebook
  • Twitter
  • Google Plus
  • del.icio.us
  • email
  • PDF
  • Print
Naar boven scrollen