After Action Review (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ść. Inaczej – czasem lepiej, czasem gorzej; inaczej.

Takie zdarzenie może zawierać w sobie lekcję, która jest ważna dla kolejnych działań – zespołu czy organizacji.
Dlatego trzeba się przy nim zatrzymać i dojść do przyczyny – dlaczego tak się stało.

Wyobraź sobie, że jesteś odpowiedzialny za wdrożenie Zarządzania Wiedzą w swojej organizacji lub choćby za przetestowanie koncepcji czy warto wdrażać.

Jak to się stało, że właśnie Ty? Jakoś tak wyszło…
Tak w ogóle to jesteś Kierownikiem Projektów.
Ostatni projekt dał ci mocno w kość (Przypadek Kierownika Projektu). Na tyle, że zacząłeś się zastanawiać, co zrobić, żeby następnym razem było łatwiej.

Rozejrzałeś się wokół siebie i dostrzegłeś, że inne projekty też mają podobne problemy.
I że niektórych problemów mogłoby w ogóle nie być, gdyby był lepszy transfer doświadczeń pomiędzy projektami. Z korzyścią dla wszystkich – ludzi, projektów i całej organizacji.

I właśnie w transferze doświadczeń zobaczyłeś okazję.
Poczytałeś, pomyślałeś, w końcu jesteś Kierownikiem Projektów.
I doszedłeś do wniosku, że warto spróbować z tym transferem.

Poszedłeś z pomysłem do swojego Szefa, on poszedł do swojego, pomysł zyskał pewną życzliwość.
Nie rozwlekając całej historii, skończyło się tak, że dostałeś zadanie – przeprowadzić firmę przez początkowe etapy wdrożenia Zarządzania Wiedzą.

Nazwijmy to wdrożenie – Projekt.

I teraz właśnie przystępujesz do planowania Projektu. Od razu widzisz, że kluczowi są ludzie.
Wiedza jest dla ludzi, wiedzę dają ludzię i wiedzę biorą ludzie.
To jest czułe miejsce.
Podchodzisz do problemu strategicznie.

Procesy Zarządzania Wiedzą to procesy, w których następuje bezpośrednia wymiana wiedzy między ludźmi czy też zespołami.

Opierają się na dialogu. Problem, pytanie, odpowiedź.

Ale tak konkretnie to jak to zrobić?
Jaki proces, w jakim momencie, będzie najbardziej użyteczny?

To zależy od tego, kto jest źródłem wiedzy (jeden człowiek/zespół czy wiele osób/zespołów) i do kogo ta wiedza ma trafić (do jednego człowieka/zespołu czy do wielu osób/zespołów)

Przykład:
Powiedzmy, że jakiś zespół rozpoczyna projekt.

Powiedzmy, że jesteś Kierownikiem Projektu.
Powiedzmy, że projekt właśnie się skończył i powiedzmy, że był trudny (Przypadek Kierownika Projektu).

Powiedzmy, że dzięki temu, że nie było łatwo, zespół sporo się nauczył. Odrobił swoje lekcje. Nabył nowej wiedzy.

Co można zrobić z tą wiedzą?

Można nic nie robić i wtedy zostanie zamknięta w tym zespole; albo można podzielić się nią z innymi zespołami (a one w swoim czasie zrobią to samo ze swoją wiedzą, jak skończą swoje projekty).

Można wykorzystać proces Knowledge Handover.

Jesteś Kierownikiem Projektu…
Wraz ze swoim zespołem rozpoczynasz nowy projekt.
Oczywiście chcesz zrealizować ten projekt w terminie, w budżecie i w ramach tych zasobów, które są przypisane.
No i produkty muszą powstać, jak założono.
I wskaźniki muszą zostać osiągnięte.

Wiesz, że macie przed sobą mnóstwo problemów, choć nawet nie wiesz jeszcze, jakie one będą. Dowiesz się, jak się pojawią. Szkoda, bo gdybyś teraz wiedział, co się może zdarzyć, to mogłoby to pomóc w realizacji. Ale nie wiesz i nic na to nie poradzisz. Wróżką nie jesteś.

Ale jednak jest coś, co możesz zrobić.
Jest taki proces – Peer Assist się nazywa.

Retencja wiedzy to strategia zatrzymywania w organizacji wiedzy, która jest w głowach odchodzących pracowników. Jeżeli nic nie zostanie zrobione, to ta wiedza odejdzie razem z nimi. 

Mały problem, jeśli jest to wiedza, którą posiada wielu pracowników albo łatwo jest zatrudnić kogoś, kto taką wiedzę posiada. Duży problem, jeśli tą wiedzą dysponował na przykład ekspert, jedyny w firmie, właśnie odchodzący. Co z tym zrobić?

Pierwszy problem jest następujący: Retencja Wiedzy – ale jakiej Wiedzy?
Nie każda zagrożona wiedza jest równie ważna dla organizacji, nie o każdą warto zabiegać. Jak dokonać selekcji?

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ędzy-firmowym 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 mi

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.

Wiedza rodzi się w głowie człowieka. Powstaje dzięki nauce albo przez doświadczenie.

Wiedzy potrzebuje też człowiek, kiedy ma zadanie do zrobienia i musi podjąć decyzję.
Może wtedy skorzystać ze swojej osobistej wiedzy albo może skorzystać z wiedzy innych.

Ale wiedza innych jest w głowach tych innych. No to prosty, logiczny wniosek jest taki, że wiedzę trzeba przenieść z jednego miejsca do drugiego. Z jednej głowy do drugiej głowy. Synchronicznie albo asynchronicznie.

Możliwe drogi tego transferu są dwie: