Toepassen van de ARBIT

Toepassen xxx xx XXXXX

Xxxxx xxx ’x Xxxxxx is advocaat bij Xxxxxxxxx Xx Xxxxxx Advocaten, Amsterdam Citeersuggestie: F. van ’t Geloof, Toepassen van de ARBIT, IT 324, 20 april 2011.

De Algemene Rijksvoorwaarden bij IT overeenkomsten (ARBIT) uit 2010 zijn al meerdere malen becommentarieerd. Soms worden ze als tamelijk evenwichtig beschouwd, vooral als ze vergeleken worden met de BiZa modelcontracten die daarvoor gebruikt werden. Soms worden ze echter negatief beoordeeld.

Het is niet zonder meer duidelijk waarvoor de ARBIT nu precies wel en niet zijn bedoeld. Vooral het perspectief van waaruit ze beschouwd worden is van belang bij de beoordeling van de voorwaarden. Daarom wordt hieronder eerst vastgesteld voor welke overeenkomsten de ARBIT toepasbaar zijn. Daarna worden een aantal bepalingen beschouwd binnen het veronderstelde toepassingsgebied.

Toepassingsgebied voor de ARBIT

ARBIT is een acroniem voor “Algemene Rijksvoorwaarden bij IT-overeenkomsten”. Het is dus van toepassing op IT overeenkomsten. Artikel 1 geeft een aantal omschrijvingen van gebruikte begrippen. De definitie van een IT overeenkomst ontbreekt echter. De reikwijdte van de ARBIT is daardoor niet formeel afgebakend. In de toelichting staat hierover:

De ARBIT zijn vooral bedoeld voor modale IT- inkopen door de overheid en niet zozeer voor grote en bijzondere IT-projecten. Dat neemt niet weg dat ze ook dan als uitgangspunt voor het opzetten van een meer specifieke contractuele relatie met de IT markt kunnen dienen. Vanwege de flexibiliteit van de Overeenkomst kan deze veelal ook gebruikt worden bij de inzet van specifieke IT-producten en diensten zoals bijvoorbeeld webhosting of SaaS (software as a service). Een zorgvuldige specifieke omschrijving van zo’n nieuw product of dienst moet dan worden opgenomen in artikel 2 van de Overeenkomst. Daarna kunnen de ARBIT, die zoveel mogelijk techniekonafhankelijk zijn geschreven, ook daarop in beginsel gewoon van toepassing worden verklaard. De combinatie van ARBIT en Overeenkomst kan daarmee een solide basis

vormen voor IT -contractering in de komende jaren. Overigens worden dergelijke specifieke IT-diensten vooralsnog niet beschouwd als ‘commodities’ waarvoor de ARBIT in de eerste plaats zijn bedoeld (zie de Algemene inleiding van deze Toelichting). Mocht uit evaluaties van de ARBIT blijken dat dergelijke thema’s hier toch meer specifiek aandacht verdienen, dan zal dat op een later tijdstip alsnog gebeuren.”

[… ] Voor afwijkingen van de ARBIT of het al dan niet (mede) van toepassing verklaren van andere (algemene) voorwaarden kan slechts in uitzonderingssituaties aanleiding bestaan. Meestal verdient het echter ook dan aanbeveling om de ARBIT wel naast en ter aanvulling op die andere algemene voorwaarden van toepassing te verklaren.[……] [accent toegevoegd]

Uit bovenstaande blijkt dat de ARBIT bedoeld zijn voor ‘commodity’-achtige IT diensten en producten. SaaS diensten (Software as a Service, ofwel ‘cloud computing’) vallen daar vooralsnog niet onder, evenals grote en bijzondere projecten. Om meer te kunnen zeggen over wat in deze context ‘grote en bijzonder projecten’ zijn, moeten de ARBIT nader inhoudelijk worden beschouwd. De ARBIT bestaan uit een algemeen deel en vier specifieke delen. De bedoeling is dat steeds alle delen van toepassing worden verklaard. Het derde deel met bijzondere bepalingen is voor ‘opdrachten’.

Daaronder vallen onder meer: Adviesdiensten ontwikkeling maatwerkprogrammatuur leiding geven aan IT projecten.

Kennelijk gaan de opstellers van de ARBIT ervan uit dat adviesdiensten commodities kunnen zijn. Dat ligt op het eerste gezicht niet voor de hand. Een commodity is een eenvormig massaproduct, met een voorspelbare inhoud. Advies is alleen nuttig als van tevoren niet bekend is wat de inhoud van het advies is. Hieronder is uitgewerkt hoe deze twee schijnbaar tegenstrijdige begrippen inwerken op de toepasbaarheid va de ARBIT. Daaruit volgt tevens wat moet worden verstaan

