Managementul incidentelor: opinii

 

“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:

 

De la

Intrare

Service Desk

Logged incidents

Problem Management

Known errors, work around, quick fixes

Change Management

Information about planned changes,

Some incidents can be solved by a change

Release and Deployment Management

Information about upcoming release

Service Asset Configuration Management

Information about CIs and relationship between CIs

Security Management

Security policy

Service Level Management

SLA

Service Catalogue

Capacity Management

Resolutions for capacity related incidents

Availability Management

Explanations of unacceptable availability

IT Service Continuity Management

Service Continuity Plan

Financial Management

Cost/service

 

Rezultat

Către

Incident with unknown cause

Problem Management

RFC

Change Management

Report on incident/release

Release and Deployment Management

Incidents connected to CI in CMDB

Service Asset Configuration Management

Reports on security incidents

Security Management

Reports on SLA

Service Level Management

Reports on capacity related incidents

Capacity Management

Reports on availability related incidents

Availability Management

Historical data for planning

IT Service Continuity Management

Report on time spent per incident by CI/service

Financial Management

 

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”….

3 gânduri despre “Managementul incidentelor: opinii

  1. OK, incercam iar🙂

    1. Problem management in sine nu e foarte impamantenit… pana sa ajungem la Kepner-Tregoe
    2. Flow-urile din instrumente se pot customiza. Cel default e in caz ca nu ai nimic in pravalie.
    3. Nu orice event e incident – event management
    4. Nu orice ajunge la SD e incident, daca la categorizare se constata altceva, se arunca in flow-ul potrivit.
    5. Indicatorii din ITIL sunt de obicei suficienti pentru orice pravalie. Nu prea am vazut pe cineva care sa aiba nevoie de mai mult.

    Apreciază

Mulţumesc.

Completează mai jos detaliile despre tine sau dă clic pe un icon pentru autentificare:

Logo WordPress.com

Comentezi folosind contul tău WordPress.com. Dezautentificare / Schimbă )

Poză Twitter

Comentezi folosind contul tău Twitter. Dezautentificare / Schimbă )

Fotografie Facebook

Comentezi folosind contul tău Facebook. Dezautentificare / Schimbă )

Fotografie Google+

Comentezi folosind contul tău Google+. Dezautentificare / Schimbă )

Conectare la %s