Zagarnij każdą kozę

Stare przysłowie mówi, że przez brak podkowy może upaść królestwo. Podobnie w programach transformacyjnych, pozornie drobne zaniedbanie może spowodować lawinę niepowodzeń. Chiński fortel[1] mówi o tym, żeby nie lekceważyć małych zwycięstw i niewielkich korzyści. Często będąc skupionym na kluczowych ale dalekosiężnych celach łatwo rezygnujemy z drobnych sukcesów, które jak nic innego budują wiarę w powodzenie całego przedsięwzięcia.

Framework COBIT5, którego używam jako bazy do transformacji, w celach fazy 3 (Gdzie chcemy być?) wskazuje wyraźnie, że niektóre rozwiązania będą łatwe do osiągniecia (quick wins), a inne trudniejsze i długoterminowe. Priorytet należy nadać projektom, które są do osiągnięcia łatwiejsze i prawdopodobnie przyniosą największe korzyści. Zadania długoterminowe powinny być podzielone na mniejsze, łatwe do wykonania części.

I najważniejsze: sukcesy powinny być stale prezentowane i komunikowane, tak aby w całym przedsiębiorstwie istniała wyraźna wiedza o poprawie uzyskiwanej dzięki transformacji. Jak widać współczesne, opracowane przez ISACA podejście do zarządzania zmianą czerpie wprost ze starego chińskiego fortelu.

Opis fortelu

Ziarnko do ziarnka, a zbierze się miarka. Ta miarka to mogą być nie tylko dobra materialne, ale morale zespołu, uznanie wewnątrz firmy i zaufanie Zarządu. Uzyskując (i demonstrując) często drobne sukcesy pokazujemy Zespołowi, że nasze działania mają sens, są przemyślane i prowadzą we właściwym kierunku – ciągłej poprawy. Podobnie z punktu widzenia Zarządu, transformacja przestaje być kosztem, który kiedyś, w przyszłości ma przynieść rozmaite korzyści, ale zaczyna przynosić korzyści tu i teraz, nawet jeśli drobne, to odczuwalne.

I z drugiej strony, trudności na drodze transformacji jest zawsze wiele. Jeśli nie będą one równoważone ciągłymi małymi sukcesami, to w końcu sumując się stworzą wrażenie jednej wielkiej trudności. Gdy w Zespole i Zarządzie pojawią się wątpliwości co do kierunku zmian i możliwości ich osiągnięcia, to transformacja ugrzęźnie. Brak sumowania małych sukcesów to po prostu przyzwolenie na sumowanie się małych trudności i prosta droga do porażki.

Zarówno metodyka zarządzania programami (Managing Successful Programmes MSP ®), jak i framework transformacyjny COBIT5 zalecają powołanie ciała (np. Rada Programu), które będzie na bieżąco informowane o uzyskiwanych postępach. To bardzo ważne aby stworzyć forum komunikacji z biznesem. Można organizować cykliczne spotkania takiego gremium, można rozsyłać newsletter, można prowadzić na tym forum badania ankietowe i wywiady oceniające poszczególne fazy i działania transformacji.

Nie bez znaczenia jest, że małe sukcesy, w których osiągnięcie wciągane są osoby z biznesu (z poza ścisłego zespołu transformacyjnego) powiększają grono sojuszników wdrażanych zmian. Jeśli ktoś dołożył swoją cegiełkę (albo kozę jak chce chiński fortel w oryginale) to będzie całą konstrukcję postrzegał jako również swoją i będzie ją popierał.

Przykłady

Realizując transformację cyfrową w dużej firmie produkcyjnej, jako jedną z inicjatyw uruchomiłem wdrożenie profesjonalnego Service Desk. O ile do tej pory usługa była świadczona temu użytkownikowi, który znalazł informatyka i najgłośniej na niego krzyczał, o tyle po zmianach oczekiwaliśmy zgłoszeń przez system ticketowy. Zaufanie do wewnętrznego IT w tym czasie było bardzo niskie i skłamałbym, gdybym twierdził, że niezasłużenie. Użytkownicy byli przyzwyczajeni, że o ile nie dopilnują osobiście aby zajęto się ich problemem to nie zostanie on ani rozwiązany ani nawet podjęty. Spodziewaliśmy się więc silnego opory przy przejściu na system zgłoszeniowy. Podjąłem więc działania przygotowujące grunt pod tę zmianę. Zaangażowałem dział marketingu w wymyślenie kilku pomysłów na hasła Srvice Desku. Dział grafiki przygotował projekty podkładek pod mysz oraz wygaszaczy ekranu. Następnie uruchomiliśmy badania ankietowe z głosowaniem na oprawę graficzną i hasło. Duża część firmy zaangażowała się w tę zabawę, wywołaliśmy tym samym dyskusję czym i po co jest ten cały Service Desk. Po wdrożeniu zmiany dokonywaliśmy miesięcznych pomiarów satysfakcji, a wyniki rozsyłaliśmy do wszystkich pracowników. Po kwartale ogłosiliśmy konkurs z nagrodami dla działu, który najwięcej zgłoszeń będzie przesyłał przez portal zgłoszeniowy (gdyż oczywiście nie wyłączyliśmy możliwości zgłoszeń mailowych i telefonicznych, przy czym wówczas rejestracji dokonywali pracownicy IT). Nie tylko wdrożenie zmiany się powiodło, ale również pozyskaliśmy dwa działy, które były dymne ze swojego wkładu.

