Zonder dat je het door hebt bestaan veel platforms en software die door bedrijven en instellingen worden gebruikt geheel of (vaker) gedeeltelijk uit open source software. Veel afnemers van dergelijke producten vinden dat eng en zijn daar op tegen. Ook investeerders schrikken vaak af als ze horen dat er sprake is van OSS. Maar is dat terecht? Nee. In dit artikel staan wij stil bij enkele misvattingen over OSS.
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.
IT-storingen zijn uitermate hinderlijk. In een recente zaak voor het hof Leeuwarden stond de vraag centraal of de afnemer er vanuit mocht gaan dat zij 100% gegarandeerde beschikbaarheid mocht verwachten van haar werkomgeving die extern werd gehost en beheerd, althans dat dit nagenoeg storingsvrij beschikbaar moest zijn. Het hof oordeelde dat dit niet het geval is omdat dat geen redelijke uitleg van de SLA was. Ook was er geen sprake van schending van de zorgplicht. Een interessante uitspraak waar de nodige lessen uit te trekken zijn voor het opstellen en managen van SLA’s.
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.
Software kan diep ingrijpen in de processen van een onderneming. Wanneer die software dan ook nog eens, op zichzelf of dankzij de specifieke implementatie, niet eenvoudig te vervangen is, ontstaat een enorme afhankelijkheid van de leverancier. Afnemers zijn dan ook veelal beducht voor al te veel maatwerk of andere vormen van afhankelijkheid. Een recente uitspraak van het Gerechtshof Arnhem-Leeuwaarden laat echter zien dat het wel zaak is heel helder af te spreken wat nu precies onder die te voorkomen afhankelijkheid wordt verstaan. Ander trek je als afnemer toch aan het kortste eind.
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?
Klinkt mooi toch? IT-leveranciers die "u volledig ontzorgen". Maar is dat wel zo? Wat houdt dit eigenlijk in. Er bestaan verschillende misvattingen over ontzorging, zoals: u hoeft helemaal nergens meer naar om te kijken, de leverancier doet al het onderhoud en meer. In dit blog sta ik stil bij enkele van deze misvattingen. Waar moet je op letten bij uitbesteding van IT-diensten aan een ander?
In onze serie IT-contracten bespreken wij per onderwerp de belangrijkste aandachtspunten. Dit keer gaan we nader in op het onderwerp “Verwerking van persoonsgegevens”.
Overmacht is eigenlijk niets meer dan een omstandigheid waar je niets aan kunt doen, maar waardoor je niet in staat bent te doen wat je eigenlijk zou moeten doen.
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.
