„Automatizácia“ patrí k najpreexponovanejším slovám v ITSM marketingu a GLPI business rules zachytávajú časť toho svetla. Poctivý obraz je užší a užitočnejší: business rules sú jednoduchý engine „podmienka → akcia“, ktorý beží pri vytvorení a aktualizácii tiketu. Pre jeden druh práce sú výborné, pre iný sa nehodia — a keď viete, ktorý je ktorý, dokážete z nich vyťažiť veľa bez neskorších sklamaní.
Čo business rule naozaj je
Business rule v GLPI je v praxi riadok v tabuľke: splň tieto podmienky na tikete a nastav tieto hodnoty do týchto polí. „Ak je entita zadávateľa Predaj a kategória Tlačiareň, nastav pridelenú skupinu na IT-Bratislava a SLA na Gold.“ Viac v tom nie je. Pravidlo beží raz pri vytvorení tiketu a voliteľne aj pri každej aktualizácii. Engine je úmyselne jednoduchý — podmienky sú porovnania polí, akcie sú priradenia hodnôt — pretože jednoduché pravidlá sú tie, ktoré o pol roka neskôr ticho neprestanú dávať zmysel, keď si už nikto nepamätá, prečo vznikli.
Čo pravidlá robia naozaj dobre
Engine sa vypláca pri automatizácii vyplňovania polí. Pár vzorov vidíme takmer v každej inštalácii:
- Smerovanie podľa kategórie a entity. Každý tiket kategórie X z entity Y ide na skupinu Z. Už len tento jeden vzor, dobre nastavený, odstráni z väčšiny service deskov dennú triage poradu.
- Priradenie SLA. Podmienené SLA podľa typu tiketu, priority alebo zadávateľa. Pridelí sa pri vytvorení, zapíše raz, žiadny manuálny krok.
- Prepísanie urgentnosti. „Ak je zadávateľ v skupine VIP, urgentnosť je vždy High“ — presadené konzistentne, bez toho aby si to niekto musel pamätať.
- Predvolené hodnoty podľa šablóny. Predvyplnenie lokality, typu zadávateľa alebo zodpovednej skupiny podľa kategórie. Čistejšie tikety, menej dopytovania sa dozadu.
- Auto-close pri neaktivite. „Ak je stav Vyriešený a sedem dní sa nič nestalo, zatvor.“ Jedno pravidlo, merateľný pokles zabudnutých tiketov v reportoch.
Nič z toho nie je efektné. Je to práca, ktorá z každého tiketu odstraňuje opakujúci sa zásah. Dvadsať dobre vyladených pravidiel dokáže pre service desk viac než celý šprint vývoja pluginu.
Na čo pravidlá nie sú
Veci, ktoré vyzerajú ako automatizácia, ale nie sú:
- Viackrokové schvaľovania s časovým oneskorením. „Posuň manažérovi, počkaj 24 hodín, eskaluj pri nereagovaní“ — business rules nevedia vyjadriť oneskorenie. Na to je workflow engine.
- Vetvenie podľa predošlých rozhodnutí. Pravidlo vie reagovať na nový stav, ale koordinovať viackrokovú rozhodovaciu reťaz nie je jeho úloha.
- Akcie naprieč objektami. „Keď sa tiket zatvorí, označ súvisiacu zmenu ako hotovú.“ Pravidlá nezasahujú medzi typmi objektov.
- Externé volania. Volanie Jira API, správa do Slacku, zápis do externej databázy — mimo rozsah rule enginu. Od toho sú webhooky a REST API.
Tlačiť business rules do ktoréhokoľvek z týchto prípadov produkuje krehké konfigurácie, ktoré skoro fungujú, a to je horšie než žiadna automatizácia.
Kde začať
Skôr než napíšete prvé pravidlo, vytiahnite tikety z najfrekventovanejšej kategórie za posledných 90 dní a pozrite sa, ako boli reálne triažované. Vzory, ktoré uvidíte — „všetko z tejto entity vždy ide na túto skupinu“, „všetko s týmto kľúčovým slovom vždy potrebuje toto SLA“ — sú prvé pravidlá, ktoré stojí za to napísať. Začnite s piatimi, sledujte týždeň, opravte zlé klasifikácie, potom pridávajte ďalšie. Typická chyba je rule engine s osemdesiatimi pravidlami, ktoré si navzájom odporujú, pretože sa niekto pokúsil modelovať každý okrajový prípad hneď v prvý deň. Menej pravidiel, lepšie vyladených, má vždy väčšiu hodnotu než vysoký zoznam starých.
Kedy siahnuť po Cascade
Ak to, čo skutočne potrebujete, je viackrokový workflow s oneskoreniami, vetvami alebo schvaľovacími reťazcami, business rules vás tam nedostanú. Náš plugin Cascade existuje presne pre túto vrstvu — vizuálne workflowy, podmienené vetvy, časové spúšťače a akcie naprieč objektami. Rule engine pod ním naďalej robí to, v čom je dobrý — „nastav pole pri vytvorení“ — a Cascade rieši to, na čo pravidlá nikdy neboli navrhnuté.