Wiedza rozproszona w firmie? Jak zbudować system wiedzy, który realnie działa

Jeżeli nowa osoba u Was musi kogoś zapytać, zanim cokolwiek zrobi, macie problem z rozproszoną wiedzą. To nie jest wyjątek, tylko najczęstszy stan małych firm: zespół pracuje, projekty się kończą, klienci są obsłużeni, ale wiedza o tym, jak to się dzieje, siedzi w głowach kilku osób, w starych mailach i w plikach nazwanych ostateczna_wersja_v3_NAPRAWDE_final.

Jak rozpoznać problem rozproszonej wiedzy

Rozproszona wiedza rzadko wygląda dramatycznie. Zwykle objawia się małymi, powtarzającymi się frustracjami:

Żaden z tych objawów osobno nie wygląda groźnie. Razem znaczą tyle, że firma płaci stały podatek czasowy za brak systemu.

Skąd się to bierze

W małych zespołach wiedza najczęściej powstaje organicznie: ktoś rozwiązuje problem, zapamiętuje rozwiązanie, czasem wysyła maila do zespołu. Nikt nie planuje tego od początku jako systemu, bo na starcie liczy się działanie, nie dokumentowanie. Problem rośnie razem z zespołem: to, co przy trzech osobach trzymało się na pamięci i bliskości biurek, przy piętnastu przestaje wystarczać.

Znam to z własnej pracy w PROMC, małej firmie prowadzącej zajęcia dla dzieci: kilkuosobowy zespół instruktorów i administracji, bez działu IT i bez nikogo, kto zajmowałby się systemami na pełny etat. Materiały, procedury i najważniejsze ustalenia leżały w mailach, na dyskach i w głowach najbardziej doświadczonych osób. Bardzo typowy punkt wyjścia.

Jak podejść do budowy systemu wiedzy

1. Najpierw sprawdź, gdzie ta wiedza jest. Najczęstszy błąd to zacząć od wyboru narzędzia (kupimy Notion i będzie dobrze) zamiast od ustalenia, gdzie wiedza naprawdę siedzi i gdzie ginie. Zanim zaprojektujesz strukturę, odpowiedz sobie: kto wie najwięcej o danym procesie? Gdzie to jest dziś zapisane, jeżeli w ogóle? Co się dzieje, kiedy tej osoby nie ma? Ile razy w miesiącu wraca to samo pytanie?

2. Układaj pod ludzi, nie pod estetykę. Struktura ma odpowiadać na pytanie czego ktoś tu szuka, a nie jak to ładnie wygląda z perspektywy autora. W praktyce znaczy to kategorie po zadaniach, nie po schemacie organizacyjnym firmy.

3. Przepisuj, nie kopiuj. To, co dotąd istniało wyłącznie w czyjejś pamięci, trzeba spisać od nowa. Nie przekleić maila do nowego narzędzia, tylko napisać tak, żeby ktoś bez kontekstu zrozumiał i wykonał to sam.

4. Zbuduj to tak, żeby przetrwało bez Ciebie. Baza wiedzy, która działa tylko wtedy, gdy jest przy niej jedna konkretna osoba, nie jest systemem. Jest kolejnym punktem ryzyka.

Co to daje

U nas skończyło się to krótszym wdrażaniem nowych osób i mniejszą liczbą pytań do tych najbardziej doświadczonych. Na slajdzie dla zarządu nie wygląda to spektakularnie, ale widać to codziennie: mniej przerywanych rozmów, szybsze wdrożenie, mniej błędów z niewiedzy.

Baza wiedzy nie jest projektem na raz. To coś, o co trzeba dbać, ale raz porządnie zrobiona zabiera dużo mniej uwagi niż bałagan, który zastępuje.


Ten tekst opisuje jeden z wątków pracy, którą wykonałem w PROMC. Całość opisuję w case study. Jeżeli macie u siebie podobny problem, robię takie rzeczy jako bazę wiedzy Start.

Zobacz też