onder ‘IT projecten’ waaraan in bovenstaande opsomming leiding gegeven kan worden.

Wat in de automatiseringsbranche onder ‘adviesdiensten’ wordt verstaan varieert sterk van aard. Vaak worden dienstverleners die werk uitvoeren ten behoeve van een klant ’consultants’ genoemd. Bijvoorbeeld programmeurs en systeemanalisten. Strikt genomen zijn dat geen adviseurs. Zij nemen wel beslissingen voor de klant op uitvoerend niveau, maar adviseren de klant daar niet over. Toch is het gebruikelijk dit wel als adviesdiensten aan te merken. Met wat goede wil kunnen deze diensten als “adviesdiensten met een commodity-karakter” worden gezien. Daar tegenover staan bijvoorbeeld adviezen waarin strategische scenario’s voor operationele bedrijfsvoering van een onderneming voor de komende tien jaar worden afgewogen. De operationele organisatie van veel ondernemingen hangt sterk af van automatiseringsmogelijkheden. In gevallen als dit betreft het ook zuiver adviezen, want de klant wint deze adviezen in om zelf een goede beslissing te kunnen nemen. Deze adviezen zijn complex en uniek, en dus geen commodity.

Adviesdiensten maken niet zelden een integraal onderdeel uit van automatiseringsprojecten. Als de opdrachtgever tijdens het project keuzes moet maken naar aanleiding van adviesdiensten, kunnen die keuzes zijn bedrijfsvoering en het project beïnvloeden. Projecten waarin dat aan de orde is, lenen zich niet voor toepassing van de ARBIT. De ARBIT laten nauwelijks ruimte voor een verantwoordelijkheidsverdeling die recht doet aan de belangrijke rol die een opdrachtgever speelt in dergelijke projecten. Een professioneel leverancier aanvaardt geen aansprakelijkheid voor projectverantwoordelijkheden van de klant.

Artikel 55 is het derde en laatste artikel dat onder het hoofdje ‘adviesdiensten’ staat, en bepaalt dat de relevante fasen van een project in de overeenkomst moeten worden benoemd, evenals de fatale termijn per fase. Het begrip ‘fatale termijn ‘ betekent dat overschrijding ervan automatisch leidt tot verzuim van de leverancier. Dat geeft de opdrachtgever bevoegdheden tot het verhalen van schade en het opschorten en ontbinden van de overeenkomst. Hieruit volgt dat projecten waarvan de op te leveren prestatie volledig kan worden beschreven, waardoor een leverancier bij de uitvoering onafhankelijk is van de opdrachtgever, op deze basis kunnen worden

uitgevoerd. Voor projecten die afhankelijk zijn van de opdrachtgever is deze bepaling ongeschikt. Artikel 55 kan dus alleen werken voor ‘commodity’ IT overeenkomsten, en is zo een voorbeeld van een bepaling die het toepassingsgebied van de ARBIT impliceert.

Enkele artikelen uit de ARBIT nader beschouwd

De ARBIT worden hierna beschouwd binnen het kader waarvoor ze bedoeld zijn. Onderstaande analyses gaan er van uit dat sprake is van IT overeenkomsten voor goederen en diensten waarvan de inhoud vooraf volledig is bepaald.

Onderzoeksplicht

Artikel 4 legt de leverancier een onderzoeksplicht op. De opdrachtgever hoeft volgens dit artikel alleen informatie aan de leverancier te verstrekken. Het commune contractenrecht voorziet in een genuanceerde balans van wederzijdse onderzoeksplichten bij het aangaan van overeenkomsten. De ARBIT sluiten deze onderzoeksplicht van de opdrachtgever niet uit. De opdrachtgever houdt dus een onderzoeksplicht. Een voorbeeldje: Een ministerie bestelt 10 PC’s, en krijgt die geleverd. Bij een poging deze PC’s als servers in te zetten, blijkt dat ze daarvoor niet geschikt zijn. Hier geldt een eigen onderzoeksplicht van het ministerie, of de ARBIT nu gelden of niet. Anders ligt dat als een welomschreven servercapaciteit gevraagd zou zijn. Dan moet de leverancier eerst punten die niet helemaal duidelijk zijn navragen, en daarna een geschikte aanbieding doen. Als de aanbieding niet aan blijkt te sluiten bij het gevraagde, is dat de verantwoordelijkheid van de leverancier. Dat is zo, of de ARBIT van toepassing zijn of niet. Het artikel verheldert wellicht de verwachtingen van het Rijk, maar heeft juridisch niet veel effect.

