Väčšina znalostných báz umrie. Niekto ju vytvorí s dobrým úmyslom, napíše 20 článkov a o pol roka je polovica neaktuálna, nikto v nej nič nenájde a agenti sa vracajú k otázkam kolegov na chate. Problém nikdy nie je nástroj -- je to proces okolo neho.
GLPI má vstavaný modul znalostnej bázy. Aby fungoval dlhodobo, treba menej písania a viac disciplíny.
Čo patrí do KB
Nie všetko. Znalostná báza je pre riešenia, ktoré agenti používajú opakovane -- nie pre jednorazové opravy alebo projektovú dokumentáciu. Dobrí kandidáti:
- Opakujúce sa riešenia incidentov -- "Outlook sa nepripojí po zmene hesla" s postupom krok za krokom
- Štandardné postupy -- "Ako onboardovať nového zamestnanca" checklist
- Známe chyby -- "SAP login zlyhá medzi 02:00-02:15 počas nočného batchu -- toto je očakávané, nie incident"
- Konfiguračné referencie -- VPN nastavenia, verzie ovládačov tlačiarní, zoznam schváleného softvéru
Zlí kandidáti: zápisnice z porád, projektové plány, zmluvy s dodávateľmi. Tie patria do systému na správu dokumentov, nie do helpdesk KB.
Písanie článkov, ktoré sa naozaj používajú
Štruktúra je dôležitejšia ako text
Agent s používateľom na telefóne nečíta odseky. Skenuje kroky. Každý KB článok by mal mať rovnakú štruktúru:
- Symptóm -- čo používateľ hlási ("nemôžem tlačiť")
- Príčina -- čo sa skutočne deje ("služba Print Spooler sa zastavila")
- Riešenie -- postup krok za krokom (číslovaný, konkrétny, so screenshotmi ak treba)
- Platí pre -- ktoré systémy, ktoré skupiny používateľov, ktoré lokality
Názov = symptóm, nie riešenie
Agenti hľadajú to, čo im povie používateľ: "Outlook sa neotvára," nie "Obnovenie profilu Outlook." Pomenúvajte články podľa symptómu, aby sa objavili vo výsledkoch hľadania, keď agent zadá to, čo počul od používateľa.
Jeden článok na jeden problém
Nekombinujte "problémy s tlačiarňou" do jedného mega-článku. Rozdeľte na: "Tlačiareň offline na Windows," "Inštalácia ovládača tlačiarne na Mac," "Chyba nesúladu zásobníka tlačiarne." Kratšie, nájditeľné, udržiavateľné.
Ako ju udržať živú
Najväčšie riziko je zastarávanie. Článok napísaný pre Windows 10 sa stane nesprávnym na Windows 11. Proces sa zmení, ale KB článok nie. Pomáhajú dva postupy:
- Dátum revízie na každom článku -- GLPI podporuje pole pre dátum expirácie/revízie. Nastavte ho na 6 mesiacov po vytvorení. Keď vyprší, článok sa objaví vo fronte na revíziu. Niekto potvrdí, že je stále presný, alebo ho aktualizuje.
- Prepojenie článkov s tiketmi -- keď agent použije KB článok na vyriešenie tiketu, môže ho prepojiť. Články, ktoré sa prepájajú často, sú jednoznačne hodnotné. Články, ktoré sa nikdy neprepoja, sú buď nenájditeľné, alebo irelevantné -- oboje stojí za preskúmanie.
Riadenie viditeľnosti
KB v GLPI podporuje rôzne úrovne viditeľnosti:
- Verejné -- viditeľné pre koncových používateľov v samoobslužnom portáli (FAQ štýl)
- Len pre technikov -- viditeľné len pre agentov (interné postupy, workaroundy)
- Podľa entít -- viditeľné len v rámci konkrétnych entít (relevantné pre multi-entity nasadenia)
Začnite s režimom len pre technikov. Publikujte koncovým používateľom len tie články, ktoré im naozaj pomôžu vyriešiť problém sami -- nie interné troubleshooting postupy, ktoré by ich zmiatli.