Archiwa Lessons Learned

Lessons learned część 3

Lessons learned - część 3

Wstęp

Najtrudniej jest przejść od teorii do praktyki. Kolejny wpis z serii „Lessons learned” chcę poświęcić praktycznym zagadnieniom związanym z prowadzeniem warsztatów lub jak wolicie wywiadów w ramach procesu. Psychologia gra tu pierwsze skrzypce.

W ramach zdefiniowanych zadań bardzo ważnym elementem jest wskazanie osoby odpowiedzialnej za realizację pojedynczego zadania, jak również konkretnej lessons identified. Pamiętacie zapewne, że na tym etapie nie możemy jeszcze mówić o lessons learned. O tym możecie przeczytać w pierwszym wpisie Lessons learned.

W dalszej części chcę poruszyć zagadnienie związane z częstością prowadzenia warsztatów, wywiadów. Bazą do rozważań jest klasyczny opis procesu obsługi incydentu bezpieczeństwa i miejsce lessons learned w tym procesie.

Na koniec pragnę omówić główne czynniki sukcesu wdrożenia procesu lessons learned w organizacji lub w najgorszym przypadku, dzięki którym znacząco zwiększy się prawdopodobieństwo jego wdrożenia. Wiecie. W niektórych, szczególnych przypadkach nawet najlepsze techniki i metody nie zadziałają, jeśli nieodpowiednio do nich podejdziecie.

Podsumowując wstęp, dzisiejszy wpis opowiada o tym:

W jaki sposób prowadzić rozmowę w ramach lessons learned?
Jak przypisać właściciela do zadania?
Jak często przeprowadzać sesje lessons learned?
Jakie możemy wyróżnić czynniki sukcesu w zakresie wdrażanego procesu?

Jak prowadzić rozmowę w ramach warsztatów, wywiadów lessons learned?

Przeprowadzając rozmowę w ramach warsztatów lessons learned, powinniśmy pamiętać o kilku istotnych faktach:

zbudujcie nic porozumienia ze swoim rozmówcą,
nie oceniajcie wypowiedzi – każda myśl, opinia, sugestia mogą być bardzo cenne,
dajcie szansę uczestnikom się wypowiedzieć. Nie uwierzycie, jak bardzo ludzie uwielbiają mówić i być wysłuchanymi,
moderujcie spotkanie w ten sposób, by żaden z uczestników „nie przejął” spotkania na własność i zagłuszył innych.

Podstawowe zasady

Przechodząc do warsztatów, wywiadów na ich wstępie:

poinformujcie uczestników o celu i formie spotkania,
poproście uczestników, by każdy z nich przedstawił się w celu przypomnienia wszystkim swojej roli pełnionej w trakcie obsługi incydentu bezpieczeństwa,
poinformujcie, że istotą warsztatów nie jest szukanie winnych, a określenie faktów: co się stało, kiedy, dlaczego, co poszło nie tak, co było w porządku,
przypomnijcie wszystkim o zasadzie wzajemnego poszanowania, nieużywaniu agresywnego języka w stosunku do uczestników spotkania,
w przypadku pojawienia się pytań, poproście o nieprzerywanie osobie, która się wypowiada. Zaproponuj zapisanie pytania na później,
starajcie się trzymać faktów i głównego wątku. W przypadku dygresji poproście osobę do powrotu do głównego tematu, nie mniej jednak poruszony wątek warto zapisać, gdyż może być ciekawym elementem dalszej analizy.

Rozmowa

Kolejnym etapem jest już sama rozmowa. Tu ważne jest, by nie przerywać. Pozwólcie wypowiedzieć się. Jeśli macie pytanie lub ktokolwiek z uczestników je ma, zanotujcie je. Zadacie je, gdy dana osoba skończy swą wypowiedź. Takie podejście to nic innego jak aktywne słuchanie. Stosujcie więc wszystkie możliwe techniki aktywnego słuchania, by rozmowa była jak najbardziej konstruktywna. À propos aktywnego słuchania, możecie o tym przeczytać w serii 7 nawyków skutecznego zarządzania incydentami – staraj się najpierw zrozumieć, potem być zrozumiany.

