Ten sam problem rozwiązywany po raz dziesiąty oznacza, że dziewięć razy nie zapisano rozwiązania. Baza wiedzy jest tanim sposobem, żeby to przerwać.
Co warto zapisywać
- rozwiązania problemów powtarzalnych,
- procedury konfiguracji stanowisk i usług,
- opis środowiska: co gdzie stoi i z czym się łączy,
- ustalenia z dostawcami i numery umów wsparcia,
- przebieg poważniejszych awarii wraz z przyczyną.
Nie wszystko musi trafić w jedno miejsce. Opis środowiska ma inny odbiorcę i inny rytm zmian niż instrukcja resetu hasła, więc naturalnie należy raczej do dokumentacji środowiska IT. Baza wiedzy jest zbiorem odpowiedzi na pytania, które już padły.
Zapisywać przy rozwiązywaniu
Notatka powstająca w trakcie pracy jest kompletna i konkretna. Odtwarzana po tygodniu — ogólnikowa. Najprościej wymagać krótkiego opisu rozwiązania przy zamykaniu zgłoszenia.
Wystarczą trzy zdania: objaw, przyczyna, co zrobiono. Wpis nie musi być ładny, musi być prawdziwy i znaleziony. Wymóg dłuższego opisu daje odwrotny skutek — zgłoszenia zamyka się wtedy bez notatki albo z notatką pustą.
Które wpisy powstają same
Warto obserwować, co powtarza się w zgłoszeniach. Zestawienie kategorii z klasyfikacji zgłoszeń helpdesku pokazuje, na co idzie najwięcej czasu, i wyznacza kolejność pisania wpisów. Baza budowana od tematów, które ktoś uznał za ważne, zwykle nie pokrywa się z tym, o co ludzie faktycznie pytają.
Część dla użytkowników
Instrukcje do spraw, które użytkownik może wykonać sam, warto udostępnić poza działem IT. To zmniejsza liczbę zgłoszeń szybciej niż jakiekolwiek usprawnienie obsługi.
Podział na część wewnętrzną i publiczną jest konieczny. Instrukcja dla użytkownika nie może zawierać nazw serwerów, adresów wewnętrznych ani kroków wymagających uprawnień administratora. Najprościej pisać ją od razu w drugą stronę: od tego, co widzi osoba przy komputerze, a nie od tego, co dzieje się w systemie.
Aktualność
Instrukcja odsyłająca do nieistniejącego ekranu jest gorsza od jej braku. Data ostatniej weryfikacji przy każdym wpisie pozwala odróżnić wiedzę aktualną od archiwalnej.
Pomaga też przypisanie właściciela do wpisu i automatyczne przypomnienie po ustalonym czasie od ostatniego sprawdzenia. Wpisy dotyczące usług chmurowych starzeją się najszybciej, bo dostawcy zmieniają wygląd paneli bez zapowiedzi. Zrzuty ekranu bywają tu przeszkodą — łatwiej utrzymać opis słowny.
Wyszukiwanie
Baza, w której nie da się znaleźć odpowiedzi, nie istnieje. Warto opisywać wpisy językiem, jakim mówią użytkownicy, a nie nazwami technicznymi.
Tytuł wpisu powinien brzmieć jak zgłoszenie: „nie mogę zalogować się do poczty na telefonie”, a nie „konfiguracja profilu pocztowego”. Do tego kilka słów alternatywnych w treści — potocznych nazw, literówek, określeń używanych w firmie. Wyszukiwarka szuka po słowach, których użył pytający, nie po tych, które są poprawne.
Czego do bazy nie wkładać
Haseł, kluczy i danych dostępowych. Baza wiedzy jest z założenia szeroko dostępna i przeszukiwalna, więc jest najgorszym możliwym miejscem na takie informacje. Wpis może wskazywać, gdzie dane dostępowe się znajdują, ale nie może ich zawierać.
Kiedy nie warto budować osobnego narzędzia
Przy jednoosobowej obsłudze IT osobny system bazy wiedzy bywa nadmiarem. Katalog plików tekstowych z sensownymi nazwami albo notatki w systemie zgłoszeń wystarczą, dopóki korzysta z nich jedna osoba. Osobne narzędzie zaczyna się bronić, gdy wiedza ma być przekazywana dalej albo udostępniana użytkownikom.
