Ach ten opluty wodospad… czyli lessons learned

Autor: Jarosław Żeliński

Jednak z tych lekcji wyłania się pewien ogólny wniosek, zresztą nie taki nowy. Zapewne wielu z Państwa znane jest stare przysłowie o wybieraniu drogi na skróty: „kto drogi prostuje ten w domu nie nocuje” i ono doskonale oddaje istotę problemu. Ale po kolei.

Typowe kroki projektu związanego z reorganizacją (jakąkolwiek) firmy to:

Decyzja (jej wypracowanie nie raz może zająć jakiś czas) o podjęciu działań mających na celu jakąś poprawę. Audyt, jego celem jest opisanie stanu obecnego, zrozumienie aktualnej sytuacji. Powstaje model biznesowy czyli opis tego jak firma tworzy wartość i zyski. Audyt powinien być zwieńczony rekomendacjami audytora na temat ewentualnych optymalizacji i związanych z nimi formalizacjami.

Jeżeli pojawi się „coś co warto zmienić”, należy to rozważyć i podjąć działania. Zwracam uwagę, że zaniechanie rekomendowanych działań to także działanie i powinno być świadome. Ten etap (głównie formalizacja) „oczyszcza” firmę z ryzyk wynikających z jej nieprzewidywalności (brak procedur, niekompletne i sprzeczne zakresy kompetencji itp.). Na tym etapie często pojawia się pojęcie zarządzania wiedzą i zarządzania ciągłością działania firmy.

Po „skonsumowaniu” wyników audytu pojawia się (może się pojawić) wniosek, że usprawnienie organizacji wymaga wdrożenia (także wymiany) oprogramowania o pewnych cechach (lub zmian organizacyjnych, innych metod zarządzania itp.). Wyspecyfikowanie tych cech wymaga analizy, której produktem jest specyfikacja wymagań, a konkretnie usług jakich oczekujemy od nowego oprogramowania. Gdyby się okazało, że „takiego” oprogramowania (modułu) nie ma na rynku, należy ocenić rentowność jego zaprojektowania i wykonania, przy pozytywnej decyzji, zlecić wykonanie. Powstaje kompletna specyfikacja wymagań nowego systemu. Na jej podstawie wybieramy produkt i jego dostawcę.

Teraz pora na realizację projektu wdrożeniowego. Mamy wiedzę co chcemy osiągnąć i jak to osiągnąć. Wiemy czego oczekiwać więc łatwo stwierdzić, czy wdrożenie się udało: czy mamy to co miało zostać dostarczone i czy odbyło się w czasie i budżecie jaki zaoferował dostawca.

Powyższe kroki można zobrazować w następujący sposób:



Jak widać, każdy etap daje „poważny” wsad w etap następny.

Wykonajmy małe ćwiczenie myślowe: jakie ryzyko wnosi decyzja o pomięciu któregokolwiek z tych etapów? A teraz ostra jazda: projekt zaczynamy od razu od realizacji czyli mamy sytuację, w której projekt zaczyna się od wdrażania jakiegoś konkretnego oprogramowania czyli realizowany jest od razu ostatni opisany etap z pominięciem wszystkich poprzednich… jakie jest ryzyko takiego podejścia?

Zwracam uwagę, że praktyka (kolejne „nauczki”) pokazuje, że jeden kompletny etap projektu powinien zamknąć się w granicach roku obrachunkowego z uwagi na prawdopodobne zmiany sytuacji rynkowej, wewnętrznej sytuacji firmy, i wielu innych. Rozpoczynanie projektu planowanego z góry na trzy, a nie raz pięć lat (typowy czas wdrażania dużego zintegrowanego systemu ERP), praktycznie z góry skazane jest na niepowodzenie, a mimo to wiele firm zgadza się na taką właśnie drogę…

Opisane tu podejście często nazywane jest „kaskadowym” (waterfall – wodospad). Jest ono dość często wskazywane jako powód porażek projektów, ale moim zdaniem jest to pewna demagogia, gdyż tak na prawdę przyczyną większości problemów jest nie tyle „wodospadowe” podejście (ono jak widać z powyżej opisanego procesu, ma głęboki sens), co wzięcie sobie na barki projektu (zawarcie umowy z dostawcą na trzy lata to przyjęcie w dniu jej zawarcia ponad rocznego harmonogramu łamiącego opisaną powyżej zasadę) na lata, zaniedbując zupełnie fakt, że otoczenie rynkowe obecnie zmienia się nawet co kwartał.

Mamy więc kuriozalne zestawienie: podjęcie projektu od razu od ostatniego etapu (wybór dostawy, produktu i realizacja) i zaplanowanie go od razu na np. trzy lata. To projekt w rodzaju „nie wiem co tu jest grane ale kupujemy [ten system] i wdrażamy go”. To nie ma prawa się udać…

A nasze „lessons learned”? No właśnie, znane mi projekty zakończone kłopotami, to właśnie projekty na skróty. Projekty prowadzone w myśl powyższych zasad (krótkie i dobrze zaplanowane odrębne etapy) są znacznie bardziej odporne na kłopoty.