Väčšina GLPI projektov, ku ktorým nás volajú ako k záchranke, zdieľa tie isté štyri chyby, a nemyslíme si, že je to náhoda — sú to tie zjavné chyby, ktoré by ste urobili, keby ste nikdy predtým implementáciu nerobili. Zaujímavé je, že žiadna z nich nie je technická. GLPI samotné je málokedy problém. Problém je zvyčajne to, čo niekto skúsil nakonfigurovať nad ním v prvom týždni.
Chyba 1: osemdesiat kategórií v prvý deň
Niekto v plánovaní postaví upratanú kategóriovú stromovú štruktúru: Hardvér > Desktopy > Dell > Monitor > Jas. Dvanásť takýchto reťazcov. Výsledok je portál, kde používatelia skutočne nevedia nájsť, kam majú zadať tiket, tak to prestanú skúšať a radšej píšu e-maily. Kategórie by mali byť postavené z reálnej prevádzky, nie z taxonómie, ktorú niekto nakreslil na tabuľu. Začnite s ôsmimi až dvanástimi kategóriami prvej úrovne, pozorujte, čo používatelia reálne zadávajú, a podkategórie pridávajte len vtedy, keď máte opakované dôkazy, že sú potrebné. Plytký strom s vyššou mierou reklasifikácie je zdravší než hlboký strom, v ktorom sa nikto nevyzná.
Chyba 2: business rules skôr než prevádzka
Rule engine je lákavý. Je to miesto v UI, kde „žije automatizácia“, takže ľudia konfigurujú pravidlá ešte predtým, než videli jediný reálny tiket. O dva mesiace neskôr je tam štyridsať pravidiel, polovica z nich si navzájom odporuje, a nikto si nepamätá, prečo bolo tretie pridané. Pravidlá by mali vychádzať z pozorovaných vzorov — „každý tiket tejto kategórie z tejto entity sa vždy smeruje rovnako“ — nie z odhadov. Začnite s nulou pravidiel a pridávajte ich po jednom, pričom každé ospravedlnite vzorom, ktorý vidíte v dátach. Prázdny rule engine po štyroch týždňoch je znak disciplíny, nie zanedbania.
Chyba 3: žiadne krytie od vedenia pre pravidlo „jednej fronty“
Tiketovací systém funguje len vtedy, keď ho ľudia skutočne používajú. Najťažšia jediná vec v každom rollouti je presvedčiť finančného riaditeľa alebo riaditeľa závodu — toho človeka, ktorý vždy písal IT leadrovi priamo — aby zadal tiket ako všetci ostatní. Bez exekutívy, ktorá verejne povie „odteraz, ak to nie je tiket, tak sa to nestalo“, systém ticho koexistuje s pôvodnými e-mailovými vláknami a dáta sú navždy neúplné. Videli sme technicky vynikajúce implementácie zlyhať práve na tomto jedinom bode. Nie je to technický problém a nemá technické riešenie.
Chyba 4: rollout pre celú firmu naraz
Big-bang rollouty produkujú big-bang zlyhania. Keď desať oddelení nabehne súčasne, pre žiadne z nich nie je nič nastavené konkrétne, školenia nedokážu držať tempo a bug reporty z prvého týždňa zavalia admin tím. Každá implementácia, ktorá podľa našej skúsenosti fungovala, začala úzko: jedno alebo dve oddelenia, šesť až osem týždňov reálnej prevádzky, opravte čo je zlé, potom pridajte ďalší tím. Nudná cesta je zároveň tá, ktorá reálne doletí do cieľa.
Ako by mal prvý rok skutočne vyzerať
Ak v prvom roku neurobíte nič efektné a len správne uchopíte tieto štyri veci, budete pred 80 % inštalácií, ktoré auditujeme: malý kategóriový strom, ktorý zodpovedá reálnej prevádzke, tri až päť šablón pre kategórie s najvyšším objemom, jedna SLA politika, ktorej všetci rozumejú, a vedenie, ktoré portál viditeľne používa samo. Pokročilé funkcie — Cascade workflowy, komplexný reporting, integrácie medzi systémami, AI klasifikácia — môžu počkať. Sú to hodnotné prídavky nad fungujúci základ a drahé žrúty času nad rozbitým.
Kedy si privolať pomoc
Ak je vaša inštalácia už v niektorej zo štyroch vyššie popísaných chýb a nie ste si istí, ako to rozmotať, vtedy je pár očí zvonka zvyčajne lacnejších než pokračovať v internom iterovaní. Na toto robíme GLPI audity — polovica dňa hodnotenia, krátka písomná správa a konkrétne odporúčania, čo prestať robiť, čo zjednodušiť, a čo si nechať. Väčšina záchrannej práce je odstránenie, nie pridávanie.