Weźmy taki przykład:
Jest firma, jest zespół i jest projekt, który ten zespół prowadzi. Przy tej okazji zespół nabywa doświadczenie i wiedzę, bo ta rodzi się z doświadczenia:
próba i sukces lub próba i porażka = nowa wiedza.
I są też w organizacji inne zespoły, inne projekty.
Z punktu widzenia firmy byłoby dobrze, żeby zespoły dzieliły się wiedzą, którą nabywają. No ale nie zawsze (prawie nigdy) to się udaje – patrz Przypadek Kierownika Projektu.
Albo inny przykład:
Jest w firmie Ekspert, ktoś kto dysponuje dużą wiedzą w swoim obszarze. Ekspert chętnie się dzieli, tym co wie. Nie jest jednak w stanie odpowiadać wszystkim, bo ma mnóstwo swoich obowiązków. Nawet stworzył jakieś dokumenty, ale trochę chaotyczne to jest, niekompletne. Fakt, nie miał czasu. I dalej przychodzą pytać. Strach pomyśleć, co by było, gdyby Ekspert odszedł (zobacz Bolesne rozstania).
Co łączy te dwa przykłady?
To, że wiedza organizacyjna zamyka się w małych silosach – w głowach członków zespołu projektowego, w głowie Eksperta albo w stworzonych przez niego dokumentach, których nikt nie czyta.
A wiedza powinna być tam, gdzie jest potrzebna w danej chwili. Trzeba ją dostarczać na żądanie.
Łatwo powiedzieć – przenieść wiedzę.
Ale jak, jak to zrobić?
Dobre pytanie. Ale najpierw: Gdzie jest wiedza organizacji?
I teraz, kiedy już wiemy, gdzie jest wiedza, to następnym problemem jest określić jak ona wędruje w organizacji, jakimi ścieżkami: Transfer wiedzy w organizacji.
Czasem wędruje bezpośrednio od człowieka do człowieka.
Czasem nie bezpośrednio, ale przez system pośrednictwa.
Choć zawsze od człowieka do człowieka.
Wiedza rodzi się w głowie człowieka i potrzebuje jej też człowiek, żeby podjąć decyzję.
W sumie, jak widać na rysunku, są 4 ścieżki, a każda z nich reprezentuje zadanie do wykonania.
I są to następujące zadania:
- komunikacja – bezpośrednia wymiana wiedzy pomiędzy Dostawcą (to nasz Ekspert albo pierwszy zespół projektowy) a Odbiorcą wiedzy, tym, który ma zadanie i nie bardzo wie, jak sobie poradzić. Komunikacja to na przykład zwykła rozmowa. Albo spotkanie. Albo seminarium. Face-to-face. Albo online. Albo przez telefon.
- przechwytywanie – to proces przejęcia wiedzy od Dostawców (np. nasz Ekspert, zespół projektowy). Ktoś coś robił, ma w tym doświadczenie. Ma wiedzę. Trzeba ją wydobyć. To wiedza, jeszcze nie uporządkowana, ale już oddzielona od właściciela.
- synteza – tę nieuporządkowaną wiedzę trzeba zamienić na uporządkowane, zakodowane zasoby. Gdzieś te zasoby złożyć. Może na dysku? Może w procedurze? Może w dokumencie? Te zasoby muszą być łatwe do przyswojenia, użyteczne, wiarygodne, aktualne, łatwe do znalezienia. No w każdym razie powinny być. Nasz Ekspert próbował, ale mu nie bardzo wyszło.
- upowszechnianie – pytanie z gatunku retorycznych: Czym się różni wiedza, której nie ma, od wiedzy która jest, a o której inni nie wiedzą. Słusznie. Niczym. Wiedzę trzeba upowszechnić. Upowszechnianie to proces czy też procesy, które zapewniają, że ludzie w organizacji będą wiedzieli, że takie zasoby są i jak je wyszukać.
A zadanie, jak to zadanie. Żeby zostało poprawnie wykonane to musi być ktoś odpowiedzialny za nie (samo się nie zrobi), musi być wiadomo jak je wykonać, żeby zostało zaliczone, może powinna być jakaś technologia. No i ludzie muszą wiedzieć, że to zadanie naprawdę trzeba wykonać. Dzisiaj każdy ma więcej pracy niż czasu na wykonanie. Jak nie musi, nie zrobi.
I w tym sensie Zarządzanie Wiedzą niczym nie różni się od innych zadań w organizacji. Żeby wiedza faktycznie została przeniesiona, to:
- muszą być wskazani ludzie, odpowiedzialni za konkretne zadania;
- muszą być procedury (procesy), które narzucą, jak postępować z wiedzą;
- musi być technologia, która to umożliwi,
- no i ludzie muszą wiedzieć, że działają zgodnie z oczekiwaniami kierownictwa. Jakiś system nagród. Albo i kar. Mierniki. A też i potrzebne będą zapewne środki na wdrożenie nowych rozwiązań. Bez akceptacji i życzliwego poparcia Kierownictwa ciężko będzie. Musi być zgodność interesów. To Zaangażowanie kadry zarządzającej – Governance.
Reasumując – są 4 zadania (komunikacja, przechwytywanie, synteza, upowszechnianie). Do każdego z tych zadań musi być:
- Przypisany człowiek, odpowiedzialny za to zadanie (Role);
- Przypisany proces, który określa jak postąpić (Procesy);
- Wskazana technologia wspierająca (Technologia);
Razem 4×3 elementów. No i Governance.
To wszystko razem tworzy Strukturę Zarządzania Wiedzą (Framework).
Cała Struktura musi być kompletna. Jeśli nie jest kompletna, jeśli w tej macierzy są luki, to część wiedzy będzie wyciekać, a organizacja będzie ponosić tego koszty (przeczytaj Jak zmniejszyć koszt zadań powtarzalnych?)
- Jeśli nie są zaprojektowane Role – to nikt nie poczuwa się do odpowiedzialności;
- Jeśli nie są zaprojektowane Procesy – to ludzie nie wiedzą, co i jak mają robić;
- Jeśli brak jest Technologii – to nie ma potrzebnych narzędzi;
- Jeśli nie są określone oczekiwania kierownictwa – nikt nie będzie zajmował się wiedzą, traktując jak nadmiarowe i nikomu niepotrzebne zadanie.
A konkretnie to na przykład:
Role:
Kto odpowiada za to, żeby ludzie się komunikowali ze sobą (spotkania, seminaria, meetingi…);
kto odpowiada za to, że kiedy pojawia się nowa wiedza w firmie, na przykład w projekcie, to jest przechwytywana, potem zamieniana na zasoby;
kto odpowiada za to, że informacja o nowej wiedzy jest rozpowszechniania? nie wystarczy, żeby wiedza była – jeszcze ludzie muszą wiedzieć, że jest i gdzie jest.
Kto odpowiada za wiedzę, która powstaje w projektach, tak, żeby mogła być powtórnie wykorzystana przez innych firmie?
Kto odpowiada za wiedzę o kliencie i kontaktach z nim?
Kto odpowiada za to, żeby przed rozpoczęciem zadania obowiązkowo był przeprowadzony bilans potrzebnej wiedzy?
Procesy:
Czy wiadomo jak przechwytywać wiedzę, jakie procesy zastosować, jak wprowadzać wiedzę do nowego projektu?
Jak poszukiwać potrzebnej wiedzy?
Co robić, kiedy w projekcie pojawia się nowe doświadczenie, nowa wiedza.
Technologia:
Jakie narzędzia są do dyspozycji, z jakiej technologii można skorzystać, czy wiadomo jak się nią posługiwać.
Governance:
Czy ludzie wiedzą, jakie są oczekiwania Kierownictwa?
Czy jest ustalony system mierników, wsparcia Kierownictwa dla projektów Zarządzania Wiedzą?
Czy oczekiwania Kierownictwa sprzyjają kulturze dzielenia się wiedzą, czy są z nią w sprzeczności, bo na przykład organizacja popiera wewnętrzna konkurencję (jak na przykład Pracownik roku).
Jednym z najczęstszych błędów, są niekompletne ramy.
Typowy przykład – w firmie zakupuje się technologię, która wspiera Zarządzanie Wiedzą – np. Wiki, SharePoint, bazę danych i oczekuje się, że ludzie automatycznie będą wymieniać się wiedzą. Nie będą. Dlaczego mieliby to robić?
Albo wprowadza się procesy, pod postacią procedur. Nikt jednak nie jest odpowiedzialny za to, żeby proces rzeczywiście wszedł do działań operacyjnych. I procedura sobie, ludzie sobie.
Czy trzeba określić Framework, żeby zarządzać wiedzą organizacji? Ależ nie, ale to nie zmienia faktu, że:
- Ktoś musi odpowiadać za realizację zadań
- Musi być technologia, która umożliwia działanie
- Muszą być określone procesy, które mówią jak zrobić
- I musi być wsparcie kierownictwa, żeby to w ogóle się udało
Zbudowanie Systemu Zarządzania Wiedzą (Framework) po prostu pomaga.
Każda organizacja zarządza swoją wiedzą, inaczej nie mogłaby funkcjonować, ale na ogół system zarządzania jest dziurawy i część wiedzy ucieka. Często pierwszym krokiem przed wdrożeniem Zarządzania Wiedzą jest ocena bieżącego stanu Zarządzania Wiedzą w organizacji (Assessment – ocena bieżącego stanu Zarządzania Wiedzą ).
Co działa, co nie działa, gdzie są luki, gdzie system jest nieszczelny.
