Baza Wiedzy > Procesy Zarządzania Wiedzą

Procesy Zarządzania Wiedzą wymienione poniżej są oparte o dialog. Dialog to pytania i odpowiedzi, których zadaniem jest wydobyć wiedzę z ludzi i zespołów, aby przekazać ją innym. Trudno byłoby sobie wyobrazić skuteczną wymianę wiedzy bez jakiejś formy dialogu. Ludzie od zawsze wymieniali się wiedzą w taki sposób. Zarządzanie Wiedzą idzie krok dalej i formalizuje te działania, aby zwiększyć ich efektywność i skuteczność.

 

Spis treści:

 

Jaki proces Zarządzania Wiedzą zastosować?

Procesy Zarządzania Wiedzą

Procesy Zarządzania Wiedzą

Zadaniem Zarządzania Wiedzą jest dostarczenie odpowiedniej wiedzy odpowiednim ludziom, w odpowiednim czasie, tak, aby mogli lepiej wykonać swoją pracę. Sposób transferu to Proces, czyli zdefiniowany sposób postępowania, wymagany w danej firmie
Jaki Proces będzie najlepszy w danej sytuacji zależy od rodzaju wiedzy (czy to wiedza Tacit czy Explicit), od tego, kto jest źródłem wiedzy i od tego, kto jest jej odbiorcą. Zarówno źródłem, jak i odbiorcą może być jeden zespół albo wiele zespołów. Jaki więc proces będzie najlepszy w danej sytuacji? A to zależy od kogo, do kogo i jaka wiedza.

Do góry

 

Peer Assist

Peer Assist

Peer Assist jest jednym z najprostszych, a jednocześnie najbardziej skutecznych z procesów Zarządzania Wiedzą. Jego wartość leży w tym, że wnosi wiedzę do projektu przed jego rozpoczęciem. Sensowne jest aby wnosić wiedzę do projektu, na tyle wcześnie, aby zrobiło to różnicę. Albo wtedy , kiedy w projekcie pojawi się nieoczekiwany problem. Proces ten pozwala:

  • Zredukować koszty
  • Skrócić czas planowania i realizacji
  • Zidentyfikować ryzyka i zarządzać nimi

Peer Assist to proces, w którym ludzie zwracają się do innych z prośbą o pomoc. To spotkanie, na które zespół projektowy zaprasza ludzi z doświadczeniem i wiedzą, której potrzebuje zespół. W szczególności proces ten pokazuje swoją wartość w sytuacji, kiedy wiedza , ważna dla zespołu projektowego jest zbyt złożona, zbyt kontekstowa, aby można ją było udokumentować w postaci procedur, dobrych praktyk czy wytycznych. W takich sytuacjach doświadczenie ludzi, którzy już wcześniej zmagali się z takim samym lub podobnym zadaniem jest bezcenne. Peer Assist można podsumować w kilku zdaniach:

  • Zespół, który przystępuje do realizacji projektu chce się nauczyć. Szuka wiedzy, która będzie przydatna w procesie realizacji, a którą trudno znaleźć w postaci skodyfikowanej.
  • Zespół zaprasza ludzi z doświadczeniem i wiedzą przydatną dla projektu. Goście to ludzie, którzy są na takim samym poziomie w hierarchii służbowej (Peer). Ludzie rozmawiają z równymi sobie o wiele swobodniej, niż wtedy, kiedy na spotkaniu jest obecny zwierzchnik.
  • Goście przychodzą, żeby pomóc.
  • Zespół omawia projekt, do którego przystępuje, bieżący status, plany, rozpoznane ryzyka, prosi o rady.
  • Rozpoczyna się dialog – Goście dzielą się swoim doświadczeniem, swoją wiedzą, przedstawiają swoje rekomendacje.

To skrócony scenariusz. Peer Assist jest dużo bardziej sformalizowanym procesem. Przede wszystkim wskazana jest obecność Facylitatora – osoby niezaangażowanej w projekt, obiektywnej, która będzie sterowała dialogiem. Muszą być też ściśle określone cele spotkania, a samo spotkanie odbywa się według ściśle określonych reguł.

