Software die alleen nog door één persoon wordt begrepen, is een serieus bedrijfsrisico. Zodra die persoon uitvalt, ziek wordt of vertrekt, staat de organisatie voor een gesloten deur: niemand weet hoe het systeem werkt, hoe het onderhouden moet worden of hoe problemen opgelost kunnen worden. Dit risico speelt vaker dan je denkt, zeker bij organisaties die al jaren draaien op legacy software die ooit door een enkele ontwikkelaar is gebouwd of beheerd. In dit artikel beantwoorden we de meest gestelde vragen over dit probleem, zodat je weet waar je op moet letten en wat je eraan kunt doen.

Wat gebeurt er als die ene persoon wegvalt?

Als de enige persoon die de software begrijpt wegvalt, verlies je in één klap toegang tot cruciale kennis over hoe het systeem werkt, hoe het geconfigureerd is en hoe problemen worden opgelost. Afhankelijk van hoe kritiek de software is voor je bedrijfsprocessen, kan dit leiden tot stilstand, dataverlies of kostbare noodoplossingen.

In de praktijk zien organisaties dan een aantal dingen tegelijk fout gaan. Bugs die normaal snel opgelost werden, blijven wekenlang onopgelost. Aanpassingen aan het systeem zijn niet meer mogelijk zonder het risico te lopen dat iets anders kapotgaat. En nieuwe medewerkers of externe partijen die wél willen helpen, moeten het systeem van de grond af aan leren kennen, zonder enige documentatie of overdracht.

Wat het extra pijnlijk maakt: dit soort situaties ontstaat zelden van de ene op de andere dag. Het is een gevolg van jarenlang dezelfde persoon verantwoordelijk laten zijn voor een systeem, zonder dat kennis structureel is geborgd. De schade is dan ook niet alleen operationeel, maar ook financieel en strategisch.

Wat is de ‘bus factor’ en waarom is die gevaarlijk?

De bus factor is een begrip uit de softwareontwikkeling dat aangeeft hoeveel mensen er zouden moeten uitvallen voordat een project of systeem in gevaar komt. Een bus factor van 1 betekent dat één persoon genoeg is om alles tot stilstand te brengen. Dat is een gevaarlijk laag getal voor elke organisatie die afhankelijk is van die software.

De naam is wat grimmig, maar de boodschap is helder: als je bedrijfskritische processen afhangen van de kennis van één individu, ben je kwetsbaar. Het gaat daarbij niet alleen om ongelukken of plotseling vertrek. Ook ziekte, een sabbatical of gewoon een nieuwe baan bij een andere werkgever zijn realistische scenario’s die dagelijks voorkomen.

Bij legacy software is de bus factor vaak structureel laag. Systemen zijn soms tientallen jaren geleden gebouwd, door mensen die al lang weg zijn, in technologieën die niemand meer actief gebruikt. Dat maakt de afhankelijkheid van de ene persoon die het systeem nog kent extra riskant: er is geen alternatief en er is geen vangnet.

Welke signalen wijzen op gevaarlijke kennisconcentratie?

Gevaarlijke kennisconcentratie is herkenbaar aan een aantal concrete signalen. Als je organisatie één of meer van deze situaties herkent, is de kans groot dat je bus factor te laag is en dat je actie moet ondernemen voordat het misgaat.

  • Één persoon is altijd de eerste die gebeld wordt bij problemen met het systeem, ongeacht het tijdstip of de urgentie.
  • Er is geen of nauwelijks documentatie over hoe het systeem werkt, hoe het geconfigureerd is of hoe wijzigingen doorgevoerd worden.
  • Nieuwe medewerkers begrijpen het systeem niet zonder uitgebreide begeleiding van die ene persoon.
  • Aanpassingen worden uitgesteld omdat alleen die ene persoon ze veilig kan doorvoeren.
  • Het systeem is gebouwd in een verouderde technologie die buiten die persoon niemand in de organisatie beheerst.
  • Er is geen testomgeving of versiebeheer, waardoor wijzigingen direct in de productieomgeving worden doorgevoerd.

Hoe meer van deze signalen van toepassing zijn, hoe groter het risico. Eén signaal kan al voldoende zijn om de situatie serieus te nemen.