W innym miejscu i czasie, a dokładnie w samym środku wdrożenia nowego systemu ERP, dyrektor zakupów poprosił o pomoc w zarządzaniu awizacjami dostawców. Firma miała kilka magazynów, w każdym od kilu do kilkunastu ramp rozładunkowych, a na każdej rampie do kilkudziesięciu rozładunków na dobę (transport zarówno wewnętrzny jak i zewnętrzny). Niestety brak systemowego rozwiązania powodował, że do ramp ustawiały się kolejki, a dostawy przyjmowano nie do właściwego magazynu, tylko do tego z aktualnie wolną rampą. Każdy, kto miał do czynienia z logistyką rozumie złożoność zagadnienia. I ten problem zostaje postawiony w momencie w którym jestem w pędzącym pociągu wdrożenia ERP. Nowa funkcjonalność = rozszerzenie zakresu = zmiana harmonogramu i budżetu. Aż ciśnie się na usta coś w rodzaju „zajmiemy się tym po wdrożeniu zakresu podstawowego”… czyli za jakieś 1,5 roku. Zarząd by pewnie to zaakceptował, Dyrektor Zakupów musiał przełknąć, a transformacja zyskałaby jednego wroga. Ale od czego są chińskie fortele. Znaleźliśmy szybko proste chmurowe narzędzie do umawiania spotkań (jest ich mnóstwo na rynku) i w ciągu tygodnia zaadoptowaliśmy je do awizacji rozładunków przez dostawców. Typowy Quick Win, typowa koza z chińskiego fortelu. Nic wielkiego, drobiazg, ale krótkoterminowo rozwiązał problem biznesowy, nam dał czas na realizację podstawowego zakresu wdrożenia i zamiast wroga pozyskaliśmy sojusznika.

Podsumowanie

We wspomnianej książce Piotra Plebaniaka, która stanowi moją inspiracje dla tego artykułu, można znaleźć przykłady historyczne odnoszące się do II Wojny Światowej oraz wojny w Wietnamie. Ale dla poznania w jaki sposób one „zagarniały kozy” albo z negatywnymi dla siebie skutkami „nie umiały ich zagarnąć” odsyłam Państwa do oryginału, który jeszcze raz serdecznie polecam.

[1] Bazą jest doskonała książka Piotra Plebaniaka pt. „36 forteli, chińska sztuka podstępu, układania planów i skutecznego działania”

Poprzedni artykuł Zabierz opał spod kociołka
Następny artykuł Uderz w trawę by wypłoszyć węża

Inne artykuły

ASAP goni FUCKUP

Definicja potrzeb biznesowych

Aby prawidłowo zdefiniować zakres projektu bądź programu należy poznać rzeczywistą motywacje kluczowych interesariuszy. Często czują oni intuicyjnie, że potrzebna jest zmiana stanu aktualnego ale nie potrafią bądź nie chcą czytelnie

ASAP goni FUCKUP

Seven Step Continuous Improvement Process

Łatwo powiedzieć, żeby do monitorowania transformacji wybrać właściwe mierniki, natomiast znacznie trudniej to wykonać. W szczególności intuicyjnie, bez znajomości odpowiednich technik zarządczych. Dlatego w tym wpisie przedstawię jedną (ale nie jedyną

ASAP goni FUCKUP

Definicja zakresu – Technika planowania opartego na produktach

Technika planowania opartego na produktach jest jedną z technik specjalistycznych dostarczanych przez metodykę PRINCE2. Technika ta koncentruje się na fizycznych produktach wytwarzanych w ramach projektu (czyli zakresie). Dopiero na podstawie