Kiedy nie stosować Peer Assist? Wtedy, kiedy potrzebna wiedza jest rutynowa i może być przekazana w postaci pisemnej, nie wymagającej bezpośredniego kontaktu z człowiekiem. Jak również wtedy, kiedy zespół poszukuje wiedzy o niezbyt dużym znaczeniu. Trzeba pamiętać, że Goście poświęcają swój czas – więc jeśli można zdobyć wiedzę inaczej, to trzeba tak zrobić.

Do góry

 

After Action Review

After Action Review to bardzo skuteczny proces, który – jeśli prowadzony dobrze i rutynowo – przynosi organizacji ogromne korzyści. Można go opisać kilkoma krótkimi zdaniami:

  • Coś się wydarzyło. 
  • Zatrzymaj się.
  • Przeanalizuj.
  • Wyciągnij wnioski.
  • Wykonaj.

AAR to krótkie, trwające pół godziny lub mniej spotkanie zespołu po tym, jak coś poszło inaczej niż miało pójść. Poszło może lepiej, może gorzej – po prostu inaczej. Takie zdarzenie może zawierać w sobie lekcję, która jest ważna dla kolejnych działań – zespołu lub organizacji. Dlatego trzeba się zatrzymać i dojść do przyczyny.

Struktura spotkania AAR jest bardzo prosta. Składa się z 5 pytań, na które zespół wspólnie szuka odpowiedzi. Proces jest sformalizowany – uczestnicy spotkania przechodzą kolejno od pytania do pytania. Dyskusja zawsze dotyczy tylko jednego pytania jednocześnie. Pytania są następujące:

  1. Jakie były początkowe założenia?
    To pytanie o to, jakie były oczekiwania przed rozpoczęciem. Wbrew pozorom nie zawsze jest to oczywiste i jasne dla wszystkich. Spotkanie rozpoczyna się więc od przypomnienia szczegółów – jakie były cele, jaki plan czasowy, kto był zaangażowany, jakie były założone wskaźniki, jakie produkty miały powstać itd. Dyskusja pomaga ustalić rzeczywisty punkt odniesienia.
  2. Co się w rzeczywistości wydarzyło?
    Drugi krok to ustalenie tego, co naprawdę zaszło. Szukamy faktów, nie osobistych wrażeń. Fakty muszą być obiektywne – co zarejestrowałaby kamera, gdyby była na miejscu zdarzenia? Nie ma tez miejsca, na szukanie winnych i bohaterów. Spotkanie jest po to, aby zidentyfikować potencjał dla poprawy procesów organizacyjnych.
  3. Dlaczego była różnica?
    Krok trzeci – dlaczego? Coś było planowane, a wyszło inaczej. Trzeba dotrzeć do przyczyny tego, co się wydarzyło. Nie zawsze przyczyna, która jest widoczna na pierwszy rzut oka jest prawdziwa. Czasem trzeba kopać głęboko, żeby zidentyfikować powód, dlaczego coś poszło tak, a nie inaczej. Na tym etapie spotkania dobry facitilator jest bardzo użyteczny, bo – stojąc z boku – pomaga dotrzeć do dna.
  4. Czego się nauczyliśmy?
    Zespół przeprowadza analizę: „Co wiemy teraz, czego nie wiedzieliśmy przedtem?”, „Gdybyśmy mieli przed rozpoczęciem tę wiedzę, co obecnie, to co mogliśmy zrobić lepiej?”, „Co zamierzamy zmienić w podobnych sytuacjach w przyszłości?”. Na koniec zespół rekomenduje działania na przyszłość: „Jakie są nasze rady dla przyszłych projektów w oparciu o nasze obecne doświadczenie?”
  5. Co z tym zrobimy?
    Następnym i ostatnim już krokiem AAR jest wprowadzenie rekomendacji w życie. Działanie może być po stronie zespołu, albo na zewnątrz. Trudno nazwać ten krok kluczowym, bo wszystkie są równie ważne, ale fakt faktem – bez działania, nie będzie zmiany

Do góry

 

Retrospekcja

Retrospekcja

Retrospekcja

