Maloprodajni lanac · izveštaj · 2026-10-01 10:11 UTC
Poverljivo
Izveštaj je napravljen samo na ovim izvorima:
| Izvor | Šta je u njemu bilo |
|---|---|
| Dnevnik incidenata | Izvoz iz vašeg sistema tiketa za period 364 dana, 1728 zapisa. Polja: vreme prijave, vreme zatvaranja, servis ili čvor, prioritet, opis ili uzrok. |
| Spisak kritičnih servisa | Po rečima naručioca: Kase u prodavnicama, Platni gejtvej, Internet prodavnica. |
| Izvozi metrika | Nisu učitani. Treba nam: opterećenje procesora, memorije i kanala, kašnjenje prenosa paketa, udeo izgubljenih paketa, varijacija kašnjenja, uspešnost rezervnih kopija i rokovi sertifikata - vreme merenja i kolona vrednosti za svaki pokazatelj. (vidi mapu provere ispod) |
| Dnevnik izmena | Nije učitan. Treba nam: datum i vreme izmene, tip (redovna ili hitna), pogođeni servis, rezultat. (vidi mapu provere ispod) |
| Podaci prve linije | Nisu učitani. Treba nam: grupa rešavanja ili linija podrške po tiketu, oznaka eskalacije, oznaka ponovnog otvaranja. (vidi mapu provere ispod) |
Tokom 364 dana registrovano je 1369 incidenata sa ukupno 1668 sati zastoja. Kase u prodavnicama su najčešće pogođen servis (408 tiketa), a ponašanje se promenilo oko septembra 2025 - dnevna stopa incidenata porasla je za 52%.
ERP sistem redovno otkazuje poslednjih dana meseca (11 od 12 meseci), a incident na linkovima prodavnica u roku od nekoliko minuta povlači prekide na kasama, Wi-Fi mreži i platnom gejtvej-u.
Mapa sadrži sve vrste provera koje nudimo. To čime će biti popunjena zavisi od pokazatelja koje možete dodati.
Oznake: izračunatotreba vaše polje ili vaš ciljtreba drugi izvor podatakadostupno u proširenom razboru
| Da li infrastruktura drži obećani nivo - 1/4 | |
Ukupno vreme zastojaDetaljnijeŠta je ovo. Ukupno vreme kada vaši servisi nisu bili dostupni tokom perioda iz dnevnika. Kako računamo. Sabiramo trajanje svih incidenata, ali spajamo intervale koji se preklapaju: dva incidenta koja traju istovremeno od 10:00 do 11:00 daju jedan sat nedostupnosti, a ne dva. Bez spajanja, broj je preuveličan utoliko više ukoliko je infrastruktura veća. Odakle definicija. Naš proračun. Pojam nedostupnosti dolazi iz availability u ITIL 4 rečniku: sposobnost servisa da obavlja dogovorenu funkciju kada je to potrebno. Šta nam treba od vas. Već izračunato - broj je u redu. Ako je red žut: potrebno je polje sa vremenom zatvaranja incidenta, inače trajanje ne može da se izračuna. |
69d 12č 24m |
Dostupnost kritičnih servisaDetaljnijeŠta je ovo. Udeo vremena kada je servis radio, u odnosu na ukupno vreme posmatranja. To je taj broj koji ljudi zovu "tri devetke". Kako računamo. Vreme rada / (Vreme rada + Nedostupnost), posebno za svaki servis koji ste naveli. Incident koji je pogodio tri servisa računa se u punom trajanju za svaki od njih: sa stanovišta jednog servisa, on je bio nedostupan celo to vreme. Odakle definicija. Formula - Google SRE Book, gl. 3 "Embracing Risk", doslovno. Pojam availability - ITIL 4 rečnik. Šta nam treba od vas. Označite kritične servise na spisku i navedite ciljni nivo (npr. 99,9%). Računamo odmah nakon odgovora, izveštaj ne treba ponovo učitavati. |
izaberite kritične servise i ciljni nivo |
Potrošeni budžet grešakaDetaljnijeŠta je ovo. Cilj poput 99,9% sam po sebi dozvoljava određeno vreme nedostupnosti. To dozvoljeno vreme je budžet. Pokazatelj govori koliko ste budžeta već potrošili. Kako računamo. Dozvoljena nedostupnost = dužina perioda x (1 - cilj). Potrošeno = stvarna nedostupnost / dozvoljena nedostupnost x 100%. Uzimamo stvarni period - tačno onoliko dana koliko ih ima u vašem dnevniku, bez zaokruživanja na mesec. Vrednost preko 100% znači da je budžet potrošen i cilj za period nije ispunjen. Odakle definicija. Google SRE Book, gl. 3: budžet je razlika između cilja i stvarnog vremena rada, ostatak "nepouzdanosti" za period. Šta nam treba od vas. Jedan broj - ciljnu dostupnost. Bez cilja pokazatelj ne postoji: budžet se računa od obećanja, a ne od podataka. |
odredite cilj - bez njega pokazatelj ne postoji |
Stvarno vreme oporavka prema ciljnomDetaljnijeŠta je ovo. RTO je rok u kome servis mora da se vrati u rad nakon otkaza. Pokazatelj govori u kom udelu slučajeva ste taj rok ispoštovali. Kako računamo. Udeo incidenata čije trajanje nije duže od vašeg cilja, plus najgori slučaj za period - najduži incident. Najgori slučaj je važniji od proseka: plan kontinuiteta se proverava na lošem danu, a ne na uobičajenom. Odakle definicija. ISO 22300:2021 (rečnik uz ISO 22301): RTO je "period nakon incidenta u kome se proizvod, usluga ili aktivnost ponovo uspostavljaju, odnosno resursi obnavljaju". Standard je plaćen, broj tačke nismo proverili i zato se na njega ne pozivamo. Šta nam treba od vas. Ciljno vreme oporavka u satima. Ako je različito za različite servise - navedite cilj za najkritičniji. |
odredite cilj - bez njega pokazatelj ne postoji |
| Koliko brzo popravljate - 1/6 | |
Vreme obnove servisaDetaljnijeŠta je ovo. Koliko vremena prođe od prijave incidenta do njegovog zatvaranja. Kako računamo. Dajemo tri broja odjednom: medijanu, prosek i P95. Medijana je uobičajen dan: polovina incidenata se rešava brže. Prosek povlače naviše retki dugi slučajevi. P95 je "rep": duže od njega traje samo svaki dvadeseti incident. Jedan prosek bez repa sakriva baš one slučajeve zbog kojih vas zove biznis. Odakle definicija. ITIL 4 ovo naziva MTRS, mean time to restore service: "mera koliko brzo se servis vraća u rad nakon otkaza". Rečnik pouzdanosti IEC 60050-192 isti broj naziva MTTR (termin 192-07-23). Šta nam treba od vas. Već izračunato. Ako je red žut: potrebno je polje sa vremenom zatvaranja incidenta. |
54 min / 1č 28m / 4č 41m - medijana / prosek / P95 |
Vreme otkrivanjaDetaljnijeŠta je ovo. Koliko je incident trajao pre nego što ste saznali za njega. To je slepa tačka: servis već ne radi, a prijave još nema. Kako računamo. Stvarni početak incidenta minus vreme prijave u sistemu. Ovo se ne može izvesti samo iz vremena prijave ni pod kakvim pretpostavkama: dnevnik zna trenutak kada je problem prijavljen, a ne trenutak kada je počeo. Odakle definicija. Standard ne postoji. MTTD je ustaljena praksa upravljanja incidentima, i to kažemo otvoreno, umesto da praksu predstavljamo kao normu. Šta nam treba od vas. Cilj ovo ne rešava - potreban je izvoz sa posebnim poljem "stvarni početak" (sistemi ga različito nazivaju: start time, occurred at, vreme nastanka). Dodajte takav izvoz preko istog linka, i red će se izračunati. |
treba popunjeno polje „stvarni početak, odvojeno od vremena prijave" u bazi |
Vreme reakcijeDetaljnijeŠta je ovo. Koliko je prijava čekala dok je neko ne preuzme. Pokazuje rad reda čekanja i dežurne smene, a ne složenost same greške. Kako računamo. Vreme preuzimanja u rad minus vreme prijave. Odakle definicija. Standard ne postoji. MTTA je praksa servisnog centra (service desk). Šta nam treba od vas. Potreban je izvoz sa poljem "vreme preuzimanja u rad" (preuzeto, dodeljeno, acknowledged - u zavisnosti kako se zove kod vas). |
treba popunjeno polje „vreme preuzimanja u rad" u bazi |
Udeo zatvorenih na vremeDetaljnijeŠta je ovo. Koji deo incidenata je ispoštovao rokove dogovorene sa biznisom. Kako računamo. Posebno po svakom prioritetu: koliko incidenata tog prioriteta je zatvoreno najkasnije do vašeg normativa. Prioritete nije moguće spojiti u jedan broj - normativ im je različit, a zbirni broj bi sakrio kašnjenje kod kritičnih. Računamo samo ako je prioritet popunjen kod najmanje 80% zapisa; ispod tog praga broj govori o kvalitetu popunjavanja dnevnika, a ne o radu službe. Odakle definicija. ITIL 4: service level - mere očekivanog ili ostvarenog kvaliteta; SLA - dokumentovan sporazum o traženim uslugama i očekivanom nivou usluge. Šta nam treba od vas. Ciljna vremena po svakom prioritetu, u minutima (npr. kritičan - 60, visok - 240, uobičajen - 1440). Ako se prioritet ne vodi u dnevniku, ili je popunjen kod manje od 80% zapisa: prvo je potreban izvoz sa tim poljem - cilj nema na šta da se primeni bez prioriteta. |
odredite cilj - bez njega pokazatelj ne postoji |
Udeo rešenih iz prvog putaDetaljnijeŠta je ovo. Koji deo incidenata se nakon zatvaranja nije ponovo otvorio. Direktna mera kvaliteta popravke: da li je prijava zatvorena ili je problem rešen. Kako računamo. Udeo incidenata bez oznake ponovnog otvaranja. Odakle definicija. Standard ne postoji, ovo je praksa servisnog centra. Šta nam treba od vas. Potreban je izvoz sa poljem "ponovo otvoreno" ili sa istorijom promena statusa - iz istorije ćemo sami rekonstruisati činjenicu vraćanja u rad. |
treba popunjeno polje „ponovo otvoren" u bazi |
Udeo rešenih na prvoj linijiDetaljnijeŠta je ovo. Koji deo incidenata je zatvoren bez prosleđivanja specijalistima. Pokazuje koliko posla ide naviše i koliko su opterećene skuplje ruke. Kako računamo. Udeo incidenata zatvorenih od strane iste grupe koja ih je i preuzela. Odakle definicija. Standard ne postoji. ITIL 4 definiše samo escalation i service desk; sama mera nije u rečniku. Šta nam treba od vas. Potreban je izvoz sa poljem "grupa za rešavanje" ili "linija podrške". |
treba popunjeno polje „grupa koja je rešila" u bazi |
| Koliko često i šta se tačno kvari - 4/8 | |
Koliko često se dešavaju incidenti i koliko često servis otkazujeDetaljnijeŠta je ovo. Koliko često se nešto pokvari u celoj kompaniji i koliko često otkazuje svaki od najčešćih servisa. Kako računamo. Period podeljen brojem incidenata: za kompaniju - ukupna učestalost, za servis - vreme između otkaza. Računamo otkaze usluge, a ne fabričku pouzdanost opreme. Odakle definicija. ITIL 4, MTBF: "mera koliko često servis ili druga konfiguraciona stavka otkazuje". IEC 60050-192, termin 192-05-13, mean operating time between failures. Šta nam treba od vas. Već izračunato. |
Incidenata: 1369, u proseku jedan na 6č 23m. Najčešće: Kase u prodavnicama - jednom na 21č 29m; Internet prodavnica - jednom na 2d 05č 38m; Mobilna aplikacija - jednom na 2d 23č 04m |
Koncentracija zastoja po servisimaDetaljnijeŠta je ovo. Pokazuje da li je vaša nedostupnost skoncentrisana u nekoliko tačaka ili ravnomerno raspoređena. Ako je skoncentrisana, rad na kratkom spisku daje nesrazmerno veliki efekat. Kako računamo. Rangiramo servise po doprinosu nedostupnosti i gledamo koliki deo daju najgornji. Dodatno računamo indeks nejednakosti od 0 do 1 (naziv formule je u Prilogu A): 0 znači "svi servisi doprinose podjednako", bliže 1 znači "skoro sve pada na nekolicinu". Odakle definicija. Naš proračun. Nema preuzetih normi: upoređujemo vašu infrastrukturu sa njom samom, a ne sa tuđim prosekom. Šta nam treba od vas. Već izračunato. Ako je red žut: potrebno je polje "servis ili čvor" - bez njega nedostupnost nema na šta da se veže. Ako je sivo-plav: proračun je uključen u prošireni razbor. |
3 od 13 servisa nose 53% ukupnog zastoja |
Povratak kvara na isti objekatDetaljnijeŠta je ovo. Koji deo kvarova se vratio na isti objekat - server, konfiguracionu stavku, prodavnicu - u roku od nedelje posle popravke, i da li je to više nego što daje slučaj. Kako računamo. Ključ je objekat zajedno sa sistemom: "kasa prodavnice 12", a ne "kase". Tiketi jednog kvara na objektu (otvoren dok traje prethodni ili u roku od sat vremena posle njegovog zatvaranja) računaju se kao jedan kvar. Povratak je kvar u roku od 7 dana posle kraja prethodnog. Pored toga: udeo koji bi dao slučaj kada bi se svi objekti sistema kvarili jednako. Objekat navodimo ako se kvari češće od ostalih objekata svog sistema ili mu kvarovi idu u serijama češće nego što daje ritam ostalih; obe provere su korigovane na broj objekata. Isti objekat još nije isti uzrok: u ITIL 4 ponavljanje ukazuje na problem, "uzrok ili potencijalni uzrok jednog ili više incidenata". Odakle definicija. Naš proračun; tumačenje - ITIL 4, problem. Šta nam treba od vas. Već izračunato. Ako je red žut: potrebna je kolona objekta - server, konfiguraciona stavka ili prodavnica, popunjena bar kod petine tiketa. Ako je sivo-plav: dostupno u proširenom razboru. |
34% kvarova se vratilo na isti objekat u roku od 7 dana posle popravke; da se objekti kvare jednako - oko 33% |
Metrika pre kvaraDetaljnijeŠta je ovo. Koja metrika nadzora - opterećenje procesora, memorija, saobraćaj, disk - unapred odstupa od uobičajenog pre kvarova, i otprilike koliko pre njih. Kako računamo. Dnevnik i izvoz metrika stavljamo na jednu vremensku osu. "Uobičajeno" za metriku je njen nivo u isti sat dana, radni dani i vikend odvojeno. Gledamo prozore 15 min - 1 h, 1-6 h i 6-24 h pre tiketa i poredimo koliko često je metrika bila iznad ili ispod uobičajenog pre kvarova i u iste sate drugih dana. Nalaz je samo ako se to pre kvarova dešava primetno češće, u različite dane i uz korekciju na broj serija. Tiket koji je otvorio alarm po istoj metrici ne smatramo predznakom. Odakle definicija. Naš proračun; proveren na veštačkim mesecima i godinama nadzora sa poznatim odgovorom. Šta nam treba od vas. Već izračunato. Ako je red siv: pošaljite uz dnevnik izvoz metrika nadzora za isti period. Ako je žut: zajednički period ili kvarova u njemu je malo - treba najmanje 14 dana i 8 kvarova. |
treba drugi izvor podataka: izvoz metrika nadzora za isti period (Zabbix, Grafana, Prometheus) |
Podela po prioritetimaDetaljnijeŠta je ovo. Kako su incidenti raspoređeni po klasama važnosti. Kako računamo. Računamo udeo svakog prioriteta, ali samo ako je polje popunjeno kod najmanje 80% zapisa. Kod manje popunjenosti, raspodela opisuje disciplinu popunjavanja dnevnika, a ne stvarnu sliku kvarova, i ne štampamo je. Gledajte dve stvari. Prvo, udeo najviših klasa: ako je kritičnih više od četvrtine toka, prioritet se dodeljuje po glasnoći prijavioca, a ne po uticaju na posao, i hitna traka prestaje da bude hitna. Drugo, uporedite to sa odeljkom "koliko brzo popravljate": kritični incidenti koji se ne popravljaju brže od običnih znače da prioritet postoji u dnevniku, ali ne i u radu smene. Odakle definicija. ITIL 4, incident: neplanirani prekid usluge ili smanjenje njenog kvaliteta. Standard ne propisuje skale prioriteta - koristimo vašu. Šta nam treba od vas. Već izračunato. Ako je red žut: potreban je izvoz sa poljem "prioritet" ili njegovo popunjavanje. |
ZATVOREN - 1369 (99%); U RADU - 14 (1%) |
Udeo incidenata sa utvrđenim uzrokomDetaljnijeŠta je ovo. Koji deo incidenata je analiziran do uzroka, a ne samo zatvoren nakon vraćanja servisa u rad. Kako računamo. Udeo zapisa sa popunjenim uzrokom ili vezom sa problemom. Odakle definicija. ITIL 4: problem - uzrok ili potencijalni uzrok incidenata; known error - problem koji je analiziran ali nije otklonjen (obilazno rešenje pritom nije obavezno). Šta nam treba od vas. Ovo polje se ne vodi u vašem dnevniku. Sama ta činjenica je već zaključak: incidenti koji se ponavljaju zatvaraju se bez analize uzroka, pa će se ponoviti. Da biste videli broj, potreban je izvoz sa poljem "uzrok" ili veza incidenata sa problemima. |
polje se ne vodi - znači da se ponovljeni incidenti zatvaraju bez utvrđivanja uzroka |
Udeo hitnih izmenaDetaljnijeŠta je ovo. Koji deo izmena se sprovodi u režimu "trebalo je juče", bez uobičajenog odobrenja. Visok udeo znači da planirani proces ne stiže za stvarnošću. Kako računamo. Udeo hitnih izmena u odnosu na sve izmene u periodu. Odakle definicija. ITIL 4: emergency change - izmena koja "mora biti sprovedena što je pre moguće"; standard change - unapred odobrena izmena niskog rizika. Šta nam treba od vas. Poljem u dnevniku incidenata se ovo ne rešava: imenilac ovde su izmene, a ne incidenti. Potreban je izvoz iz dnevnika izmena za isti period. On će takođe precizirati red "udeo incidenata sa tragom izmene" - trenutno je tamo donja procena po tekstu opisa. |
treba drugi izvor podataka: dnevnik izmena |
Udeo incidenata krivicom dobavljačaDetaljnijeŠta je ovo. Koji deo kvarova je došao van vašeg perimetra - od provajdera, dobavljača, izvođača. Ovo je broj za razgovor sa dobavljačem, a ne sa vašim timom. Kako računamo. Udeo incidenata sa navedenom spoljnom odgovornom stranom. Odakle definicija. ITIL 4, praksa upravljanja dobavljačima (supplier management practice). Šta nam treba od vas. Potreban je izvoz sa poljem "odgovorna strana" ili "dobavljač". |
treba popunjeno polje „strana koja je kriva" u bazi |
| Kapacitet i zdravlje | |
| Ovde treba da stoje pokazatelji stanja resursa: opterećenje, kašnjenje i gubici u mreži, rezervne kopije, rokovi sertifikata, komponente van podrške. Dnevnik incidenata ih nema - potreban je poseban izvoz metrika za isti period: vreme merenja i po jedna kolona vrednosti za svaki pokazatelj. | |
Ukupno: 6 pokazatelja izračunato, 10 čeka vašu odluku ili popunjeno polje, 8 traži druge podatke.
Svaki red sa oznakom „treba vaše polje ili vaš cilj" nije naša granica, već ime konkretnog polja u vašoj bazi. Pošaljite polje „vreme preuzimanja u rad" i dobićete vreme reakcije odvojeno od vremena popravke. Tada se vidi gde gubite više: dok dispečer traži slobodnog inženjera ili dok inženjer popravlja.
Šta nismo dobili
Ispod je ono što bi zatvorilo najviše redova mape. Odgovor vas ni na šta ne obavezuje.
Izvoz metrika nismo dobili. Da li merite opterećenje resursa, gubitke, kašnjenja ili vreme odziva?
U zapisima nije naveden uzrok. Da li ponovljene uzroke vodite odvojeno, kao probleme?
Dnevnika izmena nije bilo u poslatim podacima. Da li ga vodite, sa datumom i vremenom svake izmene?
Stepenik 2 od 5 - Beležimo
Kvarovi se beleže. Iz te istorije se već vidi koliko traje oporavak, gde se zastoj gomila i kakve kvarove očekivati.
Stepenik je izračunat samo iz dnevnika. Funkcije koje se u dnevniku ne vide nisu uračunate dok nam ne kažete za njih, pa je ovo donja granica. Potvrđeno podacima: 1 od 1 ključnih funkcija do stepenika 2.
| Stepenik | Funkcija | ITIL 4 praksa | Status |
|---|---|---|---|
| 2 | Svaki kvar je zabeležen | Incident management | potvrđeno podacima |
| 3 | Glavne usluge imaju vlasnike | Service level management | potvrđeno podacima |
| 3 | Prioritet se dodeljuje po uticaju i hitnosti | Incident management | ne vidi se u podacima (jedna vrednost u 98% zapisa) |
| 3 | Obećani su rokovi oporavka | Service level management | ne vidi se u podacima |
| 3 | Dežurstvo i redosled predaje kvara | Service desk | ne vidi se u podacima |
| 4 | Ponavljanja se analiziraju do uzroka | Problem management | ne vidi se u podacima |
| 4 | Izmene se beleže sa vrstom i ishodom | Change enablement | ne vidi se u podacima |
| 4 | Za kvar se saznaje pre korisnika | Monitoring and event management | ne vidi se u podacima |
| 5 | Poboljšanja imaju vlasnika i izmeren efekat | Continual improvement | ne vidi se u podacima |
| 5 | Pokazatelji se preispituju sa korisnikom | Measurement and reporting | ne vidi se u podacima |
| 5 | Poznate su zavisnosti usluga od opreme | Service configuration management | ne vidi se u podacima |
Šema ocene je kao u formalnoj oceni procesa (ISO/IEC 33000, metod ocene CMMI): reči ljudi i radni zapisi. Odgovor daje status „prijavljeno", izvoz - „potvrđeno", neslaganje - „sporno".
Funkcija je potvrđena podacima ako dnevnik pokriva najmanje 90 dana i 30 zapisa, početak, kraj i objekat kvara popunjeni su u 95% zapisa, polje same funkcije (usluga, prioritet) u 80%, i nijedna vrednost ne stoji na više od 95% zapisa.
Prakse i njihovi nazivi su iz ITIL 4. Lestvica se oslanja na ITIL 4, CMMI i ISO/IEC 33000; to nije sertifikacija niti ocena akreditovanog ocenjivača.
Šta smo gledali. 1728 zapisa dnevnika za 364 dana.
Šta smo dobili. Od 1728 zapisa dnevnika, njih 320 (18%) su po koloni „Tip“ zahtevi za uslugu, a ne kvarovi; kod 45 od ovih zahteva tip nije popunjen, prepoznali smo ih po rečima u opisu - to je procena; još 25 su izmene, problemi ili planirani radovi. Izbacili smo sve ove zapise iz svih proračuna izveštaja: dalje radimo sa 1369 incidenata, to je 3.8 dnevno. Ukupno su servisi bili nedostupni ili su radili lošije od normale 69d 12č 24m - to je zbir po svim objektima, a ne vreme kada je sve istovremeno ležalo.
Traka pokazuje koliko zapisa dnevnika ima svake vrste. Narandžaste smo izbacili iz svih proračuna izveštaja: to nisu kvarovi, i njihovo vreme izvršenja ne ulazi u vreme oporavka.
Redovi dnevnika koje smo izbacili
| Broj | Početak | Tip ili opis |
|---|---|---|
| INC025000 | 01.01.2025 08:54:09 | Zahtev za uslugu |
| INC025002 | 01.01.2025 12:51:31 | Zahtev za uslugu |
| INC025012 | 03.01.2025 11:41:38 | Zahtev za uslugu |
| INC025062 | 17.01.2025 10:02:51 | Otključati nalog posle odmora |
| INC025076 | 20.01.2025 16:48:40 | Molim instalirajte softver za e-potpis |
Šta to znači. Kada se broje svi tiketi zajedno, kvarova ispada 25% više nego što ih je bilo, a vreme obnove se meša sa rokom izvršenja zahteva. Izveštaj rukovodstvu po svim tiketima pokazuje više havarija nego što ih je stvarno bilo. O zastoju posebno: da smo trajanja sabirali jedno za drugim, dobili bismo 83d 06č 19m. Razlika od 13d 17č 54m su incidenti koji su tekli istovremeno. Brojati ih dvaput znači uvećati zastoj.
Šta uraditi. Računajte pokazatelje kvarova samo po zapisima sa tipom incidenta u koloni „Tip“ i pazite da tip uvek bude popunjen.
Proverite sami.* Filtrirajte izvoz po koloni „Tip“: zapisa sa tipom zahteva, izmene ili problema treba da bude 300.
Šta smo gledali. Vreme od prijave incidenta do obnove, po 1369 incidenata. Vreme je kalendarsko: noći i vikendi ulaze u njega u celosti. Nije zatvoreno 14 tiketa: njihov kraj nije poznat, pa nisu ušli u račun.
Šta smo dobili. Polovina incidenata se zatvara brže od 54 min. Prosek je 1č 28m. Najgorih 5% traje duže od 4č 41m, najduži je bio 19č 30m. Tih 69 incidenata drži 24% ukupnog zastoja.
Polovina incidenata se zatvara brže od 54 min, prosek je 1č 28m. 5% najdužih (desno od 4č 41m) nosi 24% zastoja.
Najveći incidenti (top-3) čine 2.4% ukupnog zastoja - najveći deo zastoja čini masa običnih incidenata, a ne nekoliko havarija.
Redovi dnevnika: najduži incidenti
| Broj | Početak | Servis | Objekat | Trajanje |
|---|---|---|---|---|
| INC025311 | 15.03.2025 22:10 | ERP | ERP-01 | 19č 30m |
| INC026498 | 26.11.2025 06:05 | Magacinski sistem | WMS-01 | 15č 00m |
| INC025788 | 08.07.2025 14:42 | Internet prodavnica | WEB-01 | 13č 15m |
| INC025807 | 13.07.2025 13:43 | Wi-Fi u prodavnicama | Prodavnica br. 33 | 11č 48m |
| INC025315 | 16.03.2025 19:09 | Rezervne kopije | BACKUP-01 | 10č 20m |
Šta to znači. Prosek (1č 28m) je iznad medijane (54 min) - kod popravki je skoro uvek tako: nekoliko dugih slučajeva vuče prosek naviše. Ali posebne klase teških incidenata nema: 5% najdužih nosi samo 24% zastoja, većinu čine obične popravke. Za izveštaj koristite medijanu - ona pokazuje tipičan incident.
Šta uraditi. Uvedite posebnu proceduru za incidente koji nisu zatvoreni u roku od 4č 41m. Ne „pojačati kontrolu", nego konkretno: po isteku tog roka - eskalacija ka inženjeru koji sme da zove proizvođača. Danas takvi incidenti stoje u zajedničkom redu.
Proverite sami.* Otvorite poslednja tri incidenta duža od 4č 41m i pogledajte koliko je vremena otišlo na dijagnostiku, a koliko na samu popravku. Ako je više od polovine na dijagnostiku, usko grlo je u nadzoru, a ne u rukama inženjera.
Šta smo gledali. Raspored incidenata i zastoja po 13 objekata, kao i ponavljanja.
Šta smo dobili. 3 objekta od 13 drže 53% ukupnog zastoja. Najgori je „Kase u prodavnicama": 407 incidenata, 19d 14č 50m zastoja. Pri ravnomernoj raspodeli bilo bi 23%. Tiketi koje je zatvorio tajmer ili čišćenje reda, i otvoreni tiketi, nisu u zastoju (detalji u odeljku 2). 34% kvarova na objektima (435 od 1296) vratilo se na isti objekat istog sistema u roku od 7 dana posle popravke. Da se svi objekti svakog sistema kvare jednako, bilo bi oko 33%. Tiketi jednog kvara na jednom objektu računaju se kao jedan kvar: takvih tiketa je 87. „ERP-01" u sistemu „ERP": 49 kvarova u periodu, tipičan objekat ovog sistema ima 22: kvari se češće od drugih, a slučaj to ne daje. „Prodavnica br. 17" u sistemu „Kase u prodavnicama": 29 kvarova u periodu, tipičan objekat ovog sistema ima 9: kvari se češće od drugih, a slučaj to ne daje.
Traka je udeo u ukupnom zastoju; isprekidana linija je koliko bi svaki imao da se zastoj deli podjednako. Narandžasto: oni o kojima govori ovaj odeljak.
Red je objekat, oznaka je kvar. Crvena tačka je došla u roku od 7 dana posle prethodne popravke, tamna crta posle prekida. Desno: kvarovi na objektu naspram tipičnog objekta istog sistema, ili koliko se vratilo.
Redovi dnevnika: najduži incidenti „Kase u prodavnicama“
| Broj | Početak | Servis | Objekat | Trajanje |
|---|---|---|---|---|
| INC026059 | 10.09.2025 09:52 | Kase u prodavnicama | Prodavnica br. 9 | 8č 08m |
| INC026162 | 28.09.2025 15:39 | Kase u prodavnicama | Prodavnica br. 34 | 7č 58m |
| INC026236 | 09.10.2025 11:08 | Kase u prodavnicama | Prodavnica br. 40 | 7č 33m |
| INC026098 | 18.09.2025 15:41 | Kase u prodavnicama | Prodavnica br. 6 | 5č 38m |
| INC026400 | 08.11.2025 08:34 | Kase u prodavnicama | Prodavnica br. 5 | 4č 55m |
Redovi dnevnika: kvarovi na „ERP-01“
| Broj | Početak | Servis | Objekat | Trajanje |
|---|---|---|---|---|
| INC026352 | 31.10.2025 16:15 | ERP | ERP-01 | 2č 21m |
| INC026506 | 27.11.2025 10:25 | ERP | ERP-01 | 4č 56m |
| INC026509 | 27.11.2025 16:21 | ERP | ERP-01 | 1č 36m |
| INC026516 | 28.11.2025 12:40 | ERP | ERP-01 | 3č 34m |
| INC026720 | 31.12.2025 13:15 | ERP | ERP-01 | 1č 20m |
Šta to znači. Zastoj drži nekoliko objekata, i to više nego što bi dao slučaj. Ljudi i analiza usmereni tamo vratiće najviše vremena. Navedeni objekti se kvare iznova. Isti objekat još nije isti uzrok, a dnevnik uzrok ne pokazuje. Mogući uzroci: uzrok nije otklonjen - popravljeno je restartom ili zaobilaznim rešenjem; objekat je istrošen ili preopterećen; objekat ima više opreme ili ljudi od susednih; jedan kvar se kasnije ponovo prijavi. Razlikuju ih opis i način zatvaranja ovih tiketa, zapis u dnevniku problema i koliko opreme objekat ima.
Šta uraditi. Počnite od 3 objekta, a ne od 13. Za „Kase u prodavnicama" - razmotrite njegove incidente zajedno, jednom analizom, i tražite zajednički uzrok, a ne uzrok svakog ponaosob. Kvarove „ERP-01" pregledati zajedno, jednom analizom: uporediti opise i šta je rađeno pri zatvaranju. Jedan uzrok, popravljen restartom - otvoriti problem i tražiti uzrok. Različiti uzroci, a objekat je veći od susednih - porediti ga sa objektima iste veličine. Isti kvar ponovo prijavljen - dogovoriti se da se ponovljeni tiket veže za prvi.
Proverite sami.* Otvorite bilo koja tri incidenta sa „Kase u prodavnicama" iz poslednjeg meseca. Ako imaju različite uzroke, pogrešili smo i objekat je samo preopterećen. Ako je uzrok isti, imate problem koji niko ne vodi. Za tromesečje ponovo poslati dnevnik: na „ERP-01" treba da bude manje kvarova i povrataka u roku od nedelje.
Šta smo gledali. Koji sistemi otkazuju zajedno: posle otkaza jednog, u roku od 15 minuta otvara se tiket za drugi češće nego slučajno.
Šta smo dobili. Posle otkaza „Linkovi prodavnica" u roku od 15 minuta otvaraju se tiketi i za druge sisteme: „Wi-Fi u prodavnicama" 14 puta od 71, „Kase u prodavnicama" 11 puta od 71, „Platni gejtvej" 9 puta od 71. Slučajno, uz sopstveni ritam tih sistema, desilo bi se najviše 0,7 puta za ceo period. 80 tiketa od 1383 otvoreno je u prvih 15 minuta kvara koji već traje: to je njegov nastavak ili isti kvar prijavljen ponovo. Broj otkaza i vreme između njih u izveštaju računati su po tiketima, pa su uvećani za oko 6%; na listi najvećih incidenata takav kvar se broji kao jedan.
Traka pokazuje koliko puta se tiket drugog sistema otvorio u roku od 15 minuta posle otkaza prvog; siva oznaka je koliko bi dao slučaj uz uobičajeni ritam drugog sistema. Strelica pokazuje koji je sistem prvi; dvostruka - nijedan nije redovno prvi.
Redovi dnevnika: „Linkovi prodavnica“ i odmah posle „Wi-Fi u prodavnicama“
| Broj | Početak | Servis | Objekat | Trajanje |
|---|---|---|---|---|
| INC026575 | 08.12.2025 06:20 | Linkovi prodavnica | Prodavnica br. 44 | 2č 41m |
| INC026577 | 08.12.2025 06:31 | Wi-Fi u prodavnicama | Prodavnica br. 44 | 2č 33m |
| INC026706 | 29.12.2025 21:00 | Linkovi prodavnica | Prodavnica br. 30 | 13 min |
| INC026708 | 29.12.2025 21:10 | Wi-Fi u prodavnicama | Prodavnica br. 30 | 17 min |
Šta to znači. Tiketi za „Wi-Fi u prodavnicama" u prvim minutima posle otkaza „Linkovi prodavnica" pre su posledica nego zaseban problem. Obično iz tri razloga: „Wi-Fi u prodavnicama" radi preko „Linkovi prodavnica"; oba zavise od trećeg - napajanja, zajedničkog čvora, lokacije; ili su dva tima prijavila jedan kvar. Razlikuje ih kolona objekta (prodavnica, čvor, lokacija): ako par tiketa ima isti objekat, to je jedan kvar.
Šta uraditi. Tikete za „Wi-Fi u prodavnicama" otvorene u prvih 15 minuta posle otkaza „Linkovi prodavnica" vezujte za njegov tiket kao podređene. Tada se otkazi više ne broje dvaput, a popravlja se jedan uzrok. Ako „Wi-Fi u prodavnicama" radi preko „Linkovi prodavnica", rezerva je potrebna za „Linkovi prodavnica".
Proverite sami.* Otvorite poslednja tri kvara „Linkovi prodavnica" i tikete za „Wi-Fi u prodavnicama" u narednih 15 minuta: da li je isti objekat i da li su zatvoreni zajedno sa kvarom?
Šta smo gledali. Raspored incidenata po satima i danima u nedelji, kao i promena učestalosti kroz vreme.
Šta smo dobili. Po vremenu u nedelji: radnim danima od 9 do 18 - 46% incidenata (to je 27% sati u nedelji), uveče i noću radnim danima - 28%, vikendom - 27%. Čet 02:00-03:00: 34 incidenata, a uobičajeni ritam dao bi ovde oko 4. Kvarovi u ovom satu ponavljali su se u 31 od 52 nedelja. Najčešće je to Magacinski sistem (28 od 34). ERP: kvarovi poslednja tri dana u mesecu - u 11 od 12 meseci. Dana sa kvarom na te datume: 22, a uobičajeni ritam dao bi oko 7. Poslednji put: 30.12.2025. Ako se ništa ne promeni, sledeći po ciklusu je 29.01.2026-31.01.2026. Učestalost incidenata je porasla: sa 3,2 dnevno na početku perioda na 5,1 na kraju. Ovi podaci ne razlikuju korak od postepenog rasta. Ako je bio korak, desio se između 13.08.2025 i 24.09.2025, najverovatnije oko 01.09.2025: bilo je 3,2 dnevno, postalo je 4,9. Ako je rast bio postepen, jedinstvenog datuma nema. Novi nivo se drži već 122 dana.
Što je ćelija tamnija, to je više incidenata. Radni dani od 9 do 18 (isprekidani okvir) - 46%, veče, noć i vikend - 54%. Crveni okvir je sat koji odstupa od vašeg uobičajenog ritma; broj su njegovi incidenti.
Svaki krug je dan ciklusa: crven kada je sistem pao tog dana, prazan kada je dan prošao mirno. Crtice su kvarovi drugih dana. Prazan crveni krug posle kraja izvoza je sledeći dan po ciklusu, ako se ništa ne promeni.
Redovi dnevnika: incidenti u označenom satu
| Broj | Početak | Servis | Objekat | Trajanje |
|---|---|---|---|---|
| INC026389 | 06.11.2025 02:21 | Magacinski sistem | WMS-01 | 1č 59m |
| INC026467 | 20.11.2025 02:15 | Magacinski sistem | WMS-01 | 1č 03m |
| INC026505 | 27.11.2025 02:23 | Magacinski sistem | WMS-01 | 2č 04m |
| INC026633 | 18.12.2025 02:04 | Magacinski sistem | WMS-01 | 1č 34m |
| INC026634 | 18.12.2025 02:25 | Platni gejtvej | PAY-01 | 1č 19m |
Redovi dnevnika: kvarovi „ERP“ u danima ciklusa
| Broj | Početak | Servis | Objekat | Trajanje |
|---|---|---|---|---|
| INC026174 | 29.09.2025 16:54 | ERP | ERP-01 | 1č 54m |
| INC026338 | 29.10.2025 19:44 | ERP | ERP-03 | 21 min |
| INC026516 | 28.11.2025 12:40 | ERP | ERP-01 | 3č 34m |
| INC026711 | 30.12.2025 09:47 | ERP | ERP-01 | 4č 28m |
| INC026716 | 30.12.2025 15:04 | ERP | ERP-01 | 4č 14m |
Šta to znači. Kvar vezan za sat gotovo uvek je vezan za raspored: noćni zadatak (razmena, izvoz, rezervna kopija), prozor za izdanja, planirani radovi dobavljača ili provera koja upisuje nađeno u svoje vreme. Slučajni kvarovi se ovako ne skupljaju. Kvar koji se vraća u jednakim razmacima gotovo uvek je vezan za raspored ili za nešto što se puni: zadatak na svakih nekoliko dana, zatvaranje meseca i izveštaji, prostor ili memorija koji se potroše do istog roka, sertifikat ili lozinka kojoj ističe rok. Slučajni kvarovi se ovako ne ponavljaju. Dnevnik ne kaže šta se desilo: nema polje uzroka. Mogućnosti: više korisnika ili lokacija, izdanje ili migracija, novi izvođač, nova pravila registracije - na primer, monitoring je počeo sam da otvara tikete. Razlikovati pomaže dnevnik izmena za te nedelje i kolona „ko je registrovao" (čovek ili monitoring).
Šta uraditi. Nađite šta se pokreće u to vreme: raspored zadataka, prozor za izdanja, radove dobavljača. Ako je zadatak - pomerite ga ili dodajte proveru pre pokretanja; ako su izdanja - proveru odmah posle uvođenja. Uporedite ove datume sa kalendarom zatvaranja meseca, izveštaja i isplata: šta opterećuje sistem tih dana. Dajte mu resurse unapred i odredite dežurnog koji poznaje sistem. Naći šta se promenilo tih nedelja. Ako je to rast posla - preračunati dežurnu smenu za novi nivo. Ako je izdanje ili izvođač - vratiti pitanje onome ko je uneo promenu.
Proverite sami.* Otvorite zahteve za Čet 02:00-03:00: ako je u njima jedan sistem i sličan tekst, to je jedan uzrok koji se ponavlja. Vreme je uzeto kako je u izvozu. Ako vaš sistem piše vreme po UTC, pomerite sate na svoju vremensku zonu. Otvorite zahteve za ERP na datume ciklusa (29.09.2025, 29.10.2025, 28.11.2025, 30.12.2025): ako je tekst isti, to je jedan uzrok. Ako je sistem ponovo pokretan između kvarova, ciklus može biti vreme za koje se resurs potroši. Pogledajte šta ste radili od 13.08.2025 do 24.09.2025: izdanja, prebacivanja, novi ugovori, podešavanje monitoringa.
Šta smo gledali. Raspodela najdužih zastoja i trenutni tempo pojave incidenata.
Šta smo dobili. 2,7% incidenata traje duže od 6 č - otprilike jedan od 37. Pri vašoj učestalosti to je oko 3 puta mesečno. Otvorenih tiketa u izvozu: 14, od njih duže od 6 č otvoreno je 13. Njihov kraj još nije poznat, pa nisu u brojanju dugih incidenata. Ako se ucestalost zadrzi, u narednih 7 dana ocekuje se oko 36 incidenata (verovatan opseg 22-53), za 30 dana - oko 156 (128-185). Procena je zasnovana na vasoj ucestalosti incidenata u posmatranom periodu - računato po poslednjih 60 dana: učestalost se menjala u periodu.
Učestalost se promenila: bilo je 3,2 dnevno, postalo je 4,9. Korak ili postepen rast - podaci ne razlikuju; traka je gde je korak mogao biti. Narednih 30 dana: oko 156 incidenata (128-185).
Šta to znači. To nije „malo verovatno": takav slučaj se dešava oko 3 puta mesečno. Vredi ga tretirati kao redovnu situaciju sa spremnim planom, a ne kao katastrofu koja se rešava u hodu.
Šta uraditi. Napišite i jednom uvežbajte redosled radnji za zastoj duži od 6 č: ko odlučuje o prelasku na rezervu, ko razgovara sa klijentima, ko sa regulatorom.
Proverite sami.* Pitajte dežurnog inženjera šta će uraditi ako se servis ne podigne za 3 č. Ako odgovor počinje sa „zvaću rukovodioca", plana nema.
Šta smo gledali. Potpunost i povezanost samog dnevnika.
Šta smo dobili. Ocena kvaliteta podataka - B (od A, B, C, D). Popunjenost polja:
Šta to znači. Polja vreme prijave, vreme zatvaranja, servis ili čvor, prioritet, opis ili uzrok su dobro popunjena - znači sve što smo rekli oslanjajući se na njih je pouzdano. Zapise bez vremena zatvaranja isključili smo iz računa trajanja, a nismo im podmetnuli prosek.
Šta uraditi. Napravite polje uzroka obaveznim pri zatvaranju, ali sa kratkom listom vrednosti umesto slobodnog teksta. Slobodan tekst se popunjava loše, lista od sedam stavki dobro. Za kvartal ćete dobiti udeo incidenata sa utvrđenim uzrokom - pokazatelj koji danas nema iz čega da se izračuna.
Proverite sami.* Otvorite vaš sistem tiketa i pogledajte koja su polja obavezna pri zatvaranju. Ako uzrok nije obavezan, eto zašto ga nema u ovom izveštaju.
| Polje | Popunjeno |
|---|---|
| Vreme prijave | 100% |
| Vreme zatvaranja | 99% |
| Servis ili čvor | 100% |
| Prioritet | 100% |
| Opis ili uzrok | 100% |
Imena metoda namerno nismo prikazivali u glavnom tekstu - da ga ne opterećujemo.
| Šta u izveštaju | Kako je izračunato |
|---|---|
| Ukupno vreme zastoja | Spajanje preklapajućih intervala pre sabiranja - bez toga se paralelni incidenti broje dvaput |
| Vreme obnove servisa | Medijana, prosek i 95. percentil trajanja. ITIL 4 taj pokazatelj zove MTRS (mean time to restore service); u rečniku pouzdanosti IEC 60050-192 isti broj se zove MTTR |
| Vreme između otkaza | Za celu kompaniju - period podeljen brojem incidenata: koliko često se nešto pokvari. Za servis - period podeljen njegovim incidentima: to je vreme između otkaza (ITIL 4: MTBF). Računamo otkaze usluge, a ne fabričku pouzdanost opreme |
| Koncentracija zastoja | Sabiranje zastoja po objektima. Posebno - Gini koeficijent: koliko različito koštaju sami incidenti. Kod vas je 0.53: 0 znači da svaki incident košta isto, iznad 0,6 - najveći deo zastoja daje nekoliko incidenata |
| Povratak kvara na isti objekat | Isti objekat istog sistema u roku od 7 dana posle popravke; tiketi jednog kvara su jedan kvar; poređenje sa slučajem u kom se objekti sistema kvare jednako |
| Udeo zahteva za uslugu | Po koloni tipa tiketa gde postoji i popunjena je; inače po frazama redovne usluge u opisu (dodela pristupa, reset lozinke, otvaranje naloga), ako pored njih nema reči o kvaru. Pronađeni zapisi su izbačeni iz svih proračuna; pronađeno po rečima je procena odozdo |
| Veze između sistema | Tiket drugog sistema u roku od 15 minuta posle otkaza, prema sopstvenom ritmu tog sistema (nivo u okolnim nedeljama, dan u nedelji, sat); korekcija na broj proverenih parova (247); veza mora da važi bez svoja dva najopterećenija dana; dani zajedničkih oluja izuzeti |
| Promena učestalosti 01.09.2025 | Nedeljni proseci pre i posle svakog mogućeg datuma, sa korekcijom na rasipanje iz nedelje u nedelju; jačina signala 5,4 prema pragu 3,3 (obične godine ga pređu u oko 3-5% slučajeva) |
| Verovatnoća dugog zastoja | Uopštena Pareto raspodela preko prekoračenja praga (Peaks-Over-Threshold). Parametar oblika ξ = +0.12, 95% interval poverenja [-0.07, +0.27]; 137 prekoračenja praga 3.4 č |
| Prognoza učestalosti | Prosečna učestalost trenutnog režima, bez produžavanja trenda; interval predviđanja prema rasipanju vaših nedelja i meseci (Poason ili, kada kvarovi dolaze u talasima, negativna binomna) |
| Ocena kvaliteta podataka | Popunjenost obaveznih polja, povezanost vremena, udeo isključenih zapisa |
Kriva se jasno odvaja od prave linije - potvrda da incidenti koštaju različito: 41.5% njih nosi 80% ukupnog zastoja (Gini=0.534). Prava linija bi značila da svaki incident košta isto.
Formulacije prate zvanični ITIL 4 rečnik.
| Termin | Značenje |
|---|---|
| Događaj | Svaka promena stanja koja je značajna za upravljanje uslugom |
| Incident | Neplanirani prekid usluge ili smanjenje njenog kvaliteta |
| Problem | Uzrok ili potencijalni uzrok jednog ili više incidenata |
| Poznata greška | Problem koji je analiziran, ali nije otklonjen |
| Zaobilazno rešenje | Rešenje koje smanjuje ili uklanja uticaj incidenta dok potpuno rešenje još ne postoji |
| Izmena | Dodavanje, izmena ili uklanjanje bilo čega što može da utiče na usluge |
| Zahtev za uslugu | Zahtev korisnika za radnju dogovorenu kao redovan deo usluge. Nije incident |
| Vreme obnove servisa | Koliko brzo se usluga obnavlja posle otkaza |
* Ovi zadaci mogu biti urađeni tačnije i kvalitetnije uz naše učešće.