Ważne jest, by w trakcie rozmowy nie pomijać nikogo z obecnych. Zachęcające do dyskusji, a nawet do konstruktywnych konfliktów. Z kolei takie podejście zostało bardzo dokładnie opisane w książce Pięć dysfunkcji pracy zespołowej Patricka Lencioni – konflikt jako narzędzie do wypracowania decyzji zespołu. Książkę bardzo polecam. Uważam, że powinna stanowić podstawową lekturę każdego lidera.

Zakończenie

Na koniec warto podziękować wszystkim za spotkanie, dokonać podsumowania. Jeśli zdefiniowaliśmy zadania do realizacji, to jedna najważniejsza rzecz – określcie ich właścicieli i upewnijcie się, że akceptują to właścicielstwo. Kolejna kwestia to wyznaczenie, jeśli konieczne, następnego spotkania.

Jak przypisać właściciela do zadania?

Jak pisałem powyżej, dla każdego zadania, które zdefiniowaliśmy w ramach omawianych lessons identified, powinniśmy określić ich właściciela. I nie chodzi tu o to, żeby na przysłowiową „sztukę” wskazać kogoś, kto będzie miał do zrobienia jakieś zadanie. Nie. To musi być osoba, która weźmie pełną odpowiedzialność za wykonanie zadania. Oczywiście, żeby tak się stało, ważne jest, by wskazana osoba miała odpowiedni poziom sprawczości w organizacji i chyba co najważniejsze w mojej ocenie, będzie jej zależało na zrealizowaniu zadania. Ja podchodzę do tego w ten sposób, że wykonawca musi rozumieć sens danej czynności.

A co jeśli nie jesteśmy w stanie przypisać właściciela do konkretnego zadania. No cóż. I takie rzeczy się zdarzają. Tu z pomocą przychodzi nam eskalacja problemu na odpowiedni poziom kadry zarządzającej. Im wyżej, tym lepiej. Oczywiście nie będziemy z każdym takim przypadkiem od razu „biegać” do CEO, choć i takie skrajne sytuacje mogą mieć miejsce. Nie bójmy się eskalować.

Jak często przeprowadzać sesje lessons learned?

Teoria

Standardowe lub jak wolisz klasyczne podejście do procesu obsługi incydentów bezpieczeństwa, zakłada, że etap identyfikacji lessons learned występuje w jego końcowej fazie. Analiza przeprowadzana jest wspólnie, przez wszystkich członków zespołu obsługujących dany incydent bezpieczeństwa. Teoria mówi, że takie spotkanie powinno odbyć się najszybciej jak to możliwe, nie później niż od jednego do dwóch tygodni. Takie podejście ma na celu uniknięcie sytuacji, w której najzwyczajniej w świecie zapomnimy o szczegółach z obsługiwanego incydentu bezpieczeństwa i w konsekwencji, nic się „nie nauczymy” jako organizacja.

Praktyka

Praktyka jednak pokazuje inaczej. Okazuje się, że im więcej przeprowadzimy spotkań i wcześniej zainicjujemy ten proces, tym zdecydowanie mniej nam umknie. Można pójść dalej. Dobrą praktyką jest, przetestowane w praktyce, by spisywać w formie dziennych notatek wszystkie obserwacje, rekomendacje, które udało nam się zidentyfikować podczas realizacji czynności obsługi incydentu bezpieczeństwa. Pozwala to na bieżąco dokonywać korekt naszych działań. Mowa tu oczywiście o drobnych korektach czynności. Nikt zapewne nie będzie dokonywał zmian całego procesu czy jego znacznej części tylko i wyłącznie po jednym dniu obserwacji, czy na bazie rekomendacji jednej osoby. Jak już wiecie z poprzednich wpisów, zmiana procesu to zmiana naszych zachowań, a te wymagają szerszej akceptacji i zrozumienia.

