Wie weet ken je de bekende uitspraak uit de komische tv-serie Little Britain: “The computer says no” van Carol die als nogal onbeschofte receptioniste in een Engels ziekenhuis werkt. In de realiteit zal zoveel klantonvriendelijkheid niet voorkomen. Toch zijn genoeg situaties waarbij problemen een eigen leven gaan leiden en hoofd- en bijzaken niet gescheiden worden of verantwoordelijkheden niet op tijd genomen worden.
Een kleine test: Welke problemen zijn groter?
- Dat de opslag voor verschillende virtuele servers niet toegankelijk is of het feit dat er geen cliëntgegevens in het ECD, elektronisch cliëntendossier, kunnen worden ingevuld?
- Dat een autorisatiesysteem niet werkt of dat er goedkeuringen op grote ordertrajecten blijven liggen?
- Een niet werkende back-up of het niet kunnen terughalen van door ransomware geïnfecteerde bestanden?
Waar ik naar toe wil is dat ‘het werkt niet, wij houden ons aan de procedure of het is de verantwoordelijkheid van de ICT afdeling’ kan leiden tot serieuze problemen in bijvoorbeeld de zorgverlening of hiccups in welke klantrelatie dan ook. Omdat ik van eenvoud, duidelijkheid en gemak hou ging ik voor een klant op zoek naar een werkbaar model om een incident in kaart te brengen, waarmee mogelijke oorzaken van een probleem beter gerangschikt kunnen worden.
Met dank aan Kaoru Ishikawa
Kaoru Ishikawa is bekend als de man achter ‘het visgraatmodel’ en is voor mij een inspiratiebron geweest. Het is een grafisch hulpmiddel waarin een diagram het onderscheid maakt tussen mogelijke oorzaken en gevolgen. Door op een bredere manier naar een probleem te kijken kunnen bestaande problemen op andere manieren dan gebruikelijk worden opgelost. Voor mij bleek zijn gedachtegang erg bruikbaar te zijn, echter gebruik ik niet zijn M’s van mens, machine, metingen, materialen, milieu en methode. Bij Kaoru Ishikwa ging het om fabrieken, bij ons om probleemloos werkende ICT omgevingen.
Het “Guillermo model”
Geïnspireerd door het ‘ visgraat-denken’ hebben we recent een RCA, Root Cause Analysis met succes uitgevoerd waarbij we de oorzaken van een incident hebben blootgelegd en advies uitgebracht. Deze informatie is natuurlijk vertrouwelijk, maar wel willen we aangeven dat we in dit model naar drie belangrijke assen kijken:
1. Gebruikers
Als het over gebruikers gaat dan wordt er bijvoorbeeld gekeken of er voldoende capaciteit is om de juiste aandacht aan mogelijke incidenten te kunnen geven. In sommige gevallen blijkt er een grote afhankelijk te bestaan van slechts één persoon, wat tot ernstige problemen kan leiden. De afhankelijkheid van een persoon kan voorkomen worden door meerdere gebruikers verantwoordelijkheid te geven of op te leiden.
2. Organisatie en processen
Hierbij brengen we onder andere in kaart welke processen en procedures er zijn en kijken we naar het doel en het effect ervan. Voldoet het bijvoorbeeld aan de beveiligingsnormen, zijn procedures getest en welke service levels met leveranciers zijn er afgesproken. Daarnaast wordt onderzocht of er bij uitbestede werkzaamheden de verantwoordelijkheden onderling duidelijk zijn om hoofdpijndossiers over wel of geen verantwoordelijkheid te voorkomen.
3. Techniek
Problemen kunnen ontstaan aan de gebruikerszijde of door het ontbreken van de juiste processen, maar zij kunnen natuurlijk ook een technische oorzaak hebben. In ons model kijken we daarom ook met een brede blik naar producten en systemen. Zijn systemen juist geconfigureerd, voldoen zij aan het beveiligingsbeleid van de organisatie en kan de beschikbaarheid die vereist wordt wel gerealiseerd worden.
Tot slot mag je dit model natuurlijk ook het “GOT IT model” noemen.
GOT IT? Gebruiker | Organisatie | Techniek
Benader ons ook als je de oorzaak van een incident wilt achterhalen en het een volgende keer wilt voorkomen! Hoofdoorzaken vinden daar halen we namelijk plezier uit. En ik vooral…
Guillermo Ortiz Aldana