Vervangen van personeel

In de artikelen 5 en 22 krijgt de opdrachtgever een vergaande bevoegdheid in te grijpen op een project door vervanging van personeel te verlangen. Daarvoor moet wel een reden zijn. Als achteraf blijkt dat voor een dergelijke ingreep geen goede reden bestond, dan moet de leverancier dat aantonen, en hij moet bewijzen dat door dat ongerechtvaardigde ingrijpen meerkosten en vertragingen zijn ontstaan. Van een opdrachtgever die direct ingrijpt op de wijze waarop

een uitbestede dienst wordt uitgevoerd, zou op zijn minst verwacht mogen worden dat deze zelf actief verantwoording aflegt voor zijn ingrijpen. De ARBIT regelen dat niet de ingrijpende opdrachtgever iets hoeft te verantwoorden, maar dat de leverancier moet aantonen dat het ingrijpen niet te verantwoorden was, iets wat buitengewoon lastig zal zijn. De leverancier wordt hiermee in een kwetsbare positie gebracht.

Intellectuele eigendom

Artikel 8 voorziet er kort gezegd in dat de intellectuele eigendom van speciaal voor de opdrachtgever gemaakte software bij die opdrachtgever ligt. Voor leveranciers is dat natuurlijk niet altijd even plezierig, maar het is duidelijk.

Het artikel gaat diep in op het feit dat persoonlijkheidsrechten bij de opdrachtgever moeten komen te liggen. Voor auteursrecht gerelateerde persoonlijkheidsrechten kan dit, maar voor octrooirecht gerelateerde persoonlijkheidsrechten is deze bepaling nietig (art 14 ROW). De leverancier moet zorgen dat zijn personeel bij voorbaat afstand doet van persoonlijkheidsrechten, en daar zelf ook bij voorbaat afstand van doen. De ARBIT bepaalt daarover dat de opdrachtnemer bij voorbaat een onherroepelijke volmacht verstrekt aan de opdrachtgever. In de huidige stand van het recht wordt een dergelijke bepaling in algemene voorwaarden vermoed onredelijk bezwarend te zijn. Persoonlijkheidsrechten zullen bij softwareontwikkeling niet snel een dispuut opleveren, maar het is toch jammer dat de overheid bepalingen opneemt die deels nietig en deels normaal gesproken als onredelijk worden beschouwd.

Garanties

Artikel 12 verlangt garanties van de leverancier. Deze lijken binnen het toepassingsgebied niet onredelijk, en zijn deels verzekerbaar. De garantie van vijf jaar onderhoud is iets om even goed op te letten. Voor levering van bijvoorbeeld smartphones lijkt mij dat vijf jaar wel erg lang is. Een leverancier moet dan goed opletten deze termijn in de overeenkomst expliciet te verkorten.

Gebruiksrechten

De bijzondere bepalingen gebruiksrechten betreffen voorwaarden bij de aanschaf van programmatuur. Het is de vraag of standaardsoftware werkelijk onder deze

voorwaarden aangeschaft kan worden. Het is niet gebruikelijk dat een leverancier van standaard software onderhandelt over de te verstrekken gebruiksrechten. Een standaardsoftwareleverancier zal niet graag aan versieregels van een klant gebonden zijn. Voor iedere klant zou dan een ander ontwikkelbeleid gevoerd moeten worden. Het voordeel van standaardsoftware is juist dat de leverancier een eigen eenduidig ontwikkelbeleid hanteert, waar alle klanten baat bij hebben. Men zou verwachten dat een Rijksoverheid juist geen zaken zou willen doen met een standaardsoftwareleverancier die zijn versiebeleid en ontwikkelingsstrategie afstemt op de wensen van één klant.

Hersteltermijnen

Met betrekking tot de oplevering van maatwerkprogrammatuur is in artikel 58.6 bepaald dat, als er gebreken worden geconstateerd bij de acceptatietest, die binnen een door de opdrachtgever vast te stellen redelijke termijn opgelost moeten worden. Als dat niet lukt mag de opdrachtgever zelf voor correctie zorgen op kosten van de leverancier. Deze bepaling levert een wat onevenwichtige situatie op. Wat voor de opdrachtgever een redelijke termijn lijkt, kan voor degene die het moet realiseren een onmogelijke termijn zijn. Voor de opdrachtnemer zal het echter niet eenvoudig zijn aan te tonen dat de door de opdrachtgever gestelde termijn onredelijk is. Dat betekent dat de opdrachtnemer bij een fout tijdens de oplevering de controle kwijt is. Het laten oplossen van fouten door een derde, in bij die derde vooraf onbekende programmatuur, zal vaak duur zijn. De situatie kan op eenvoudige wijze verbeterd worden, namelijk door te verlangen dat de opdrachtgever een motiveringsplicht krijgt bij het stellen van een termijn als hier bedoeld.

