zijn arbit-contracten te managen?
Deze zomer zijn de Algemene Rijksvoorwaarden bij IT-Overeenkomsten (ARBIT) door de Ministerraad goedgekeurd en in werking getreden. De Algemene Rijksvoorwaarden bij IT-Overeenkomsten (ARBIT) onderschrijven het belang van zorgvuldig contractmanagement. Maar wordt zorgvuldig contractmanagement ook door de ARBIT mogelijk gemaakt? Een korte beschouwing gevolgd door aanbevelingen vanuit de praktijk.
Wat zijn ARBIT-contracten?
De ARBIT vormen een set algemene inkoopvoorwaarden die de Rijksoverheid hanteert bij het contracteren van IT-producten en diensten in de markt. In het oog springende projecten – P-Direct, Elektronisch Patiëntendossier (EPD )– hebben geleid tot verhoogde aandacht voor thema’s zoals de inrichting van goed opdrachtgeverschap, IT-governance en regie op uitbesteding. In de ‘Toelichting bij de ARBIT’ wordt de aandacht gevestigd op het belang van zorgvuldig contractmanagement. De invoering van de ARBIT roept dan ook de vraag op of de ARBIT zorgvuldig contractmanagement faciliteren.
Wat is contractmanagement?
Contractmanagement bestaat uit de maatregelen gericht op het deugdelijk en naar tevredenheid uitvoeren van een contract met het oog op de te bereiken doelen. Dat kan bestaan uit het bewaken van de kwaliteit van de diensten, het realiseren van targets en termijnen, het gecontroleerd doorvoeren van wijzigingen in de overeenkomst en het tijdig identificeren en oplossen van problemen in de dienstverlening of in de relatie met de andere contractspartij(en).
ARBIT in vogelvlucht
De ARBIT zijn ten dele de opvolger van de BIZA-modelcontracten waarvan de laatste versie dateert uit 1995. In de ARBIT worden rechten en verplichtingen tussen de contractspartijen in afwijking van of in aanvulling op de wet geregeld. De ARBIT bestaan uit een deel Algemene Bepalingen en vier delen met Bijzondere bepalingen met betrekking tot Koop, Gebruiksrechten, Onderhoud en Opdrachten. In de ARBIT worden onderwerpen geregeld zoals de overdracht van intellectuele eigendomsrechten indien een prestatie (zoals de software) specifiek voor opdrachtgever wordt ontworpen, de reikwijdte van verstrekte gebruiksrechten, garanties, acceptatie, betaling, meerwerk, beëindiging van de overeenkomst en aansprakelijkheid van de leverancier. De ARBIT dienen primair de belangen van de contracterende overheid en werpen op onderdelen (ernstige) beletsels op voor contractspartijen. Zo bepalen de ARBIT dat de aansprakelijkheid van de leverancier contractueel beperkt wordt tot een bedrag van ten hoogste viermaal de hoogte van de vergoeding per aanspraak. Bij een contract voor een totale duur van 5 jaren met een contractswaarde van € 1 miljoen per jaar (dus in totaal € 5 miljoen) zou dat kunnen betekenen dat de limitering bij iedere aanspraak ligt bij € 20 miljoen. Voor veel leveranciers is dat – los van de daadwerkelijke kans op een dergelijke claim en schadeomvang – een moeilijk of niet te verzekeren risico en in zijn algemeenheid een brug te ver. Ook de verregaande advies- en waarschuwingsplicht die de ARBIT op de schouders van de leverancier leggen, ook voor omstandigheden die vooral in de sfeer van de opdrachtgever liggen, maakt een opdracht aanmerkelijk risicovoller en de kans op aansprakelijkheid groter. Hieronder een drietal van de knelpunten uit oogpunt van de uitvoering van contracten gesloten onder toepasselijkheid van de ARBIT.
Escaleren doe je met elkaar en niet alleen
Wie de dagelijkse praktijk van de uitvoering van contracten kent weet dat de problemen zich veelal op operationeel niveau voordoen: Op de werkvloer lopen medewerkers vast omdat zij tegen een issue aanlopen dat buiten hun beslissingsbevoegdheid valt bijvoorbeeld een deliverable die te laat dreigt te worden opgeleverd of een service die onder de afgesproken norm scoort. Deze melding zal via de project- of servicemanager bij de contractmanager terecht komen. De contractmanager van de opdrachtgever spreekt de contractmanager van de leverancier hierop aan. Als zij binnen de grenzen van het contract en hun beslissingsbevoegdheid geen oplossing weten te vinden zullen zij moeten escaleren. Een andere situatie die bij de contractmanagers terecht kan komen is bijvoorbeeld een onduidelijkheid in de toepassing van tarieven in een specifieke situatie Wanneer het contract niet eenduidig is (en dat komt nog wel eens voor) zal in onderling overleg een oplossing gevonden moeten worden. Artikel 2.3 bepaald dat partijen dienen te beschikken over een interne escalatieprocedure. Dat helpt in deze gevallen echter niet want het issue moet opgelost worden met de externe partij, de leverancier. Op een andere niveau dient het probleem besproken en opgelost te worden namelijk daar waar voldoende beslissingsbevoegdheid ligt in relatie tot het ontstane issue. Escaleren is dan ook niet negatief maar een normale manier om een issue op het juiste niveau in de organisatie op te lossen. De mogelijkheid om te escaleren is een belangrijk element voor goed contractmanagement.
Wijzigen van de overeenkomst
Het is een bekend verschijnsel: de inkt op het contract is nog niet droog of nieuwe wensen en voortschrijdend inzicht leiden tot wijzigingen en soms een herdefiniëring van uitgangspunten die aan de basis lagen van het contract. Partijen moeten periodiek op contractniveau overleg voeren, wijzigingen signaleren, onduidelijkheden oplossen en dan volgens een vaste procedure de nodige (nieuwe) afspraken maken. De contractmanager houdt daarvoor een Dossier Afspraken en Procedures (DAP) bij, waarin namens beide partijen door de daartoe aangewezen personen geldige afspraken worden gemaakt. Tot slot: wie heeft welke rol en wat zijn per rol de verantwoordelijkheden en bevoegdheden? Zijn bijvoorbeeld de door medewerkers op de werkvloer gedane toezeggingen bindend of niet? Wie mag wijzigingen goedkeuren: de contracteigenaar, de contractmanager of de projectmanager? Wie mag service levels die afwijken van de overeenkomst, accepteren? De ARBIT bieden geen duidelijkheid over de bevoegdheid tot wijziging van een overeenkomst. Het tegendeel is het geval. In artikel 2.2. wordt uitdrukkelijk bepaald “contactpersonen kunnen partijen alleen vertegenwoordigen en binden voor zover het betreft de uitvoering van de Overeenkomst. Tot wijziging van de Overeenkomst zijn zij niet bevoegd”. Significant punt is echter dat de ARBIT vervolgens niet duidelijk maken wie dan wel bevoegd is of op welke wijze welke de noodzakelijke wijzigingen dan wel op een goede manier tot stand kunnen komen. Het belang daarvan is evident. De oplossing echter ontbreekt. Met betrekking tot meerwerk (artikel 14.4) is bepaald dat meerwerk niet voor vergoeding in aanmerking komt dan na instemming van Opdrachtgever. Alleen wie vertegenwoordig de Opdrachtgever? Maar afwachten dus.
Exit en ontvlechting
Het regelen van de exit wordt bij IT-overeenkomsten soms vergeten en vaak onderschat. Het belang is echter groot. Zeker bij langdurige projecten en meerjarige contracten voor dienstverlening (zoals de outsourcing van IT-beheer en ontwikkeling). Recente rechtspraak over de geschillen na beëindiging van de werkzaamheden bij Bank Insinger de Beaufort en de exitperikelen bij Telfort tonen aan hoe precair de situatie voor een opdrachtgever kan zijn indien leverancier en opdrachtgever afscheid van elkaar nemen en een retransitie nodig is. Bij beëindiging van de overeenkomst liggen de belangen plots heel anders en zijn afspraken veel moeilijker te maken dan bij aanvang of gedurende de looptijd. De leverancier heeft doorgaans geen belang bij een exit. De verhouding tussen de partijen wordt verder scheefgetrokken doordat een feitelijke afhankelijkheid is ontstaan en de opdrachtgever grip zal moeten krijgen op de continuïteit. In de ARBIT is slechts een algemene en daarmee moeilijk te handhaven medewerkingsverplichting van de leverancier opgenomen (exitclausule artikel 32). Juist bij de exit zal echter op voorhand, dus bij contractering, het fundament dienen te worden gelegd voor een ordentelijke ontvlechting. Beter is dan om te bepalen dat reeds bij aanvang een concept-exitplan dient te worden opgeleverd dat de belangrijke onderwerpen omvat die aan de orde zullen zijn zoals software, licenties, overeenkomsten met derden, activa en medewerkers. Daarmee kunnen kwetsbaarheden in kaart worden gebracht. Verder zal het periodiek dienen te worden bijgesteld zodat de exit een proces wordt dat, al naar gelang de noodzaak of wenselijkheid, meer of minder intensief kan worden gemanaged. Een effectieve manier kan zijn om reeds tussendoor aanvullende afspraken te maken. Bijvoorbeeld dat licentie en onderhoud van een applicatie ook na beëindiging van de overeenkomst inzake het IT-beheer onder gelijke voorwaarden en tarieven zal plaatsvinden of dat door de leverancier nieuw aangeschafte apparatuur bij exit zal worden overgenomen tegen een bepaalde prijs of overeenkomstig een bepaald mechanisme om die prijs te bepalen.
Afronding en aanbevelingen
Contracten dienen na sluiting te worden gemanaged en de basis hiervoor ligt in de contracten. Bij contractering op basis van de ARBIT is het raadzaam om Bij het hanteren van de ARBIT is het, naast de gebruikelijk maatregelen, aan te bevelen om een regeling uit te werken waarbij op meerdere niveaus van contact met hun bevoegdheden te definiëren: minimaal het operationele niveau, het contractmanagementniveau en een escalatieniveau. De bevoegdheid tot wijziging dient veel meer handen en voeten te worden gegeven. Een exitregeling dient in de overeenkomst tussen reeds te zijn opgenomen en die dient concrete kapstokken te bieden om de exit te zijner tijd te faciliteren.
Dit artikel is een opiniebijdrage in de Computable van 3 december 2010 met als titel Contractmanagement met ARBIT is geen sinecure. De bijdrage vindt u hier in pdf.