Argument pre použitie GLPI aj mimo IT znie jednoducho: HR má požiadavky, facility má požiadavky, finance má schvaľovania — sú to všetko tikety, takže ich dajme do jedného systému. O čom sa však nehovorí, je to, ako GLPI vlastne izoluje tieto tímy jeden od druhého, pretože bez izolácie vám nevznikne medzioddelenský service desk, ale zdieľaný inbox s kategóriami. Tá izolačná vrstva sa volá entity a jej správne nastavenie je väčšina celej práce.
Čo entita naozaj je
V GLPI je entita hranica rozsahu. Kategórie, SLA, priraďovacie skupiny, šablóny notifikácií, články KB a viditeľnosť tiketov — to všetko žije vo vnútri jednej entity. Používateľ v entite IT nevidí tikety z entity HR, pokiaľ mu explicitne nepridelíte profil aj v HR. Reporty a vyhľadávania sa scope-ujú na entitu, v ktorej sa práve pozeráte. Nie je to tagovanie ani filtrovanie — je to tvrdá stena, ktorú vynucuje permissions systém. Keď tento princíp raz pochopíte, otázka „GLPI pre všetko“ prestáva byť „dokáže to?“ a stane sa „kam umiestniť steny?“
Čo získate, keď to nastavíte dobre
Dobre nastavená zdieľaná inštalácia prináša tri veci, ktoré by žiadne oddelenie nedostalo samo:
- Jedno prihlásenie, jedna URL, jedna ikonka v prehliadači. Používatelia sa neučia tri nástroje na zadanie troch typov požiadaviek; portál im ukazuje formuláre, ktoré patria do ich entity, a nič iné.
- Jeden admin tím namiesto troch. Zálohy, upgrady, SSO, mail catcher, inventár pluginov — spravované raz. Cena prevádzky tiketovacieho systému na oddelenie klesne výrazne.
- Cross-entity reporting pre vedenie. Finančný riaditeľ alebo COO dostane jediný pohľad naprieč IT, HR a facility bez toho, aby ťahal tri excely. Rekurzívne nastavenia GLPI riadia presne to, ktoré role môžu vidieť naprieč a ktoré nie.
Rozhodnutia, ktoré si treba vyjasniť dopredu
Multi-entity návrhy zlyhávajú vtedy, keď sa kreslia na tabuľu popoludní. Otázky, ktoré stojí za to brať vážne hneď na začiatku: sú vaše entity funkčné (IT / HR / Facility) alebo geografické (Bratislava / Košice / Viedeň), a ak oboje, ktoré je rodič? Ktoré kategórie majú žiť na roote (viditeľné všade) a ktoré vnútri jednej entity (napríklad len HR)? Kto potrebuje medzientitnú viditeľnosť na reportovanie a kto na skutočné riešenie tiketov? A — ten najčastejšie preskakovaný — kto vlastní konfiguráciu na úrovni rootu, keď chce mať každé oddelenie miesto pri stole?
Kde sa to kazí
Dve najčastejšie cesty k zlyhaniu. Prvá, „jedna entita na všetko, odfiltrujeme neskôr.“ Toto vždy skončí únikom oprávnení a HR riaditeľkou, ktorá vidí IT tikety o svojom vlastnom notebooku. Dodatočné nasadzovanie hraníc entít po šiestich mesiacoch dát znamená premapovať každý tiket. Druhá, hlboké stromy entít postavené ešte predtým, než má niekto reálnu prevádzku. Päť úrovní zanorenia vyzeralo v návrhovom dokumente ako rozumné budúcnostné zabezpečenie; v praxi používatelia nevedia nájsť svoje formuláre, reporty dvojito počítajú a nikto si nepamätá, na ktorej úrovni vlastne SLA platí. Začnite plytko.
Kde začať
Vyberte dve oddelenia — zvyčajne IT a jedno ďalšie, podľa toho, ktoré je zo súčasného stavu najviac sklamané. Vytvorte ich ako súrodencov pod rootom. Vylaďte pre oboje kategórie, skupiny a SLA. Nechajte systém bežať šesť až osem týždňov s reálnou prevádzkou, než pridáte tretie. Keď sa dostanete na dvojnásobok, budete vedieť, či vaše rozhodnutia o hraniciach držia alebo potrebujú zmenu, a náklady na ich opravu budú ešte stále malé.