“Any event wich is not part of the standard operation of a service and which cause, or may cause, an interruption to, or a reduction in, the quality of that service” – ITIL

De la Kuhn încoace, în lumea ştiinţei lucrurile evoluează după tiparul: teorie-metodă-observare-interpretare-teorie nouă. În demersul meu am plecat de la definiţia din teorie. Nu doresc a lămuri în câteva rânduri un subiect aşa de complex.  Motivul este undeva mai jos în această pagină, dar pot să mai adaug: organizaţii “mari” vs “organizaţii mici”, organizaţii ce vând servicii IT vs. organizaţii ceu un departament IT. Aduc în discuţie aici doar câteva ideii, fără pretenţie de “ştiinţă” sau “adevăr”.

Mi-am îndreptat atenţia asupra relaţiilor dintre IM şi celelalte procese descrise în ITIL:

Am păstrat termenii din limba engleză. Cam aşa poate să arate “privirea de ansamblu” pornind de la “adapt and adopt” (sinteza de mai sus poate fi completată). Întorcându-ne la definiţia incidentului observăm doi termeni importanţi: eveniment respectiv serviciu. Prin urmare, înainte de a discuta de incidente trebuie să discut de servicii pentru că incidentul este asociat cel puţin unui serviciu. Mai exact despre Service Catalogue. Apoi despre SLA pentru că incidentele trebuie definite pe acolo pe undeva.

Asta înseamnă că trebuie să am în primul rînd un punct de vedere al celor din zona economicului, un punct de vedere al “clienţilor” presupunînd că au deja la dispoziţie “Service Catalogue”. Ei sînt cei care ar trebui să definească ce înseamnă “funcţionare normală”, sau mai exact spus “operare standardizată”. Pentru început, poate ar fi bine să fie avute în vedere doar serviciile “strategice”.

Cam aşa stau lucrurile din punct de vedere teoretic. Practic însă este posibil să nu pot identifica doar un serviciu afectat, ci mai multe (aş fi curios să aflu câţi folosesc în practică Kepner-Tregoe pentru Problem Management…. )

Abia după ce am acest punct de vedere pot să trec la clasificări (una este a utilizatorului, alta a operatorului SD), escaladare şi restul ce ţin de Incident Management şi Service Desk (punctul unic de contact). Pot să le fac fără prea mari constrângeri, dacă nu folosesc încă un instrument software  şi sînt la început (poate unii nu ştiu încă, dar există deja pe piaţă instrumente certificate “ITIL compliant”). Pentru că trebuie să reflecte realitatea din companie şi nu viziunea furnizorului aplicaţiei. Unele din aplicaţiile cu care am avut şansa să interacţionez folosesc un flux standardizat al acestui proces, “one size fits all”. Dar nu prea îmi place.

Nu trebuie uitat că utilizatorul simplu, fără prea multe cunoştinţe tehnice (nu mă refer la utilizare), raportează despre lucruri prin prisma percepţiilor proprii. Altfel spus, răspunsul vine în funcţie de întrebare. Nu orice eveniment este un incident!

Aş mai spune că trebuie avută mare grijă şi cu indicatorii. Câte din incidentele “închise” într-o primă instanţă au fost ulterior redeschise? Să abordezi Incident Management trecând cu vederea Problem Management cred că este o greşeală.

IT-ul, ca orice altă componentă organizatorică are rolul său la bunul mers al afacerii. Bun mers reflectat în final prin “rezultatul exerciţiului financiar”. Puţin scepticism nu strică. Aş mai adăuga nevoia unei abordări mai puţin pasională cînd discutăm subiecte circumscrise sintagmei “IT alignment”….