Ilość upadających projektów.
W dobie transformacji cyfrowej i ciągłego niedoboru rąk do pracy automatyzacja zadań powtarzalnych oraz gromadzenie danych stały się nie tylko trendem ale też koniecznością. Dlatego też coraz więcej organizacji wdraża systemy komputerowe, które w pierwszym rzędzie mają odciążyć pracowników od powtarzalnych zadań. Mają także zbierać dane, które w następnym kroku będą wykorzystane do analizy aktualnej sytuacji, poszukiwania błędów w historii oraz przewidywaniu przyszłości. Niestety duża część projektów, zarówno tych małych, jak i tych dużych kończy się niepowodzeniem, czego skutkiem są poniesione koszty, a końcowy efekt jest niezadowalający. Wdrożenie systemu w firmie, jak każda ze zmian, u większości ludzi wywołuje strach i opór. Istotne jest, aby poza technicznymi aspektami systemu pamiętać również o tych ludzkich. Poniżej podaję kilka błędów, jakie zaobserwowałem podczas mojej kariery zawodowej. Są to błędy, które znacząco wpłynęły na efekt końcowy.
Brak dobrego przygotowania do projektu.
Na początku był chaos, a potem ktoś postanowił wdrożyć system (najczęściej ERP). Tak może się zaczynać opis większości projektów, które nie zakończyły się sukcesem. Często wielu menedżerów uważa, że wdrożenie systemy zaprowadzi porządek w ich organizacji. Niestety system komputerowy jest tylko narzędziem i można w nim zaimplementować niemalże każdy proces biznesowy niezależnie czy jest wydajny, czy nie. Dlatego przed przystąpieniem do wdrażania systemu należy przygotować ogólną analizę biznesową całej organizacji oraz szczegółową dla obszaru który zmierzamy automatyzować. Analiza biznesowa pomoże w znalezieniu obszarów, które są niewydajne, lub są wąskimi gardłami oraz pomoże w wyeliminowaniu procesów, które są nieopłacalne. Musimy zdać sobie sprawę z tego, że błędy popełnione na poziomie analizy biznesowej będą się ciągły przez cały projekt. Dlatego w przypadku wykrycia takich błędów warto wykonać krok wstecz w celu ich wyeliminowania, niż uparcie dążyć do zachowania terminów i budżetów.
Brak zapewnienia zasobów.
Na etapie analizy należy również zaprojektować, jak wdrażane narzędzie będzie się komunikować z już istniejącymi: jakie dane będą wymieniane między systemami i który względem którego będzie nadrzędny.
Systemy same się nie wdrażają, a do wdrożenia systemu wymagane jest zaangażowanie wielu pracowników w organizacji – dział IT, kierownicy i przełożeni wszystkich szczebli, użytkownicy końcowi. Na początku należy przygotować analizę biznesową oraz opis funkcjonalności. Należy wykonać instalacje oraz opracować system tworzenia kopii zapasowych oraz monitorowania rozwiązania. Konieczne jest przeprowadzanie szkoleń. Pracownicy muszą mieć czas na wdrożenie się w nowe rozwiązanie, do czego będą potrzebować wsparcia konsultantów. To wszystko wymaga czasu i powinno być zaplanowane w planach każdego zaangażowanego działu. Często zarząd/przełożeni uważają, że może się to wydarzyć w tak zwanym międzyczasie bądź potrzeba na to tak mało czasu, że można tego nie planować. W większości organizacji, z którymi miałem kontakt, tak planowano pracę swoim pracownikom, aby mieli wypełnione całe 8 godzin. Dołożenie kolejnego obowiązku powodowało, że musieli oni pracować po godzinach bądź musieli zrezygnować z jakiś innych zadań. Często destabilizowało to aktualną sytuację w firmie, za co obarczane było wdrożnenie nowego systemu. To z kolei powodowało opór ze strony przełożonych. Dlatego konieczne jest zarezerwowanie niezbędnych zasobów przed przystąpieniem do wdrożenia. Wdrożenie systemu jest tymczasową sytuacja i zatrudnianie nowych pracowników jest bezcelowe. Lepszym rozwiązaniem będzie zatrudnienie firmy zewnętrznej (np. do przygotowania analizy biznesowej), bądź posiłkowanie się wynajmem pracowników wspomagających pracę np działu IT. Warto też zaplanować wdrożenie w tak zwanym sezonie ogórkowy dla branży. Łatwiej wówczas będzie znaleźć czas na wyszkolenie użytkowników końcowych i wdrożenie ich w nowe narzędzie.
Zbyt duży zakres projektu.
Zbyt duży zakres wdrażanego systemu niesie za sobą dwa zagrożenia. Pierwszy to potrzeba zaangażowania dużej ilości pracowników firmy. Taka sytuacja może zdestabilizować codzienną pracę organizacji, a co za tym idzie, może spowodować zachwianie płynności finansowej. Drugi problem pojawia się podczas wdrażania systemu w zbyt dużym zakresie. Doprowadzamy wówczas do sytuacji, w której czas potrzebny na przygotowanie rozwiązania jest na tyle długi, że po zakończeniu wdrożenia rozwiązanie jest już nieprzystające do realiów rynkowych oraz nie pasuje do organizacji. Cyfryzacja małych obszarów organizacji skraca czas liczony od podjęcia decyzji o wdrożeniu, do wdrożenia produkcyjnego rozwiązania. Ryzyko jakie niesie ze sobą jest małe ze względu niewielki obszar jakiego dotyka. Oczywiście taki sposób wdrożenia wymaga integracji nowego rozwiązania ze starym sposobem prowadzenia procesów w organizacji. Generuje to koszty, jednak koszty poniesione w przypadku nieudanego wdrożenia rozwiązania w całej organizacji mogą znacznie przerastać koszty stopniowego wdrażania.
Ciągłe zmiany w systemie.
Tworzenie oprogramowania zgodnie ze specyfikacją jest równie łatwe jak chodzenie po wodzie. Łatwe, pod warunkiem że jedno i drugie jest zamrożone. Niestety bardzo rzadko zdarza się, aby założenia początkowe były dotrzymane do końca projektu. Często jest to podyktowane słabym przygotowaniem do projektu przez zamawiającego. W trakcie projektu okazuje się, że poza głównym procesem biznesowym jest dużo pobocznych, realizujących marginalny odsetek przypadków, które powinny być wyeliminowane/zewidencjonowane na poziomie analizy biznesowej. Każdy wyłom w procesie narusza stabilność logiki biznesowej, co powoduje błędy i zagrożenie dla jakości danych. W dobie metodyk zwinnych lepszym podejściem do realizacji projektów (zwłaszcza średnich i dużych) jest realizowanie ich w procesie iteracyjnym, co ułatwia szybsze wykrycie nieobsłużonych przypadków.
Brak dobrych testów.
Niektórzy twierdzą, że nie ma złych systemów, tylko są źlę przetestowane. Jest w tym dużo racji. Często osoby odpowiedzialne za testowanie rozwiązania po stronie zamawiającego dostają ten obowiązek, jako dodatkowy do swojej pracy bieżącej i po prostu z braku czasu wykonują go niedostatecznie dobrze. System powinien być testowany również przez reprezentacyjnych użytkowników końcowych, gdyż to oni najlepiej wiedzą, jak będą używać systemu i poza wykryciem błędów, są w stanie zasugerować zmiany ułatwiające pracę. Często na etapie wdrażania usprawnień w systemie, popełniany jest istotny błąd: testowana jest zamówiona, wąska funkcjonalność, a nie cały proces. Niestety oprogramowanie jest produktem, w którym wprowadzenie jednej małej zmiany może wywołać problem w zupełnie innym miejscu. Dlatego po dostarczeniu nowej wersji przez dostawcę konieczne jest przetestowanie podstawowych procesów od początku do końca np: od założenia zamówienia do wysłania faktury.
Przerzucenie całej odpowiedzialności za wdrożenie na dostawcę.
Częstym błędem przy wdrażaniu aplikacji jest przerzucanie całej odpowiedzialności za powodzenie projektu na dostawcę. Dostawca, pomimo szczerych chęci ma ograniczone możliwości do motywowania i egzekwowania wyników po stronie klienta. Bez takiej współpracy nie ma możliwości na to, aby projekt się powiódł. Firmy podchodzą do wdrożenia, jak do zakupu samochodu. Mniej więcej tak to wygląda, gdy kupujemy rozwiązanie “pudełkowe” lub w modelu SaaS. Kiedy jest konieczne dopasowanie rozwiązania do aktualnych systemów organizacji, bądź jest to system wykonywany na zamówienie, konieczna jest współpraca pracowników po stronie zamawiającego. Należy też pamiętać, że po etapie wdrożenia to pracownicy firmy powinni być w stanie utrzymywać system w podstawowym zakresie. Może się zdażyć np., że firma dostarczająca rozwiązanie upadnie, a czas potrzebny na przejęcie utrzymania przez inna firmę może być na tyle duży (może się również zdarzyć, że żadna firma nie będzie chciał się podjąć takiego utrzymania), że konieczne będzie utrzymywanie systemu przez pracowników wewnętrznych. Dlatego warto wyznaczyć ludzi, którzy będą brali aktywny udział we wdrożeniu rozwiązania i będą stanowili integralną część zespołu stworzonego razem z pracownikami partnera/dostawcy. Im więcej wiedzy firma przejmie w trakcie wdrożenia, tym bardziej efektywnie będzie w stanie wykorzystywać system, a koszty utrzymania będą niższe.
Brak zaangażowania ze strony zespołu, a czasem wręcz opór.
Nowy system w organizacji jak każda zmiana wywołuje u większości ludzi strach i opór. Strach z reguły dotyczy tego, czy sobie poradzą z nowym narzędziem, a nawet tego, czy pracodawca ich nie zwolni w związku z przejęciem części obowiązków przez system. To jest sprawa czysto psychologiczna i nie zamierzam się o niej tu wypowiadać. Jest to sprawa kluczowa i często zapomniana w sytuacji wdrażania aplikacji, która może doprowadzić do porażki. O wdrażaniu zmian jest napisane kilka książek, a o podstawach można poczytać np tu.
Wybór najtańszego rozwiązania a nie najlepiej pasującego do wymagania.
W Polsce ciągle przy wyborze większości rzeczy, czy to w życiu prywatnym, czy służbowym, dominujące znaczenie ma cena. Często ludzie popełniają błąd wybierania najtańszego rozwiązania, nie patrząc na inne czynniki. Podczas wyboru produktu powinniśmy sobie uzmysłowić, że projekty które są tanie, często nie są priorytetowe dla dostawcy, wręcz leżą w marginalnym obszarze jego zainteresowania. Tani projekt oznacza też, że dostawca nie oddelegowuje do niego najlepszych ludzi, gdyż dobrzy fachowcy są drodzy, a bilans na końcu projektu musi się zgadzać. Cena zawsze miała i będzie miała duże znaczenie przy wyborze rozwiązania, jednak poza ceną należy również uwzględnić inne aspekty takie, jak czas potrzebny dostawcy na dostarczenie rozwiązania. Im wcześniej rozwiązanie będzie gotowe do użytku (chociażby w niepełnym zakresie), tym szybciej zacznie przynosić wymierne wartości. Należy również zwrócić uwagę na referencje firmy. Oczywiście nie wyklucza to sytuacji, w której najtańsze rozwiązanie będzie równie dobre, jak ich droższe odpowiedniki, ale wybór rozwiązania i partnera, który będzie je wdrażał nie powinno być podyktowane tylko i wyłącznie ceną.
Podsumowanie
Rzadko się zdarza, żeby powyższe błędy występowały pojedynczo. Najczęściej występują całymi stadami, gdyż jedne z nich pociągają za sobą pozostałe: brak zapewnienia zasobów powoduje, że rozwiązanie będzie źle przetestowane, a zespół po stronie zamawiającego nie będzie traktował wdrożenia priorytetowo. Bardzo ważne jest, żeby projekt i organizacja była właściwie przygotowana, wówczas większość prac idzie płynnie i zgodnie z planem, a efekt końcowy jest zadowalający. Poza całkowitym upadkiem projektu, może się również zdarzyć, że projekt zostanie wdrożony z kilkuletnim opóźnieniem. W dobie tak dynamicznych zmian może to spowodować, że tuż po zakończeniu wdrożeń projekt będzie przestarzały, będzie wymagał zmian i dostosowania do realiów. W dobrze przygotowanej transformacji cyfrowej proces powinien wyglądać mniej więcej tak:
- Analiza biznesowa
- Zapewnienie zasobów i przygotowanie zespołu
- Wybór rozwiązania
- Wdrożenie testowe a potem produkcyjne
- Ogłoszenie sukcesu
Często pierwsze dwa punkty są pomijane, a cały proces zaczyna się od wyboru rozwiązania, który pada na najtańsze rozwiązanie, co ostatni punkty przekształca w ogłoszenie klapy.