Procesy

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.

Proces Lessons Learned

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

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ę.

Wywiady

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.

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.

Knowledge Handover

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.

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.
Knowledge Exchange
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ą.

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.

  • 1
  • 2