Prioriteti, SLA i eskalacija

Prioritet (Priority), ozbiljnost (Severity) i utjecaj na poslovanje (Business Impact)

Ozbiljnost

Ozbiljnost pokazuje koliko je trenutačno stanje tehnički ozbiljno.

Prioritet

Prioritet pokazuje redoslijed kojim se radovi izvode.

Ozbiljnost i prioritet nisu isto.

Na primjer, problem (Issue) može istodobno imati Severity = High i Priority = P3.

Takav je slučaj moguć kada je problem tehnički ozbiljan, ali pogađa rezervni objekt (Asset) i trenutačno ne utječe na operativno poslovanje.

Ocjena utjecaja (Impact Score)

Za rangiranje može se primijeniti zbirna ocjena:

gdje je:

• $S$ – ozbiljnost;
• $B$ – utjecaj na poslovanje;
• $A$ – broj ili kritičnost pogođenih objekata;
• $R$ – rizik za sigurnost ili regulatorni rizik;
• $D$ – trajanje.

Utjecaj na poslovanje

OHM podržava strukturirana polja za opis utjecaja:

• broj pogođenih uređaja;
• broj krajnjih kupaca ili lokacija;
• obujam plina izložen riziku;
• trajanje degradacije;
• mogući gubitak podataka;
• rizik od pogrešnog obračunskog mjerenja;
• rizik od izlaska na teren;
• rizik od kršenja sporazuma o razini usluge (SLA);
• rizik za informacijsku sigurnost;
• troškovi zastoja;
• razina utjecaja na ugled.

Upravljanje razinom usluge

OHM implementira cjelovit model upravljanja SLA rokovima.

Prati se ne samo rješavanje problema nego i cijeli ciklus njegove obrade.

flowchart TD
  A["Issue stvoren"] --> B["Response SLA"]
  B --> C["SLA za potvrdu primitka"]
  C --> D["Resolution SLA"]
  D --> E["Verification SLA"]
  E --> F["Closure SLA"]

Svaka faza ima vlastita pravila izračuna.

SLA politika

SLA politika definira:

• dopušteno vrijeme za reagiranje;
• rok za potvrdu primitka;
• rok za rješavanje;
• rok za verifikaciju;
• pravila eskalacije;
• radni kalendar;
• iznimke.

SLA se automatski dodjeljuje na temelju kanonskog problema (Canon), kritičnosti i kategorije objekta.

Radni kalendari

Sustav podržava:

• 24×7;
• 12×7;
• radne dane;
• regionalne kalendare;
• blagdane i neradne dane;
• pojedinačne rasporede rada odjela.

Vrijeme izvan radnog kalendara ne računa se, osim ako SLA politika ne zahtijeva danonoćno reagiranje.

SLA mjerači vremena

Za svaki problem sustav istodobno računa nekoliko neovisnih mjerača vremena.

Na primjer:

• vrijeme do reagiranja;
• vrijeme do potvrde primitka;
• vrijeme do rješavanja;
• vrijeme do verifikacije;
• vrijeme do zatvaranja.

Svaki mjerač vremena može imati vlastita pravila zaustavljanja.

Uvjeti za pauziranje

Odbrojavanje SLA roka može se pauzirati.

Na primjer:

• čekanje na dobavljača;
• čekanje na pristup;
• čekanje na odobrenje;
• sezonska ograničenja;
• viša sila.

Razlog pauze mora biti zabilježen.

Kršenje SLA roka

Kada se prekrši SLA rok, sustav automatski:

• mijenja status;
• povećava razinu rizika;
• pokreće mehanizam eskalacije (Escalation Engine);
• stvara revizijski zapis;
• uračunava kršenje u ključne pokazatelje uspješnosti (KPI).

Mehanizam eskalacije (Escalation Engine)

Mehanizam eskalacije automatski prenosi problem na višu razinu odgovornosti kada se prekrše zadani uvjeti.

Eskalacija ne ovisi o radnjama korisnika i izvršava se automatski.

Razine eskalacije

Tipičan scenarij:

flowchart TD
  P1["P1"] -->|"15 minuta"| L1["Voditelj smjene"]
  L1 -->|"1 sat"| L2["Regionalni voditelj"]
  L2 -->|"4 sata"| L3["Direktor operativnog poslovanja"]

Konkretne intervale određuje politika organizacije.

Okidači eskalacije

Eskalaciju može pokrenuti:

• kršenje SLA za reagiranje (Response SLA);
• kršenje SLA za rješavanje (Resolution SLA);
• izostanak dodjele izvršitelja;
• izostanak potvrde primitka;
• ponovno otvoren problem;
• masovnost;
• visok utjecaj na poslovanje.

Radnje pri eskalaciji

Kada je uvjet ispunjen, sustav može:

• obavijestiti voditelja;
• promijeniti odgovornu osobu;
• podići prioritet;
• stvoriti masovni incident (Massive Incident);
• stvoriti tiket u vanjskom sustavu;
• obavijestiti više rukovodstvo;
• pokrenuti dodatnu analizu.

Sve se radnje u potpunosti bilježe.

Povijest eskalacije

Karton problema sadrži potpun dnevnik:

Povijest se nikada ne briše i koristi se pri izračunu operativnih KPI-jeva.