Pamiętaj. Im więcej spotkań, tym lepiej. Jako minimum przyjąłbym: spotkanie na początku obsługi incydentu bezpieczeństwa, w trakcie oraz na końcu jego obsługi. Liczba spotkań powinna zależeć od czasu trwania incydentu bezpieczeństwa. Zastanawiasz się, dlaczego na początku? Odpowiedź jest bardzo prosta. Znając kontekst incydentu bezpieczeństwa, warto sięgnąć do już utrwalonych „Lessons learned”, Polecam również analizę lessons learned w ramach incydentów bezpieczeństwa, których doświadczyły inne organizacje, a które upubliczniły ten fakt do szerszej wiadomości. Mam świadomość tego, że publikowane raporty z incydentów bezpieczeństwa mogą nie zawierać prawdopodobnie wszystkich faktów, lub są odpowiednio „wygładzone”, nie mniej jednak i tak mogą stanowić cenne źródło informacji.

Osobną kwestią są zapewne incydenty poważne, gdzie istnieje duża dynamika działań. Dla tych incydentów zalecałbym przeprowadzanie spotkań lessons learned w cyklu dziennym.

Najważniejszym czynnikiem sukcesu jest zaangażowanie się kierownictwa organizacji we wdrożenie procesu

Jakie możemy wyróżnić czynniki sukcesu wdrożenia procesu lessons learned?

W najprostszym ujęciu możemy dokonać podziału czynników sukcesu wdrożenia procesu lessons learned na takie, które mają wysoki, średni lub niski wpływ. Intuicja nam podpowiada, że skupienie się na tych z najwyższym wpływem, pozwoli na osiągnięcie dość szybkich efektów, przy stosunkowo małym „koszcie”. Tylko uwaga. Nie są to tzw. „low hanging fruits”. Nic z tego. Często rzeczy z pozoru najprostsze, okazują się bardzo trudne w realizacji.

Przejdźmy jednak do konkretów. W zakresie czynników sukcesu o wysokim stopniu wpływu na sukces wdrożenia procesu można wyróżnić:

określenie jawnych oczekiwań od wyższego kierownictwa w zakresie ich zaangażowania we wdrażanie procesu w organizacji,
definiowanie zadań do realizacji w ramach lessons identified,
określenie sposobu oceny czy zadanie zostało zrealizowane w całości, czy też nie,
określenie procesu uzgadniania zadań do realizacji,
określenie procesu wyznaczania osoby odpowiedzialnej do realizacji zadań.

I na tym bym zakończył. Są oczywiście czynniki o średnim i niskim wpływie na sukces wdrożenia procesu. Uważam jednak, że i w tym przypadku będzie miała zastosowanie zasada Pareta 80/20, tzn. czynniki o najwyższym stopniu wpływu przyczynią się w największym stopniu do wdrożenia z sukcesem procesu lessons learned w organizacji. Nie ma w tym nic nadzwyczajnego, biorąc pod uwagę, o jakich czynnikach mówimy. W mojej ocenie, gdyby przyszło mi wskazać ten najważniejszy, to z wyżej opisanych byłoby to jawnie określenie oczekiwań wobec wyższego kierownictwa w stosunku do ich zaangażowania się we wdrożenie procesu. Na bazie różnych doświadczeń, zarówno moich, jak i tych wyczytanych w literaturze czy usłyszanych w środowisku cyber, bez wsparcia i zaangażowania wyższego kierownictwa, ciężko jest z sukcesem zrealizować wdrożenie jakiegokolwiek procesu, a proces lessons learned nie stanowi wyjątku od tej reguły.

Podsumowanie

