Tento článok nie je o tom, ako sa GLPI nastaví — to je iná téma. Je o tom, čo sa reálne zmení v dennej IT prevádzke, keď organizácia prejde z e-mailového/telefonického helpdesku na štruktúrovaný ticket nástroj. Pohľad CIO alebo IT manažéra, ktorý zvažuje rozhodnutie a chce vedieť, čo bude vidieť — týždeň po týždni, mesiac po mesiaci, rok po roku.
Stav „nula": e-mailový helpdesk
Typická stredne veľká firma pred GLPI:
- Požiadavky chodia na
support@firma.sk+ Teams chat + WhatsApp + telefón. Niektoré priamo na konkrétneho technika. - Výkon tímu sa meria pocitom („Marek zvláda veľa", „Peter sa stratil").
- Pri reklamácii klienta IT manažér 30 min hľadá v Outlook archívoch.
- Nikto nevie, koľko incidentov mesačne sa opakuje (lebo nie sú kategorizované).
- Nový technik 3 mesiace zisťuje, „čo sa robí najčastejšie".
Týždeň 1 – 2: viditeľnosť
Prvý okamžitý efekt: jeden zoznam otvorených prípadov. Tímový dashboard ukáže, koľko vecí je rozrobené, kto to rieši, ako dlho. Skryté tikety v osobných e-mailoch sa zrazu zviditeľnia. Často nepríjemný moment: „máme otvorených 87 vecí, naozaj?". Toto je správny stav — viditeľnosť pred tým, čo sa skutočne deje.
Druhý efekt: žiadateľ má kde pozrieť stav. Prestane volať „už ste sa na to pozreli?" a otvorí si tiket. To samé o sebe ušetrí prerušovacie hovory.
Mesiac 1: triáž a kategorizácia
Po pár týždňoch začnú dáta dávať zmysel. Top kategórie: 35 % reset hesla, 22 % VPN/Office365, 18 % tlačiarne, 25 % iné. Pred ticketing-om to boli „pocity"; teraz sú to čísla. Z týchto čísel sa rodia rozhodnutia: zaviesť self-service reset hesla (lacné, vysoký objem), kúpiť silnejšie tlačiarne (drahé, ale opakujúce sa).
Druhá vec: rozdiel medzi incidentom (niečo nefunguje) a požiadavkou (žiadosť o niečo) sa prestane miešať. Tímy začnú vidieť, že 60 % objemu je „požiadavky" (prístupy, nové konto, hardvér), nie „incidenty". To zmení, kto sa o ne stará — request management môže ísť cez self-service portál, incidenty potrebujú technika.
Mesiac 3: SLA a očakávania
Tretí mesiac sa zvyčajne zavádza prvé SLA — nie tvrdé, ale meranie. „Priemerný čas od vytvorenia k riešeniu je 14 hodín, P1 je 3 hodiny". Týmto sa diskusia s biznisom premení z „IT je pomalé" na „máme tieto čísla, kde chcete byť?". Niektoré jednotky budú mať vyššie nároky a sú ochotné platiť, iné nie. Toto je prvý raz, kedy IT vie odpovedať na „koľko by stálo zlepšiť P1 SLA z 3 hodín na 1 hodinu" reálnymi dátami.
Mesiac 6: akumulovaná znalosť
Po pol roku tikety obsahujú zaznamenané riešenia. Pri novom podobnom probléme technik nájde starý tiket, prečíta riešenie, aplikuje. Začnú sa rodiť KB články — najprv ako „toto sa opakuje, dám to do FAQ", neskôr ako proces. Onboarding nového kolegu sa skráti zo 6 týždňov na 2 — má kde čítať.
Toto je moment, kedy GLPI prestáva byť „len ticket nástroj" a stáva sa znalostnou pamäťou IT tímu. Čo predtým sídlilo v hlave seniorného technika, teraz je vyhľadateľné.
Mesiac 12: audit-readiness
Po roku príde prvý ISO 27001 alebo NIS2 audit. Audítor sa pýta:
- „Ako sledujete bezpečnostné incidenty?" → filter Tickets, kategória Security.
- „Aký bol priemerný čas riešenia P1?" → built-in report.
- „Kto schválil zmenu firewall pravidiel 14. marca?" → Change #244 → Validation log.
- „Aký SLA máte na výmenu hardvéru?" → SLA dashboard.
Predtým: panika, hľadanie v Outlook, „skúsme dohľadať". Teraz: 5 minút v UI, export PDF. Compliance ľudí to robí šťastnými, audítori odchádzajú skôr a s menej findings.
Čo sa NEzmení
Aby bol obraz úprimný — GLPI nevyrieši zlú prácu:
- Tlačiareň, ktorá je pokazená 8 mesiacov, bude pokazená aj v GLPI. Nástroj len ukáže, že sa neopravuje.
- Technik, ktorý nezatvára tikety, bude mať plný backlog. To si vyžaduje manažérsku konverzáciu, nie nástroj.
- Tím s nedostatkom kapacity. GLPI to len zviditeľní; kapacitu nepridá.
To je dobrá správa: GLPI dáva manažérovi nástroje na vidieť pravdu a robiť rozhodnutia, ktoré sú dovtedy boli na pocit. Pre implementáciu to znamená, že prvé mesiace nie sú o softvéri, ale o tom, že vedenie pozná svoju IT prevádzku po prvý raz reálnymi číslami.