Software is bij oplevering niet af. Welke vier soorten onderhoud er zijn, wat het jaarlijks kost, welke afspraken je vooraf maakt en waarom een AI-onderdeel een eigen categorie toevoegt.
Bij maatwerksoftware gaat alle aandacht naar de bouw: wat het moet kunnen, wat het kost, wanneer het klaar is. De oplevering voelt als de finish. In werkelijkheid begint daar de periode waarin de software het grootste deel van zijn waarde levert, en waarin de meeste onaangename verrassingen zitten.
Die verrassingen zijn te voorkomen. Alleen niet achteraf: de afspraken die het verschil maken, maak je voordat er een regel code is geschreven.
Onderhoud klinkt als af en toe een fout herstellen. Dat is het kleinste deel ervan.
Correctief. Iets doet het niet meer of doet iets verkeerd. Dit is wat mensen bedoelen als ze onderhoud zeggen.
Preventief. Het bijwerken van onderliggende onderdelen. Elke applicatie leunt op tientallen externe pakketten met eigen beveiligingsupdates. Wie dat een jaar laat liggen, staat voor één grote sprong in plaats van een reeks kleine.
Adaptief. De wereld verandert. Een koppeling wijzigt zijn interface, een leverancier stopt een dienst, een boekhoudpakket verandert zijn export. Er is niets kapot aan jouw kant en er is toch werk.
Perfectief. Gebruikers vragen aanpassingen omdat ze het systeem nu pas echt kennen. Dat is een goed teken en hoort in een aparte pot.
De eerste drie zijn de bodem. Wie alleen voor de vierde begroot, komt elk jaar tekort.
De vuistregel in de branche is vijftien tot twintig procent van de bouwsom per jaar, afhankelijk van het aantal koppelingen en van hoe kritisch het systeem is. Een interne applicatie zonder externe koppelingen zit aan de onderkant. Een systeem waar klanten op zitten en dat aan vier diensten hangt, zit erboven.
Daar komt de infrastructuur bij: hosting, database, opslag, mailverzending en foutmonitoring. Meestal bescheiden bedragen, maar ze bestaan elke maand.
Wat je daarvoor koopt, is niet af en toe een fout minder. Je koopt dat het systeem over drie jaar nog draait en nog veilig is. Zie beheer en onderhoud van maatwerksoftware.
Dit is het deel dat later niet meer te repareren valt.
Leg vast wie eigenaar is van de code, zwart op wit en niet als gewoonte. Leg vast waar de repository staat en dat jij daar toegang toe hebt, ook als de samenwerking stopt. Leg vast wie eigenaar is van de accounts bij hosting, database en externe diensten, want rekeningen op naam van de bouwer zijn een gijzeling die niemand zo bedoelde.
Spreek af hoe een overdracht eruitziet: documentatie, omgevingen, sleutels en een installatie-instructie die iemand anders heeft nagelopen. Spreek reactietijden af bij storingen, los van doorlooptijden bij wensen. En spreek af wat er gebeurt bij stilstand: wie belt wie, binnen welke tijd.
Dit klinkt wantrouwig en is het tegenovergestelde. Het maakt het makkelijk om jaren met dezelfde partij door te gaan, juist omdat vertrek geen ramp zou zijn.
Dat ligt grotendeels vast op de dag van oplevering. Vier dingen bepalen het.
Automatische tests, zodat een wijziging aantoonbaar niets anders breekt. Foutmonitoring, zodat een storing bekend is voordat een gebruiker belt. Een reproduceerbare installatie, zodat de applicatie op een andere machine op te zetten is zonder de oorspronkelijke bouwer. En documentatie van de keuzes, niet van de code maar van waarom het zo is opgezet.
Software zonder tests is niet goedkoper gebouwd. Hij is duurder in onderhoud, en dat verschil betaal je jarenlang.
Zit er een taalmodel in, dan komt er onderhoud bij dat klassieke software niet kent.
Modellen worden vervangen en uitgefaseerd, en een nieuwe versie gedraagt zich net anders bij dezelfde instructie. Prijzen per verwerkte hoeveelheid tekst veranderen. En de kwaliteit van de uitkomst is niet vast te leggen in een test die alleen groen of rood kent.
Daarom hoort er een kleine, vaste verzameling voorbeelden met verwachte uitkomsten bij, die je na elke wijziging doorloopt. En een grens op het verbruik, zodat een lus of een piek geen onbeperkte rekening oplevert. Zie wanneer mag AI zelf handelen.
Er zijn drie werkbare modellen. Bij de bouwer laten, tegen een vast bedrag per maand met afgesproken reactietijden. Zelf doen met hulp op afroep, wat past bij bedrijven met een eigen ontwikkelaar. Of overdragen aan een derde partij, wat alleen werkt als de oplevering op orde was.
In alle drie de gevallen geldt: leg vast of er buiten kantooruren iemand bereikbaar is. Software die de bedrijfsvoering raakt en alleen op werkdagen ondersteund wordt, is een prima keuze zolang het een bewuste keuze is.
Een tijdje wel, en de rekening komt later in één keer. Achterstallige updates zijn het duurste soort onderhoud.
Dat hoort te kunnen. De voorwaarden daarvoor zijn eigenaarschap van de code en de accounts, plus een werkende installatie-instructie.
Een uur. Langs de foutmeldingen, de updates, het verbruik en de wensenlijst. Dat uur voorkomt de meeste verrassingen.
Soms wel, en dat is een eerlijke uitkomst. Zie interne tool of standaardsoftware.
Dat hangt af van het aantal aanroepen en de lengte van de tekst per aanroep. Belangrijker dan het bedrag is dat er een plafond op zit.
Staat er een regel over tests, over monitoring, over eigenaarschap en over onderhoud na oplevering? Ontbreken die, dan is de offerte niet goedkoper maar onvolledig.
Wilt u weten wat het beheer van uw systeem realistisch kost, neem contact op.
dGEN Productions, AI agency en business-automation partner uit Eindhoven. info@dgenproductions.nl · 06-87413056