Problem management: meer dan alleen tooling

Voorkomen is beter dan genezen. Dat geldt voor veel zaken in het leven, zo ook voor storingen. Maar wat als de genezing sneller, goedkoper en duurzamer is dan het nemen van preventieve maatregelen? Dan verandert proactief in reactief handelen en zeg nou zelf, daar zijn we met zijn allen over het algemeen best goed in.

Toch heeft het woord reactief op de één of andere manier een vieze bijsmaak. Reactief heeft de associatie met gemakzucht. Alles dient proactief te zijn, energie uit te stralen. Oftewel problem management in plaats van incident management. Waarom eigenlijk?

Kurkentrekkers en reactief handelen

Terwijl ik dit schrijf, denk ik terug aan een gesprek dat ik ooit voerde over kurkentrekkers. Een groothandel op het gebied van wijnartikelen leverde per ongeluk een batch foutief geproduceerde kurkentrekkers. Niet de kurk, maar het handvat schoot los. De productmanager vond een terugroepactie echter onnodig, ‘dat kost veel te veel tijd en geld, incasseren is ook een kunst’.

Slechts een aantal klanten stuurde hun kapotte kurkentrekker retour. Deze klanten ontvingen, naast nu een goed functionerende kurkentrekker, ook nog een waardebon. Attent, niet? Nu wil ik een product als een kurkentrekker niet vergelijken met een bedrijfskritisch IT-component, maar het is zeker een interessante invalshoek.

Problem management versus incident management

Volgens ITIL is een probleem een onderliggende oorzaak van één of meerdere incidenten. Waar incident management louter focust op snel herstel, richt problem management zich op het begrijpen van de oorzaak en daarmee op preventieve acties. Incidenten voorkomen, de impact van een incident beperken én herhaling voorkomen staan hierbij centraal.

Het problem management proces wordt hiervoor meestal niet geïnitieerd. Dit kan zijn omdat de oorzaak niet relevant is of omdat de kosten simpelweg te hoog zijn. Daarentegen kijkt men bij goed problem management ook naar de economische aspecten en de imagoschade. Toch blijft problem management voor veel bedrijven een onaantrekkelijke klus.

De reactieve variant heeft dan ook sterk de voorkeur: Er wordt brand gespot, de brandweer wordt gebeld, er wordt gewacht, de brand wordt geblust, de brandweer geeft aan dat de brand is geblust en gaat weer weg. Hele afdelingen zijn hierop ingericht. En, zeg nou eerlijk, het werkt toch best lekker?

Meneer de forumganger

Laatst was er iemand op een gespecialiseerd ITIL-forum aan het opperen om problem management in zijn geheel uit de ITIL-literatuur te schrappen. Met als reden: “Niemand gebruikt het en er zijn tegenwoordig allerlei tools die fouten opsporen en daarmee indirect aan problem management doen”, aldus deze tot toen toe gerespecteerde forumganger. Tools vervangen geen processen, maar ondersteunen deze doorgaans, meneer de forumganger.

Toch had hij mijn nieuwsgierigheid gewekt. De betreffende persoon sprak over een tool, die aan de hand van bepaalde activiteiten en patronen het ‘normale gedrag’ in kaart bracht. Afhankelijk van de grootte en complexiteit van de omgeving kon dit uren tot weken duren. Na deze leerperiode wist het systeem afwijkingen te detecteren en zo specialisten tijdig te alarmeren óf zelfs automatisch, wat dat ook mag zijn, in te grijpen. Een geconditioneerd systeem dat wakker wordt zodra de wekker gaat.

De root cause analyse (RCA) die naderhand wordt opgeleverd ziet er fatsoenlijk uit. Al is deze wel beperkt tot een aantal parameters en een échte RCA, die je even naar een klant stuurt, is het zeker niet. Nee, daar is menselijk handelen voor nodig in de vorm van kennis, inzicht en misschien wel wat wijsheid, ongeveer alles dat de meest moderne tools nog steeds niet kunnen leveren. Voor nu zijn deze tools meer geschikt voor wat geavanceerder incident management, eerst detecteren en dan oplossen. Al vraag ik mij af wat zij kunnen in zeer complexe multi-vendor infrastructuren met duizenden variabelen. Een groot voordeel blijft dat er ingegrepen kan worden voordat de gebruiker aan de telefoon hangt. Op deze manier zijn we toch nog proactief bezig.

Combinatie van technische en soft skills

Zolang er geen tools bestaan die voor ons denken zal problem management grotendeels een menselijke activiteit zijn, waarbij de combinatie van technische skills en soft skills groter dan ooit is. Het zijn de mensen die het werk uitvoeren. We zullen moeten analyseren, vragen stellen, overleggen en onderhandelen om vervolgens beslissingen te nemen. Zoals: wanneer wordt een incident een probleem?

Een gigantisch incident waarbij in een stad de lichten uitgaan hoeft volgens ITIL nog geen probleem te zijn. Terwijl een klein incident dat zich keer op keer herhaalt rijp is voor het problem management proces. Analyse en kritisch kijken naar de omgevingsfactoren. Om terug te keren naar de stad in het donker, is de oorzaak evident? Wat is de waarschijnlijkheid van herhaling? Betreft het een logisch gevolg van bepaald handelen? Kortom, vragen die de trechter van problem management stelt. Kunnen we deze vragen met een ja beantwoorden, waarom zouden we dan problem management toepassen?

Last but not least

Uiteraard mogen we als het problem management betreft de known error database niet vergeten, waarbij antwoord wordt gegeven op vragen als: Kunnen we de problemen, storingen en incidenten linken aan bekende fouten? Zijn er workarounds beschikbaar? En kunnen we deze workarounds toepassen zonder een gehele infrastructuur over z’n nek te laten gaan? Het kost tijd om een known error database te bouwen, laat staan te onderhouden. Toch is het de moeite waard, al is het alleen voor de lerende organisatie. Als we stoppen met leren kunnen we net zo goed stoppen met werken.

Wil je weten hoe wij bij Nomios omgaan met incident en problem management voor onze klanten? Neem dan contact met ons op en we gaan er graag over met je in gesprek.