De onderhoudsovereenkomst als vrijbrief om prutswerk te leveren

| AE 2544 | Intellectuele rechten | 8 reacties

Een lezer vroeg me:

Als ik producten inkoop, dan mag ik verwachten dat die voldoen aan de gestelde eisen. Doen ze dat niet, dan gaan ze retour en dan krijg ik vervanging of herstel. Volkomen logisch lijkt me; je koopt iets en dan moet je dat ook krijgen. Maar bij software lijkt dat allemaal anders te liggen. Je vraagt om bepaalde functionaliteit, je krijgt iets dat er een beetje op lijkt maar vol zit met fouten – maar als je die hersteld wilt hebben dan moet je een onderhoudscontract afnemen, oftewel elke maand betalen in de hoop dat je op zeker moment krijgt wat je zoekt. Waarom kan dat zomaar, juridisch?

Dat kan vooral omdat iedereen het accepteert.

Hoofdregel is dat je bij elke overeenkomst recht hebt op nakoming op de manier die je mocht verwachten. Of het nu gaat om levering van een product of van een dienst (zoals ontwikkelen van software), er zijn afspraken en de leverancier moet die nakomen. Doet hij dat niet, dan is het wanprestatie.

Bij software-ontwikkeling is het zeer gebruikelijk om af te spreken (via niet-onderhandelbare clausules in algemene voorwaarden van leveranciers) dat de software zonder garantie komt en dat je maar moet hopen dat het werkt. Een wederpartij die dat accepteert, zit daar aan vast. En ja dat mag, een bedrijf is vrij om af te spreken dat ze veel geld betaalt zonder kwaliteit te hoeven verwachten. (Dit geldt óók voor producten trouwens, je mag als bedrijf je aanspraak op garantie of conformiteit ‘wegtekenen’ als je dat wilt.)

Vorig jaar oordeelde het Gerechtshof dat standaardsoftware als ‘zaak’ aangemerkt kan worden, waarmee je in principe langs dezelfde weg als bij producten kunt eisen dat fouten hersteld of vervangen worden. De Europese Commissie wil een dergelijke aanpak wettelijk vastleggen. Maar dat zal dan alleen voor consumenten gelden, voor bedrijven zal het mogelijk blijven om hiervan af te wijken.

Natuurlijk kun je als bedrijf prima eisen dat je wél kwaliteit krijgt, bijvoorbeeld via een uitgebreide acceptatietest of gratis onderhoud op alle fouten die je binnen $X maanden na levering ontdekt. Ook dat is onderdeel van dat vrije mogen afspreken. Wat er uiteindelijk wordt besloten, hangt dus af van hoe stevig de partijen kunnen onderhandelen.

Dit voorjaar kwam de Hoge Raad met een arrest over melkmachines, dat ook voor ICT-dienstverlening relevant kan zijn. (Met dank aan ITenRecht.) Er waren melkrobots geleverd, maar de robots bleken niet goed te werken. De storingen (“voortdurende stroom van klachten”) bleken zo erg dat de klanten gingen klagen, en op zeker moment zelfs kortingen gingen opleggen vanwege de slechte kwaliteit van de melk. Ook liep een aantal koeien uierontsteking op, wat het bedrijf weet aan de slechte kwaliteit van de machines.

Er was een onderhoudsovereenkomst: 24/7 beschikbaarheid van een storingsmonteur voor ” 5.000 per jaar plus kosten per bezoek. En die monteur kwam ook wel, maar een definitieve oplossing bleek niet te kunnen worden gevonden. Het bedrijf ontbond op zeker moment de overeenkomst wegens wanprestatie, waar de leverancier bezwaar tegen maakte. Er was toch een onderhoudsovereenkomst? Daarmee was elke fout gedekt.

De Hoge Raad gaat daar niet in mee, omdat

het systeem ten gevolge van de herhaalde storingen telkens een of meer uren, oplopend tot een of meerdere dagdelen, plat ligt, hetgeen een aanzienlijk negatieve invloed op de bedrijfsvoering (welzijn van de koeien en kwaliteit van de melk) heeft, hetgeen [verweerder] niet behoefde te verwachten.

