Software na oplevering: onderhoud, documentatie en een uitweg

"Een systeem dat niemand begrijpt, is een risico, ook als het vandaag perfect werkt."

Bij oplevering is iedereen blij. Het werkt, het ziet er goed uit en het team heeft een training gehad. Een jaar later is er een update nodig, iemand wil een extra veld, en de inlog is stuk door een wijziging bij een externe dienst. Wie kan dat oplossen, en weet hij nog hoe het systeem in elkaar zit?

Kort antwoord: spreek bij het sluiten van het contract af wie het systeem onderhoudt en wat dat kost, vraag documentatie en toegang tot alle onderdelen, zorg dat minstens één persoon in je team begrijpt hoe het werkt, en leg een uitweg vast voor als de samenwerking stopt. Dat is het verschil tussen een systeem en een afhankelijkheid.

Inhoudsopgave

1. Wat onderhoud is
2. Wat het kost
3. Documentatie: wat je moet krijgen
4. Toegang: sleutels en accounts
5. Je team: wie moet wat kunnen
6. De uitweg
7. Een checklist bij oplevering

Wat onderhoud is

Software veroudert, ook als je er niets aan verandert. De onderdelen waar het op draait, krijgen updates, beveiligingslekken worden ontdekt, externe diensten passen hun werking aan en browsers veranderen. Onderhoud bestaat uit:

Wat niet onder onderhoud valt, zijn nieuwe functies. Dat is doorontwikkeling en heeft een eigen prijs. Wees hier vooraf duidelijk over, want het is de bron van de meeste discussies.

Wat het kost

Er zijn drie kostenposten na oplevering:

1. Doorlopende diensten: hosting, database, e-mailversturing, domeinen. Vaak een vast bedrag per maand, op jouw naam.
2. Onderhoud: de tijd van degene die het bijhoudt. Per maand een vast bedrag, of per keer.
3. Doorontwikkeling: nieuwe wensen, per project geprijsd. Zie wat kost een app laten bouwen voor hoe ik dat bij een vaste projectprijs aanpak.

Reserveer in je planning een bedrag voor onderhoud. Een systeem zonder onderhoudsbudget is een systeem dat langzaam verslechtert. Vraag daarom altijd om een onderhoudsvoorstel naast de bouwofferte, en vergelijk beide samen.

Documentatie: wat je moet krijgen

Documentatie is geen luxe, maar de verzekering tegen vergeten. Vraag minimaal:

Een goede test: zou een ervaren bouwer die het systeem nooit zag, hiermee in een dag begrijpen hoe het werkt? Zo niet, dan ontbreekt er iets.

Toegang: sleutels en accounts

Documentatie zonder toegang helpt niet. Bij oplevering hoort:

• de code in een opslagplaats (repository) waar jij eigenaar van bent of waartoe je volledige toegang hebt;
• accounts voor hosting, database en diensten op jouw naam of die van je organisatie;
• een wachtwoordbeheerder of een veilige manier waarop sleutels worden overgedragen (niet per e-mail);
• een lijst van wie waar bij kan, en een afspraak om dat bij vertrek van mensen aan te passen.

Dit klinkt zakelijk, maar het is de meest praktische manier om afhankelijkheid te voorkomen. Het gaat ook samen met de afspraken over eigendom: zie eigenaar van de code en data bij maatwerksoftware.

Je team: wie moet wat kunnen

Niet iedereen hoeft het te begrijpen, maar sommige rollen zijn nodig.

De plaatsvervanger wordt het vaakst vergeten. Als de enige persoon die het systeem kent met vakantie of weg is, ligt het hele proces stil.

Training bij oplevering is niet genoeg. Plan na enkele maanden een opfrisronde, en neem nieuwe collega's mee.

De uitweg

Een uitweg is wat je regelt voor het geval de samenwerking stopt, of de bouwer niet meer beschikbaar is. Je hoopt hem nooit nodig te hebben.

Wat erin hoort:

1. Overdracht: de bouwer werkt mee aan overdracht naar een andere partij, tegen een afgesproken tarief of kosteloos.
2. Exportmogelijkheid: je kunt al je gegevens exporteren in een gangbaar formaat.
3. Regeling bij uitval: wat gebeurt er bij ziekte of stopzetting van de bouwer? Een zelfstandige bouwer kan afspreken met een collega die kan inspringen, of een bewaargeving van de code.
4. Opzegtermijn en voorwaarden: helder en redelijk.
5. Geen blokkades: geen sloten of verborgen afhankelijkheden die overstappen onmogelijk maken.

Vraag de bouwer hoe hij dit regelt. Een goed antwoord is concreet. Een zwak antwoord is stilte. Zie ook een bouwpartner kiezen: twaalf vragen.

Een checklist bij oplevering

• Er is een schriftelijk onderhoudsvoorstel met prijs en reactietijden.
• Het is duidelijk wat onder onderhoud valt en wat doorontwikkeling is.
• De code staat in een opslagplaats waar jij toegang toe hebt.
• Alle accounts en abonnementen staan op jouw naam, met een lijst.
• Er is documentatie die een andere bouwer zou begrijpen.
• Een back-up is gemaakt en het terugzetten is getest.
• Er is een eigenaar, een beheerder en een plaatsvervanger.
• Je team is getraind en weet wie je belt bij een storing.
• Er is een uitweg afgesproken.
• De lijst voor fase 2 is vastgelegd.

Meer over wat een goed traject eruitziet, vind je in maatwerksoftware laten bouwen: de complete gids en zo bouw ik een werkende app in drie weken. Zit er een AI-onderdeel in? Dan komt er beheer bij: zie wat kost een AI-agent echt.

Hulp nodig?

Heb je een systeem dat niemand meer goed begrijpt, of wil je een nieuw systeem met dit goed geregeld? Plan een gesprek via contact of bekijk de Rapid Solution Studio.

Gerelateerde artikelen

• Maatwerksoftware laten bouwen: de complete gids
• Een bouwpartner kiezen: twaalf vragen voor je tekent
• Bouwen, kopen of no-code: een beslismodel
• Eigenaar van de code en data bij maatwerksoftware
• Productized interim: software die verandering borgt

Bronnen en verder lezen

• Nationaal Cyber Security Centrum, voor basismaatregelen op het gebied van digitale veiligheid
• MKB Digitaal

Dit artikel is geschreven door Vincent van Munster van WeAreImpact. Hij levert software op met documentatie en overdracht, zodat opdrachtgevers niet van hem afhankelijk hoeven te zijn.