Harmonogram wdrożenia systemu informatycznego, czyli dlaczego projekty nie wykolejają się nagle

Harmonogram wdrożenia systemu informatycznego. Zazwyczaj pojawia się w projekcie jako plik PDF albo wykres Gantta, który ktoś otwiera na kick-offie, a potem… wraca do niego dopiero wtedy, gdy zaczynają się opóźnienia.

Prawda jest jednak taka, że jeśli ktoś mówi, że projekt IT „nagle się opóźnił”, to z dużym prawdopodobieństwem… opóźniał się od dawna. Tylko nikt tego nie widział albo nie chciał zobaczyć. Tymczasem harmonogram może pomóc w zrozumieniu, co się dzieje z projektem, zanim będzie za późno.

Ten artykuł pokazuje, jak w praktyce podchodzić do harmonogramu wdrożenia systemu IT – bez idealizowania, ale też bez chaosu.

Zacznijmy od podstaw, bo tu bardzo często pojawia się chaos pojęciowy. Przewrotnie sformułujmy antydefinicję: harmonogram to nie:

Harmonogram wdrożenia systemów IT to – mówiąc obrazowo – opowieść o projekcie ujęta w pewne ramy czasowe. Inaczej mówiąc, to mapa, która nie przedstawia wszystkiego, co robią programiści czy automatycy, ale pokazuje kolejne etapy, ich kolejność, zależności i momenty kontrolne. To wszystko pozwala sprawdzić, czy nadal jedziemy w dobrą stronę.

Harmonogram wdrożenia systemu informatycznego jest pisany tak, aby był czytelny również dla klienta.Klient nie potrzebuje wiedzieć, że ktoś tworzy kontrolkę albo pisze skrypt. Klient chce wiedzieć, kiedy:

Przy wdrażaniu systemów informatycznych harmonogram powinien więc opisywać efekty, a nie techniczne szczegóły realizacji.

Odpowiedź na powyższe pytanie jest krótka. Bez harmonogramu wdrożenia systemu informatycznego projekt bardzo szybko zaczyna przypominać realizację planu pod tytułem „jakoś to będzie”.

Harmonogram, szczególnie przy wdrażaniu systemów informatycznych:

Co ważne, te funkcje harmonogramu wdrożenia systemu informatycznego w przedsiębiorstwie są ważne z perspektywy obu stron: klienta i firmy IT. Harmonogram bowiem nie jest dla klienta narzędziem kontroli nad dostawcą ani odwrotnie. Raczej przypomina on mapę, dzięki której obie strony wiedzą, gdzie są i dokąd zmierzają.

W teorii wszystko da się rozpisać idealnie. Co prawda każdy projekt jest trochę inny, ale mimo to pewne etapy się powtarzają, choć z inną wagą i często w innej kolejności.

Zanim powstanie sensowny harmonogram, trzeba wiedzieć, co w ogóle ma zostać wdrożone. Temu właśnie służą analiza przedwdrożeniowa i warsztaty. To jeden z najważniejszych etapów wdrożenia systemu informatycznego w przedsiębiorstwie, bo właśnie tu zapadają decyzje, które później wpływają na cały harmonogram. Bez niego harmonogram przypomina zabawę w zgadywanie. To właśnie na tym etapie wychodzi, że:

Dobry harmonogram zaczyna się od rozmowy, nie od narzędzia, bo tylko komunikacja pozwala określić:

Projektowanie rozwiązania to etap, na którym układana jest architektura systemu: zakres funkcjonalny, integracje, sposób przepływu danych. Dobrze zaprojektowany system skraca kolejne fazy projektu, źle zaprojektowany – zemści się przy testach albo Go-Live.

To etap, który wszyscy kojarzą z „robieniem systemu”. W harmonogramie warto traktować go iteracyjnie, bo rzadko wszystko da się przewidzieć na start. Ważne, aby harmonogram zostawiał tu przestrzeń na korekty, a nie zakładał idealny przebieg.

Integracje z innymi systemami to klasyczny punkt zapalny projektów. Czekanie na dane, maszyny, PLC, serwery albo podwykonawców to codzienność. W praktyce wdrażanie systemów informatycznych w środowisku produkcyjnym bardzo rzadko odbywa się w izolacji od innych narzędzi. Harmonogram, który tego nie uwzględnia, jest życzeniowy. Harmonogram wdrożenia systemu informatycznego, który zostawia bufory – daje przestrzeń do manewru.

Testy nie są nagrodą na koniec projektu. Są jego częścią i powinny mieć swoje miejsce w harmonogramie – razem z czasem na poprawki i stabilizację. Brak testów w harmonogramie to najkrótsza droga do problemów po uruchomieniu.

System może być gotowy, a projekt i tak zakończy się porażką, jeśli użytkownicy nie będą wiedzieli, jak z niego korzystać. Harmonogram powinien uwzględniać szkolenia, materiały i czas na „oswojenie” nowego rozwiązania.

No dobrze, skoro harmonogramowanie wdrożenia obejmuje tak wiele etapów, to jak dużo czasu może wymagać? To zależy. I każda inna odpowiedź byłaby nieuczciwa.

Czas wdrożenia zależy od zakresu projektu, liczby integracji, gotowości organizacji i realnego zaangażowania po stronie klienta. Dlatego pierwsze harmonogramy są czysto orientacyjne. Dopiero po analizie przedwdrożeniowej nabierają konkretnych kształtów.

Przy wdrożeniach systemów IT harmonogramy psują się nie dlatego, że ktoś źle policzył liczbę dni potrzebnych na implementację, ale dlatego, że nie uwzględniono realiów pracy organizacji.

Najczęstsze błędy w harmonogramach to:

Harmonogram bez bufora to nie plan. To mrzonka.

W projektach realizowanych przez explitia harmonogram musi uwzględniać realia produkcji. Doskonale wiemy, że system IT nie działa w oderwaniu od zakładu produkcyjnego, tylko na hali, z ludźmi, dostępnym już oprogramowaniem, parkiem maszynowym. Do tego dochodzą takie zmienne, jak: ciągłość produkcji, bezpieczeństwo, integracja IT i OT.

Krótko mówiąc, w projektach przemysłowych wdrożenie systemu informatycznego w przedsiębiorstwie oznacza pracę na żywym organizmie, a nie na środowisku testowym.

Dobry harmonogram wdrożenia systemu IT nie jest obietnicą, że wszystko na pewno się uda. Bardziej przypomina wsparcie kolegi, który powie: „Wiemy, co robimy, wiemy, gdzie są ryzyka, i wiemy, co zrobimy, gdy coś się zmieni”.

I to w zupełności wystarczy, żeby projekt miał sens.