GLPI máte v prevádzke. Tickety sa vytvárajú, notifikácie chodia, na dashboarde je všetko zelené. Tu je jednoduchý test: otvorte si posledných desať Change ticketov. Viete z nich bez doplnkového dopytu povedať, kto schválil, aké riziko bolo vyhodnotené, ktorého CI sa zmena týkala a či zbehla v SLA? Ak nie, systém sa vám zredukoval na evidenciu.
V praxi evidencia vyzerá takto: jediná entita „IT“ pre celú firmu. Kategórie ticketov, ktoré z 80 percent končia v jednej zbernej kategórii. SLA definované na root entite, takže platia na všetko a nepáli nikoho. Profil „technician“ priradený štyridsiatim ľuďom. Change workflow, ktorý má pole pre CAB schválenie, ale nikto nekontroluje, či je vyplnené. Na polovici ticketov chýba prepojenie na aktívum — itemtype prázdny, žiadna CI väzba.
Každý jeden z týchto bodov je nastaviteľný. Ani jeden si nevšimnete, kým niekto nepovie „ukážte mi všetky zmeny na doméne za Q3“.
Čo sa typicky nájde v GLPI audite
Ide o konfiguračný aj procesný audit — v GLPI sa tieto dve roviny od seba ťažko oddelia. Väčšina nálezov sa opakuje naprieč inštaláciami:
- Strom entít vs. organizačná štruktúra. Ak sa nezhodujú, všetko pod tým (profily, SLA, kategórie) dedí nesprávnu štruktúru.
- Profily a roly. Koľko účtov má Super-Admin? Koľkí sú nad rámec potreby (technician zvláda 90 % úloh)? Kedy bol profil naposledy zmenený — a kým?
- Pokrytie SLA. Aké percento ticketov je pokryté SLA, ktoré má definované akcie (eskalácie, notifikácie), nielen číslo v poli?
- Asset ↔ ticket väzba. Na koľkých ticketoch je
itemtypevyplnený? Bez väzby nemáte MTTR na službu, nemáte dopadovú analýzu, nemáte postmortem. - Change workflow. Blokuje uzavretie zmeny bez schválenia, alebo je schválenie len pole? Prechádza zmena rovnakým procesom, keď ju vytvorí admin?
- Paralelné evidencie. Excel s CI zoznamom. Zdieľaný mailbox pre schválenia. Confluence stránka s asset inventárom. Každá z nich je signál, že GLPI nepokrýva to, čo malo.
Výstupom auditu je typicky 20 až 40 nálezov. Zhruba tretina sú rýchle opravy (hodiny práce), tretina konfiguračné zmeny (dni), tretina procesné rozhodnutia (týždne). Väčšina nevyžaduje upgrade, migráciu ani nový nástroj.
Prečo to tak dopadne
GLPI sa typicky nasadí ako projekt. Dodávateľ ukončí zmluvu, interný administrátor nástroj zdedí, ďalšia evolúcia je riadená ticketmi — „pridajte pole“, „spravte kategóriu“, „zvýšte mi prioritu“. To nie je konfigurácia, to je údržba na požiadanie. Proces pomenovaný pri implementácii sa rok po roku rozpadá na individuálne výnimky.
Medzičasom firma pribrala dve dcérske spoločnosti, prešla na hybrid cloud, podpísala ISO 27001 a pod tlakom NIS2 od seba žiada auditovateľný change management. GLPI ostalo v pôvodnej konfigurácii. Vznikne medzera medzi realitou a tým, čo sa do systému zapisuje. Reporty sa prestanú robiť v GLPI a začnú v Exceli.
Kde začať, ak to v tomto texte spoznávate
Začnite entitou. Ak strom entít nekopíruje organizáciu, všetko ostatné je kompenzácia. Druhý krok sú profily — zistite, kto má aké práva a prečo. Tretí krok je jeden reálny procesný use case (najčastejšie change alebo incident-to-problem) prekreslený v GLPI tak, aby reflektoval to, čo sa naozaj deje.
Ostatné nadväzuje: SLA sa prepnú na služby, kategórie sa prestrihnú podľa toho, čo tím reálne rieši, reporty začnú chodiť z GLPI, lebo dáta majú konečne štruktúru. Nepotrebujete meniť platformu. Potrebujete si sadnúť, otvoriť konfiguráciu a odstrániť výnimky, ktoré sa nazbierali.