Het “wat” en “hoe” van de overeenkomst
De onderwerpen levering, implementatie en opleiding zijn vaak verdeeld over meerdere artikelen. Grosso modo zou je kunnen zeggen dat:
- het artikel over levering gaat over de vraag “wat is X en hoe krijg ik X in huis?”; en
- de artikelen over implementatie en opleiding gaan over de vraag “hoe kom ik tot ingebruikname van X?”.
Het in huis krijgen van het gecontracteerde
Eerder beschreven we dat in het artikel over het voorwerp van de overeenkomst staat wat er in de kern wordt geleverd.
In het artikel over levering gaat het vervolgens meer concreet over wat die leveringsplicht dan precies inhoudt, en hoe die te leveren dienst of de te leveren producten dan ter beschikking komt/komen van de klant. Meer concreet gaat het dan bijvoorbeeld om:
- de aard en het type van de te leveren licenties, in combinatie met de wijze van levering (op DVD, ter download, etc.);
- een nadere omschrijving van wat de te leveren SaaS/cloud-dienst nu eigenlijk omvat (features, uptime, etc.), inclusief de wijze waarop de klant daartoe toegang krijgt (inloggegevens, SSO, etc.);
- een specificatie van de te leveren hardware, inclusief de wijze van (en afspraken over het risico voor) bezorging;
- een omschrijving van de te realiseren maatwerkprogrammatuur, inclusief planning van tussentijdse deelleveringen en de waarop deze ter beschikking worden gesteld (bijv. uploaden in een bepaalde cloudomgeving).
De kunst is om voldoende precies te beschrijven wat er nu eigenlijk wordt geleverd. We zien te vaak dat er allerlei open eindes blijven bestaan, waardoor er verkeerde verwachtingen kunnen ontstaan bij (met name) de afnemer.
Het inregelen van het gecontracteerde
Levering is één ding, in de praktijk is de ingebruikname van IT vaak een grote uitdaging.
Een IT-product of –dienst moet bijna altijd worden ingepast in een bestaand IT-landschap van de afnemer. Voor dat inpassen zijn vaak allerlei werkzaamheden nodig, zoals het aanleggen van koppelingen of het aanpassen van bestaande software. Er is hierbij vaak sprake van een afhankelijkheid van vele partijen, zowel intern als extern. Het loont om op voorhand die afhankelijkheden zeer goed in beeld te brengen en (de gevolgen daarvan) te adresseren.
Voor veel IT-producten en –diensten geldt daarnaast ook dat deze vaak een bestaand systeem vervangen of aanvullen. In die bestaande systemen staan gegevens opgeslagen en die gegevens zullen mee over moeten naar het nieuwe systeem, of op een ander manier toegankelijk worden gemaakt voor dat nieuwe systeem. We spreken dat over datamigratie en –synchronisatie. We zien dat dit in de praktijk nog heel vaak een weerbarstig onderwerp blijkt te zijn. Data lijkt wellicht op het eerste gezicht overzichtelijk, maar wat bepaalde data ‘betekent’ wil van systeem tot systeem nog wel eens verschillen. Denk hierbij ook aan hele praktische problemen, zoals het gegeven dat bepaalde velden niet of alleen in andere vorm bestaan in het opvolgende systeem.
Wanneer te voorzien is dat implementatie en/of de migratie omvangrijk of complex zal zijn, kan het lonen om dat onderwerp naar voren te halen en bijvoorbeeld proefconversies, proof of concepts of soortgelijke proefprojecten al voorafgaand aan het project uit te voeren (om zodoende haalbaarheid te toetsen). Dit kan dan gecombineerd worden met procesafspraken over hoe om te gaan met issues die in die fase worden gevonden, met tegenvallers en met de situatie dat in die fase zou blijken dat het beoogde einddoel helemaal niet te realiseren is. We zien ook wel eens dat er losse overeenkomsten worden gesloten om sec zo’n POC of (proef)migratie uit te voeren.
In het artikel over definities in deze serie is overigens te zien wat een wereld van het verschil het kan maken hoe je 'implementatie' definieert.
Na de migratie, implementatie en andere inregelingshandelingen volgt in de regel een acceptatie. Daarover schrijven we een andere blog in deze serie.
Het in gebruik nemen van het gecontracteerde
Tussen de implementatie en de daadwerkelijke ingebruikname zit vaak – als de acceptatietest overleefd wordt – de fase van training en opleiding.
Een nieuw systeem vergt vaak een nieuwe manier van werken. Het is cruciaal dat eindgebruikers zowel vertrouwd worden gemaakt met die nieuwe manier van werken als goed snappen waarom het systeem op een bepaalde wijze is ingericht. Een goede uitleg over de werking bevordert de acceptatie van het gebruik. Een goede uitleg over het ‘waarom’ van bepaalde inrichtingskeuzes voorkomt dat het systeem op een verkeerde manier wordt gebruikt. Verkeerd gebruik van een systeem kan er bijvoorbeeld toe leiden dat data ‘vervuild’ raken of dat het systeem anderszins onjuist gaat functioneren, waardoor op de lange termijn de acceptatiegraad weer daalt (en er een negatieve spiraal ontstaat).
Er zijn allerlei vormen van opleidingen en trainingen denkbaar en het is van belang op voorhand een bewuste keuze te maken voor de meest passende vorm. Keuzes lopen uiteen van het type opleiding (van slechts het uitreiken van folders tot intensieve meerdaagse sessies), door wie de training wordt gegeven (bijv. train-the-trainer principe, of juist alles door leverancier of alles door afnemer), de wijze van het geven van de training (1-op-1, groepslessen fysiek bij elkaar of e-learning op afstand), het onderwerp waarover de training gaat (alleen functioneel of ook meer technisch), etc. etc. Wat passend is zal van allerlei omstandigheden afhangen, zoals aard en complexiteit van het systeem, aantal te trainen mensen, achtergronden en opleidingsniveau van die mensen, doorlooptijden van de trainingen, etc.
Opleidingen en trainingen zijn dus cruciaal. Goede afspraken daarover kunnen het succes van een project maken of breken. In de praktijk zien we regelmatig dat er te weinig aandacht wordt besteed aan dit aspect van een IT-project.
Slotopmerking
De fases van “Levering, implementatie en opleiding” in een IT-project zijn cruciaal. In deze fases komt het immers aan op het daadwerkelijk krijgen, inrichten en in gebruik nemen van het IT-product of de IT-dienst. Een IT-project kan in ieder van die fases nog mislukken. Aandacht voor die fasen is dan ook cruciaal. Heldere afspraken maken het ook makkelijker om in de acceptatieprocedure te toetsen of er conform afspraken is geleverd. Daarover meer in de volgende blog in deze serie.
Leest u vooral ook de andere onderwerpen uit onze serie IT-contracten en blijf het geheel in samenhang bekijken.