Retrospekcja jest spotkaniem, które odbywa się zaraz po zakończeniu projektu. To jeden z najbardziej skutecznych procesów przechwytywania wiedzy od zespołu projektowego po zakończeniu większego zadania.

Czas trwania zależy od wielkości zespołu projektowego, długości projektu i jego złożoności. Może to być 30 minut do godziny, dla krótkich, prostych projektów; a może to być kilka albo więcej godzin dla projektu, który trwa 6 miesięcy, a zespół projektowy liczy 10 osób. Retrospekcja realizowana w partnerstwie, wewnątrz- lub międzyfirmowym może zająć dwa dni. Generalna zasada mówi, że aby oszacować czas trwania procesu Retrospekcja należy pomnożyć ilość osób należących do zespołu projektowego przez 30 minut.

Przy pomocy Retrospekcji można wydobyć kluczową wiedzę i doświadczenie zdobyte przez zespół projektowy i przełożyć to na działanie, a także zasoby, które będą mogły być wykorzystane przez przyszłe projekty. Dzięki ułatwieniu dialogu (facylitacja) wewnątrz zespołu, wydobywana jest wiedza, której poszczególni ludzie są nieświadomi, ale którą zespół jako całość posiada.

Do góry

 

Knowledge Exchange

Knowledge Exchange

Knowledge Exchange

Knowledge Exchange jest spotkaniem, w trakcie którego ludzie z różnych zespołów (ale na ogół z tej samej   community of practice – sieci praktyków, jeśli takie istnieją) spotykają się, aby wymienić wiedzę na temat jednego z kluczowych zagadnień operacyjnych. To proces o pierwszorzędnym znaczeniu dla rozwoju bazy wiedzy.

Na spotkanie zaprasza się ludzi, którzy są zaangażowani w pracę w jakimś obszarze. W większości są to ludzie z doświadczeniem, którym mogą się podzielić, ale również ludzie, którzy dopiero startują w tym obszarze i chcieliby zdobyć potrzebną wiedzę.

Każdy uczestnik spotkania jest potencjalnym klientem wiedzy, a wiele osób będzie także dostawcami wiedzy. Uczestnicy (15 do 50 osób)  powinni pracować na równorzędnych stanowiskach (peer). Spotkanie ma formalną strukturę, z góry zaplanowaną.

Do góry

 

Knowledge Handover

Knowledge Handover

Knowledge Handover

Knowledge Handover jest spotkaniem organizowanym po zakończeniu projektu, podczas którego zespół projektowy udostępnia i poddaje pod dyskusję lekcje, które zostały zidentyfikowane w projekcie.

Odbiorcami wiedzy są inne zespoły projektowe, liderzy Communities, eksperci merytoryczni. Uczestnicy spotkania mają okazję szeroko przedyskutować przechwycone lekcje, zadać dodatkowe pytania, tak aby dokładnie przeanalizować zarówno lekcje jak i ich implikacje.

Knowledge Handover jest jedną z metod upewnienia się, że lekcje zostaną wdrożone do działalności operacyjnej.

Zalety Knowledge Handover są następujące:

  • Lekcje przechwycone w projekcie będą raczej prowadzić do akcji, a nie tylko będą „zapisane na dysku i zapomniane”.
  • Promuje się współpracę pomiędzy projektami.
  • Zwiększa szanse na to, aby lekcje zostały zaadoptowane w przyszłych projektach.

Do góry

 

Wywiady

Wywiady

Wywiady

Czasami wiedza musi być przechwycona od pojedynczego człowieka albo jako część Learning History albo dlatego, że ten człowiek przechodzi na emeryturę lub zmienia pracę. W takich przypadkach najlepszym podejściem jest wywiad (Knowledge Capture Interview). Proces przejmowania wiedzy obejmuje następujące elementy:

  • Identyfikacja wiedzy, jaka musi być przechwycona
  • Ustalenie priorytetów poszczególnych tematów
  • Pogłębiony wywiad, aby odkryć ukrytą wiedzę i przechwycić historie, które przywracają ją do życia.

Zapakowanie wiedzę do postaci zasobu, który będzie użyteczny dla innych.

Do góry

 

Lessons Learned

Proces Lessons Learned

Proces Lessons Learned

Jeśli coś w organizacji pójdzie inaczej niż zaplanowano – może lepiej, może gorzej, po prostu inaczej, to takie zdarzenie może być lekcją dla organizacji, lekcją, która w przyszłości pozwoli podjąć lepsze decyzje. Można też o takiej lekcji zapomnieć i powtarzać w kółko te same schematy.

Uczenie się organizacji

Ludzie uczą się w sposób całkiem naturalny na swoich doświadczeniach – czy to porażkach czy sukcesach. Jeśli coś powtarzają wielokrotnie, to za każdym razem robią to lepiej. Tak to pokazuje krzywa uczenia (learning curve).
Zespoły uczą się tak samo, jak jednostki – na swoich doświadczeniach. Ludzie, którzy po raz kolejny raz prowadzą podobny  projekt lepiej sobie z nim pewne poradzą, niż zespół, który pierwszy raz zmaga się z takim zadaniem. Każdy zespół się uczy w miarę swojej pracy.

A co by oznaczało, że nie tyle zespół, ale cała organizacja uczy się? To by oznaczało, że ludzie i zespoły uczą się nie tylko na swoich doświadczeniach, ale też na doświadczeniach innych. W efekcie oznaczałoby to, że w różnych miejscach organizacji nie powtarza się tych samych błędów, a dobre praktyki, wypracowane w jednym miejscu, rozpowszechnia się po wszystkich zespołach. To oznaczałoby, że organizacja stale się doskonali, a jej „krzywa uczenia” stale się poprawia.

W odróżnieniu od jednostki, ścieżki uczenia się muszą zostać w organizacji specjalnie zaszczepione, a konkretnie chodzi o to, że jeśli coś pójdzie inaczej niż oczekiwano (może lepiej, może gorzej, po prostu inaczej), to nad takim doświadczeniem należy się pochylić, zastanowić, wyciągnąć lekcje i zadbać o to, żeby błąd nie był w przyszłości powtarzany. To jest właśnie system system Lessons Learning.

Lekcja zidentyfikowana

Wiele organizacji tak robi w dosyć naturalny sposób, ale nałożenie na ten system kompletnych ram KM (Framework) przyspieszy proces uczenia organizacji i nie pozwoli gubić doświadczeń, zarówno dobrych , jak i złych. 
Zacznijmy od początku, czyli od momentu kiedy w trakcie realizacji projektu zostaje zidentyfikowane zdarzenie, które  może zawierać ważną lekcję dla przyszłych działań.

Zespół projektowy zbiera się i analizuje:

  1. Co się wydarzyło?
  2. Jakie były podstawowe przyczyny tego zdarzenia?
  3. Czego się nauczyliśmy?
  4. Co warto zmienić w przyszłości?

Ludzie stwierdzają: „Zrobiliśmy tak i tak, to nie był dobry pomysł, należało zrobić inaczej. Teraz już wiemy jak. Następnym razem trzeba uważać, żeby nie popełnić tego błędu.” 
Albo: „ Znaleźliśmy pułapkę. Następnym razem trzeba uważać, bo może to mieć takie i takie konsekwencje.”
Albo: „ Zrobiliśmy to w taki i taki sposób, wyszło świetnie. Następnym razem trzeba koniecznie powtórzyć ten schemat, bo jest korzystny dla firmy.”

Następnie zespół projektowy sporządza raport, a w nim: odkryliśmy nowy, lepszy sposób na zrobienie czegoś; albo – znaleźliśmy błędny sposób działania. Widzimy, że następnym razem może to być zrobione lepiej. Nasza rekomendacja na przyszłość jest następująca ….

To jest właśnie lekcja. Na razie to jest jedynie lekcja zidentyfikowana. Coś się zdarzyło, co dało nam do myślenia. Mamy jakieś wnioski na przyszłość, chcemy się tymi wnioskami podzielić z innymi.

Rekomendacja

