PH.
< Zpět na blog

Proč je dokumentace důležitější než si myslíte

Když zachráníte den, ale nenapíšete do Knowledge Base jak, jako by se to nestalo.

Detaily
4 min čtení
Tagy
dokumentace Knowledge Base ITIL

Proč je dokumentace důležitější než si myslíte

Známe to všichni. Máte kritický incident. Systém X nekomunikuje se systémem Y. Projdete padesát fór, vyzkoušíte dvanáct věcí a nakonec ten správný flag v registrech najdete. Fixnete to, systém naběhne, dostanete pochvalu. Hotovo, vyřešeno, zavřený tiket.

Chyba. Drtivá chyba. Pokud jste do pěti minut po vyřešení neotevřeli šablonu pro nový Knowledge Article, celá ta hodina utrpení byla v dlouhodobém měřítku zbytečná.

Zde je jednoduchý diagram toho, proč to tak je.

Rozdíl mezi zapsanou a nezapsanou znalostí

graph TD
    subgraph Bez Dokumentace
        A1[Problém nastane] --> B1[Kolega hledá řešení hodinu]
        B1 --> C1[Opraví to a nezapíše]
        C1 -. "Za 3 měsíce znovu" .-> A1
    end

    subgraph S Dokumentací
        A2[Problém nastane] --> B2[Kolega vyřeší za hodinu]
        B2 --> C2[Zapíše řešení do KB článku]
        C2 -. "Za 3 měsíce znovu" .-> D2[Jiný kolega najde KB = řešení za 3 minuty]
    end
    
    style Bez Dokumentace fill:#ffeeee,stroke:#f00,stroke-width:2px
    style S Dokumentací fill:#eeffee,stroke:#0f0,stroke-width:2px

Není to jen pro kolegy, je to pro vás

V IT se často stává, že si říkáme: “Tohle si budu pamatovat, to bylo docela unikátní.” Nebudete. Za dva týdny, po dalších stovkách tiketů, vytlačí nové informace ty staré.

Mám vlastní pravidlo zvané Zero-state memory rule. Dělám poznámky a píšu dokumentaci tak detailně, aby to pochopil i člověk (nebo já zítra ráno po špatné kávě), který o daném systému neví naprosto nic.

Jak má vypadat správný článek v bázi znalostí (Knowledge Base):

  1. Symptomy (Jak se to projevuje): Co přesně nahlásil uživatel? Jaký chybový kód systém vyhodil? (Aby to šlo vygooglit ve vaší ITSM aplikaci).
  2. Příčina: Co se reálně stalo na pozadí.
  3. Krok za krokem řešení: “Otevři X -> Zadej příkaz Y -> Restartuj službu Z”. Žádné “nějak jsem to vyřešil”.
  4. Ověření: Jak poznám, že je to opravené ještě předtím, než zavolám uživateli?

Dobře napsaná dokumentace na Service Desku je rozdíl mezi týmem, který se utápí v tiketech, a týmem, který jede plynule dál a má klid v duši.

[09 - Kontakt]

Kontakt

Otevřen spolupráci

Ať už řešíte záludný technologický oříšek, hledáte parťáka pro nový projekt, nebo si chcete jen vyměnit nápady, neváhejte mi napsat 👋

[01] Telefon
[03] Adresa
Ostrava, Česká Republika
Ověření
Dostupný pro spolupráci © 2026 Petr Hromádka. Všechna práva vyhrazena.
TERMINAL_OUTPUT //
// SYSTEM.STATUS: ONLINE /// DESIGNED IN OSTRAVA /// V.1.0.0 /// NO ERRORS FOUND // SYSTEM.STATUS: ONLINE /// DESIGNED IN OSTRAVA /// V.1.0.0 /// NO ERRORS FOUND /// SYSTEM.STATUS: ONLINE /// DESIGNED IN OSTRAVA /// V.1.0.0 /// NO ERRORS FOUND ///  // SYSTEM.STATUS: ONLINE /// DESIGNED IN OSTRAVA /// V.1.0.0 /// NO ERRORS FOUND // SYSTEM.STATUS: ONLINE /// DESIGNED IN OSTRAVA /// V.1.0.0 /// NO ERRORS FOUND /// SYSTEM.STATUS: ONLINE /// DESIGNED IN OSTRAVA /// V.1.0.0 /// NO ERRORS FOUND ///