Onlangs berichtten we al over de komst van DORA. DORA stelt allerlei eisen aan financiële entiteiten op het gebied digitale operationele weerbaarheid, cyberrisico’s en uitbestedingsrisico’s. Ook IT-contracten moeten straks dankzij DORA aan strenge eisen voldoen. Zowel op financiële entiteiten als IT-bedrijven die daar diensten aan verlenen komt veel af. In deze blog staan we hier alvast bij stil.
Begint uw klant steeds meer en steeds gedetailleerdere controlevragen te stellen over de status van het project? Krijgt u van uw leverancier te horen dat dit soort vragen veel te veel tijd kost en ten koste gaat van het halen van de beloofde go-live datum? Kan uw leverancier wederom geen inzicht geven in de stand van zaken van het project? Gefeliciteerd (cynisch), uw IT-project is aan het ontsporen. Hoe zet u uw project weer op de rails? In dit blog geef ik een aantal tips om dit om te draaien en om te voorkomen.
Agile-projecten gaan uit van een stapsgewijze ontwikkeling of implementatie van software. In korte ‘sprints’ van tussen de 2 en 4 weken wordt door teams van de leverancier en afnemer samengewerkt om snel stappen voorwaarts te zetten. Per sprint wordt vooraf vastgelegd wat er in de sprint gerealiseerd moet worden. En als dat niet geheel lukt dan wordt een en ander in een andere of volgende sprint alsnog opgepakt. In de praktijk leidt deze manier van werken nog wel eens tot discussie en geschillen omdat een project uitloopt in tijd of het budget opraakt zonder dat het beoogde eindstation is bereikt. In een recente kwestie moest het Hof Arnhem-Leeuwarden oordelen over een dergelijk geschil. Daarbij komt het hof tot een opmerkelijk oordeel, althans opmerkelijk in een Agile-context.
In de meeste SLA’s staan beschikbaarheidsperscentages (99,99% per maand/jaar) en reactietijden bij incidenten centraal. Tegenwoordig lezen we ook over XLA’s waarin de vraag centraal staat hoe de klant de dienstverlening ervaart (X van eXperience). Dat is al beter maar gaat wat mij betreft niet ver genoeg. Bij SaaS diensten zou de continuïteit van dienstverlening voor de afnemer centraal moeten staan: een CSLA dus (C van continuïteit). In deze bijdrage ga pleit ik voor een andere benadering van SLA’s met focus op continuïteit van dienstverlening in plaats van beschikbaarheid en andere reactieve service levels en geef ik 4 tips hoe je dit aan kunt pakken.
Momenteel worden door steeds meer organisaties lopende IT-contracten tegen het licht gehouden. Dit kan te maken hebben met het noodzakelijkerwijs moeten snijden in kosten, maar net zo goed kan het gaan om het wijzigingen van functionaliteiten of tooling (bijvoorbeeld snel implementeren en uitrollen van Microsoft Teams of Zoom om online vergaderingen te houden). Passen de afspraken daar nog wel bij ? Ligt de focus nog goed? Kan ik snijden in de kosten? In deze blog geef ik 5 praktische tips hoe je dit zou kunnen aanvliegen. Er kan meer dan u denkt.
Stel een afnemer en een IT-leverancier spreken af dat een softwaresysteem uiterlijk over een half jaar wordt opgeleverd (op 31 december 2011 om precies te zijn). De leverancier laat begin december weten dat het hem niet voor 31 december gaat lukken. De afnemer besluit om direct over te gaan tot ontbinding van de overeenkomst omdat hij uit de mededeling mocht afleiden dat de fatale termijn niet zou worden gehaald. Heeft de afnemer de overeenkomst met succes ontbonden?
De duur van een overeenkomst is een belangrijk onderwerp bij contractonderhandelingen, niet in de minste plaats omdat hier vaak kortingen aan verbonden kunnen worden. Overeenkomsten kunnen voor bepaalde en onbepaalde tijd worden aangegaan. Wat zijn de voor- en nadelen van dergelijke afspraken? Verder kunnen overeenkomsten op meerdere manieren worden beëindigd, bijvoorbeeld door opzegging of door ontbinding. Waarom is het zo van belang om hier een duidelijk en juist onderscheid in te maken? In deze bijdrage wordt op deze vragen ingegaan.
Als je een IT-contract sluit tot de levering of terbeschikkingstelling van bijvoorbeeld een website of software is het belangrijk na te denken over de intellectuele eigendomsrechten. Het auteursrecht is veruit het belangrijkste intellectuele eigendomsrecht om software te beschermen. Op het moment dat je hiertoe niets regelt, komen de rechten aan de ontwikkelaar toe. Met name in geval van maatwerksoftware kan dit verstrekkende gevolgen voor de afnemer hebben: zo mag je niets (laten) wijzigen en kan je zelfs gedwongen worden te stoppen met het gebruik van de software. Het is dan ook belangrijk de intellectuele eigendomsrechten contractueel goed te regelen. In dit blog ga ik in op de contractuele afspraken omtrent intellectuele eigendomsrechten. Hierbij komen zowel de vermogensrechtelijke handelingen als enkele andere belangrijke regelingen aan bod. Ik sluit af met enkele praktische tips.
Binnen IT-contracten is garantie een veelbesproken en bediscussieerd onderwerp. Het overeenkomen van garanties geschiedt immers in het spanningsveld tussen de belangen van de leverancier enerzijds en de belangen van de afnemer anderzijds. In dit blog ga ik in op wat een garantie eigenlijk is, waarna ik een aantal veelvoorkomende garanties behandel.
In het vorige artikel zijn wij ingegaan op duur en beëindiging van de overeenkomst. In dit artikel ga ik in op de praktische gevolgen van een beëindiging van een overeenkomst. Het komt in onze praktijk met enige regelmaat voor: een IT-contract voor een essentieel softwarepakket wordt opgezegd en vervolgens blijkt dat de leverancier niet zonder meer (lees: niet zonder meerkosten) wil meewerken aan het teruggeven van de data of een overstap naar een opvolgende leverancier. Vaak wordt gedacht dat je een leverancier, zeker als het gaat om essentiële software, te allen tijde kunt dwingen om mee te werken aan een dergelijke overstap of aan teruggave van data. Dit is echter niet zo. Deze problematiek is te verhelpen door het opnemen van een goede exitregeling in het IT-contract waarin vermeld staat hoe partijen moeten handelen nadat het contract is opgezegd. In dit artikel geef ik enkele praktische handvatten voor het opstellen van een adequate exitregeling.
IT-contracten kunnen snel een internationaal karakter hebben doordat bijvoorbeeld wordt gecontracteerd met een buitenlandse softwareleverancier en/of dat de hosting van de SaaS-applicatie buiten Nederland plaatsvindt. In veel contracten worden dan (terecht) afspraken gemaakt over welk recht van toepassing is op de overeenkomst en ook waar eventuele geschillen kunnen worden voorgelegd (rechter, arbiter).
Goede aansturing en contractmanagement zijn van uitermate groot belang bij een IT-project. Lees verder hoe je dit kunt vormgeven.