Tym wpisem chciałbym zakończyć serię „Lessons learned”. Jestem głęboko przekonany, że materiał, który mieliście okazję czytać do tej pory, pozwoli Wam zaimplementować z sukcesem proces w Waszej organizacji. Jeśli potrzebujecie więcej wiedzy, odsyłam Was do fachowej literatury, która posłużyła za tło wpisów. Jeśli potrzebujecie konsultacji, zapraszam do kontaktu. Jeśli macie doświadczenie w tym obszarze, zapraszam do dyskusji i wymiany doświadczeń.

Jeśli podobał Ci się wpis, zostaw komentarz pod wpisem, podziel się swoją opinią lub napisz do mnie na adres marcin.sikorski@ctrust.me.

Lessons learned część 3 Read More »

Lessons learned część 2

Zostaw komentarz

Lessons learned - część 2

Wstęp

Mam nadzieję, że poprzednim wpisem skłoniłem Cię do refleksji na temat istotności procesu lessons learned, jego kluczowej, wręcz strategicznej roli w organizacji. Dzisiejszy wpis to próba zmierzenia się z zagadnieniem związanym z właściwym definiowaniem lessons. Kiedy możemy mówić o dobrych lessons identified, a konsekwencji lessons learned? Okazuje się, że można wskazać pewne elementy, które świadczą o tym, że poprawnie je zidentyfikowaliśmy. Oczywiście, by poprawnie identyfikować nasze lessons learned, wpierw musimy mieć zdefiniowany proces i co najważniejsze postępować zgodnie z nim.

W dzisiejszym wpisie poruszę następujące tematy:

Jak wyglada proces lessons learned?
Jakie cechy powinna mieć dobrze zdefiniowana lessons learned?
Pułapki związane z lessons learned.
Jak wdrożyć lessons identified by stały się lessons learned?

Gorąco zapraszam do lektury.

Proces lessons learned

Jak przyjrzymy się procesowi lessons learned, to raczej nie należy on do skomplikowanych. Można w nim wyróżnić trzy podstawowe etapy:

identyfikacja lessons – na potrzeby tej serii wpisów będziemy je nazywać lessons identified,
zdefiniowanie zadań do realizacji,
realizacja zadań, zazwyczaj prowadząca do zmiany zachowania organizacji, a w konsekwencji uczynienia z lessons identified ostatecznie lessons learned.

Można by się zastanowić, który z elementów procesu jest najważniejszy dla całości procesu. Ja skłaniam się do stwierdzenia, że chyba ten ostatni. Jak już pisałem uprzednio, zmiana zachowania organizacji do łatwych nie należy. Z różnych powodów nie chcemy, nie możemy lub najzwyczajniej w świecie boimy się wprowadzać zmiany. Co nam więc po tym, jak świetnie określimy problemy, ba nawet zdefiniujemy zakres zadań, jak nic z tego ostatecznie nie zrobimy.

Wracając jednak do opisu procesu. W ramach identyfikacji lessons możemy wyróżnić trzy podetapy i na tym już koniec podziałów:

Przegląd – polegający na określeniu co przysłowiowo poszło dobrze, a co źle;
Analiza – skupiająca się na odnalezieniu pierwotnego problemu, który przyczynił się do wystąpienia incydentu bezpieczeństwa – już wspominałem o „root cause”.
Generalizacja – polegająca na sformułowaniu ogólnej rekomendacji czy jak wolisz nazywać wniosku.

Tak na marginesie, to celowo nie chcę używać stwierdzenia wniosek, bo z tego nic nie wynika. Wniosek może być i tyle. Angielskie nazwy znacznie lepiej oddają istotę rzeczy.

Co to oznacza, że lessons learned są dobre?

Przede wszystkim powinny być:

