Väčšina GLPI inštalácií začne ako ticketing systém. Niekto pošle požiadavku, technik ju zoberie, vyrieši, uzavrie. Pri 20 tiketoch denne to funguje. Pri 200 už nie — technici trávia viac času triedením a prideľovaním než samotným riešením. Tu nastupujú business rules v GLPI. Žiadna AI, žiadne machine learning — len rozumne nakonfigurované pravidlá, ktoré urobia opakujúce sa rozhodnutia za vás, aby sa technici sústredili na skutočnú prácu.
Engine business rules
Pravidlá pre tikety nastavujete v Administration → Rules → Rules for assigning a category, podobne pre Rules for assigning a ticket created through a mail collector a ďalšie typy. Engine pracuje na first-match báze: pravidlá majú poradie, GLPI prejde od prvého a aplikuje to, ktoré sedí. Toto je ten istý engine, ktorý GLPI používa na priradenie SLA, smerovanie notifikácií a entity-split tiketov.
Každé pravidlo má dve časti:
- Conditions — boolean súbor podmienok cez polia tiketu (kategória, žiadateľ, e-mail predmet, obsah, lokácia, atď.). Operátory: equals, contains, regex, is empty, is not empty.
- Actions — čo nastaviť: kategóriu, prideliť skupine, prideliť technikovi, nastaviť prioritu, urgenciu, dopad, status.
Čo sa dá automatizovať
Smerovanie tiketov
GLPI vie automaticky priradiť tiket podľa kategórie, skupiny žiadateľa, lokality alebo kombinácie polí. Tiket od finančného oddelenia o SAP ide rovno na aplikačný tím. HW požiadavka z košickej pobočky ide na lokálny support. Žiadne manuálne triedenie.
Konkrétny príklad pravidla:
Name: Route SAP requests to apps team
Conditions:
Requester group contains "Finance"
Subject regex /sap|s4hana|fiori/i
Actions:
Set category → Software → Applications → SAP
Assign group → Apps team
Set priority → MediumPriorita a SLA priradenie
Namiesto toho, aby používatelia stanovovali prioritu (vždy si vyberú "urgent"), GLPI ju vypočíta z kombinácie urgency a impact — štandardná ITIL matica priorít. SLA pravidlá potom automaticky priradia časový rámec podľa výslednej priority a kategórie. P1 incident dostane 4-hodinový response SLA bez toho, aby ho niekto manuálne nastavoval. A eskalačné pravidlá sa spustia automaticky, ak hodiny vypršia.
Notifikácie, ktoré dávajú zmysel
GLPI v štandardnom nastavení posiela priveľa e-mailov. Automatizačná vrstva to upravuje: notifikujte žiadateľa pri zmene stavu, vedúceho tímu pri eskalácii, manažéra pri schvaľovaní — ale tam zastavte. Nikto nepotrebuje e-mail za každú internú poznámku.
Čo neautomatizovať
Automatizácia funguje pre rozhodnutia, ktoré sa riadia jasnými pravidlami. Nefunguje pre judgment calls. Časté chyby:
- Auto-uzatváranie tiketov po X dňoch nečinnosti — znie efektívne, frustruje používateľov, ktorých problém ešte nebol vyriešený.
- Priradenie všetkého najmenšiemu tímu — rozdeľuje záťaž, ale ignoruje skill match.
- Auto-vyriešenie podľa template odpovede — funguje pre password reset, zlyhá pri čomkoľvek vyžadujúcom diagnostiku.
Cieľom je automatizovať smerovanie a administratívu tak, aby technici trávili čas na riešení, nie na triedení.
Praktický štartovací set
Ak je váš helpdesk ešte plne manuálny, začnite tromi pravidlami:
- Auto-priradenie podľa kategórie — namapujte každú kategóriu tiketu na zodpovednú skupinu. Toto je 80 % hodnoty automatizácie.
- Auto-nastavenie SLA podľa priority — definujte 3-4 prioritné úrovne so zodpovedajúcimi response a resolution časmi.
- Notifikácie len pri eskalácii — znížte e-mailový šum na signály, ktoré sú dôležité.
Tieto tri pravidlá samé osebe môžu zlepšiť triage time a urobia z SLA tracking-u niečo zmysluplné, namiesto formálneho čísla na reporte.
Cascade pre zložitejšie scenáre
Natívne business rules dobre pokryjú lineárne pravidlá typu "ak X, urob Y". Pre viacstupňové workflow s vetvením a vlastnou logikou pozri náš workflow plugin Cascade — postavený nad business rules tak, aby sa udržala kompatibilita s natívnymi mechanizmami GLPI.
Ako overiť, že pravidlo funguje
Po vytvorení pravidla GLPI ponúka tlačidlo Test v každom pravidle — zadáte vzorové hodnoty polí a uvidíte, či by sa pravidlo aplikovalo a aké akcie by spustilo. Vyhnete sa tak nasadeniu pravidla, ktoré nikdy nezachytí žiadny tiket alebo naopak chytí všetko.
Ďalšia kontrola po nasadení: za 24 hodín sa pozrite na uložené vyhľadávanie nad poľami, ktoré pravidlo nastavuje. Ak je v ňom 0 záznamov, pravidlo sa nikdy nespustilo a treba ho preskúmať. Ak je v ňom 100 % tiketov, pravidlo je príliš široké.