GLPI nemá jeden objekt na „prácu" — má štyri. Ticket, Problem, Change, Task. Každý sa hodí na inú vec a zámena pošle helpdesk do chaosu, kde technik nevie, čo má riešiť ako prvé a čo ako súčasť čoho. Tento článok je o tom, kedy sa ktorý objekt používa, ako spolu súvisia, a ako sa vyhnúť anti-patternu „všetko je tiket".
Ticket: incident a request
Ticket je jediný objekt, ktorý vyplní koncový používateľ. V GLPI je Ticket rozčlenený na dva podtypy cez pole Type:
- Incident — niečo nefunguje. „Outlook neotvára e-maily.", „Tlačiareň hlási error.", „ERP padá pri prihlásení."
- Request — žiadosť o niečo. „Potrebujem nový notebook.", „Chcem prístup do SAP.", „Reset hesla."
Z pohľadu používateľa je rozdiel marginálny — obidvoje vytvorí cez self-service portál a sleduje progres. Z pohľadu reportingu je rozdiel kľúčový: incidenty merate cez SLA TTR (čas do vyriešenia, lebo niečo nefunguje a treba to opraviť), requesty cez SLA TTO (kedy začneme, lebo niečo treba získať alebo zmeniť). MTTR má zmysel pre incident, nie pre „nový notebook za 3 dni".
Problem: root cause
Problem nie je viditeľný používateľovi. Vytvorí ho IT tím, keď sa vyriešia incidenty, ale technik vie, že príčina je hlbšia a vráti sa. Príklad:
- Pondelok: incident #1234 „Outlook nefunguje" — technik reštartuje, opraví.
- Streda: incident #1267 „Outlook nefunguje" — od inej osoby, na inom PC.
- Piatok: incident #1289 „Outlook nefunguje" — od tretej osoby.
Po treťom incidente technik vytvorí Problem „Sporadické zlyhanie Outlook v M365 prostredí". Problem má vlastný workflow:
- Investigation — zber log-ov, reprodukcia, analýza.
- Root cause — zápis príčiny (napr. „M365 update spôsobuje konflikt s antivirusom XYZ verzie 4.2").
- Workaround — dočasné riešenie (vypnutie konkrétnej AV politiky pre Outlook).
- Solution — trvalé riešenie (upgrade antivirus na 4.3, alebo zmena konfigurácie).
Problemy umožňujú merať recurring issues a venovať im strategickú pozornosť — niečo, čo sa v incident-only modeli nikdy nepodarí.
Change: zmena s schvaľovaním
Change je naplánovaná zmena infraštruktúry — upgrade, deployment, konfiguračná úprava — ktorá môže ovplyvniť produkciu. Workflow:
- Návrh zmeny — popis, dôvod, dopad, plán.
- CAB review — Change Advisory Board posúdi a schváli (cez GLPI Validations).
- Implementácia — vykonanie zmeny v dohodnutom okne.
- Post-implementation review — overenie, že zmena funguje a nepriniesla regresie.
Change je správny objekt pre veci ako: upgrade GLPI z 10.0 na 11.0, nasadenie nového load balanceru, migrácia DNS provider-a. Nie pre „pridajte mi prístup do Confluence" — to je Request.
Task: sub-úloha v rámci tiketu
Task v GLPI nie je samostatný objekt — je sub-úloha v rámci tiketu, problému, zmeny alebo projektu. V detaile tiketu cez záložku Tasks → Add sa pridá úloha s vlastným popisom, priradeným technikom, plánovaným časom a trvaním. Slúži na rozčlenenie tiketu na konkrétne kroky:
- Tiket: „Onboarding nového kolegu Karol Novák"
- Task 1: „Vytvoriť M365 účet" (technik A, 30 min)
- Task 2: „Pripraviť notebook" (technik B, 2 hod)
- Task 3: „Konfigurovať VPN" (technik A, 15 min)
- Task 4: „Nastaviť prístup do CRM" (technik C, 30 min)
Task netvorí novú odpoveď do tiketu pre používateľa — je interným nástrojom rozdelenia práce. Pre niečo, čo používateľ má vidieť, použijete Followup.
Rozhodovacia matica
Ktorý objekt vytvoriť pri novej požiadavke:
Niečo nefunguje, hlási to používateľ
→ Ticket type Incident
Používateľ chce niečo dostať / urobiť
→ Ticket type Request
Opakujúci problém, ktorý treba zanalyzovať
→ Problem (linkujete naň súvisiace incidenty)
Plánovaná zmena s rizikom dopadu na produkciu
→ Change (s validáciami od CAB)
Sub-úloha v rámci existujúceho tiketu/zmeny
→ Task (priamo v záložke objektu)
Dlhodobá iniciatíva s fázami a deliverables
→ Project (s task-mi a sub-projektmi)Anti-pattern: „všetko je tiket"
Najčastejšia chyba pri rozbiehaní GLPI je používať len Tickets. Krátky term zisk: jednoduchosť. Dlhý term strata:
- Žiadny problem management — recurring issues sa nikdy neidentifikujú, len sa stále riešia ad hoc.
- Žiadny change control — risky deployments idú bez schvaľovania a po chybe sa nedá vystopovať, kto čo schválil.
- Tickets sa premieňajú na epické vlákna — onboarding sa „rieši" v jednom tikete s 40 followup-mi, namiesto rozdelenia na 5 task-ov so zodpovednými.
Štyri typy objektov nie sú zbytočná komplexita — sú jazyk pre rôzne typy práce. Keď ich tím správne používa, GLPI prestane byť „lepší e-mail" a stane sa skutočným ITSM nástrojom.