łatwe do zrozumienia i nauczenia. Oczywiście jest to pojęcie względne czy coś jest łatwe, czy nim nie jest. Myślę, że istotą jest, żeby nie przekombinować. Rozwiązania powinny ogólnie spełniać zasadę KISS (keep it simple stupid), czyli im prostsze, tym lepsze.
zadania zdefiniowane w ramach lessons learned powinny być wykonywalne – nie ma sensu tworzyć zadań, które z natury, albo będę bardzo złożone i tym samym trudne w implementacji, albo najzwyczajniej za drogie w ujęciu biznesowym, gdzie koszty przekroczą potencjalne zyski.
powinniśmy zadbać również o to, by rzeczywiście nasza lessons identified była rekomendacją, a nie czystą obserwacją. Co nam po stwierdzeniu jak jest? Istotne jest, by wypracować rozwiązanie, które zapewni nam wyeliminowanie lub przynajmniej zminimalizowanie skutków wystąpienia podobnego incydentu bezpieczeństwa w przyszłości.

Pułapki lessons learned

Jakość danych

Pamiętaj, że proces lessons learned, jak każdy inny proces, rządzi się tym samym prawem – „garbage in, garbage out”. Kto pisał raporty, ten wie, o czym mówię. Jeśli nie zapewnimy odpowiedniej jakości danych na wejściu procesu, to nie spodziewajmy się cudów na jego wyjściu, a w konsekwencji dobrej jakości lessons learned.

Wzajemne obwinianie się

To, w jaki sposób podejdziemy do przeglądu, zależy przede wszystkim od ogólnie panujących nastrojów w organizacji. Jeśli na przykład pracujesz w firmie, gdzie szuka się winnych, to raczej nikt nie będzie chętny do tego, by w otwarty sposób mówić o tym, co poszło nie tak. To chyba wydaje się naturalne, prawda? Jest jeszcze jedno stwierdzenie – „Szukanie winnych, karanie niewinnych”. Musisz wiedzieć, że jest to istotny problem dla organizacji, stąd też, jeśli planujesz wdrożyć proces, bezwzględnie musisz zadbać o przyjazne środowisko, gdzie ludzie będą mogli w nieskrępowany sposób rozmawiać z sobą, gdzie będzie panował wzajemny szacunek, zrozumienie.

Nauka tylko i wyłącznie na błędach

To, o czym często zapominamy, to powielanie dobrych zachowań. Może i robimy to intuicyjnie, ale zwróć uwagę na to, że jeśli ktoś robi coś dobrze i trzyma tę wiedzę tylko dla siebie, to organizacja jako całość, nie ma możliwości powielania dobrych wzorców.

zadbaj o przyjazne środowisko, gdzie ludzie będą mogli w nieskrępowany sposób rozmawiać z sobą, gdzie będzie panował wzajemny szacunek, zrozumienie.

Jak sprawić by lessons identified stały się lessons learned

Jednak zidentyfikowanie rekomendacji, ba nawet zadań to dopiero początek, niech będzie, to połowa sukcesu. Pozostaje teraz najtrudniejszy etap – „nauczenie” organizacji działać według nowych reguł, czyli wprowadzić zmianę. Oczywiście im mniej osób dotknie zmiana, tym lepiej dla nas. Mówię o tym, bo ma to związek z naturalnym oporem, który pojawia się wśród ludzi poddawanych zmianie. Stąd też im więcej osób poddanych zmianie, tym większy opór, no i prawdopodobieństwo, że nam się nie uda. Pisałem zresztą o tym w pierwszym wpisie tej serii. Nie pozostajemy jednak bezbronni i jako osoby wprowadzające zmianę w ramach lessons learned możemy posłużyć się pewną techniką.

Wytłumacz sens wprowadzanej zmiany