Het moest daarmee de leverancier duidelijk zijn dat er iets serieus mis was met het systeem. En dat de klant dan op zeker moment er genoeg van heeft, had hij ook moeten begrijpen.

Dat partijen tevens een onderhoudsovereenkomst hadden gesloten op grond waarvan [eiser] verplicht was tot herstel over te gaan, staat aan dat oordeel niet in de weg.

De klant mocht dus de overeenkomst opzeggen wegens wanprestatie, ondanks de onderhoudsovereenkomst en de daarbij behorende afspraken over herstel van fouten. Volkomen terecht, lijkt me.

Arnoud

Deel dit artikel

  1. Klinkt als mijn UPC zakelijk abonnement met garantie dat er binnen 4 uur een monteur op locatie is. Die bleven ook onvermoeibaar monteurs sturen die dan (netjes binnen 4 uur kwamen en) weer hoofdschuddend weggingen.

    Overigens stond daar wel in de welkomstbrief dat we konden rekenen op 99% beschikbaarheid (hetgeen later als foutje-van-marketing werd afgedaan bij mijn beroep op nonconformiteit…).

    Ere wie ere toekomt, na een moeizame aanloop van 5 maanden werkt het inmiddels al weer jarenlang perfect.

  2. Wat vaak vergeten wordt bij software, is dat het ontwikkelen van software extreem veel werk-uren nodig heeft indien een ontwikkelaar alles zelf moet bouwen. Dat gaat gewoon niet meer! Ontwikkelaars zijn tegenwoordig enorm afhankelijk van modules van derden en moeten daarbij ook vaak nog zien dat ze die modulen correct in elkaar kunnen passen. Daarnaast is er een enorme variatie aan configuraties “in het wild” en is het niet mogelijk om overal rekening mee te houden. Cyrillische software op een japanse Windows-versie? Het moet kunnen maar je krijgt de raarste situaties indien bepaalde taalpakketten ontbreken. Maar ook meer eenvoudige configuraie-problemen kunnen voorkomen. Bijvoorbeeld gebruikers die enkele fonts hebben gedeinstalleerd omdat ze die toch niet gebruiken. Of bedrijven die Chrome of Firefox gebruiken en daarbij alle Internet Explorer componenten hebben uitgeschakeld. Of het meest voorkomende probleem: bedrijven die een proxy-server gebruiken die dusdanig is geconfigureerd dat er vrijwel geen verbinding naar buiten mogelijk is. Da’s eigenlijk een der vervelendste dingen bij software: bied je de mogelijkheid dat de software automatisch updates binnenhaalt, is dat bij een bedrijf niet mogelijk omdat de proxyserver en firewall alles tegenhoudt!

    Zelfs de software voor een blog zoals dit heeft de nodige bugs. Daarnaast is het ook nog eens dusdanig geconfigureerd dat enkele letter-combinaties (vooral PHP code) hier geblokkeerd wordt. En daarnaast zijn er altijd mensen die zullen klagen over wat dit forum niet kan. Ik noem maar een [target=”_blank”] optie bij url’s. 🙂 Maar dergelijke foutjes worden gewoon geaccepteert omdat iedereen wel beseft dat foutvrije software gewoon niet haalbaar is voor een goede prijs. Het maken van de software kan wel redelijk snel maar het vervolgens testen onder diverse condities met verschillende configuraties en taalinstellingen kost dusdanig veel test-uren dat het goedkoper is om een deel van deze tests gewoon door de gebruikers te laten doen. Dus als je software koopt help je tevens mee aan de ontwikkeling van betere versies indien je alle problemen in de software netjes en duidelijk rapporteert aan de makers. 🙂 In ruil voor die hulp krijg je een royale korting aangeboden op de prijs van de software indien deze 100% bugvrij zou zijn. 🙂 Echt, dat prijsverschil is enorm. Je zou er de staatsschuld van Griekenland mee af kunnen betalen en dan nog genoeg overhebben voor Portugal en Italie…

  3. Volgens mij ligt er ook een verantwoordelijkheid bij de klant (als het om maatwerksoftware gaat). Deze moet de software testen voordat zij deze accepteert. En mijn ervaring leert dat er nauwelijks getest wordt, tuurlijk wordt er doorheen geklikt, maar testen op inhoudelijke juistheid gebeurt nauwelijks.

    Als leverancier is het niet haalbaar om na zoveel tijd nog steeds bereid te zijn om wijzigingen aan te brengen (onbetaald). Daarbij lever je als leverancier een product met afhankelijkheden waar je als leverancier nauwelijks controle op kan uitoefenen. Zie de voorbeelden van Wim.

  4. Dat is het inderdaad, het kan allemaal wel bugvrij en EXACT volgens specificatie, maar dan kost het heel veel meer geld en tijd. Als NASA een Voyager ofzo op pad stuurt dan reken maar dat die software heel veel beter werkt en HEEEL veel duurder was dan een PC pakketje.

    In de dagelijkse IT praktijk moet het natuurlijk gisteren af zijn en vlot een beetje want de marketing afdeling is al bijna klaar en de campagne start morgen.

    Het grootste struikelblok van het eerste scenario is misschien nog wel die specificatie, ik moet de eerste klant nog tegenkomen die EXACT tot in details weet wat en hoe ‘ie het wil…

    Dus in de praktijk begin je te werken met een vage spec vol onbekenden en doe je je best om te maken wat je denkt dat ze bedoelen, veilig in de wetenschap dat het toch nog wel verandert voor je klaar bent. En zo draai je een beetje rond tot het resultaat voor beide partijen acceptabel is…

  5. @Wim, in mijn vakgebied (machinebesturing) is het gebruikelijk dat de software “gewoon werkt”. Dat betekent dat je als leverancier de nodige aandacht besteed aan de kwaliteit van je software (en de keuze van platform en bibliotheken.) We hebben het wat makkelijker omdat we ook hardware en besturingssysteem leveren (en alleen ondersteunen wat we geleverd hebben.) Ik ben erg conservatief waar het gaat om het kiezen van ontwikkelomgevingen en bibliotheken; juist omdat de software goed moet werken. Het najagen van fouten in een bibliotheek is enorm tijdrovend (en die tijd kan ik beter besteden…)

    @Keeees: een deel van mijn werk is op papier te zetten wat de klant nu echt wil (in overleg met de klant natuurlijk.) Het is daarbij vaak belangrijker om de “workflow” goed te specificeren dan user interface details. Exact is niet nodig, maar alle belangrijke aspecten moeten op papier staan voordat je gaat coderen. En de software is onderdeel van de acceptatietest van het apparaat, de klant kan daar altijd zijn opmerkingen maken.

  6. @Wim. Je bent wel heel vlot met het probleem bij je klanten te leggen. Als die problemen die jij noemt zo veelvoorkomend en fnuikend voor de juiste werking zijn dan is het aan jou als ontwikkelaar om daar een goede checklist voor te ontwikkelen en die problemen in kaart te brengen voor je aan het werk gaat. Ofwel een dekkende lijst van benodigde hulpbronnen op te stellen zodat de klant zelf kan checken of zijn systeem voldoet. En natuurlijk zal die lijst in het begin niet dekkend zijn maar als je elke nieuwe omissie toe blijft voegen dan kom je vanzelf steeds beter in de buurt.

    Aan de andere kant zijn klanten ook vaak te gemakzuchtig en nemen ze veel te veel voor lief. Als jij een belangrijk stuk gereedschap voor je bedrijfsvoering koopt dan moet je vooraf wel bedingen dat het aantoonbaar werkt vóór je de rekening betaalt. En houdt je in als klant en ga niet halverwege het project de scope of de specificaties wijzigen want dan geef je meteen een vrijbrief om de planning zo ver te wijzigen als de ontwikkelaar maar wil.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS