ISO/IEC 20000-1, klauzula 8.6.3 — Upravljanje problemima

Šta standard zahteva

Klauzula 8.6.3 traži da organizacija analizira podatke i trendove o incidentima kako bi prepoznala probleme. Organizacija mora da sprovede analizu osnovnog uzroka i odredi moguće mere za sprečavanje pojave ili ponavljanja incidenata. Problemi moraju biti:

• evidentirani i klasifikovani;
• prioritizovani;
• eskalirani kad je potrebno;
• rešeni, ako je moguće;
• zatvoreni.

Evidencije problema moraju biti ažurirane preduzetim merama. Promene potrebne za rešavanje problema moraju biti upravljane u skladu sa politikom upravljanja promenama. Tamo gde je osnovni uzrok prepoznat, ali problem nije trajno rešen, organizacija mora da odredi mere za smanjenje ili uklanjanje uticaja problema na usluge. Poznate greške moraju biti evidentirane, a ažurne informacije o poznatim greškama i rešenjima problema moraju biti dostupne drugim aktivnostima upravljanja uslugama, prema potrebi. U planiranim intervalima, efektivnost rešavanja problema mora se pratiti, pregledati i izveštavati.

Primer

Primer: IT sektor Adria Trade-a redovno analizira podatke o incidentima i primećuje da se POS terminali u nekoliko starijih prodavnica učestalo zamrzavaju. Umesto da svaki slučaj tretira kao izolovan incident, pokreće se analiza osnovnog uzroka, koja pokazuje da je problem u zastareloj verziji firmvera na tim konkretnim uređajima. Problem se evidentira, klasifikuje i prioritizuje na osnovu učestalosti i uticaja, a zatim eskalira dobavljaču opreme radi izrade ispravke firmvera.

Dok se čeka ispravka, osnovni uzrok je poznat, ali problem još nije trajno rešen — IT sektor određuje privremenu meru za smanjenje uticaja (jednostavan postupak restarta koji brzo vraća terminal u funkciju) i evidentira ovo kao poznatu grešku. Informacija o poznatoj grešci i privremenom rešenju odmah se deli sa svim agentima service deska, tako da svaki sledeći sličan incident prepoznaju odmah i primene poznati postupak, umesto da svaki put iznova traže uzrok. Kad dobavljač isporuči ispravku firmvera, ta izmena se uvodi kroz redovan proces upravljanja promenama, ne mimo njega. Tri meseca kasnije, IT sektor proverava da li se broj incidenata vezanih za zamrzavanje terminala stvarno smanjio, i taj nalaz izveštava rukovodstvu.

Šta treba uraditi

• Redovno analizirati podatke o incidentima u potrazi za obrascima koji se ponavljaju — pojedinačan incident retko otkriva problem, ali isti tip incidenta koji se vraća iz nedelje u nedelju gotovo sigurno ukazuje na nešto dublje.
• Sprovesti stvarnu analizu osnovnog uzroka umesto da se stalno rešavaju samo simptomi — svaki put isti brzi popravak bez traženja uzroka znači da će se problem sigurno ponoviti.
• Primeniti isti nivo discipline na probleme kao i na incidente — evidentiranje, klasifikaciju, prioritizaciju, eskalaciju po potrebi, rešavanje i zatvaranje.
• Svaku promenu potrebnu za rešavanje problema sprovesti kroz uspostavljeni proces upravljanja promenama (klauzula 8.5.1), čak i kad je rešenje hitno potrebno — zaobilaženje procesa zbog žurbe često izazove novi problem.
• Kad je uzrok poznat, ali trajno rešenje još nije moguće, odrediti i zapisati privremenu meru koja smanjuje uticaj na korisnike u međuvremenu — ne ostavljati korisnike bez ikakvog rešenja dok se čeka konačna ispravka.
• Učiniti informacije o poznatim greškama i privremenim rešenjima dostupnim svima kojima trebaju, posebno service desku — ovo direktno ubrzava rešavanje ponovljenih incidenata.
• Periodično proveravati da li je rešavanje problema stvarno dalo rezultat — pratiti da li se učestalost povezanih incidenata zaista smanjila, ne pretpostavljati da je problem rešen samo zato što je ispravka implementirana.