W pierwszej kolejności powinniśmy w jasny i klarowny sposób zakomunikować, co chcemy zrobić, dlaczego wprowadzenie zmiany ma znaczenie. Tak na marginesie uważam, że jest to najważniejszy element całości. Nie wiem jak dla Was, ale dla mnie istotą jest wytłumaczenie sensu zmiany. Nie mówię, że musi to być elaborat, po co dana zmiana jest wprowadzana. Uważam jednak, że ogólnie ludzie zasługują na to, by wytłumaczyć im sens poświęcania ich energii na jakieś czynności. Bez wątpienia tło incydentu może posłużyć za świetny business case i wytłumaczenie. Nic tak nie przemawia do ludzi, jak incydenty bezpieczeństwa z własnego podwórka. Kwestie zgodności z regulacjami, to kolejny przykład konieczności wdrażania rozwiązań.

Dostarcz narzędzia

Kolejnym elementem jest dostarczenie pracownikom odpowiednich narzędzi i w razie potrzeby przeszkolenie ich ze sposobu ich używania. Mówiąc o narzędziach, mam na myśli zarówno sprzęt, oprogramowanie, jak również procesy czy procedury postępowania.

Sprawdź realizacje zadania

Na koniec należy dokonać sprawdzenia, czy zadanie zostało w prawidłowy sposób wykonane? Tu samoistnie ciśnie się na usta określenie czynników sukcesu. Kiedy stwierdzimy, że dana lessons została learned? Pamiętasz, jak mówiłem o zmianie zachowania. To, w mojej ocenie, jest wyznacznikiem czy nauczyliśmy się czegoś, czy nie. Oczywiście do jakiego stopnia udało nam się nauczyć, przyswoić konkretną lessons learned, to inna sprawa. Spotkałem się ze stwierdzeniem, że jak dokonamy aktualizacji dokumentacji, to możemy już mówić o lessons learned. Owszem. Do pewnego stopnia tak może być. W zakresie napisania, zaktualizowania dokumentu, czegoś się nauczyliśmy. Jednak to zmiana zachowania pod dyktando procedury konstytuuje lessons learned i o tym należy pamiętać.

Podsumowanie

To, co sprawia, że organizacja wychodzi silniejsza z incydentu cyberbezpieczeństwa, to prawidłowo przeprowadzony proces lessons learned. Rekomendacje, jakie z niego płyną, mogą w sposób znaczący zminimalizować ryzyko ponownego wystąpienia podobnego incydentu w organizacji lub przynajmniej zminimalizować skutki jego wystąpienia. Kolejnym istotnym elementem związanym z lessons learned jest budowanie w organizacji wzajemnego zaufania i szacunku. Prawidłowo przeprowadzone spotkania lessons learned, powodują, że ludzie zaangażowani w obsługę incydentu, w otwarty, nieskrępowany sposób, często krytyczny w stosunku do samych siebie, omawiają przebieg incydentu. Takie postawy budują zaufanie, które jest nieocenione przy tworzeniu jedności zespołu.
Najistotniejsze elementy, które powinniście zapamiętać z tego wpisu, to:

nawet najlepsze rekomendacje, bez wprowadzonych zmian, są niczym wartościowym,
wdrożenie lessons learned to nic innego jak wprowadzenie zmiany w organizacji,
dobrze zaimplementowany proces w organizacji sprzyja budowaniu wzajemnego zaufania.

Jeśli podobał Ci się wpis, podziel się swoją opinią lub napisz do mnie na adres marcin.sikorski@ctrust.me.

Lessons learned część 2 Read More »

Lessons learned

Zostaw komentarz

Lessons learned

Wstęp

