Onlangs adviseerde ik een organisatie over de afspraken die zij hadden gemaakt over de ontwikkeling, het gebruik, het onderhoud en het beheer van een platform. Alle processen die plaatsvinden binnen de organisatie gaan via dit platform. Met ander woorden, zonder (goed werkend) platform geen business. Dat was ook de reden voor opdrachtgever om stil te staan bij de continuïteit van de dienstverlening met betrekking tot het platform en dus ook over de partij die het platform heeft ontwikkeld en in onderhoud heeft. Leverancier wilde graag meedenken over de mogelijkheden. Er is al een regeling getroffen voor de mogelijkheid tot overstappen naar een andere leverancier en leverancier is zelfs bereid om het auteursrecht op de software voor zover als mogelijk over te dragen.

Open source, licenties en maatwerk

Niet alle software in de applicatie is maatwerk. Een deel van de software bestaat uit open source software en een deel is ook door de leverancier in licentie verkregen. Dat betekent dat de organisatie die licenties op enig moment ook zal moet verkrijgen om het gebruik van de software voort te kunnen zetten.
De sfeer tussen partijen is prettig en de bereidheid om bij te dragen aan een goede regeling is groot. Tot zover dus echt geen vuiltje aan de lucht. Tot het moment dat de opdrachtgever naar de documentatie van de software vroeg. Toen werd het stil, heel stil, aan de zijde van de leverancier. Nee, ze konden niet vertellen welke open source software er was gebruikt. Ja ze konden wel vertellen welke betaalde software er was gebruikt, maar dat zou wel een heleboel uitzoekwerk vragen. Of klant daarvoor wilde betalen? Nee, er was ook geen documentatie van de maatwerksoftware geschreven, maar daar wilde de leverancier nog wel een sprint aan wijden. Of opdrachtgever die ook wilde betalen?

Verplichtingen leverancier

Deze reactie heeft mij aan het denken gezet.
Laat ik vooropstellen dat aan het goed regelen van je continuïteit (bijvoorbeeld voor het geval je leverancier failliet gaat) een kostenplaatje hangt. De meeste overeenkomsten bestaan uit de ontwikkeling van de software, gevolg door de dienstverleningsovereenkomst met daarin afspraken over beheer en onderhoud en eventueel doorontwikkeling. Een regeling in het kader van de continuïteit hoort daar niet vanzelfsprekend bij. Daar moet je dus apart afspraken over maken.

Een regeling voor continuïteit heeft vele aspecten, maar een daarvan is de mogelijkheid dat een derde partij mogelijk de software moet kunnen beheren, onderhouden en doorontwikkelen. Om dit te kunnen doen, moet de software goed gedocumenteerd zijn. Maar die documentatie is niet alleen maar nodig voor het geval een derde partij beheer, onderhoud en doorontwikkeling overneemt. Die documentatie is ook nodig binnen de leverancier zelf om te zorgen dat het beheer en onderhoud kan worden gecontinueerd. Als de software namelijk alleen in het hoofd van een of twee developers zit, kun je je dienstverlening niet meer garanderen als deze developers weggaan of langdurig ziek worden. Als leverancier ben je dus, om je eigen dienstverlening te kunnen leveren, genoodzaakt om je documentatie op orde te hebben.

Opstellen documentatie

De opmerking van de leverancier of mijn klant bereid was om te betalen voor het opstellen van documentatie verbaasde mij dan ook. Het opstellen van de documentatie moet onderdeel moet zijn van het ontwikkelen van de software, simpel gezegd omdat een leverancier het onderhoud en het beheer niet kan garanderen als de documentatie niet op orde is.

Nu ben ik jurist en geen softwaredeveloper, dus ik weet niet precies wat er nodig is voor het opstellen van die documentatie. Ik kan me ook voorstellen dat de documentatie voor de interne organisatie van een ander niveau is dan de documentatie voor een derde die beheer, onderhoud en doorontwikkeling gaat overnemen. Dat zou een afspraak over een aanvullende vergoeding voor die documentatie wel rechtvaardigen. Maar over het feit dat de ontwikkelaar impliciet of expliciet verplicht is tot het opstellen van bruikbare documentatie en hierop ook de wijzigingen doorvoert, zou geen discussie mogen bestaan.

Nu is de werkelijkheid kennelijk wat weerbarstiger, want bij navraag blijkt dat het opstellen van die documentatie vaak achterwege blijft. Soms is dat een “ego-dingetje” van de individuele developer, die zijn kennis niet wil delen. Soms is het de waan van de dag en soms is de planning zo strak dat de developer gewoonweg geen tijd heeft om ook de documentatie op orde te houden. Geen van de argumenten is wat mij betreft goed genoeg om tot de conclusie te komen dat er dan maar geen documentatie geschreven hoeft te worden, maar kennelijk is daarvoor nog wat cultuurverandering nodig binnen die leveranciers. En kennelijk realiseren deze leveranciers zich dus ook niet dat dit henzelf in de toekomst in grote problemen kan brengen. Developers krijgen ook gewoon wel eens een andere baan.

Conclusie

Voor mij in elk geval reden genoeg om in de toekomst alerter te zijn op afspraken over het opstellen van de documentatie. Want zoals (bijna) met alles, voer ik liever bij voorbaat de discussie over het opstellen van de documentatie, dan dat ik achteraf tot de ontdekking kom dat een leverancier dat niet goed heeft geregeld. De kosten van die laatste ontdekking zijn namelijk vele malen hoger.

Wil je meer weten over hoe je problemen met je ICT-leverancier zoveel mogelijk kunt voorkomen? Ik heb er een boek over geschreven: ICT-contracten: goed geregeld. Over grip op contractsonderhandelingen voor ICT-managers en ondernemers.