Keď sa tá istá tlačiareň zasekne každý pondelok, to nie je desať incidentov. To je jeden problém. Tento rozdiel je dôležitý a GLPI má na to dedikovaný modul.
Väčšina tímov žije výlučne vo fronte tiketov. Opravia každý incident, uzavrú ho a idú ďalej. Tá istá porucha sa vráti budúci týždeň a opravia ju znova. Správa problémov tento cyklus prerušuje tým, že kladie inú otázku: prečo sa to stále opakuje?
Ako funguje modul problémov v GLPI
Modul Problémy v GLPI (v časti Podpora > Problémy) je oddelený od systému tiketov. Problém je samostatný objekt s vlastným životným cyklom: Nový, Priradený, Plánovaný, Vyriešený, Uzavretý. Sleduje analýzu koreňovej príčiny, dokumentuje riešenia a odkazuje na incidenty, ktoré vyvolali vyšetrovanie.
Workflow je priamočiary:
- Agent si všimne vzor: ten istý typ incidentu sa objavuje opakovane.
- Vytvorí tiket problému z menu Problémy.
- Prepojí súvisiace tikety incidentov s problémom pomocou záložky "Tikety" na formulári problému.
- Tím vyšetrí koreňovú príčinu a zdokumentuje zistenia v poli riešenia problému.
- Ak oprava vyžaduje zmeny v infraštruktúre, vytvoria change request prepojený s problémom.
- Po nasadení a overení opravy sa problém uzavrie.
Všetky prepojené incidenty teraz odkazujú na problém, čím vzniká jasný reťazec od symptómu cez koreňovú príčinu až po opravu.
Incident vs. problém: odlišné ciele
Správa incidentov obnovuje službu. Tlačiareň je zaseknutá: uvoľnite ju, nech zas tlačí. Záleží na rýchlosti. Nesnažíte sa pochopiť, prečo sa to stalo; snažíte sa dostať používateľa späť k práci.
Správa problémov predchádza opakovaniu. Tlačiareň sa zasekáva každý pondelok, pretože konkrétny zásobník papiera má opotrebovaný podávací valček. Výmena valčeka eliminuje budúce incidenty. Tu záleží na dôkladnosti viac ako na rýchlosti.
Miešanie týchto dvoch režimov v jednom tikete vedie k tomu, že ani jeden sa nerobí dobre. Agenti urýchľujú analýzu koreňovej príčiny, pretože tiká SLA incidentu, alebo odkladajú obnovu služby, pretože vyšetrujú. Oddelené moduly GLPI vynucujú správny prístup pre každý z nich.
Budovanie databázy known error
Nie každý problém sa dá vyriešiť okamžite. Rozpočtové obmedzenia, závislosti na dodávateľoch alebo plánované okná údržby môžu oddialiť trvalé riešenie. Medzitým potrebujete workaround.
Problémy v GLPI podporujú prístup "Known Error." Keď identifikujete koreňovú príčinu, ale ešte nemôžete nasadiť opravu, zdokumentujte workaround v poli riešenia problému a nechajte problém otvorený so statusom Pozorovaný alebo Plánovaný. Agenti riešiaci budúce incidenty rovnakého typu môžu skontrolovať prepojený problém, nájsť zdokumentovaný workaround a vyriešiť incident rýchlejšie.
Postupom času sa tak buduje interná znalostná báza známych problémov a ich workaroundov. Je hodnotnejšia ako akákoľvek wiki, pretože je priamo prepojená s reálnymi dátami tiketov.
Kedy vytvoriť problém (a kedy nie)
Nie každý incident si zaslúži vyšetrovanie problému. Dobré pravidlo:
- Tri alebo viac incidentov s rovnakým symptómom za 30 dní: vytvorte problém.
- Jeden závažný incident postihujúci veľa používateľov: vytvorte problém, aj keď sa stal len raz, pretože rozsah dopadu ospravedlňuje vyšetrovanie.
- Jednorazový incident s jasnou, neopakujúcou sa príčinou (chyba používateľa, jednorazová nesprávna konfigurácia): uzavrite incident normálne. Problém nie je potrebný.
Cieľom nie je vytvoriť problém pre každý incident. Cieľom je zachytiť vzory, ktoré plytvajú najviac času, keď sa neriešia.
Prepojenie problémov so zmenami
Modul Zmeny v GLPI sa priamo prepája s problémami. Keď analýza koreňovej príčiny identifikuje opravu vyžadujúcu zmenu infraštruktúry, softvéru alebo konfigurácie, vytvorte change request priamo z problému. Získate tak sledovateľnosť od pôvodných incidentov cez analýzu problému až po schválenú zmenu a jej implementáciu. Audítori a manažéri môžu sledovať celý reťazec bez prehrabávania sa komentármi tiketov.
Cyklus vyzerá takto: zaznamenanie opakujúcich sa incidentov, vytvorenie problému, identifikácia koreňovej príčiny, žiadosť o zmenu, schválenie a nasadenie zmeny, uzavretie problému. Každý krok je prepojený objekt v GLPI, nie poznámka zakopaná v tikete.