W pierwszym wpisie serii „7 nawyków skutecznego zarządzania incydentami” poruszyłem zagadnienie dotyczące procesu lessons learned. Tak na marginesie zastanawiałem się, czy jest konieczność szukania polskiego odpowiednika tego angielskojęzycznego stwierdzenia. W branży cyber to określenie stało się na tyle popularne i tak wrosło do słownika pojęć, w szczególności, w obszarze zarządzania incydentami cyberbezpieczeństwa, że chyba nikt nie zadaje sobie obecnie trudu, by znaleźć jego polskie znaczenie. Zauważyłem również, że lessons learned odmieniane jest przez wszystkie możliwe przypadki i podkreślane jest jego istotne znaczenie w procesie zarządzania incydentami. Jednak gdy zgłębiłem tę tematykę, zacząłem zadawać, wydaje się, bardzo podstawowe, lecz uważam trafne pytania? Kiedy lessons są learned, a kiedy nie? Co skłania nas do podejmowania działań naprawczych? Na te i inne pytania postaram się opowiedzieć Wam w kolejnych wpisach tej serii, wpisach, gdyż już wiem, że na jednym się nie skończy.

Przy opracowaniu materiału posłużyłem się głównie lekturą książki „The Lessons Learned Handbook: Practical approaches to learning from experience” autorstwa Nicka Miltona. Uważam, że tytuł ten jest jak najbardziej trafiony. Praktyczne podejście od pierwszych stron. Dzisiejszy wpis proszę, potraktujcie jak wstęp do czegoś większego. Będę chciał w nim poruszyć kilka podstawowych, wręcz fundamentalnych kwestii procesu lessons learned. W szczególności chciałbym rozpocząć dyskusję w następujących tematach:

Czym jest proces lessons learned?
Kiedy lessons są learned?
Psychologia zmiany.
Rola kadry kierowniczej w procesie lessons learned.
Kryzys napędza wszystko.

Czym jest proces lessons learned?

Najprościej rzecz ujmując, lessons learned jest procesem analizy doświadczeń, zarówno tych pozytywnych, jak i negatywnych, które zebraliśmy podczas realizacji określonych czynności np. związanych z zarządzaniem incydentem cyberbezpieczeństwa. Rezultatem tego procesu jest zestaw wniosków/rekomendacji, które mogą posłużyć nam w przyszłości do usprawnień w obszarze wykonywanych czynności. Celowo użyłem stwierdzenia „mogą nam posłużyć”, gdyż to, co często uważamy za lessons learned, w praktyce, tu przepraszam za angielskie sformułowanie, jest lessons identified — czyli zidentyfikowaliśmy wnioski/rekomendacje, ale się do nich jeszcze nie zastosowaliśmy. Jak się okazuje, stąd jeszcze daleka droga do lessons learned, a może nie daleka, ale często „bolesna”. Dlaczego postawiłem taką tezę?

Kiedy lessons są learned?

Nauczenie się czegoś lub inaczej mówiąc wyciągnięcie wniosków z danej sytuacji, wymaga zmiany naszego zachowania. Ucząc się, stosując nowe metody podejścia do realizacji czegoś, dokonujemy zmiany. Kiedy mówimy, że może coś zmienimy w naszym podejściu, bo robiliśmy coś źle lub chcemy wzmocnić nasze zachowanie, bo robiliśmy coś dobrze, ale nie idą za tym żadne czyny, to tak jakbyśmy się niczego nie nauczyli. Istnieje wtedy bardzo duże prawdopodobieństwo, że w przyszłości, w podobnej sytuacji, popełnimy podobne błędy lub nie będziemy powielać dobrych zachowań.

Psychologia zmiany

Dlatego stwierdziłem, że droga do lessons learned bywa bolesna, gdyż z definicji, ludzie nie lubią zmian. Nawet najlepiej przygotowana zmiana powoduje, że prędzej czy później, na jakimś jej etapie doświadczymy negatywnych emocji związanych z jej wprowadzeniem. Nie zagłębiając się na tym etapie w szczegóły procesu zmiany, istnieje kilka jej faz, których warto być świadomym, że występują i są to:

szok,
zaprzeczenie,
gniew,
targowanie się (z sobą),
smutek,
akceptacja i otwartość na nową zmianę.

