Sector
Kennisborging bij IT-dienstverleners en MSP's
Elke klantomgeving heeft eigen afwijkingen van het standaardplaatje. Bij een MSP bepaalt niet het beheerplatform, maar de tweedelijnsengineer wat er echt gebeurt als een storing buiten het boekje valt.
01Uitgangspositie
Documentatie loopt achter op de praktijk
Een MSP werkt met een CMDB, een RMM-platform en een PSA-tool voor tickets en contracten, maar de kennis die een storing echt oplost zit vaak niet in een van deze systemen.
In theorie beschrijft het runbook per klant welke stappen bij een incident horen: welke server als eerste herstart, welke firewallregel een uitzondering vormt, welk wachtwoordbeheer afwijkt van het standaardsjabloon. In de praktijk wordt een runbook geschreven bij de opstart van een contract en zelden herzien zodra de omgeving verandert.
Een tweede- of derdelijnsengineer die een terugkerend probleem drie keer heeft opgelost, weet inmiddels dat de officiële workaround uit het runbook niet meer werkt sinds een firmware-update. Die wetenschap wordt gedeeld in een ticketopmerking of mondeling tussen collega's, maar zelden teruggeschreven naar het runbook zelf.
Zo ontstaat een gat tussen wat het CMDB zegt dat waar is en wat de engineer weet dat waar is. Voor de klant maakt dat gat weinig verschil zolang dezelfde engineer beschikbaar blijft. Zodra die persoon met verlof is, van team wisselt of vertrekt, wordt het gat zichtbaar in de vorm van een langere oplostijd of een verkeerde escalatie.
02Rolverdeling
Wie draagt welke kennis
- Servicedeskmedewerker (L1)
- Herkent bekende patronen aan de hand van scripts en beslisbomen
- Tweede- en derdelijnsengineer
- Kent klantspecifieke uitzonderingen en tijdelijke workarounds
- Accountmanager of delivery lead
- Kent contractuele afspraken en escalatiepaden richting de klant
- Security officer
- Bewaakt toegangsgrenzen per klant en welke informatie klantoverstijgend gedeeld mag worden
03Beslismomenten
Wanneer moet kennis worden vastgelegd, niet alleen opgelost
- Een incident wordt met een workaround opgelost die afwijkt van het runbook
- Zonder terugkoppeling herhaalt de volgende engineer het uitzoekwerk
- Een klant vraagt om een tijdelijke uitzondering op het standaard toegangsbeleid
- Zonder vastlegging van de reden en einddatum wordt de uitzondering permanent zonder besluit
- Een accountteam wisselt van eigenaar
- Afspraken die nooit in het contract stonden, maar wel golden, gaan verloren
- Een tool wordt vervangen (bijvoorbeeld het RMM-platform)
- Klantspecifieke scripts en filters moeten opnieuw worden herbouwd op basis van geheugen
04Kennisrisico's
Waar gaat kennis het vaakst verloren
- Tickets die nooit worden samengevat
- Een opgeloste storing bevat vaak de beste beschrijving van een uitzondering, maar tickets worden zelden herlezen als kennisbron; ze worden gesloten en vergeten.
- Mondelinge overdracht bij ploegwissels
- Bij 24/7-dienstverlening wordt kennis over lopende issues vaak mondeling doorgegeven aan het volgende team, zonder dat dit ergens structureel wordt vastgelegd.
- Persoonlijke aantekeningen van senior engineers
- Ervaren engineers houden eigen notities bij over klantomgevingen die nooit gedeeld worden met het bredere team.
05Validatie
Wie mag een uitzondering als geldig bestempelen
Technisch lead per klantaccount
Beoordeelt of een workaround structureel in het runbook hoort of eenmalig blijft
Security officer
Valideert of een toegangsuitzondering binnen het beveiligingsbeleid van de klant past
Klantcontact of accountmanager
Bevestigt of een afspraak nog steeds gewenst is voordat deze als standaard wordt vastgelegd
06Voorbeeld uit de praktijk
Wanneer het runbook en de praktijk botsen
Een MSP beheert de infrastructuur van een middelgrote zorginstelling. Het runbook schrijft voor dat bij een storing in de authenticatieomgeving eerst de identity-server wordt herstart. Een derdelijnsengineer weet echter dat deze stap sinds een migratie naar een nieuwe directory-dienst averechts werkt: een herstart forceert een resynchronisatie die de storing juist verlengt.
Toen deze engineer met verlof was, volgde een collega het runbook letterlijk. De storing duurde daardoor aanzienlijk langer dan nodig, en de klant escaleerde naar het management omdat de afgesproken reactietijd in het gedrang kwam.
Achteraf bleek dat de afwijkende kennis nooit was teruggekoppeld naar het runbook, ondanks dat de workaround al maanden werd toegepast. Vakinhoudelijk bleef de oplossing bij de engineer zelf; het punt was niet de technische keuze maar het ontbreken van een vastgesteld moment waarop die kennis institutionele status kreeg.
07Operationele uitkomst
Wat verandert als klantkennis wel wordt vastgelegd
- Kortere doorlooptijd bij ploegwissel
- Een nieuwe of vervangende engineer vindt de actuele uitzondering terug in plaats van het incident opnieuw te moeten doorgronden.
- Minder afhankelijkheid van individuele engineers
- Klantspecifieke kennis is niet langer gekoppeld aan de beschikbaarheid van één persoon.
- Beter onderbouwde escalaties
- Accountteams kunnen bij een klantgesprek verwijzen naar een vastgestelde afspraak in plaats van een losse herinnering.
Start gratis met KOS.
Bouw uw eerste kennisdomein op en doorloop de volledige kenniscyclus.
Alle onderwerpen in het kennisoverzicht.
Elk thema staat op zichzelf: het probleem, de sector of het moment waarop kennis wordt vastgesteld.