Business Brief
Waarom afhankelijkheid van sleutelpersonen de waarde van een mkb-MSP beperkt
Vier dimensies waarin kennis vastzit in mensen — en wat dat doet met je marge, multiples en groeicapaciteit.
In een mkb-MSP wordt waarde minder vaak vernietigd door techniek of marktomstandigheden dan door operationele afhankelijkheid van individuen. Naarmate klantkennis, configuratiebeheer, incidentafhandeling en besluitvorming primair afhankelijk zijn van specifieke mensen — in plaats van van systemen, runbooks, policies en vastgelegde proceskennis — verschuift het bedrijf van bedrijfsmiddel naar persoonsgebonden praktijk. Dat verlaagt overdraagbaarheid, drukt multiples bij overname, vergroot incident-impact in BAU en zet een plafond op haalbare groei.
1. Waarom kopers altijd doorvragen op één engineer
In vrijwel elk overnameproces van een mkb-MSP komt dezelfde vraag terug, vroeger of later: wat gebeurt er als die ene engineer weggaat? Kopers stellen hem niet omdat ze geloven dat het gaat gebeuren. Ze stellen hem omdat hun bod weerspiegelt wat het zou kosten als het wél gebeurt — en omdat ze in due diligence systematisch zoeken naar werk dat niet zonder een specifiek persoon gedaan kan worden.
Wat in due diligence aan het licht komt, was er meestal al jaren. Het verschil is dat een koper er een prijs op zet. Eigenaren die zelf nooit verkopen, dragen dezelfde afhankelijkheid mee — alleen wordt de vraag dan niet gesteld, en de prijs niet betaald in één keer. Hij wordt betaald in stukjes: in marges die niet schalen, in incidenten die langer duren, in groei die stagneert zodra de senior engineer met vakantie is.
De vraag van een koper is niet anders dan de vraag die elke eigenaar zichzelf zou moeten stellen — alleen krijgt de koper een prijs op het antwoord.
Dat het inzichtelijk maken van die afhankelijkheid een meetkader vereist, is precies waar de rest van deze brief over gaat.
2. OAG: vier dimensies waarin kennis vastzit
De operationele afhankelijkheidsgraad (OAG) meet welk deel van de operatie van een MSP — klantkennis, configuratiebeheer, incidentafhandeling en besluitvorming — primair afhankelijk is van individuen in plaats van van systemen, runbooks, policies en vastgelegde proceskennis.
OAG is geen oordeel over mensen. Het is een inspectiehoek op werk. Een MSP met lage OAG heeft niet minder bekwame engineers — hij heeft engineers wier kennis verankerd is in systemen die anderen kunnen lezen, gebruiken en verbeteren. Een MSP met hoge OAG heeft die kennis óók, maar opgeslagen in hoofden.
Klantkennis
Wie weet hoe een specifieke klantomgeving écht in elkaar zit: afwijkingen van het standaardpatroon, historische beslissingen die niet zijn opgeschreven, onuitgesproken afspraken met de klant.
Configuratiebeheer
Staat de actuele staat van klantomgevingen in een CMDB, infrastructure-as-code of policy-store, of zit die staat verspreid over verschillende tools waarvan alleen één of twee engineers de echte structuur kennen.
Incidentafhandeling
Kan een doorsnee engineer een P1-incident bij een willekeurige klant tot resolutie brengen, of moet voor bepaalde klanten altijd dezelfde persoon erbij worden gehaald.
Besluitvorming
Welke operationele beslissingen worden uitgesteld of niet genomen wanneer een specifieke persoon afwezig is. Welke wijzigingen wachten standaard "tot Mark terug is".
OAG is een belangrijke operationele component van de operationele overdraagbaarheidsgraad (OOG), maar niet de enige. Lees BI-06 over operationele overdraagbaarheid en waardering voor het bredere kader. Hoge OAG dwingt OOG naar beneden, maar OOG kent meer componenten — tooling-fragmentatie, contractkwaliteit, documentatiediscipline, audit trail. OAG zoomt in op de humane sublaag.
3. Wat OAG kost in dagelijkse operatie
Hoge OAG vertaalt zich operationeel meestal niet in fouten, maar in wachttijd: collega's wachten op antwoorden, klanten wachten op beslissingen en incidenten wachten op de juiste persoon. Dat is een belangrijk onderscheid. De zichtbare incidentbacklog blijft soms verbazend stabiel — wat verandert is hoeveel werk er onder de oppervlakte vastloopt op één agenda.
Rekenmodel (werkhypothese)
Stel een mkb-MSP met twaalf engineers — twee senior, vier medior, zes junior — en richtwaarde €1,5M ARR. In een typisch hoog-OAG-profiel hangt een substantieel deel van het klantenbestand inhoudelijk aan de twee senior engineers: zij kennen de klantcontext, zij hebben de niveau-3-beslissingen genomen, zij worden gebeld wanneer escalatie nodig is.
Het effect daarvan in BAU is zelden dramatisch op één dag. Het is structureel:
Geen van bovenstaande effecten is een marktnorm. Het zijn werkhypotheses, bedoeld om de orde van grootte zichtbaar te maken in omgevingen waar OAG zonder mitigatie is doorgegroeid.
4. Wat OAG kost bij een overname
Bij een mogelijke overname werkt OAG anders dan in BAU. In BAU is OAG een marge- en schaalvraagstuk. In een overnamesituatie is OAG een prijs- en structuurvraagstuk.
Drie effecten doen zich consistent voor:
| OAG-profiel | Kenmerken | Waarschijnlijke impact bij overname |
|---|---|---|
| Licht | Kennis verspreid over team, runbooks compleet, infrastructure-as-code op orde | Marktconforme waardering waarschijnlijk |
| Gemiddeld | Deel in systemen, kritische klantkennis bij twee of drie personen | Verhoogde kans op waarderingsdruk of aanvullende voorwaarden |
| Zwaar | Kritische klantkennis bij één of twee personen, weinig vastgelegde proceskennis | Materiële kans op waarderingsdruk, earnout-constructies of uitgebreider due-diligence onderzoek |
Scenario-tabel (werkhypothese — geen marktnorm). De scenario-impact is kwalitatief geformuleerd.
Voor de onderbouwing per koperstype, zie BI-07 over koper-risico versus groei en de inspectiehoeken in BI-08 over due diligence.
5. Hoe je OAG structureel verlaagt
Echte OAG-reductie ontstaat wanneer systemen, processen en governance ervoor zorgen dat kennis niet afhankelijk blijft van individuen. Documentatie speelt daarin een rol, maar is zelden voldoende als zelfstandige maatregel. Een wiki die niemand bijhoudt, verlaagt OAG niet — die geeft alleen het gevoel dat OAG verlaagd is.
Structurele interventie per dimensie:
Klantkennis
Een centraal systeem-of-record voor klantcontext: niet alleen contactgegevens, maar configuratiegeschiedenis, gemaakte uitzonderingen op het standaardpatroon, en de redenen daarvan. Wat informeel in een hoofd zit, wordt expliciet aan een record gekoppeld.
Configuratiebeheer
Infrastructure-as-code als bron van waarheid, gecombineerd met drift-detection. Veranderingen aan de actuele staat zonder dat ze door het systeem zijn voorgesteld, worden zichtbaar. De omgeving stuurt zichzelf bij wanneer iemand iets met de hand verandert.
Incidentafhandeling
Policy-driven, closed-loop remediation voor routinematige incidenten. Het systeem detecteert, beslist binnen vooraf gedefinieerde grenzen, voert uit, en legt vast wat het gedaan heeft. Een engineer hoeft pas bij escalatie betrokken te raken — en niet uit gewoonte.
Besluitvorming
Expliciete policies plus een audit trail. Wat een engineer normaal in het hoofd weegt ("dit is een uitzondering die we eerder zo hebben opgelost"), wordt een leesbare regel met een herleidbare beslisgrond.
Dit patroon — detecteren, beslissen, uitvoeren, vastleggen — komt terug in GW-08 over Detect. Decide. Act. De relatie tot brede operationele rijpheid staat in AP-01, het MSP Automation Maturity Model.
Documentatie alléén verschuift kennis van hoofd naar archief. Systemen die kennis afdwingen — die het uitvoeren ervan vereisen of automatiseren — verschuiven kennis van hoofd naar werking. Pas dan ontstaat een OAG-daling die in de dagelijkse operatie zichtbaar wordt.
6. Wanneer is investeren in OAG-reductie de moeite waard?
Niet elke MSP heeft hetzelfde investeringsmoment. Vier categorieën:
| Categorie | Trigger-conditie |
|---|---|
| Nog niet automatiseren | Schaal te klein (< 5 engineers), OAG laag, geen overnameperspectief op middellange termijn |
| Eerst proces standaardiseren | OAG hoog, maar processen ongedocumenteerd — automatisering zonder onderliggende discipline lost niets op en kan zelfs verbergen waar de afhankelijkheid zit |
| Nu automatiseren | OAG hoog, processen beschreven maar handmatig — directe payback in BAU door capaciteitsvrijgave |
| Nu agressief automatiseren | OAG hoog én een overname binnen twee jaar realistisch, óf OAG blokkeert actief een groeibeweging die anders mogelijk zou zijn |
Nog niet automatiseren
Schaal te klein (< 5 engineers), OAG laag, geen overnameperspectief op middellange termijn
Eerst proces standaardiseren
OAG hoog, maar processen ongedocumenteerd — automatisering zonder onderliggende discipline lost niets op en kan zelfs verbergen waar de afhankelijkheid zit
Nu automatiseren
OAG hoog, processen beschreven maar handmatig — directe payback in BAU door capaciteitsvrijgave
Nu agressief automatiseren
OAG hoog én een overname binnen twee jaar realistisch, óf OAG blokkeert actief een groeibeweging die anders mogelijk zou zijn
De categorieën zijn cumulatief in volgorde, niet in zwaarte: een MSP die in "eerst proces standaardiseren" zit, kan zonder die stap niet succesvol naar "nu automatiseren". Wie probeert de volgorde over te slaan, automatiseert chaos.
7. Veelgestelde vragen
Mijn senior engineers zijn loyaal — moet ik dit nu écht aanpakken?
Loyaliteit is geen mitigatie voor operationele afhankelijkheid. Loyale engineers kunnen ziek worden, met pensioen gaan, of de werkdruk die loyaliteit met zich meebrengt niet onbeperkt blijven dragen. OAG is geen vertrouwensvraagstuk maar een continuïteitsvraagstuk. Bovendien: organisaties met hoge OAG vragen het meest van hun loyale mensen, juist omdat het systeem hen nodig heeft. Loyaliteit erodeert dan in stilte.
Verlies ik niet juist mijn beste mensen als ik hun kennis vastleg?
Het tegenovergestelde patroon komt vaker voor. Senior engineers die uitsluitend brandhaarden blussen, branden zelf op. Senior engineers wier kennis verankerd is in systemen, krijgen ruimte voor architectuur, klantstrategie en het ontwikkelen van anderen — werk dat hen aan een organisatie bindt in plaats van uitput.
Wat kost OAG-reductie en wanneer is de payback?
Het grootste deel van de payback zit in BAU — niet in een toekomstige verkoop. Capaciteitsvrijgave van senior engineers, lagere MTTR en minder uitgesteld werk leveren in omgevingen met hoge OAG een payback op in een orde van grootte van twaalf tot vierentwintig maanden. De exacte termijn hangt sterk af van waar je begint en hoe ver je gaat.
Telt dit ook als ik nooit ga verkopen?
Ja. OAG is in de eerste plaats een BAU-vraagstuk. Pas in de tweede plaats een M&A-vraagstuk. Hoge OAG drukt marge, beperkt schaal en vergroot incident-risico — los van enige verkoopintentie. Dat een koper er een prijs op zet, is een gevolg van de operationele realiteit, niet een vervanging ervan.
Hoe meet ik OAG zonder dure consultancy?
Per dimensie aan de hand van een handvol concrete vragen. Voor klantkennis: kan een andere engineer dan X klant Y zelfstandig bedienen? Voor configuratiebeheer: staat de actuele staat van klantomgevingen in een systeem dat het team kan lezen, of in losse tools? Voor incidentafhandeling: hoeveel P1-incidenten in de afgelopen drie maanden moesten naar een specifieke persoon? Voor besluitvorming: welke wijzigingen wachten standaard op één persoon? Het MSP Automation Maturity Model biedt het bredere zelfdiagnose-kader.
Hoe UptimePilot dit aanpakt
In de praktijk daalt OAG pas wanneer operationele kennis onderdeel wordt van de werking zelf: detectie, beslissing, uitvoering en vastlegging. UptimePilot past dat patroon toe op de infrastructuurlaag van een mkb-MSP.
OAG-reductie is in die zin geen apart project. Het is een bijproduct van operationele discipline die het systeem afdwingt — en niet aan goede voornemens overlaat.
Volgende stap
Wil je weten hoeveel van je operatie in mensen vastzit in plaats van in systemen?
In een demo lopen we per dimensie door je OAG-profiel heen en laten we zien waar UptimePilot de afhankelijkheid actief verlaagt.
Plan een demo →