Zarządzanie zmianą (change management) – co to jest, po co to jest i czy można wdrożyć Microsoft Teams w organizacji BEZ tego?
Jeżeli ktoś z was miał styczność z przedstawicielami Microsoft i brał udział w rozmowach o przyswojeniu Microsoft Teams w organizacji – na pewno spotkał się z określeniem change management – zarządzanie zmianą. Pytanie brzmi natomiast – co to dokładnie jest? Artykułów w internecie na ten temat jest sporo i ciągle przybywa (wraz z popularyzacją tego określenia), ale często zaczynają one od części mocno teoretycznej, albo zbyt praktycznej. W tym, stosunkowo krótkim, artykule, chciałbym pokazać tzw. ‘core’ (podstawy) zarządzania zmianą, omówić jego połączenie właśnie z produktami Microsoft i w końcu odpowiedzieć na pytanie – czy bez tego da się w organizacji zaadoptować np. Microsoft Teams?
No dobra – zarządzanie zmianą… Skąd to?
Zacznę od nieco innej strony – kojarzycie pewnie zarządzanie projektami, co? Jest to podejście, które już na stałe przyjęło się w niemal każdej organizacji. Po pierwsze: istnieje “projekt” – przykładowo chcemy coś zbudować. W tym projekcie dysponujemy zasobami – ludźmi, materiałami itd. Następnie pod uwagę bierzemy dostępność tych zasobów, różne ceny etc. Na koniec zwracamy uwagę na etapy – jak budujemy dom, to nie zaczniemy od dachu 😊
Żeby miało to ręce i nogi – powstaje plan, którego staramy się trzymać i (mamy szczerą nadzieję) wszystko gra!
No i tutaj pojawia się właśnie nasz change management, jako uzupełnienie tradycyjnego modelu prowadzenia projektów. Zobaczcie – dostajecie licencję Microsoft Teams jako nowego narzędzia do komunikacji. Od strony IT – przypisujemy te licencje do użytkowników i instalujemy oprogramowanie (MOCNO spłycając proces :D). Czy to oznacza, że następnego dnia nasza efektywność w organizacji skoczy o 40%?
Aby tak faktycznie było, nasi użytkownicy muszą wiedzieć jak się poruszać w nowym środowisku, po co ono jest itp. itd. Nawiążę do tradycyjnego powiedzenia, że jak dacie człowiekowi rybę to nie będzie głodny do końca dnia, ale jak mu dacie wędkę, to nie będzie głodny do końca życia.
Osobiście się z tym nie zgadzam, bo wychodzimy z założenia (często mylnego), że nasz gość będzie umiał tą wędką się posługiwać, a nie np. rzucać nią w ryby z nadzieją, że trafi…
A co w momencie, kiedy tutaj mówimy o bardziej skomplikowanej „wędce”, jak np. Microsoft Teams?
Metodologia Prosci i model ADKAR
Właśnie ze względu na wcześniejszy scenariusz, do wdrażania nowych technologii, procesów itp. powinniśmy rozważyć zarządzanie zmianą (a najlepiej uwzględnić, a nie ‘rozważyć’ 😉). Czyli konkretnie – powinniśmy uwzględnić LUDZI.
Metodologia, która jest polecana przez Microsoft (i przeze mnie, z racji na mój certyfikat 😉) to Prosci – skalowalne podejście, wypracowane na podstawie ponad 20 lat badań.
Ja dzisiaj chciałbym wam przekazać drobny wycinek jakim jest model ADKAR. Jest to jedna z podstaw całego zarządzania zmianą, akronim, którego każda litera oznacza kolejny ‘etap’ wymagany do prawidłowego wdrożenia i zaadaptowania zmian.
Po kolei – pierwsza A to Awareness, czyli świadomość. Będę cały czas posługiwał się tymi naszymi nieszczęsnymi Teamsami jako przykład 😊
Co mamy na myśli, mówiąc o świadomości – chodzi de facto o to, aby nasi użytkownicy wiedzieli, dlaczego w ogóle te Teamsy wprowadzamy. Co to w ogóle za apka (‘tims? A na co to komu?), dlaczego nagle mamy z niej korzystać (‘przecież nasze obecne gadu-gadu świetnie działa!’), skąd potrzeba do zmiany?
Możemy o to zadbać na szereg różnych sposobów – odpowiednia informacja przesłana do wszystkich, wsparcie ze strony menadżerów średniego szczebla, organizowanie sesji pytań i zgłaszania wątpliwości od strony waszych użytkowników.
ALE – to nie wystarczy. Nawet jeżeli ktoś mnie przekona, że mój wypracowany sposób działania MOŻNA usprawnić i dlatego wpada coś nowego, to wcale nie znaczy, że ja teraz będę chciał to zrobić. Pojawia nam się druga literka, czyli D – Desire (chęć).
Musimy zachęcić naszych użytkowników do tejże zmiany, do spróbowania nowej technologii. Może marchewką – np. gamifikacją, albo jakimiś nagrodami czy przywilejami, raczej stroni się od metody ‘kija’ 😉 Pokazując, że z wykorzystaniem nowego podejścia uciążliwe zadania nagle stają się banalnie proste, nasi użytkownicy sami będą chcieli tego spróbować!
I tutaj pojawiają się kolejne dwie literki – K i drugie A. K odnosi się do Knowledge (wiedza), jak możemy się zmienić. Przykładowo – mamy tutaj taką jedną fajną aplikację Microsoft Teams, gdzie, jeżeli zaczniecie wymieniać się danymi w ramach zespołu, to tworzycie wspólne repozytorium na pliki, w ogóle to możecie pracować i edytować te pliki naraz w kilka osób, a każda zmiana jest zapisywana w historii wersji.
Wiedza natomiast nie wystarcza, bo potrzebne są jeszcze umiejętności – stąd A od Ability. Nasi pracownicy muszą wiedzieć jak wykorzystać tą aplikację, jak zaadoptować procesy, jak zmienić swoje przyzwyczajenia.
I wydaje mi się, że jedna z najważniejszych literek na sam koniec – R od Reinforcement (wzmocnienie, wsparcie, utrzymanie). Zmiana jest procesem – dlatego na bieżąco musimy naszym użytkownikom pomagać, rozwijać, wspierać w całym procesie. Pojawiają się nowi pracownicy, nowe aplikacje etc. – trzeba to uwzględnić 😊 Ważne, aby nie stracić zapału na początku!