Jak możecie zauważyć, z większością z nich związane są raczej negatywne niż pozytywne uczucia. Dlatego też tak niechętnie zmieniamy nasze zachowania. Tu nasuwa mi się analogia do nawyku. Jednak od reguły bywają wyjątki. W książce, która posłużyła za tło tego wpisu, opisywana jest historia piętnastowiecznych, zamorskich wypraw Portugalczyków i ustanowienia instytucji, której celem było wymiana doświadczeń, powtórzę się: tych negatywnych, ale w dużej mierze tych pozytywnych. Zdano sobie sprawę, że tylko dzięki temu możliwe jest powiększenie zysków oraz minimalizowanie ryzyka utraty zdrowia i życia. Co jest jednak istotne w całym tym procesie, to zaangażowanie się najważniejszej osoby w państwie — króla.

jedyną pewną rzeczą w życiu jest zmiana

heraklit z efezu

Rola kadry kierowniczej

To w interesie króla była dbałość o należycie realizowany proces lessons learned. Jest to idealny przykład zaangażowania się najwyższej kadry zarządzającej w utrzymanie i rozwój tego procesu. Bo kto spróbowałby sprzeciwić się królowi? A tak serio to myślę, że ten element, pomimo swej istotności, był jednak mniej istotny niż fakt pożegnania się z życiem, w wyniku nieprzepracowania wniosków „kolegów” z innych wypraw. To chyba bardzo motywująco wpływało na chęć nauki, wyciągania wniosków, stosowania dobrych praktyk, unikania najczęstszych błędów. Wielokrotnie zastanawiałem się, jak w dzisiejszych czasach, można przekonać kadrę kierowniczą do ważności tego procesu. Tu jeszcze mała dygresja. Jak pisałem wcześniej, samo mówienie wszem wobec o lessons learned, bez konkretnych działań, jest tylko i wyłączenie gadaniem i niczym więcej.

Kryzys napędza wszystko

To, co przyszło mi na myśl, zastanawiając się, dlaczego w tamtych czasach jednak można było wyciągać wnioski i uczyć się na nich, to sytuacja kryzysowa, z jaką mogli się mierzyć marynarze podczas rejsów. Odnosząc się do cyberbezpieczeństwa, można odnaleźć bardzo podobne sytuacje, jak na przykład atak ransomware. Analogie chyba same się nasuwają. Brak odpowiedniego przygotowania do rejsu, nieprzestudiowanie map, itp. mógł skutkować śmiercią. W przypadku wystąpienia ataku ransomware może być podobnie. Brak odpowiednich backupów, ich testowania, może spowodować, w sytuacji wystąpienia ataku, „śmierć biznesową„ dla organizacji — wyłączenie jej z biznesu na długi czas. O ransomware będę pisał w innym czasie. Teraz chciałbym podkreślić jedno, że może taka refleksja skłoni firmy, instytucje do przygotowania się na tego typu atak. Może na poziomie organizacji zadziała instynkt samozachowawczy i spowoduje wymuszenie działań przygotowawczych.

Podsumowanie

Dziękuję, że jesteś ze mną i zgłębiasz tajniki cyberbezpieczeńśtwa, w trochę inny, niż standardowy sposób. Uważam, że nawet w tak technicznej domenie należy rozmawiać o tzw. elementach miękkich – jak np. psychologia zmiany. Będąc świadomy występowania tego typu zjawisk, dużo łatwiej będzie Wam wdrożyć np. działania naprawcze w ramach zidentyfikowanych rekomendacji. Najistotniejsze elementy, które powinniście zapamiętać z tego wpisu, to:

bez zmiany nie możemy mówić o lessons learned,
najwyższe kierownictwo odgrywa kluczową rolę w promowaniu ważności procesu lessons learned,
sytuacje kryzysowe często popychają nas do zmiany, ale chyba lepiej przygotować się zawczasu.

Jeśli podobał Ci się wpis, zostaw komentarz pod wpisem, podziel się swoją opinią lub napisz do mnie na adres marcin.sikorski@ctrust.me

Lessons learned Read More »