Wat kost software onderhoud en beheer?
De bouwkosten van software zijn maar de helft van het verhaal. Zodra een systeem live staat, begint een doorlopende kostenpost voor hosting, patches, monitoring en doorontwikkeling die vaak zwaarder weegt dan de initiële ontwikkeling. Een eerlijk overzicht van wat onderhoud kost en welke keuzes die kosten bepalen.
Onderhoud is geen bijzaak, maar een eigen begroting
Veel organisaties begroten de bouw van een systeem zorgvuldig, en gaan er daarna van uit dat onderhoud "er wel bij hoort". In de praktijk is beheer een structurele, terugkerende kostenpost met een eigen dynamiek: infrastructuur draait door, afhankelijkheden verouderen, en gebruikers vragen om kleine aanpassingen zodra het systeem in gebruik is.
Op deze pagina leest u welke vormen van onderhoud er zijn volgens de internationale ISO/IEC/IEEE 14764-standaard, welke factoren de kosten bepalen, en hoe u een realistisch beheerbudget opstelt naast uw ontwikkelbudget.
- Hosting en infrastructuurkosten
- Beveiligingspatches en dependency-updates
- Monitoring en incidentrespons
- Afgesproken SLA-niveau en reactietijden
- Doorontwikkeling naast instandhouding
- Leeftijd en complexiteit van het systeem
De vier vormen van software-onderhoud
De internationale standaard ISO/IEC/IEEE 14764 (oorspronkelijk vastgelegd in IEEE 1219) onderscheidt vier soorten onderhoud. Elke soort heeft een eigen kostenpatroon en een eigen moment waarop u ervoor betaalt.
Fouten herstellen
Reactief, na melding
Het oplossen van fouten die pas na livegang aan het licht komen: een crash bij een specifieke invoer, een berekening die niet klopt, een koppeling die vastloopt. Dit is de meest zichtbare vorm van onderhoud, maar meestal niet de grootste kostenpost.
Meebewegen met de omgeving
Gedreven door externe wijzigingen
Aanpassingen die nodig zijn omdat de omgeving verandert: een nieuwe versie van een besturingssysteem, een gewijzigde API bij een gekoppelde partij, of aangepaste wetgeving zoals de AVG of NIS2 die nieuwe eisen stelt.
Verbeteren en doorontwikkelen
Vraag-gedreven, doorlopend
Uitbreidingen en verbeteringen die niet voortkomen uit een fout, maar uit voortschrijdend inzicht: een sneller rapport, een extra rol in de rechtenstructuur, een workflow die na een half jaar gebruik net anders moet lopen.
Problemen voorkomen
Proactief, vóór het misgaat
Werk dat gebeurt vóórdat er een probleem is: verouderde libraries bijwerken terwijl ze nog ondersteund worden, codekwaliteit bewaken, en performance monitoren voordat gebruikers een systeem als traag ervaren.
Welke factoren bepalen de kosten?
Los van welke vorm van onderhoud er nodig is, bepalen deze factoren het grootste deel van de jaarlijkse beheerkosten.
Hosting en infrastructuur
Serverkosten, opslag en dataverkeer lopen door zolang het systeem draait, en schalen mee met het aantal gebruikers en de hoeveelheid data. Een systeem dat groeit, vraagt periodiek een herziening van de infrastructuurkeuzes.
Beveiligingspatches en dependency-updates
Frameworks, libraries en besturingssystemen krijgen doorlopend updates, waarvan een deel beveiligingskritisch is. Een systeem dat hierin achterloopt, bouwt technical debt op die later duurder is om in te halen.
Monitoring en incidentrespons
Actief monitoren of een systeem naar behoren draait, kost tijd, ongeacht of er daadwerkelijk incidenten zijn. Hoe sneller een storing moet worden opgelost, hoe meer beschikbaarheid dat aan de beheerkant vraagt.
Afgesproken SLA-niveau
Een reactietijd van enkele uren op werkdagen vraagt een andere organisatie dan 24/7-beschikbaarheid met gegarandeerde reactietijden. Hoe strenger de afspraak, hoe hoger de kosten om die na te kunnen komen.
Doorontwikkeling naast instandhouding
Zuiver "in de lucht houden" is goedkoper dan een systeem dat blijft meegroeien met nieuwe wensen. De meeste organisaties willen beide, en begroten dat vaak als één post terwijl het twee verschillende activiteiten zijn.
Leeftijd en complexiteit van het systeem
Een ouder systeem met weinig documentatie en verouderde technologie kost meer om te onderhouden dan een recent gebouwd systeem met moderne, goed ondersteunde technologie. Achterstallig onderhoud is zelden goedkoper naarmate het langer wacht.
Basaal onderhoud of structureel beheer: welke afweging telt?
Niet elk systeem heeft hetzelfde beheerniveau nodig. De juiste keuze hangt af van hoe kritiek het systeem is voor uw bedrijfsvoering en hoe vaak het proces eromheen verandert.
Basaal onderhoud volstaat als
het systeem een ondersteunende, stabiele functie vervult, storingen geen directe bedrijfskritische impact hebben, en het proces eromheen zelden verandert.
Structureel beheer met SLA is nodig als
het systeem bedrijfskritisch is, downtime direct impact heeft op klanten of omzet, of het proces eromheen regelmatig wijzigt en het systeem daarin moet meebewegen.
Twijfelt u nog of een systeem uberhaupt op maat gebouwd moet worden of dat een bestaand pakket volstaat? Lees build vs. buy: kant-en-klaar of maatwerk software. Wilt u het beheer van een bestaand systeem juist uitbesteden in plaats van zelf te organiseren, bekijk dan applicatiebeheer uitbesteden.
Hoe ziet een onderhoudstraject er in de praktijk uit?
Overdracht en documentatie
Vastleggen hoe het systeem in elkaar zit, welke koppelingen er zijn en welke keuzes bewust zijn gemaakt tijdens de bouw, zodat onderhoud niet begint met reverse-engineering.
Monitoring en incidentafhandeling inrichten
Afspreken hoe storingen worden gesignaleerd, wie ze oppakt en binnen welke termijn, passend bij hoe kritiek het systeem is.
Periodieke onderhoudscyclus
Vaste momenten voor het bijwerken van dependencies, controleren van beveiligingsupdates en evalueren van de systeemprestaties, in plaats van dit uit te stellen tot er iets misgaat.
Periodieke evaluatie en doorontwikkeling
Terugkerend bespreken welke wensen zijn opgehaald sinds livegang, en welke daarvan de moeite waard zijn om als doorontwikkeling in te plannen.
Hoe budgetteert u verstandig voor onderhoud?
Reserveer beheerbudget los van het ontwikkelbudget, in plaats van te hopen dat er na oplevering geen kosten meer bijkomen. Onderhoud is geen eenmalige post, maar loopt door zolang het systeem in gebruik is.
Maak onderscheid tussen instandhouding (het systeem laten blijven werken zoals het is) en doorontwikkeling (het systeem laten meegroeien). Beide zijn legitiem, maar horen niet automatisch in dezelfde begrotingspost.
Plan dependency- en beveiligingsupdates periodiek in, in plaats van ze te laten oplopen. Een update die twee jaar is uitgesteld, kost vrijwel altijd meer om in te halen dan wanneer die steeds op tijd was gedaan.
Leg vooraf vast wie verantwoordelijk is voor welk type onderhoud, zeker als bouw en beheer bij verschillende partijen liggen. Onduidelijkheid hierover is een veelvoorkomende bron van vertraging bij incidenten.
Veelgestelde vragen over onderhoudskosten
Onderhoudskosten hangen sterk af van de complexiteit en leeftijd van het systeem, het afgesproken SLA-niveau en hoeveel doorontwikkeling u naast instandhouding wilt. Dat maakt een generiek bedrag misleidend; na een intake kunnen we een realistische inschatting geven.
Onderhoud houdt het systeem draaiende zoals het is: bugs oplossen, updates doorvoeren, monitoren. Doorontwikkeling voegt nieuwe functionaliteit toe of past bestaande functionaliteit aan. Beide zijn legitiem, maar verdienen een eigen budgetregel omdat de een reactief is en de ander vraag-gedreven.
Uitgestelde updates en ongebruikte monitoring stapelen zich op tot technical debt: verouderde afhankelijkheden die niet meer veilig zijn, en een systeem dat steeds lastiger aan te passen wordt. Inhalen kost daardoor vrijwel altijd meer dan periodiek bijhouden.
Niet per se, maar een partij die het systeem kent, heeft minder inwerktijd nodig bij incidenten. Gaat het onderhoud naar een andere partij, zorg dan voor goede documentatie en een overdrachtsmoment, zodat kennis over eerdere keuzes niet verloren gaat.
Kijk naar de impact van downtime: raakt een storing direct klanten of omzet, dan is een strakke SLA met korte reactietijden verstandig. Is het systeem ondersteunend en is een storing van een paar uur acceptabel, dan volstaat een lichter niveau.
Ja, het bijhouden van beveiligingskritische updates in frameworks en libraries hoort bij preventief onderhoud. Dit gebeurt idealiter voordat een kwetsbaarheid actief wordt misbruikt, niet pas nadat die is gemeld.
Dat kan, na een technische intake waarin we de code, documentatie en huidige status van het systeem doornemen. Op basis daarvan bepalen we of en hoe we het beheer verantwoord kunnen overnemen.
Beheerinschatting voor uw systeem?
Beschrijf kort welk systeem het betreft en wat u nu al aan onderhoud doet. We geven binnen enkele werkdagen een realistische inschatting van wat structureel beheer voor uw situatie inhoudt.