Business Brief
Engineer aannemen of automatiseren?
Het kantelpunt voor mkb-MSPs — en wat incidentvolume je vertelt over de juiste investering.
Voor een mkb-MSP met een herhalend incidentvolume boven 80 tot 120 tickets per maand kantelt de economische balans van een extra engineer naar operationele automatisering. Onder dat volume is een hire vrijwel altijd de juiste keuze; daarboven verandert de kostencurve fundamenteel. Het kantelpunt is geen marktnorm maar een functie van vier variabelen: incidentvolume, herhalingsgraad, volledig belaste engineering-uurkost en de mate van procesdocumentatie vooraf. Deze brief is een investeringsbeslissing, geen operationele diagnose — de overlap met alert-fatigue-analyse is bewust: dezelfde variabelen, ander doel.
Vuistregel
1. Engineer of automatisering: waarom de vraag verkeerd wordt gesteld
De vraag wordt in mkb-MSP-land vaak gesteld als een keuze tussen twee alternatieven van dezelfde categorie: "moeten we een nieuwe engineer aannemen of in automatisering investeren?" Die framing is bijna altijd misleidend. Een engineer en een automatiseringsplatform zijn geen substituten op het hele werkterrein — alleen op een specifieke deelverzameling. Wie de vergelijking op het verkeerde scope-niveau maakt, krijgt onbruikbare uitkomsten.
De juiste vraag is daarom niet "engineer of automatisering", maar "bij welk niveau van herhalend incidentvolume wordt het marginaal goedkoper om dat herhalende deel uit handen van de engineer te nemen?". De niet-herhalende werkstromen — projectwerk, klantadvies, escalaties — blijven menselijk werk, ongeacht welke investering je doet. De vergelijking gaat dus alleen over de capaciteit die nodig is om het herhalende deel af te handelen, niet over de hele engineering-functie.
Wat de vergelijking voor mkb-MSPs bijzonder maakt, is dat beide investeringen niet alleen op kosten verschillen, maar ook op risicoprofiel en schaalbaarheid. Een engineer-hire schaalt lineair: je betaalt voor een vaste capaciteit, ongeacht of die op piekmomenten net niet voldoende is of in dalmomenten onderbenut. Automatisering schaalt anders: je betaalt voor een platform dat alle herhalende events afhandelt, ongeacht of dat er 50 per maand zijn of 500. Pas in vergelijking van deze twee kostencurves wordt zichtbaar waar het kantelpunt ligt.
Tot slot één expliciete afbakening: deze analyse is een investeringsbeslissing — wat is goedkoper op de marge? Het is geen diagnose van wat je huidige operatie kost (dat is een alert-fatigue-analyse) en geen ROI-berekening over een specifiek platform (dat is een payback-analyse). De drie analyses gebruiken overlappende variabelen, maar leveren verschillende antwoorden op verschillende vragen.
2. Wat een engineer-hire werkelijk kost
De volledig belaste kost van een engineer in een Nederlandse mkb-MSP ligt naar werkhypothese 1,4 tot 1,7 keer hoger dan het bruto-salaris. Dat is geen marktnorm maar een bandbreedte die de meeste MSPs herkennen als ze hun eigen cijfers nalopen. Wat in die opslag zit, is grotendeels niet-loongerelateerd.
| Kostencomponent | Type | Bandbreedte (werkhypothese) |
|---|---|---|
| Bruto-jaarsalaris L2/L3-engineer | Doorlopend | €55.000 – €75.000 |
| Sociale lasten en werkgeverskosten | Doorlopend | ~25 procent bovenop bruto |
| Werkplek, tooling, certificaties | Doorlopend | €4.000 – €8.000 per jaar |
| Werving en onboarding (over 3 jaar afschrijven) | Eenmalig | €8.000 – €18.000 |
| Management-overhead en mentoring | Doorlopend | ~5 tot 10 procent van de full-time-equivalent kost |
| Volledig belaste jaarkost | Doorlopend | ~€85.000 – €120.000 |
Werkhypothese, geen marktnorm. Werkelijke uitkomsten zijn afhankelijk van regio, ervaringsniveau en marktomstandigheden in de Nederlandse arbeidsmarkt voor IT-engineers. Bij senior-profielen of schaars gespecialiseerde rollen ligt de bovenkant aanzienlijk hoger.
Vertaald naar uurkost: bij circa 1.700 productieve uren per jaar (na vakantie, training, ziekteverzuim) komt de volledig belaste uurkost neer op een werkhypothese van 50 tot 70 euro per uur — in lijn met het bereik dat in de payback-analyse wordt gebruikt en in de Nederlandse ticket-kost-benchmark.
Eén nuance die in mkb-MSP-context vaak ontbreekt: een hire is geen vaste maandlast die je naar believen kunt afschalen. Eenmaal aangenomen, draagt die kost door — ongeacht of het incidentvolume volgende maand met 30 procent daalt of stijgt. Voor de marginale beslissing waar deze analyse over gaat, is dat een wezenlijk verschil met een platform-investering, die meeschaalt met het werkelijke aanbod aan events.
3. Wat automatisering werkelijk kost
De volledige eigenaarschapskost van een automatiseringsplatform voor een mkb-MSP bestaat uit drie componenten, en is structureel anders opgebouwd dan een engineering-hire.
| Kostencomponent | Type | Bandbreedte (werkhypothese) |
|---|---|---|
| Platform-licentie of abonnement | Doorlopend | €18.000 – €48.000 per jaar |
| Implementatie en initiële policy-set | Eenmalig (over 3 jaar) | €20.000 – €50.000 |
| Onderhoud van policies en uitbreidingen | Doorlopend | ~5 tot 10 uur per maand engineering-tijd |
| Volledig belaste jaarkost | Doorlopend | ~€30.000 – €70.000 |
Werkhypothese, geen marktnorm. Werkelijke uitkomsten zijn afhankelijk van leverancier, schaal van de portefeuille, en de mate waarin processen vooraf gedocumenteerd zijn. De onderkant van de bandbreedte veronderstelt een MSP met goede runbook-discipline; de bovenkant veronderstelt aanzienlijke procesinrichting als onderdeel van de implementatie.
Wat de kostencurve van automatisering structureel anders maakt dan die van een engineer: de variabele kost per extra event is laag. Een platform dat 50 events per maand afhandelt en een platform dat 500 events per maand afhandelt, scheelt in licentiestructuur typisch weinig — vaak een schaal-factor in de orde van 1,3 tot 1,8, niet 10. Bij een engineer is die schaalrelatie veel directer: 10× zoveel werk betekent in benadering 10× zoveel engineers — of een operationele crisis.
Een tweede verschil: implementatie is een eenmalige kost met een voorspelbare doorlooptijd. Een hire is een eenmalige kost (werving) plus een doorlopend risico (verloop, ziekteverzuim, marktconcurrentie om talent). Voor de marginale beslissing weegt dat verschil mee — niet als hard getal, maar als risicokorting op de doorlopende kostencurve van de hire.
4. Het kantelpunt: bij welk incidentvolume verschuift de balans?
De kantelpunt-vraag laat zich uitdrukken in één formule. De vraag is: bij welk maandelijks herhalend incidentvolume wordt het marginaal goedkoper om dat werk via automatisering te laten lopen in plaats van via een extra engineer?
Kantelpunt (events/maand) = (Jaarkost engineer − Jaarkost automation) ÷ (12 × Uurkost engineer × Tijd per event in uren)
Met de werkhypotheses uit secties 2 en 3 en een typische tijd per event van 0,5 uur (variabel naar incidenttype):
Het kantelpunt schuift mee met de inputs. Bij een lagere automation-jaarkost daalt het kantelpunt; bij een duurdere engineer of langere tijd per event daalt het ook. Bij een goedkopere engineer of complexere events met meer manuele afhandeling stijgt het. De 128-events-per-maand is geen universeel getal — het is een illustratie van de orde van grootte.
Belangrijk: dit getal heeft alleen betekenis als het wordt vergeleken met het herhalend incidentvolume, niet met het totale ticketvolume. Een MSP met 300 tickets per maand maar slechts 60 daarvan in herhalende categorieën zit ondanks het hoge totaal nog steeds in het engineer-domein. Het is de samenstelling, niet de omvang, die bepaalt waar de balans kantelt — en dat hangt nauw samen met de EKM-belasting van je portefeuille.
5. Drie scenario’s: licht, typisch, zwaar volume
Dezelfde formule, drie verschillende incidentvolumes — en de uitkomst verschuift radicaal. Werkhypothese: engineer-jaarkost €100.000, automation-jaarkost €50.000, tijd per event 0,5 uur, engineer-uurkost €65.
| Variabele | Licht | Typisch | Zwaar |
|---|---|---|---|
| Herhalend incidentvolume (events/maand) | ~60 | ~150 | ~350 |
| Engineering-uren per maand op herhalend werk | ~30 | ~75 | ~175 |
| Kost herhalend werk via engineer-uurkost | ~€23k/jr | ~€58k/jr | ~€137k/jr |
| Vergelijking met automation-jaarkost (€50k) | Automation duurder | Automation 14% goedkoper | Automation 64% goedkoper |
| Conclusie | Eerst proces standaardiseren | Nu automatiseren | Nu agressief automatiseren |
Werkhypothese ter illustratie van orde van grootte. Werkelijke kantelpunten zijn afhankelijk van uurkost-bandbreedte, tijd-per-event-verdeling, en eventuele schaalvoordelen op de automation-licentie bij grotere portefeuilles. De typische uitkomst in deze tabel ligt dichtbij het kantelpunt en is bewust gekozen om te tonen waar de marginale beslissing onzeker wordt.
Drie inzichten uit de scenario-tabel. Het lichte profiel laat zien waarom automatisering in kleine MSP-portefeuilles vaak voortijdig wordt aangeschaft: het volume is er simpelweg niet om de investering te dragen, ongeacht hoe overtuigend de leverancier-pitch is. Het typische profiel is het meest interessant omdat de uitkomst dichtbij het kantelpunt ligt — kleine veranderingen in aannames kantelen de beslissing. Het zware profiel laat zien dat uitstel op een bepaald moment duurder wordt dan implementatie-risico.
Een dimensie die in deze tabel niet zichtbaar wordt maar wel meeweegt: de mate van procesvolwassenheid. Een MSP op niveau 1 of 2 van het MSP Automation Maturity Model behaalt zelfs bij hoog volume zelden de bovenkant van het automation-rendement — eerst moet de procesfundament op orde. Voor MSPs op niveau 3 en hoger schuift het werkelijke kantelpunt naar links, omdat de implementatie-kost lager uitvalt.
6. Besliskader: welke investering past bij jouw volume?
De vraag is zelden binair. Vier profielen, gerangschikt op herhalend incidentvolume per maand:
Minder dan 50 events/maand
Nog niet automatiseren
Onder dit volume is een engineer-investering vrijwel altijd logischer, of moet je voorlopig de bestaande capaciteit optimaliseren. De vaste kost van automatisering spreidt zich over te weinig events om concurrerend te zijn. Mocht het volume binnen 12 maanden naar verwachting groeien, plan dan een herziening — maar geen investering nu.
→ Engineer-hire of procesoptimalisatie. Automation uitstellen.
50 tot 120 events/maand
Eerst proces standaardiseren
Dit is de zone waar de beslissing het meest gevoelig is voor aannames. Een MSP met goede runbook-discipline en een hogere uurkost zit feitelijk al boven het kantelpunt; een MSP zonder die discipline zit er waarschijnlijk onder, omdat de implementatie-kost de automation-jaarkost opdrijft. Eerst valideren op je eigen cijfers, dan beslissen.
→ Eigen kantelpunt-berekening valideren. Beslissing volgt uit de cijfers.
120 tot 300 events/maand
Nu automatiseren
Boven het typische kantelpunt wordt automatisering structureel goedkoper dan een marginale hire — en het verschil groeit met elk extra event. In deze zone is uitstel duurder dan implementatie: elke maand wachten betekent een extra maand engineering-tijd kwijt aan werk dat geautomatiseerd had kunnen worden. Starten met de top-5 herhalende incidenttypes geeft de snelste payback.
→ Fasering op incidenttype-impact. Hire alleen voor niet-herhalend werk.
Meer dan 300 events/maand
Nu agressief automatiseren
Op dit volume is een engineer-hire-strategie niet alleen duurder, hij is operationeel niet meer haalbaar — geen Nederlandse mkb-MSP kan in dit tempo betrouwbaar hires plaatsen. Parallelle uitrol op meerdere incidenttypes, met capaciteitsherbestemming als expliciet doel. De vraag is niet meer "wel of niet", maar "hoe snel".
→ Parallelle uitrol op meerdere incidenttypes. Arbeidsmarktrisico zelf is reden genoeg.
Eén veelvoorkomende valkuil
Veel MSPs proberen het kantelpunt te omzeilen door beide te doen: een hire én automatisering, in de hoop dat de capaciteitsexpansie het volume opvangt. In specifieke groeisituaties is dat verantwoord — als je werkelijk verwacht binnen 12 maanden 2× zoveel klanten te bedienen. In de meeste gevallen leidt het echter tot onderbenutte hires of onderbenutte automation, omdat het volume niet meegroeit zoals voorspeld. De kantelpunt-analyse dwingt je om expliciet te zijn: welke van de twee is de marginale beslissing? Zelden zijn het beide tegelijk.
7. Veelgestelde vragen
Is dit niet hetzelfde vraagstuk als de operationele alert-fatigue-kost waar we eerder naar gekeken hebben?
Het is een ander vraagstuk dat gebruikmaakt van overlappende variabelen. De alert-fatigue-analyse meet wat de huidige operatie kost in personeelsbelasting en kwaliteitsverlies — een diagnose van de status quo. Deze kantelpunt-analyse meet wat een toekomstige investering oplevert ten opzichte van een alternatief — een vergelijking van twee toekomstige scenarios. Een MSP die alleen naar alert-fatigue-kosten kijkt, weet of er een probleem is. Een MSP die de kantelpunt-analyse doet, weet welke interventie het probleem het meest kostenefficiënt oplost.
Onze engineers doen meer dan herhalend werk. Hoe weeg ik die andere taken mee in de vergelijking?
Door de vergelijking expliciet te beperken tot het herhalende deel. Een engineer doet typisch drie soorten werk: herhalend incident-werk, projectwerk, en advieswerk. Alleen het eerste is direct vergelijkbaar met automatisering. Voor de kantelpunt-analyse splits je de tijdsverdeling van je engineers, en gebruikt het percentage dat naar incident-werk gaat als de relevante variabele. Een engineer die 60 procent van de tijd aan incidenten besteedt, draagt 60 procent van zijn volledige belaste kost bij aan de vergelijking. De andere 40 procent valt buiten de scope — dat is werk dat automatisering niet vervangt.
Wat als we een engineer net hebben aangenomen en nu pas automatisering overwegen? Maakt dat de berekening anders?
Niet in de structuur, wel in de interpretatie. Een recente hire vertegenwoordigt geen marginale beslissing meer — die kost loopt door, ongeacht je investeringskeuze. De kantelpunt-analyse blijft relevant voor de volgende hire-beslissing: wat is goedkoper op het moment dat capaciteit weer een probleem wordt — een tweede hire of automatisering? In die situatie kan automatisering juist de hire-kandidaat zijn die je nu niet hoeft te plaatsen, en dat is feitelijk de sterkste vorm waarin de business case zich uit: niet als kostenbesparing op bestaand personeel, maar als vermeden volgende kostenpost.
Hoe houd ik rekening met arbeidsmarktrisico — engineers zijn schaars en wat als we de juiste persoon niet kunnen vinden?
Door arbeidsmarktrisico expliciet als variabele te behandelen, niet als achtergrondruis. In de huidige Nederlandse arbeidsmarkt voor IT-engineers is de doorlooptijd tot een succesvolle hire vaak 3 tot 6 maanden — soms langer voor gespecialiseerde profielen. Tijdens die wachttijd loopt de overbelasting van het bestaande team door, met als gevolg verhoogd verloop-risico (zie de aanpalende analyse over verloop-kosten in MSP-land). Automatisering kent dat risico niet: implementatietijd is voorspelbaar en niet afhankelijk van een externe pool. In configuraties waar arbeidsmarkt-onzekerheid hoog is, schuift het kantelpunt structureel in het voordeel van automatisering.
Onze incidenten zijn juist niet repetitief — kan automatisering dan überhaupt helpen?
Niet als de premisse klopt. Maar in de praktijk schat de meeste MSP-eigenaar het herhalingspercentage van zijn incidenten te laag in, omdat hij de incidenten waarderend onthoudt (de complexe escalatie van vorige week) en niet kwantitatief beoordeelt (de zes identieke disk-space-alerts van afgelopen maand). Een eenvoudige analyse: pak je ticket-export van het laatste kwartaal en cluster de tickets op type. Vrijwel altijd valt 50 tot 70 procent van het volume in 10 tot 15 herhalende categorieën. Die categorieën zijn de scope van een kantelpunt-analyse — niet de complexe staart die nooit terugkomt.
Wat als de uitkomst van de analyse "geen van beide" is — en we het werk gewoon moeten herzien?
Dat is een geldige uitkomst en vaker voorkomend dan eigenaren denken. Het wijst doorgaans op een onderliggend procesprobleem: incidenten die niet onmiskenbaar herhalend zijn omdat ze symptomen zijn van iets anders (slechte klantsegmentering, gebrekkige onboarding, achterstallig onderhoud). In dat scenario is investeren in capaciteit — engineer of automatisering — minder effectief dan investeren in oorzaak-eliminatie. De kantelpunt-analyse maakt dit zichtbaar: als beide opties een vergelijkbare slechte ROI tonen, ligt het echte probleem ergens anders dan in capaciteitstekort.
Hoe UptimePilot dit aanpakt
UptimePilot is gepositioneerd om aan de juiste kant van het kantelpunt te zitten voor de meeste mkb-MSPs vanaf 50 klanten. De implementatie start met een feitelijke meting van het herhalend incidentvolume in jouw portefeuille — niet met een platform-pitch. Pas als die meting boven het kantelpunt uitkomt, is een investering verantwoord.
Een gesprek begint daarom altijd met de incidentvolume-meting — niet met een product-demo. Zonder die meting is elke kantelpunt-conclusie een aanname; mét meting wordt het een toetsbare beslissing.
Volgende stap
Waar ligt jouw kantelpunt — en zit je erboven of eronder?
In een demo doorlopen we eerst je incidentvolume van het laatste kwartaal, splitsen we herhalend van niet-herhalend werk, en berekenen we waar jouw eigen kantelpunt ligt. Geen aanname, geen marketing-cijfer.
Plan een demo →