Contracten

Bij de aanschaf van standaard software en/of de opdracht tot (aanvullend) maatwerk komen een groot aantal aspecten aan de orde. Het kan geen kwaad om de aspecten met meerdere leveranciers te bespreken. Het zal opvallen, dat elke leverancier andere onderwerpen onbesproken laat in vrijblijvende aanbiedingen.
Er zijn grote verschillen tussen interne en externe leveranciers. Het aansprakelijk stellen bij calamiteiten en bij afwijkingen van de overeen- komst biedt bij interne leveranciers (automatiserings-afdelingen) veel minder mogelijkheid op verhaal van schade. Interne opdrachten binnen (grote) organisaties vergen een overeenkomst tussen betrokken afdelingen. Hierbij spreekt men dan meestal van een projectplan en/of een produktbeschrijving. In het onderstaande wordt uitgegaan van een relatie met externe leveranciers.

Uw aanvraag tot offerte kunt u altijd vergezeld laten gaan van uw leveringsvoorwaarden. Deze zullen (door het feit van overdracht bij het eerste contact) bij geschillen 'harder meetellen' dan de leveringsvoorwaarden van uw leverancier (tenzij u daar in een later stadium schriftelijk van af ziet). De leverancier zal zich met zijn leveringsvoorwaarden altijd meer indekken tegen leverings-risico's dan u lief is.

In het verlengde van het overdragen van gebruiksrechten ligt de garantie, dat de software zal werken zoals beschreven. Het kan zeer verhelderend werken, als niet de opgeleverde software zelf, maar het doel, waarom de software wordt aangeschaft, centraal staat bij de overeenkomst. Naar alle partijen toe is dan duidelijk dat de effectiviteit van het project centraal staat en niet de oplevering van de software sec.

Een overeenkomst hoort te beginnen met een beschrijving van het onderwerp van de overeenkomst, voorafgegaan door een aantal definities van begrippen en direct gevolgd door de looptijd van de overeenkomst.

Sommige leveranciers vragen ook voor het doen van offerte een vergoeding. U kunt zich hiervoor bij voorbaat vrijwaren in de aanvraag voor het uitbrengen van offerte. Een proef-installatie moet zonder verdere gevolgen voor de afnemer tot ontbinding van een (voorlopige) overeenkomst tot aanschaf van de software kunnen leiden. In de overeenkomst dient altijd een bepaling voor te komen over de beeindiging van de looptijd van de overeenkomst. Bij een standaard pakket zonder aanvullend maatwerk zal de looptijd beperkt worden tot een overdrachtsmo- ment, gecombineerd met een onderhoudscontract met een 'oneindige' looptijd en een wederzijdse opzegmogelijkheid.

Een overeenkomstvorm kan zijn dat met het gebruiksrecht ook het recht van zelfstandige aanpassing (aanvullend maatwerk in eigen beheer) kan worden verkregen. In dat geval dienen ook de 'sources' te worden overgedragen aan de afnemer. Vaker komt voor, dat men de sources niet verkrijgt, maar alleen een gebruiksrecht van een specifieke versie. In dat geval kan men zich verzekeren van continuiteit door de sources bij een onafhankelijke partij te bewaren. Bij faillissement van de leverancier (of bij beeindiging van onderhoud van een versie) kan zo alsnog over deze sources beschikt worden (escrow-bepaling).

Ook kunt u vastleggen, dat nieuwe versies niet verplicht na een bepaalde tijd aangeschaft moeten worden. Dit is wat anders, dan het recht van de leverancier om een bepaalde versie niet langer te ondersteunen, bijvoorbeeld drie jaar na het verschijnen van een nieuwe versie, volgend op de laatst aangekochte versie.

Veel software maakt gebruik van een 'database-engine' of iets dergelijks. Vaak is een dergelijke engine reeds in de organisatie in gebruik, maar dat hoeft niet het geval te zijn. Waar het op neer komt, is dat de aangeboden software wel mogelijkheden heeft om zijn eigen informatie goed te verwerken, maar dat de 'kast', waarin de informatie wordt opgeslagen, niet in de prijs is inbegrepen. Vraag dus aan een leverancier, wat het totale bedrag is, dat voor deze toepassing uit uw bedrijfskas verdwijnt. Maak de leverancier voor dat bedrag verantwoordelijk in het contract.

Leveranciers kunnen de levering van hard- en software scheiden. Maak uw leverancier verantwoordelijk voor het totale project! Dit kan geregeld worden door de softwareleverancier hoofdaannemer te laten zijn.

Waak voor aanbiedingen, die alleen de oplevering/overdracht van de software regelen en niet de daaropvolgende implementatie! Bij het aangaan van een overeenkomst dient een implementatie-planning ingebouwd te worden. De financiele gevolgen van wederzijdse vertragingen (software opleveren versus het in gebruik kunnen nemen van de software) dienen goed beschreven te worden. Bij de uitvoering van een project (en met name bij de implementatie) is een vaste projectleider onontbeerlijk. Leg de betreffende namen vast in het contract met een aanmerkelijk bedrag als boete.

Bij geschillen/arbitrage is doorgaans de 'menselijke factor' een belangrijk gegeven. Vele geschillen zijn op te lossen met enig overleg. Het is zaak om geschillen niet te laten groeien tot niet omkeerbare processen. In een overeenkomst kunnen hiervoor voorzieningen worden getroffen.

Overeenkomsten eindigen meestal met een bepaling, waar eventuele geschil- len juridisch kunnen worden behandeld (bij welke rechtbank e.d.). Om reistijd te voorkomen en om te vermijden, dat u in de jungle van een buitenlands rechtsstelsel verzand, kunnen een paar standaardbepalingen dienaangaande veel ellende voorkomen.

Met betrekking tot overeenkomsten zijn nog veel meer opties mogelijk. Hierboven is slechts een beperkte opsomming gegeven.