Overview

Een grote Nederlandse netbeheerder wilde kritieke IT-incidenten niet alleen tellen. De organisatie moest kunnen onderzoeken uit welk systeem een incident kwam, welke afdeling erbij betrokken was, wat de mogelijke hoofdoorzaak was en hoe het incident samenhing met onderliggende problems en uitgevoerde changes. DataGrow bracht die informatie samen in één datamodel en een informatieproduct voor operationele sturing.

Wat de oplossing samenbracht

• Incidenten, problems en changes in één samenhangend model;
• Analyse per systeem, afdeling en mogelijke hoofdoorzaak;
• Kennis van domeinexperts en de technische route van data-engineers;
• Een stuurlaag die binnen de bestaande dataomgeving van de organisatie paste.

Als een incident organisatiebreed voelbaar wordt

Een high-priority incident vraagt direct aandacht van verschillende teams. Technische specialisten onderzoeken wat er is uitgevallen. Operationele teams willen weten welke dienstverlening geraakt wordt. De verantwoordelijke head moet ondertussen kunnen uitleggen hoe vaak dit gebeurt, waar de incidenten ontstaan en welke structurele verbeteringen nodig zijn.

Binnen deze netbeheerder lag voor die laatste vragen nog geen centraal analysekader. De organisatie registreerde incidenten, maar kon de gegevens niet vanuit één plek verbinden met de achterliggende problems, changes, systemen en verantwoordelijke afdelingen. Daardoor bleef het lastig om patronen te herkennen en een gerichte verbeteragenda te onderbouwen.

De uitdaging zat ook in de organisatievorm. IT-verantwoordelijkheid was verdeeld over verschillende ketens, afdelingen en teams. Een incident kon op één plek zichtbaar worden terwijl de technische oorzaak, de relevante change en het eigenaarschap elders lagen. Wie het probleem wilde begrijpen, moest eerst weten welke mensen en systemen bij elkaar hoorden.

De vraag achter het dashboard

De eerste behoefte was een helder overzicht van de performance van een afdeling. Onder die managementvraag lag een concreter operationeel probleem: het aantal high-priority incidenten moest omlaag en de verantwoordelijke teams hadden beter inzicht nodig in terugkerende oorzaken.

Een rapport met alleen aantallen zou weinig veranderen. De organisatie moest per incident kunnen onderzoeken:

• In welk systeem het ontstond;
• Welke afdeling of welk team erbij hoorde;
• Met welk problem het was verbonden;
• Welke change eraan voorafging of erop volgde;
• Welke hoofdoorzaak was vastgelegd;
• Waar een structurele verbeteractie nodig kon zijn.

Daarmee verschoof de opdracht van visualisatie naar beslisinformatie. Het dataproduct moest een gesprek ondersteunen over oorzaken, eigenaarschap en preventie.

Eerst begrijpen wie welke beslissing moest nemen

DataGrow begon bij de informatiebehoefte van de verantwoordelijke head en de lead die het inzicht moest organiseren.

• Welke vragen moesten zij in een stuurmoment kunnen beantwoorden?
• Welke acties konden volgen uit het antwoord?
• En op welk detailniveau moest iemand kunnen doorklikken?

Daarna sprak het team met domeinexperts die het incidentproces kenden. Zij konden uitleggen hoe incidenten werden geregistreerd, hoe problems en changes zich tot elkaar verhielden en welke uitzonderingen in de praktijk voorkwamen. Die gesprekken waren nodig om te voorkomen dat een technisch correct model de operationele werkelijkheid verkeerd zou weergeven.

Parallel bracht DataGrow samen met interne data-engineers het datalandschap in kaart: de relevante bronsystemen, de route via het datawarehouse, de toegangsvoorwaarden en de ontwikkelafspraken van de organisatie. Zo kon het product aansluiten op de bestaande omgeving in plaats van ernaast te komen staan.

Het technische mechanisme: relaties zichtbaar maken

Een incidentrecord zegt dat er iets is gebeurd. Voor structurele verbetering is meer context nodig. DataGrow modelleerde daarom de relaties tussen:

• 1. Het incident;
• 2. Het onderliggende problem;
• 3. Een relevante change;
• 4. Het geraakte systeem;
• 5. Het verantwoordelijke organisatieonderdeel;
• 6. De geregistreerde hoofdoorzaak.

De benodigde gegevens werden via de goedgekeurde route ontsloten en in het datawarehouse samengebracht. Daarop bouwde DataGrow een BI-laag waarmee gebruikers vanuit het totaalbeeld naar afzonderlijke systemen, afdelingen en oorzaken konden navigeren.

Deze opzet maakte nieuwe analyses mogelijk. Teams konden bijvoorbeeld onderzoeken of incidenten zich rond bepaalde typen changes concentreerden, welke systemen vaker voorkwamen en waar geregistreerde problems nog aandacht vroegen. Het model leverde geen automatische causaliteit: domeinexperts bleven nodig om patronen te beoordelen en verbetermaatregelen te kiezen.

Werken binnen de organisatie, samen met het interne datateam

De interne datafunctie bleef verantwoordelijk voor platform, toegang en technische standaarden. De business- en domeinexperts bewaakten de betekenis van de informatie. DataGrow verbond die twee werelden en nam de coördinatie van het project op zich.

Dat vroeg meer dan een technische koppeling. De juiste bronhouder moest worden gevonden, definities moesten worden afgestemd en verschillende teams moesten akkoord geven op de gekozen route. DataGrow kon daarbij door de organisatie bewegen, terwijl de oplossing binnen de interne werkwijze en ontwikkelomgeving bleef.

Deze samenwerking beantwoordde ook een belangrijk risico voor grote netbeheerders: extra snelheid mocht niet leiden tot een los dataproduct dat later moeilijk te beheren was. De betrokkenheid van interne engineers en domeinexperts maakte de technische en inhoudelijke keuzes toetsbaar.

Herkenbaar voor andere netbeheerders

Dit probleem ontstaat vooral wanneer één verantwoordelijke op een kritieke KPI wordt aangesproken, terwijl data, systemen en eigenaarschap over meerdere teams zijn verdeeld. Het interne datateam kan sterk zijn en toch onvoldoende ruimte hebben om iedere businessvraag direct op te pakken.

Een werkbare eerste scope begint dan bij één beslissing:

• Welke incident-KPI moet beter verklaarbaar worden?
• Welke bronnen zijn nodig om van telling naar oorzaak en actie te gaan?
• Wie bezit de betekenis, wie bezit de techniek en wie beslist over prioriteit?
• Wat moet in het volgende stuurmoment aantoonbaar beter kunnen?