Tweede oplevering moet foutloos

Het recht om de overeenkomst te ontbinden als bij de tweede test nog steeds fouten geconstateerd worden, is een erg rigoureus middel. Zelfs bij uitgesproken degelijk testen kan een matig ingewikkeld stuk programmatuur in een tweede acceptatietest nog gemakkelijk fouten bevatten. Bijvoorbeeld: een systeem bevat 20 parameters met gemiddeld 4 verschillende waarden. Dat levert 4 tot de macht 20 combinaties op, wat 1600 miljard combinaties oplevert. Van een dergelijk matig complex systeem zijn niet alle combinaties uit te testen. Temeer niet, omdat

als een fout hersteld wordt, in beginsel alle combinaties opnieuw getest moeten worden. In dit licht is de algemene regel dat fouten in een tweede test het recht geeft tot ontbinding van de overeenkomst, is in veel gevallen niet redelijk. Een dergelijk recht schept een situatie waarin de opdrachtgever op niet gedwongen is zich redelijk op te stellen. Hoewel er best situaties te bedenken zijn waarin deze bepaling redelijk is, is dat bij maatwerkontwikkeling vaak niet het geval. Leveranciers dienen er dus alert op te zijn hierover in de overeenkomst zelf het nodige op te nemen, en opdrachtgevers dienen er bedacht op te zijn dat een zorgvuldig leverancier dit zal verlangen.

Jaarlijkse controle

Volgens de bijzondere bepalingen over onderhoud moet de opdrachtnemer minstens één keer per jaar controleren of de geleverde prestatie goed functioneert. Bij applicaties waarbij disfunctioneren niet onmiddellijk opgemerkt wordt, wil je waarschijnlijk vaker controleren dan één keer per jaar, terwijl in andere gevallen een periodieke controle gewoon niet nuttig is. Partijen doen er beiden verstandig aan erop te letten afspraken hierover standaard in de overeenkomst op te nemen.

Fatale termijnen

Opdrachtnemers moeten zich bij het sluiten van een overeenkomst bewust zijn dat artikel 76.2 bepaalt dat Functiehersteltermijnen en Reactietijden gelden als fatale termijnen. Zij moeten dus niet lichtvaardig afgesproken worden. Als een opdrachtnemer niet zeker is die termijnen en tijden te realiseren, dan moet hij ze niet afspreken.

Onderhoud bevat innovatief onderhoud

Artikel 82 bevat een opmerkelijke formulering: als de opdrachtgever dat wenst, omvat het onderhoud ook innovatief onderhoud. Artikel 84 werkt de inhoud van innovatief onderhoud nader uit: Onder de ARBIT bestaat een standaard onderhoudsovereenkomst tevens uit nieuwe versies. Bij pakketsoftware is dat gebruikelijk, maar bij maatwerksoftware niet. Deze artikelen leggen de opdrachtnemer van maatwerk op dat hij onder het onderhoudscontracten nieuwe versies moet ontwikkelen als de opdrachtgever dat wenst. Dat dit als ‘onderhoud’ is aangemerkt, valt moeilijk te begrijpen. Immers, innovatief onderhoud op

maatwerk is kostbaar. Het is alleen gewenst als daarvoor een uitgesproken reden bestaat, en zou om die redenen expliciet afgesproken moeten worden. Vooral de leverancier moet er alert op zijn prijsafspraken hierover specifiek te regelen in de overeenkomst. Doet hij dat niet, dan kan hij in de toekomst onverwacht substantieel meer verplichtingen onder het onderhoudscontract blijken te hebben dan hij verwachtte.

Overigens is het maar de vraag of de verplichting nieuwe versies te leveren op maatwerksoftware geen kernbeding betreft, en daardoor geen algemene voorwaarde is, maar in de overeenkomst ze3lf moet zijn opgenomen. Het zal in een onderhoudscontract in veel gevallen de hoofdprestatie zijn die de leverancier moet leveren. Als in de overeenkomst niets verder is opgenomen, en de opdrachtgever zou een beroep willen doen op deze bepaling, dan zal al snel onenigheid ontstaan over wat wel en niet onder het begrip innovatief onderhoud moet worden verstaan in een specifiek geval.