Lekcja zidentyfikowana i lekcja nauczona to dwie zupełnie różne sprawy. Lekcja jest nauczona wtedy, kiedy w jej wyniku zajdzie w organizacji zmiana. Jeśli zmiana nie nastąpi, wówczas lekcja pozostaje jedynie Lekcją Zidentyfikowaną. Może i miło ją mieć, ale korzyści z niej nie ma żadnej.
Zidentyfikowana lekcja to rekomendacja działań, propozycja do wyboru dla pracownika. Pracownik może postąpić tak, jak ktoś rekomenduje, ale nie musi. To jego wybór.

Proces to obowiązujący w firmie wskazuje sposób wykonywania zadania. To już nie jest do wyboru. Pracownik realizuje wytyczne albo łamie zasady, z wszystkimi tego konsekwencjami. Proces może dotyczyć dowolnego obszaru funkcjonowania firmy. Może być zapisany w dowolnej formie – może to być procedura, instrukcja, opis zadania czy cokolwiek innego, co ma wpływ na sposób pracy.
Żeby nastąpiła zmiana musi zmienić się proces, który spowoduje trwałą zmianę zachowań pracowników i sposobu pracy, a w konsekwencji zapewne dokumenty opisujący ten proces.

Wiara w to, że zidentyfikowanie lekcji spowoduje, że pracownicy będą z własnej inicjatywy korzystać z rekomendacji, jest życzeniem z kategorii pobożnych. Mała szansa na to, że się ziści. Za rekomendacją musi iść działanie. Aby zaszła zmiana, musi zostać podjęta akcja. Jeśli w wyniku tej akcji zmieni się proces, to ta zmiana pociągnie za sobą zmianę zachowań – pracowników i całej organizacji. Wówczas lekcja, która została zidentyfikowana, stanie się Lekcją Nauczoną.

Akcja

Jeśli lekcja jest zidentyfikowana i są przypisane do niej rekomendacje, to przychodzi czas na działanie. Same rekomendacje to za mało. Akcja w dziewięciu przypadkach na 10 będzie dotyczyła napisania lub poprawienia procesu firmowego. Najczęściej będzie się to wiązało ze zmianą dokumentu opisującego proces. W jednym przypadku na 10 akcją będzie wykonanie jakiegoś działania – zakup nowego wyposażenia, rekonfiguracja tego wyposażenia, które już jest, zatrudnienie nowej osoby.

Ktoś musi być odpowiedzialny za weryfikację rekomendowanej zmiany i przeprowadzenie akcji. Warunkiem koniecznym jest więc wskazanie osoby odpowiedzialnej. Dlaczego za weryfikację, skoro w lekcji jest już zawarta rekomendacja działań? Czy to nie jest jednoznaczne? Nie jest, ponieważ rekomendacja to jedno, a wprowadzenie w życie to drugie.

Każdy proces ma swojego właściciela (a co najmniej powinien mieć) i tylko on może zadecydować o tym, że rekomendowana zmiana jest korzystna dla firmy. Następny krok należy więc do właściciela procesu. Jeśli zaakceptuje rekomendowaną akcję, wówczas koryguje proces. Skorygowany proces jest wprowadzany w życie – to upowszechnienie zmiany.

Trzeba upewnić się, że ludzie postępują zgodnie z nowymi zasadami, że są świadomi że proces został zmieniony, że zapoznają się z zaleceniami przed przystąpieniem do kolejnego zadania. Innymi słowy – poprawiona procedura trafia musi z powrotem do działań operacyjnych.

Jak to najlepiej zrobić? To już zależy od organizacji. Może to obejmować szkolenia, może być po prostu podanie poprawionych procedur do publicznej wiadomości, może zaangażować Społeczności Praktyków (Community of Practice)  i dyskusję na temat tego, co się zmieniło; ostatecznie, niezależnie od formy – ludzie muszą po prostu wiedzieć, że zmienił się sposób pracy.

Jeśli te trzy kroki identyfikacja – rekomendacja – akcja są robione skutecznie to:

  • Po pierwsze lekcja jest przechwycona
  • Po drugie proces jest poprawiony
  • Po trzecie organizacja postępuje zgodnie z nowym procesem.

I dopiero wtedy coś się w organizacji zmienia

Do góry