Zarządzanie wiedzą w organizacji

Do napisania tego artykuły skłonił mnie post kolegi z pracy, Piotra Rawskiego pt. „Firmowa baza wiedzy – jak ją efektywnie zbudować?„. Poniższy tekst nie jest polemiką z tym postem, a raczej spojrzeniem z innej perspektywy na ciekawy skądinąd temat.

Dlaczego zarządzanie wiedzą w organizacji łatwe nie jest

O tym, że dane, informacje i wiedza to podstawa działania wielu firm na całym świecie nie trzeba nikogo przekonywać. I o ile dane i informacje udaje się w wielu organizacjach odpowiednio przechowywać i nimi zarządzać, o tyle z wiedzą jest problem. Dlaczego?

Najczęstszym miejscem przechowywania wiedzy w firmach jest głowa (ang. head) pracownika, a dokładnie część zwana mózgiem (ang. brain). I jest to całkiem dobre miejsce do składowania i wydobywania wiedzy, ale nie pozbawione wad. Po pierwsze do wiedzy zgromadzonej w głowie, bezpośredni dostęp ma jedynie tej głowy posiadacz. Aby mógł z tej wiedzy skorzystać ktoś inny, potrzebny jest proces zwany komunikacją (ang. communication). A nie zawsze taka komunikacja przychodzi łatwo. Po drugie nasze mózgi mają fatalną przypadłość zwaną zapominaniem (ang. forgetfulness). Nawet jeśli jakaś wiedza znajdowała się kiedyś w głowie pracownika, to po jakimś czasie właściciel owej głowy może ze zdumieniem stwierdzić, że niestety nie może tej wiedzy odnaleźć. Po trzecie – i jest to potwierdzone wieloma przypadkami – w momencie kiedy pracownik odchodzi z firmy najczęściej zabiera swoją głowę ze sobą, razem z nagromadzoną tam wiedzą.

Podsumowując – wiedza musi być przechowana na innych, niż tylko głowy pracowników, nośnikach. Piotr w swoim artykule wskazał na kilka różnych narzędzi, które mogą wspomóc utrwalanie wiedzy w organizacji. Moim zdaniem trzeba jednak zacząć od czegoś zupełnie innego ….

Kultura dzielenia się wiedzą

Nawet jeśli w firmie mamy wdrożone fantastyczne narzędzie klasy ECM, dzięki któremu możemy zarządzać dokumentami, ich wersjami itd, to nie rozwiązuje ono dwóch podstawowych problemów.

Po pierwsze – część pracowników nie ma najmniejszej ochoty na dzielenie się z innymi tym co wiedzą. Często wynika to z przekonania, że unikalna wiedza którą posiadają w jakimś obszarze (np. znajomość tajników konfiguracji złożonego systemu informatycznego) czyni ich wyjątkowymi pracownikami (ang. self-awesomeness). Być może uważają, że podzielenie się tą wiedzą z innymi sprawi, że przestaną być tacy wyjątkowi i wspaniali, a dodatkowo posiadana przez nich unikalna wiedza może stać się skuteczną kartą przetargową np. przy negocjacjach podwyżki. Podejście takie jest oczywiście krótkowzroczne – przynosi szkody zarówno firmie jak i pracownikowi. Na miejscu pracodawcy zadbałbym o to, żeby jak najszybciej udokumentować wiedzę posiadaną przez takiego pracownika, a następnie awansować go poza struktury firmy (ang. you are fired).

Po drugie – dokumentowanie wiedzy zabiera dodatkowy czas i męczy – a ponieważ z natury jesteśmy leniwi, odkładamy te czynności na później, albo w ogóle tego nie robimy. Być może lekceważymy fakt, że dodatkowe nakłady pracy na udokumentowani swoich działań zwrócą się w przyszłości z nawiązką – skorzysta na tym cała organizacja, a pośrednio także i my. Rozważmy prosty przykład z obszaru IT – zarządzanie incydentami informatycznymi. Wyobraźmy sobie, że pracownik zgłasza do Service Desk problem z systemem informatycznym. Pracownicy SD ze względu na ograniczone kompetencje i czas nie mogą rozwiązać incydentu i przekazują go do kolejnej linii wsparcia IT. Tam zgłoszenie jest podejmowane i informatykowi po kilku godzinach analizy, przeszukiwania Internetu (ang. google it) udaje się problem rozwiązać. W polu ‚opis rozwiązania’ informatyk wpisuje ‚zrobione’ i zamyka zgłoszenie w systemie – wszyscy szczęśliwi. Ale co wtedy, gdy inny pracownik firmy zgłosi do SD podobny incydent? Cała zabawa zaczyna się od nowa. Szczęście, gdy zgłoszenie trafi do tego samego informatyka z kolejnej linii wsparcia i pamięta on, co zrobił poprzednim razem. Gdyby jednak za pierwszym razem po rozwiązaniu incydentu umieścić opis zrealizowanych kroków w bazie wiedzy, następnym razem być może incydent mógłby być rozwiązany podczas pierwszego kontaktu z SD (ang. first call resolution). Korzystają na tym wszyscy – pracownik zgłaszający incydent o wiele szybciej otrzymuje rozwiązanie, dzięki czemu może kontynuować pracę, zgłoszenie nie trafia niepotrzebnie do drugiej linii wsparcia itd. W przypadku dużych przedsiębiorstw, w których do SD spływa setki albo tysiące incydentów dziennie oszczędności mogą być liczone w bardzo konkretnych pieniądzach.

Oczywiście – do dzielenia się wiedzą można pracowników ‚zmuszać’. Np. przełożony może regularnie sprawdzać jakość opisów rozwiązanych incydentów/problemów w bazie wiedzy i ‚karać’ pracowników, którzy tego nie robią. O wiele lepszym podejściem będzie jednak budowanie w organizacji kultury wspierającej dzielenie się wiedzą. Jak to robić? Np. publikowane przez nas artykuły w bazie wiedzy mogą być oceniane i nagradzane wirtualnym kudosem (ang. kudos) przez kolegów/współpracowników. Raz w miesiącu/kwartale można też wybrać autora najpopularniejszych/najwartościowszych artykułów i nagrodzić go publicznie firmowym gadżetem itp. Dobrym pomysłem jest też organizowanie pół formalnych spotkań (ang. meet-up) na których chętne osoby podzielą się swoimi doświadczeniami w maksymalnie 15 min prezentacjach / przemówieniach (ang. lightning talk). W intive mamy dobre doświadczenia z tym związane 🙂 Ważne jest ustawiczne budowanie w pracownikach świadomości, że dzielenie się wiedzą wychodzi na dobre absolutnie wszystkim. Warto też dzielić się swoimi porażkami i błędami – zawsze lepiej uczyć się na błędach cudzych niż swoich (porażką jest gdy ktoś nie uczy się na swoich błędach).

Trzy fazy cyklu życia bazy wiedzy w organizacji

W niejednej organizacji firmowa baza wiedzy przechodzi trzy zasadnicze fazy:

  1. pustynia
  2. śmietnisko
  3. cmentarz

Żeby nie powielić tego schematu potrzebujemy w organizacji odpowiednie procesy i narzędzia. O narzędziach napisał Piotr na swoim blogu. Jeśli jesteście zainteresowani kwestią procesów – dajcie znać w komentarzach. Przy okazji kolejnego L4 (hiszp. eL-quatro) napiszę część dalszą …

Dodaj komentarz

avatar
  Subscribe  
Powiadom o