Service Management
Prioritatea nu este o părere: impact, urgență și ceasul SLA
De ce calculăm prioritatea unui incident dintr-o matrice în loc să lăsăm oamenii să se certe, cum se derivă termenele SLA în orele de lucru și când are voie ceasul să se oprească.
Orice service desk cunoaște propoziția „Dar asta chiar e urgent.” Se spune la telefon, se scrie în tichete și, din când în când, o aduce șeful personal. Problema nu este că ar fi falsă. Problema este că nu poate fi comparată. Când trei apelanți spun „chiar e urgent”, tot trebuie cineva să decidă cine intră primul.
De aceea OpsCloud365 calculează prioritatea în loc să o ceară.
Două întrebări în loc de o părere
La crearea unui incident, agentul răspunde la două întrebări. Cât de mare este impactul, adică câte persoane sau ce servicii sunt afectate? Și cât de urgentă este rezolvarea, adică cât timp poate rămâne situația așa? Matricea de priorități transformă cele două răspunsuri într-o prioritate de la P1 la P4.
Trucul nu este matricea în sine; o are orice carte despre ITIL. Trucul este că discuția se mută în altă parte. Nu se mai discută „P1 sau P2”, ci „este afectată toată locația sau o singură persoană”. La întrebarea asta se poate răspunde. Iar dacă matricea nu se potrivește organizației tale, schimbi matricea, nu răspunsurile.
Ceasul merge în orele de lucru
Termenele decurg din prioritate. Fiecare serviciu din OpsCloud365 poate avea propriul SLA; incidentele fără SLA de serviciu folosesc SLA-ul implicit. Un SLA definește un timp de răspuns și un timp de rezolvare în minute pentru fiecare prioritate și dacă aceste timpuri curg doar în orele de lucru. Un P3 cu opt ore timp de rezolvare, raportat vineri la ora 16 cu program până la 17, este scadent luni la ora 16, nu sâmbătă dimineața.
Incidentul arată ambele termene într-un panou propriu: răspuns scadent, răspuns dat, rezolvare scadentă, rezolvat la, plus o bară care arată cât din timpul de rezolvare este deja consumat. Filtrezi lista după „SLA depășit” și vezi imediat unde arde. Un job în fundal reîmprospătează marcajele de depășire la fiecare 15 minute, ca afișarea să nu depindă de faptul că cineva deschide întâmplător tichetul.
Când are voie ceasul să se oprească
Există un singur motiv legitim pentru a opri ceasul: când munca nu este la service desk. Solicitantul nu a răspuns încă, o piesă de schimb este comandată, un furnizor extern lucrează la ea. Pentru asta există starea „În așteptare”. Ea cere un motiv și pune ceasul SLA pe pauză. Timpul petrecut în așteptare se afișează pe incident în minute.
Ce nu există în mod deliberat: resetarea discretă a termenului. Un incident redeschis primește un contor, nu un nou început. Dacă un tichet a fost redeschis de trei ori, aceea este o informație, nu o problemă cosmetică a statisticii.
Incidente majore: fii zgomotos când contează
Uneori un P1 este mai mult decât un P1. Când sistemul ERP a căzut pentru toate locațiile, nu ajută pe nimeni ca o sută de oameni să sune pe rând. De aceea un P1 poate fi marcat ca incident major. Apare apoi în portalul de self-service ca întrerupere curentă, cu ora de început și serviciul afectat.
Ce contează la final
La sfârșitul săptămânii nu contează tichetul individual, ci tiparul. Dashboardul ITSM arată incidentele după stare, incidentele deschise după prioritate și grup, volumul săptămânal și lista depășirilor SLA. Dacă vezi același grup la P2 în fiecare săptămână, știi unde este necesară o discuție.
Un ultim gând: nimic din toate acestea nu înlocuiește judecata. Un agent experimentat recunoaște când matricea greșește într-un caz anume și poate schimba prioritatea. Dar o face vizibil, cu istoric, și nu pentru că cineva a fost mai zgomotos decât ceilalți.
Toate imaginile prezintă aplicația reală cu date demo fictive, în versiunea în limba engleză.