business.telenet.be - De pijnpunten van het softwarecontract

De software die u bij de gespecialiseerde firma bestelde, doet niet echt wat u ervan verwacht. Het project ligt achter op het tijdsschema of u moet voor elke nieuwe versie fors in de geldbuidel tasten. En alles druist in tegen eerdere afspraken. Een goed doordacht contract kan uw leven heel wat vergemakkelijken. En het zal u op zijn minst helpen in uw uiteindelijke betoog voor een of andere rechtbank, vermits de rechter bij het opstellen van zo''n contract de ultieme toetssteen is. Ook al is procederen duur, tijdrovend en dus eerder zeldzaam.
Een IT-verantwoordelijke of projectleider is vaker betrokken bij het opstellen van contracten dan hem lief is. Ook bij softwareprojecten is dit het geval, want een waterdicht contract kan hem later veel ellende en geld besparen. Ellende die zich overigens situeert rond een aantal vaak voorkomende pijnpunten. We zetten er vier op een rijtje:

1. Inschatting van de concrete IT-behoeften

"Het pakket doet niet helemaal wat we ervan verwachtten."

Software heeft weinig zin als het uiteindelijke resultaat niet of niet helemaal is wat de opdrachtgever verwachtte, en er dus niet is voldaan aan de oorspronkelijke behoeften. Om dergelijke problemen te voorkomen, raden juristen vaak aan om de verantwoordelijkheid van de behoefteanalyse bij de leverancier te leggen en hem te laten instaan voor het inventariseren van de behoeften en de functionele en technische analyse. Dit uiteraard in nauw overleg met de klant. U zal voor dit werk weliswaar in veel gevallen moeten betalen, maar de zekerheid neemt toe dat het uiteindelijke resultaat beter of helemaal aansluit bij wat u er als klant op voorhand van verwachtte.

Ook op het vlak van de concrete omvang van het IT-project komen bedrijven meer dan eens voor verrassingen te staan. Er gaapt vaak een diepe kloof tussen wat tijdens een voorbereidend verkoopsgesprek aan de man wordt gebracht en het uiteindelijke resultaat. Het komt er dus op aan om, als het nodig is, deze beloften op papier te hebben en bij te houden. Koopt u een standaard softwarepakket, dan kan u steeds een beroep doen op de reclamefolder van de leverancier. Gaat het om software die u op maat laat ontwikkelen, dan verzoekt u uw leverancier op voorhand om u op papier een beschrijving te bezorgen van alles wat het toekomstige softwarepakket zal kunnen. Vaak wordt aangeraden om ook zoveel mogelijk briefwisseling met de leverancier te bewaren, zoals nota''s, offertes, e-mails en verslagen van vergaderingen. Alles wat maar kan aantonen dat de oorspronkelijke beloften niet zijn ingelost.

2. Timing van het project

"Het project loopt hopeloos achter op schema."

Misschien wel het allergrootste probleem dat bij softwareprojecten opduikt. Tot voor een paar jaar was het uitlopen van een ontwikkelingsproject eerder regel dan uitzondering. Nu gaat het iets beter. Voor het bedrijf dat uiteindelijk op de afgewerkte versie rekent, en er op die manier dus afhankelijk van is, blijft zo''n vertraging een serieuze streep door de rekening. Meer dan eens vatten leveranciers bij aanvang van een softwareproject de koe stevig bij de horens, om het na verloop van tijd wat rustiger aan te doen en de aandacht helemaal te laten verslappen. In veel gevallen blijft een project wat aanmodderen of wordt het nooit echt helemaal afgewerkt.

In de praktijk zijn er twee keuzes die u contractueel kan afdwingen om de timing van uw project toch min of meer binnen de perken te houden. Ten eerste is er de zogenaamde milestone aanpak. Hierbij verdeelt u het ontwikkelingsproject over verschillende modules. Zodra één module is afgewerkt, volgt de facturatie. De laatste facturatie gebeurt slechts na de definitieve aanvaarding van het project. Voorschotten worden zoveel mogelijk vermeden. Een tweede aanpak, de resultaatsverbintenis inzake opleverdatum, zoals die in het juridisch jargon wordt omschreven, leunt hier een beetje bij aan. Hierbij richt u zich op een finale opleverdatum waarop heel het pakket klaar moet zijn. Pas op die bewuste datum betaalt de klant het belangrijkste deel van de factuur. Ideaal is een combinatie van milestones en opleverdatum, al valt dit in de praktijk moeilijk te hard te maken in de onderhandelingen met de leverancier.

Heel wat klanten hebben de neiging om in het contract met de leverancier boetes op te leggen als deze laatste de opgestelde timing aan zijn laars lapt. Een logische maatregel, al mag zo''n vertragingsboete niet worden aanzien als straf. (Alleen de overheid mag in ons land een straf opleggen.) Als een ondernemer zo''n vertragingsboete opneemt in de schriftelijke overeenkomst, dan moet die in overeenstemming zijn met de geleden schade. Buitensporige boetes zal u dus nooit kunnen afdwingen van uw leverancier, vermits hier geen wettelijke grond voor is.

3. Waarborgen en garanties

"Het pakket werkt niet op onze Windows 98."

Een klant moet ook de nodige waarborgen krijgen opdat de ontwikkelde software voldoet aan zijn noden. Waarborgen dat de software conform is met de oorspronkelijke analyse of documentatie, maar ook beantwoordt aan prestatie- en functionele eisen van de klant. Bijvoorbeeld: het boekhoudpakket dat u liet maken of aankocht, moet niet alleen een jaarafsluiting tot een goed einde kunnen brengen, het mag ook geen half uur duren vooraleer een berekening is afgewerkt. U voegt dus best in het contract een clausule toe die stelt dat de programma''s moeten functioneren in overeenstemming met de verwachtingen van u als klant.

Een andere nuttige formulering is de waarborg dat de software moet functioneren op de bestaande hardware- en softwarevoorzieningen in uw bedrijf, en niet alleen in de omgeving van de leverancier. Overigens een vaak voorkomend twistpunt.

Iets wat ook af en toe uit het oog wordt verloren, is de formulering waarin staat dat de klant kan genieten van intellectuele en andere eigendomsrechten. Met andere woorden: uw leverancier staat zelf in voor de gevolgen indien hij onrechtmatige of namaaksoftware zou hebben aangeboden.

4. Ondersteuning

"Mijn leverancier is failliet. Wat nu?"

Een softwareprogramma is maar een begin. De echte gebruikswaarde ervan hangt ook af van de latere ondersteuning. Probeer contractueel vast te leggen dat u, zonder al teveel bijkomende kosten, ook van volgende versies van de software kan genieten. Of stel ineens een onderhoudsovereenkomst op voor een vaste prijs. Zo vermijdt u dat u later voor verrassingen komt te staan.

Sommige klanten proberen contractueel ook de broncode van de software in hun bezit te krijgen, al is dit vaak onmogelijk. Een goed idee is bovendien het escrow-principe: plaats uw broncode bij een derde partij (vaak gewoon een notaris). Gaat uw leverancier failliet of in gerechtelijk akkoord, dan kan u hier een beroep op doen. Op uw ter ziele gegane leverancier zal u helaas niet meer kunnen rekenen, maar met behulp van een goed informaticus kan u in elk geval toch nog even verder.

Dit artikel kwam tot stand met de medewerking van Benny Backx, advocaat bij Declerck & Van Mierlo Advocaten.

business.telenet.be - De pijnpunten van het softwarecontract ^ TOP

21-07-03 - 00:05:57 - - item printen - item mailen

-

Comments

Reageer