Contracten maken is een ambacht. In eerder blogs heb ik geschreven over de kernvragen die je in elk IT-contract moet kunnen beantwoorden (
de formule voor een goed (IT-)contract: W+W+W+H+K). Bij complexere opdrachten is echter minstens zo belangrijk dat je in kaart brengt welke risico’s er zijn en die mitigeert. Maar hoe doe je dat? In dit blog enkele praktische handvatten voor het doen van risicoanalyses en een concreet voorbeeld.
Toen ik laatst tijdens een seminar over IT-geschillen (voorkomen en genezen) bij het behandelen van dit onderwerp aan de zaal (100 personen) vroeg wie van de aanwezigen bij het opstellen van een contract wel eens een risicoanalyse had uitgevoerd, stak welgeteld 1 persoon zijn hand op. Dit verbaast niet, maar viel wel tegen. Natuurlijk is dit geen representatief onderzoek, maar dit sluit wel aan bij wat ik in mijn praktijk zie: er wordt veel te weinig aandacht besteed aan het adresseren van risico's. Hier is snel winst te behalen. Maar wat moet je doen en wat vooral niet? Laat ik met het laatste beginnen.
Het volgende werkt in mijn ervaring niet. Let op: dit is geen limitatieve lijst.
Om te beginnen moet je je gezond en kritisch verstand blijven gebruiken. Ga te werk aan de hand van de trechter techniek: begin breed (algemeen) en werk gestructureerd naar smal (specifiek) toe. Een stappenplan dat je hier bij kan helpen is de volgende:
Hieronder treft u een (fictief) voorbeeld aan van een project waarbij eerst software wordt ontwikkeld en daarna in de cloud wordt gehost en dus op afstand ter beschikking wordt gesteld (SaaS). Hieronder wordt een schaal toegepast van 1-5, waarbij 3 staat voor een normaal risico en impact niveau. Dit betekent dat als de prioriteit hoger is van 9 er extra aandacht moet zijn voor die risico’s. Onder de 9 betekent niet dat er geen actie nodig is, maar geeft aan dat er wellicht minder nadruk nodig is, al hangt dit natuurlijk wel af van het desbetreffende risico.
Het moge duidelijk zijn dat het van de concrete omstandigheden van het geval afhangt welke risico’s er spelen en hoe je die waardeert. In bovenstaand voorbeeld is het kennelijk niet heel erg als er vertraging ontstaat. Dit kan uiteraard ook anders zijn.
Waar men zich wel van bewust moet zijn is dat dergelijke risicoanalyses wel meetellen juridisch. In geval van een geschil over de niet-tijdige oplevering, kan een rechter zich wel afvragen wat je al hebt voorzien aan tegenmaatregelen en gaan onderzoeken in hoeverre die gevolgd zijn. Als je die overeengekomen route niet volgt kan dat ertoe leiden dat de rechter geen tekortkoming aanmerkt.
De kritische lezer hoor ik denken: dit geldt toch niet alleen voor IT-contracten. Nee, zeker niet. Eigenlijk zou je dergelijke analyses ook kunnen (moeten) toepassen bij andersoortige contracten. Punt bij IT is alleen dat er tegenwoordig zoveel van afhankelijk is. Er zijn tegelijkertijd ook IT-producten en -diensten te bedenken waar een dergelijke uitgebreide risico-inventarisatie wellicht wat te veel van het goede voor is. Die afweging moet u zelf maken.
Ernst-Jan van de Pas, advocaat IT-recht
Toen ik laatst tijdens een seminar over IT-geschillen (voorkomen en genezen) bij het behandelen van dit onderwerp aan de zaal (100 personen) vroeg wie van de aanwezigen bij het opstellen van een contract wel eens een risicoanalyse had uitgevoerd, stak welgeteld 1 persoon zijn hand op. Dit verbaast niet, maar viel wel tegen. Natuurlijk is dit geen representatief onderzoek, maar dit sluit wel aan bij wat ik in mijn praktijk zie: er wordt veel te weinig aandacht besteed aan het adresseren van risico's. Hier is snel winst te behalen. Maar wat moet je doen en wat vooral niet? Laat ik met het laatste beginnen.
Wat werkt niet?
Het volgende werkt in mijn ervaring niet. Let op: dit is geen limitatieve lijst.
- Alle mogelijke risico’s willen dichttimmeren in een contract: Is simpelweg onmogelijk. Je kunt niet alles van tevoren inschatten, maar wat je wel kunt (moet) doen is die onwenselijke situaties die wel voorzienbaar zijn, adresseren. Een goed contract moet duidelijk zijn als het gaat om wat, wanneer, door wie, hoe en tegen welke kosten wordt geleverd, maar een goed contract moet partijen daarnaast wel de nodige bewegingsruimte geven om dat allemaal te kunnen bereiden. Een te strak keurslijf, is wachten op problemen. Een te strak keurslijf is bovendien jammer omdat je dan geen optimaal gebruik maakt van de expertise van je contractpartij. Richt je dus op de belangrijkste risico’s en gun elkaar ook wel de ruimte. Deze balans zoeken is de uitdaging voor de contractenmaker.
- Direct overgaan tot adressering van risico’s: Hierdoor staar je je vaak blind op bepaalde risico’s en vergeet je risico’s die minstens net zo belangrijk zijn. Stel eerst vast wat je precies gaat doen en koppel daar de risico’s aan vast. Aan een SaaS-systeem hangen andere risico’s (meer) vast dan aan een lokale installatie; hetzelfde geldt voor software ontwikkelen via Agile of waterval. Het maakt wat uit of je te maken hebt met een eenvoudige levering van hardware of software of dat dit een project is van meerdere maanden of zelfs jaren waarbij verantwoordelijkheden moeten worden verdeeld, etc.
- Zoek de oplossing niet in boetes, garanties en aansprakelijkheid: dit zijn geen oplossingen voor risico’s. Boetes zijn ofwel gefixeerde schadevergoedingen dan wel (meestal) financiële prikkels die aanzetten tot tijdige nakoming. Garanties onderstrepen de importantie van een bepaalde verplichting (en schakelen soms een beroep op overmacht uit, tenzij dit weer wordt overruled door een algemene overmachtbepaling). De aansprakelijkheidsbepaling is een restbepaling voor alle risico’s die met goed fatsoen niet zijn te redresseren met concrete praktische oplossingen. Die rest-risico’s moet je dan onderling verdelen. Hierbij zou je eerst moeten kijken in hoeverre die risico’s verzekerbaar zijn. Wat dan nog overblijft moet je onderling zien te verdelen door aansprakelijkheid uit te sluiten of te beperken. Let op: Bij een uitsluiting van aansprakelijkheid door de leverancier komen die risico’s volledig voor rekening van de afnemer. Bij een beperking tot een bepaald bedrag verdeel je dat risico onderling (tot het bedrag = risico leverancier; daarboven = risico afnemer.)
Hoe pak je het dan wel aan?
Om te beginnen moet je je gezond en kritisch verstand blijven gebruiken. Ga te werk aan de hand van de trechter techniek: begin breed (algemeen) en werk gestructureerd naar smal (specifiek) toe. Een stappenplan dat je hier bij kan helpen is de volgende:
- Stap 1: Wat ga je doen? IT-contracten soms lastig te typeren:
- Gaat het om de koop/huur/lease van hardware?
- Gaat het (ook) om de installatie en implementatie van standaard software (klassieke licentie of SaaS/PaaS/IaaS)?
- Gaat het (ook) om de ontwikkeling van software? Volgens welke methodiek? (waterval of Agile/Scrum of een hybride vorm hiervan? Wordt er open source software gebruikt en zo ja tegen welke OSS licentievoorwaarden?
- Gaat het (ook) om dienstverlening: beheer en onderhoud, trainingen, implementatie; tijdelijk inhuur mensen; outsourcing?
- Andere relevante vragen: in welke context ga je een en ander doen? Je kunt je voorstellen dat bij de implementatie van een Ziekenhuis Informatie Systeem (ZIS/EPD) in een ziekenhuis weer andere risico sferen gelden als bij de implementatie van een ERP systeem bij een logistiek dienstverlener. Beide systemen zijn bedrijfskritisch.
- Stap 2. Breng de fases van het contract in kaart:
- Fase 1: Softwareontwikkeling: hoe ga je dat doen: via waterval methodiek of Agile/Scrum?
- Fase 2: Implementatie: vertraging; duurder; anders dan verwacht
- Fase 3: Gebruiksfase / onderhoudsfase
- Fase 4: Einde overeenkomst: medewerking overstap
- Stap 3: Wat zijn de belangrijkste voorzienbare risico’s: deze zijn uiteraard afhankelijk van wat er precies gaat gebeuren. Het is hier van belang dat je even een doemdenker wordt. Doorloop de verschillende fases van het contract en stel je zelf de “wat als”- vraag. Pas wel op dat je geen spijkers op laagwater gaat zoeken. Je kunt een contract niet volledig dichttimmeren, dat moet je ook niet willen omdat er voor beide partijen bewegingsruimte moet zijn. Richt je dus op de majeure risico’s.
- Stap 4: Impactanalyse (kans * impact = prioriteit) toepassen: zie voorbeeld hierna.
- Stap 5: Prioriteiten sorteren (hoog laag) en tegenmaatregelen overeenkomen: Om deze laatste stap is het natuurlijk allemaal te doen bij een risicoanalyse. De prioritering is een handig middel om vast te stellen of je je wel aan het richten bent op de juiste risico’s. Wellicht ben je tegenmaatregelen aan het verzinnen voor een risico waarvan de kans veel te laag is en kun je energie en geld (!) beter besteden aan andere risico’s.
Voorbeeld van impactanalyse (stap 4 en 5)
Hieronder treft u een (fictief) voorbeeld aan van een project waarbij eerst software wordt ontwikkeld en daarna in de cloud wordt gehost en dus op afstand ter beschikking wordt gesteld (SaaS). Hieronder wordt een schaal toegepast van 1-5, waarbij 3 staat voor een normaal risico en impact niveau. Dit betekent dat als de prioriteit hoger is van 9 er extra aandacht moet zijn voor die risico’s. Onder de 9 betekent niet dat er geen actie nodig is, maar geeft aan dat er wellicht minder nadruk nodig is, al hangt dit natuurlijk wel af van het desbetreffende risico.
| Voorbeeld van risico impactanalyse | ||||
| Fase 1 – Risico’s ontwikkeling | Kans (1-5) | Impact (1-5) | Prioriteit(9 med) | Tegenmaatregel |
| Uitloop tijd | 4 | 2 | 8 | Helder plan van aanpak met duidelijke planning en tussentijdse oplever-/evaluatiemomenten; aanwijzen projectleider die bevoegd is tot sturing/ingrijpen, eventueel termijn met boete versterken. |
| Niet krijgen wat je wilde | 3 | 5 | 15 | Afnemer zelf heel kritisch zijn in wat hij nodig heeft en wil bereiken (programma van eisen). Doelstellingen vertalen naar heldere scope en planning. Plan van aanpak opstellen waarin scope aan planning gekoppeld wordt. Als je nog niet goed genoeg weet wat je wilt, eerste fase inrichten om dit helder te krijgen door opstellen blauwdruk/projectplan. Hierin ook een exit-mogelijkheid inbouwen. Netjes afrekenen met leverancier. |
| Fase 2 – SaaS | ||||
| Systeem niet beschikbaar | 3 | 5 | 15 | Uitwijkmogelijkheid inbouwen, als server 1 niet beschikbaar is overstappen op server 2 die standby staat. |
| Dataverlies/ -corruptie |
2 | 5 | 10 | Adequate backup-regeling. Wellicht backup in huis houden om grip te houden op eigen data. |
| Leverancier wil niet meewerken bij exit | 1 | 4 | 4 | Exit-regeling optuigen: meewerken aan overstap tegen redelijke vergoeding; verplichting tot afgifte van data in algemeen gangbaar bestandsformaat of database met databasemodel; voor de zekerheid verlengde licentie (pro rato) voor geval overstap niet tijdig mogelijk blijkt. |
| Etcetera | ||||
Het moge duidelijk zijn dat het van de concrete omstandigheden van het geval afhangt welke risico’s er spelen en hoe je die waardeert. In bovenstaand voorbeeld is het kennelijk niet heel erg als er vertraging ontstaat. Dit kan uiteraard ook anders zijn.
Waar men zich wel van bewust moet zijn is dat dergelijke risicoanalyses wel meetellen juridisch. In geval van een geschil over de niet-tijdige oplevering, kan een rechter zich wel afvragen wat je al hebt voorzien aan tegenmaatregelen en gaan onderzoeken in hoeverre die gevolgd zijn. Als je die overeengekomen route niet volgt kan dat ertoe leiden dat de rechter geen tekortkoming aanmerkt.
De kritische lezer hoor ik denken: dit geldt toch niet alleen voor IT-contracten. Nee, zeker niet. Eigenlijk zou je dergelijke analyses ook kunnen (moeten) toepassen bij andersoortige contracten. Punt bij IT is alleen dat er tegenwoordig zoveel van afhankelijk is. Er zijn tegelijkertijd ook IT-producten en -diensten te bedenken waar een dergelijke uitgebreide risico-inventarisatie wellicht wat te veel van het goede voor is. Die afweging moet u zelf maken.
Ernst-Jan van de Pas, advocaat IT-recht
Gerelateerd
IT
