Najmenej formálny schvaľovací proces v IT vyzerá takto: niekto napíše do Slacku "kúpime ten server?", manažér odpovie "ok", o tri mesiace nikto nevie, kto rozhodol a načo. Najformálnejší vyzerá ako e-mailové reťazce s desiatimi adresátmi a tabuľkou v prílohe. Medzi nimi je GLPI s vstavanými validáciami — schvaľovacie procesy, ktoré sú dohľadateľné, ale nepoškodia rýchlosť. Tento článok je o ich nastavení.
Validations: vstavaný schvaľovací mechanizmus
GLPI má pre každý objekt typu Ticket, Change a Problem samostatnú záložku Validations. Cez ňu žiadateľ alebo technik vyžiada formálne schválenie od konkrétneho používateľa alebo skupiny. Schvaľovateľ dostane notifikáciu a vidí v rozhraní svoje čakajúce schválenia v jednom zozname.
Tri stavy validácie:
- Waiting — vyžiadané, čaká sa.
- Granted — schválené.
- Refused — zamietnuté, povinný komentár prečo.
Každá zmena stavu sa loguje s časovou pečiatkou — pri audite máte presný kompletný záznam, kto čo kedy schválil.
Sekvenčné vs paralelné schválenie
GLPI natívne podporuje obe stratégie:
- Paralelné — vytvoríte viacero validation requests súčasne. Schvaľovatelia rozhodujú nezávisle. Vhodné pre situácie, kde každý posudzuje iný aspekt (manažér rozpočet, tech lead architektúru, security risk).
- Sekvenčné — druhý validation request sa vytvorí (typicky cez business rule alebo ručne) až po schválení prvého. Vhodné pre eskaláciu nadol-nahor: priamy nadriadený → riaditeľ → CFO.
Štandardné pravidlo: paralelné schválenie pre rýchlosť, sekvenčné pre formálne procesy s odsúhlasovacou hierarchiou.
Podmienené smerovanie podľa nákladov
Pre Change Management typicky chcete rôzne schvaľovacie cesty podľa veľkosti zmeny:
- Štandardná zmena (low risk, low cost) — len schválenie tech lead-a. Validation request sa po vytvorení Change automaticky pošle vedúcemu skupiny, ktorá Change vlastní.
- Normálna zmena (medium impact, do 5 000 €) — tech lead + manažér oddelenia. Sekvenčne, pretože manažér potrebuje vedieť, že tech lead to už posúdil.
- Zásadná zmena (high impact, nad 5 000 € alebo dotyk produkčnej DB) — pridáva CAB (Change Advisory Board) ako paralelnú validáciu.
Implementácia v GLPI: Administration → Rules → Rules for changes definuje, ktoré validation requests sa pri vytváraní Change automaticky vyrobia. Podmienky používajú polia Change (kategória, dopad, naliehavosť) a custom fields (cena, ovplyvnené aktíva).
Eskalácia po vypršaní časového limitu
Najčastejšia bolesť schvaľovacieho procesu: schvaľovateľ ide na dovolenku a tiket leží. GLPI to rieši cez SLA-podobnú logiku aplikovanú na validations:
- Validation request má voliteľné pole Time limit (napr. 48 hodín).
- Po vypršaní cron task
Ticket::cronCheckValidationsspustí business rule. - Pravidlo môže: poslať reminder schvaľovateľovi, eskalovať na zástupcu, alebo automaticky zamietnuť (zriedka odporúčame).
Najlepšia praktika: jeden reminder po polovici limitu, eskalácia po jeho vypršaní. Eskalujte na konkrétneho zástupcu, nie na celú skupinu — inak má zmena dvoch nesúhlasiacich schvaľovateľov a zaseknete sa ešte viac.
Audit trail
Každý objekt v GLPI má záložku Historical, ktorá zaznamenáva všetky zmeny vrátane validations. Pre auditné potreby (ISO 27001, NIS2, finančný audit) je toto váš primárny dôkaz schvaľovacieho procesu. Záznam obsahuje:
- Kto request vytvoril a kedy.
- Komu bol pridelený.
- Kedy a ako odpovedal (Granted / Refused).
- Komentár pri zamietnutí.
Toto je dôvod, prečo formálne schvaľovacie procesy patria do GLPI a nie do e-mailov — kompletné audit trail máte zadarmo, bez ďalšej infraštruktúry.
Limity natívnych validations
Vstavané validations dobre pokryjú jednoduché schvaľovacie reťazce. Pre zložitejšie scenáre narážajú na limity:
- Bez podpory vetvenia podľa odpovede — nie je nárazová cesta "ak schvaľovateľ A povie áno, choď k B; ak nie, koniec".
- Bez podpory dynamického delegovania (zástup počas dovolenky musíte priraďovať ručne).
- Bez vizuálneho návrhára — validations konfigurujete cez business rules a manuálne requesty.
Pre bohatšie viacúrovňové workflow s vetvením, dynamickými rolami a vizuálnou mapou pozri náš workflow plugin Cascade — postavený nad GLPI tak, aby zachoval audit trail, ale dovolil komplexnejšie procesy.
Praktický príklad: nákup nového servera
- Žiadateľ vytvorí Change "Nákup nového Dell PowerEdge", kategória Hardware → Server, dopad High, cena 4 800 €.
- Business rule podľa ceny < 5 000 € spustí dve paralelné validations: tech lead (overí špecifikáciu) + manažér oddelenia (overí rozpočet).
- Tech lead schváli za 2 hodiny.
- Manažér je na dovolenke. Po 24 hodinách reminder, po 48 hodinách eskalácia na CFO ako zástupcu.
- CFO schváli. Change prejde do stavu Approved, business rule automaticky vytvorí tiket "Objednať Dell PowerEdge" pre obstarávanie.
- V Historical je presný záznam: kto kedy aký krok urobil.
Bez tejto stopy by sa o tri roky pri audite nikto nedohádal, kto rozhodol o nákupe — a to je presne ten moment, kedy formálny proces vrátený investíciu.