Samenvatting

De ARBIT zijn voor het grootste deel prima toepasbaar op ‘commodity’ IT diensten en producten. De ARBIT zijn niet bedoeld en niet geschikt voor een project waarin de opdrachtgever het project inhoudelijk sterk beïnvloedt. Dat is bijvoorbeeld het geval bij veel zakelijke automatiseringsprojecten. Toepassing van de ARBIT in dergelijke gevallen zal het risico op een mislukt project vergroten door de verstorende werking van de ARBIT op een evenwichtige verdeling van verantwoordelijkheden tussen opdrachtgever en leverancier.

Binnen de categorie IT overeenkomsten waarvoor de ARBIT bedoeld zijn, zijn enkele kanttekeningen te maken bij de ARBIT. Een aanbestedende instantie dient alert te zijn dat leveranciers onderstaande punten in de relevante gevallen onderkennen en ter discussie stellen. Doet een leverancier dat niet, dan kan dat aanleiding zijn vraagtekens bij de professionaliteit van die leverancier te zetten.

De kracht van standaardsoftware zit hem in de mogelijkheid voor veel klanten tegelijk software te ontwikkelen en gestandaardiseerd uit te brengen. De ARBIT regelen het versiebeheer van standaardsoftwareleveranciers. Een opdrachtgever moet zich ernstig afvragen of hij een

standaardsoftwareleverancier wil die de kern van zijn bedrijfsvoering, namelijk het versiebeheer van zijn software, aanpast aan één klant, omdat die klant dat verlangt in zijn inkoopvoorwaarden. In beginsel is dat geen goed idee.

De leverancier wordt door de ARBIT op twee manieren in een kwetsbare positie voor willekeur van een opdrachtgever gebracht. De eerste is dat de opdrachtgever personeel van de opdrachtnemer kan doen vervangen, zonder daarvoor zelf consequenties te hoeven dragen. Een deugdelijke verantwoording door de opdrachtgever voor een dergelijk ingrijpen zou op zijn plaats zijn. De tweede is dat de opdrachtgever de overeenkomst mag ontbinden als in een tweede acceptatietest nog fouten gevonden worden. Bij maatwerkontwikkeling van enige omvang zal deze bevoegdheid bijna zeker ontstaan, ongeachte de kwaliteit van de leverancier. De opdrachtgever mag daardoor dergelijke overeenkomsten vaak in een laat stadium ontbinden, met behoud van recht op schadevergoeding. Het gevolg van ontbinding voor de opdrachtnemer is dat hij alle ontvangen vergoedingen onder de overeenkomst moet terugbetalen, plus eventuele schadevergoeding. Een professionele opdrachtnemer zal een dergelijk risico niet accepteren.

De toepasbaarheid van een aantal bepalingen in de ARBIT is sterk afhankelijk van de aard van de in te kopen producten of diensten. Dit geldt voor de garantieperiode van vijf jaar, dat onderhoud per definitie inhoudt dat de geleverde prestatie één keer per jaar door de leverancier moet worden gecontroleerd, en dat innovatief onderhoud standaard binnen het begrip ‘onderhoud’ valt. Zowel opdrachtgevers als leveranciers moeten er alert op zijn deze punten altijd in de overeenkomst zelf te regelen. Gebeurt dat niet, dan kunnen de ARBIT ongewenste situaties in het leven roepen, en, vooral voor leveranciers, ook onverwachte verplichtingen.

Conclusie

De ARBIT zijn alleen bedoeld voor IT producten en diensten waarvan het resultaat vooraf in detail bekend is. Voor diensten waarbij dat niet het geval is, moeten zijn niet worden toegepast. Als dat wel gebeurt, roept dat voor de opdrachtgever serieuze risico’s in het leven. De kans op een succes zal afnemen door de mismatch tussen verantwoordelijkheden en aansprakelijkheden. Een leverancier die in een

dergelijk geval de XXXXX accepteert, verdient enige argwaan.

Binnen het toepassingsgebied bevatten de ARBIT een aantal bepalingen waar vooral de leveranciers iedere keer bij stil moeten staan. Zo nodig moeten zij ervoor zorgen dat die bepalingen in de overeenkomst genuanceerd worden. Opdrachtgevers doen er goed aan leveranciers die dat nalaten met reserves te beschouwen, omdat dergelijk nalaten niet van een professionele houding getuigt.