Hoe voorkom je dat kennis bij één persoon blijft hangen?

Kennisconcentratie voorkom je door kennis structureel te verdelen, vast te leggen en te onderhouden. Dat vraagt om bewuste keuzes in hoe je software ontwikkelt, beheert en overdraagt. Er zijn een aantal concrete maatregelen die het verschil maken.

  • Documenteer actief. Zorg dat er altijd up-to-date documentatie is over de architectuur, de configuratie en de belangrijkste bedrijfslogica van het systeem. Dit hoeft niet perfect te zijn, maar het moet bestaan.
  • Werk met code reviews. Laat wijzigingen altijd door minimaal één andere persoon bekijken. Dit zorgt ervoor dat kennis wordt gedeeld en dat meerdere mensen begrijpen wat er in het systeem verandert.
  • Gebruik versiebeheer. Tools zoals Git maken het mogelijk om wijzigingen bij te houden, terug te draaien en te begrijpen wie wat wanneer heeft gedaan.
  • Plan kennisoverdrachten. Zorg dat meerdere mensen regelmatig betrokken zijn bij het systeem, ook als dat niet strikt noodzakelijk is. Kennis veroudert snel als niemand er actief mee werkt.
  • Bouw met onderhoudbare technologie. Kies voor moderne, breed gedragen technologieën waarop meerdere ontwikkelaars kunnen instappen. Dat verlaagt de drempel voor kennisoverdracht enorm.

Bij bestaande legacy software is dit lastiger, maar niet onmogelijk. Soms is een grondige analyse van het systeem de eerste stap, zodat je in kaart brengt wat er precies is en wie wat weet. Vanuit die analyse kun je een plan maken om kennis breder te borgen of het systeem te moderniseren.

Wanneer is het verstandig om externe software-expertise in te schakelen?

Externe software-expertise inschakelen is verstandig zodra de interne kennis over een systeem te smal is geworden om het veilig te onderhouden of te verbeteren. Dat moment is eerder bereikt dan de meeste organisaties denken, zeker als het gaat om legacy software die al jaren op de rug van één persoon draait.

Concrete situaties waarin externe hulp zinvol is:

  • Je wilt het systeem moderniseren, maar niemand intern heeft de kennis of capaciteit om dat veilig te doen.
  • De enige persoon die het systeem kent, gaat binnenkort weg of is al weg.
  • Je wilt een onafhankelijke beoordeling van de staat van het systeem en de risico’s die het met zich meebrengt.
  • Er zijn aanpassingen nodig die intern niet gedaan kunnen worden zonder grote risico’s.
  • Je overweegt het systeem te vervangen of te migreren naar een nieuw platform.

Externe experts kunnen niet alleen helpen met de technische kant, maar ook met het in kaart brengen van de risico’s en het opstellen van een plan voor de langere termijn. Ervaren softwareprofessionals die tijdelijk worden ingezet, kunnen bovendien kennis overdragen aan het interne team, zodat de afhankelijkheid structureel wordt verkleind.

Hoe VL Software helpt bij legacy software risico’s

VL Software helpt organisaties die vastzitten aan software die alleen nog door één persoon wordt begrepen, of waarbij die persoon er al niet meer is. Het team analyseert het bestaande systeem, brengt de risico’s in kaart en werkt samen met jou aan een plan om de situatie beheersbaar te maken.

  • Legacy scan: een grondige analyse van je bestaande software, inclusief architectuur, technologie en kennisrisico’s.
  • Replatforming: het omzetten van verouderde systemen naar moderne, onderhoudbare webapplicaties met behoud van waardevolle bedrijfslogica.
  • IT-detachering: ervaren softwareprofessionals die tijdelijk bij jou inzetbaar zijn om kennis over te dragen, het systeem te stabiliseren of de migratie te begeleiden.
  • Maatwerk ontwikkeling: als het systeem toe is aan vervanging, bouwt VL Software een oplossing op maat die aansluit op jouw processen en schaalbaar is voor de toekomst.

Wil je weten hoe groot het risico is voor jouw organisatie en wat de beste stap vooruit is? Neem contact op met VL Software voor een vrijblijvend gesprek.

Gerelateerde artikelen