Wdrożenie oprogramowania bez chaosu — jak zarządzać projektem IT
Widziałem to dziesiątki razy. Firma decyduje się na nowy system — ERP, CRM, cokolwiek. Wszyscy są podekscytowani, podpisują umowę z dostawcą, ustalają termin uruchomienia. Pół roku później wdrożenie nadal trwa, ludzie w firmie są zmęczeni i zrezygnowani, a właściciel zaczyna żałować całej decyzji. Nie dlatego że oprogramowanie było złe. Dlatego że nikt nie zadbał o to, jak to wdrożenie poprowadzić.
Problem zwykle nie leży w technologii. Leży w tym, że projekty IT traktuje się jak zakup sprzętu — zamawiam, dostaję, używam. Tymczasem to bardziej jak remont mieszkania. Możesz mieć najlepszych wykonawców, ale jeśli nie wiesz czego chcesz i nie masz kogoś, kto pilnuje całości, skończy się płytkami w złym kolorze i ścianą nie tam gdzie trzeba.
Zanim ktokolwiek napisze linijkę kodu
Największy błąd popełniany na samym początku to zbyt szybkie przejście do rozmów o funkcjach systemu. Firma z Wrocławia, z którą pracowałem, kupiła system do zarządzania magazynem, bo kolega z branży polecał. Nikt nie przeanalizował wcześniej jak realnie wyglądają ich procesy, gdzie są wąskie gardła i co tak naprawdę ma się zmienić. System wdrożyli, ale połowy funkcji nie używają, a problem z inwentaryzacją nadal istnieje — tylko teraz w nowym interfejsie.
Dobry projekt IT zaczyna się od rozmowy z ludźmi którzy będą z tego korzystać na co dzień — magazynierem, księgową, handlowcem. Nie tylko z właścicielem i kierownikiem. To oni wiedzą gdzie realnie gubi się czas i gdzie popełniane są błędy. Bez tego etapu dostawca dostanie nieprecyzyjne wymagania i wdroży coś, co technicznie działa, ale biznesowo nie rozwiązuje problemu.
Scope creep — rozrastanie się zakresu projektu w trakcie jego trwania — to kolejna rzecz, która potrafi zatopić nawet dobrze zaplanowane wdrożenie. W połowie projektu ktoś wpada z pomysłem "a może jeszcze dodajmy integrację z systemem X" i nagle harmonogram pęka. Z doświadczenia — każda zmiana zakresu powinna przechodzić przez formalną decyzję: co to kosztuje, ile zajmie i czy rzeczywiście jest potrzebne teraz, a nie za rok.
Kto tym steruje i kto za co odpowiada
Projekty IT bez wyraźnego właściciela po stronie firmy kończą się źle. Dostawca nie jest w stanie samodzielnie poprowadzić całości — on dostarcza rozwiązanie, ale nie zna specyfiki twojego biznesu. Ktoś wewnątrz organizacji musi pełnić rolę osoby decyzyjnej: zbierać feedback od pracowników, akceptować kolejne etapy, pilnować terminów i eskalować problemy zanim urosną do rozmiarów kryzysu.
To nie musi być dedykowany project manager na pełny etat. Często wystarczy doświadczony pracownik, który ma mandat do podejmowania decyzji i czas żeby realnie w ten projekt się angażować — nie tylko "być do kontaktu". Różnica jest kolosalna.
Spotkania statusowe raz na tydzień to minimum. Nie po to żeby omawiać co zostało zrobione, tylko po to żeby wychwytywać ryzyka zanim staną się problemami. Dobry dostawca sam będzie na takich spotkaniach sygnalizował gdzie jest ryzyko opóźnienia i dlaczego. Jeśli przez trzy spotkania z rzędu słyszysz tylko "wszystko idzie zgodnie z planem" — dopytaj mocniej, bo coś jest nie tak.
Odbiór systemu to też temat, który wiele firm traktuje zbyt pobieżnie. Klikają po interfejsie przez dwa dni, mówią "wygląda okej" i podpisują protokół. A potem po tygodniu produkcyjnego użytkowania wychodzą błędy, których nikt wcześniej nie sprawdził. Testy powinny być przeprowadzone na realnych danych, przez realnych użytkowników, w scenariuszach które faktycznie zdarzają się w firmie — nie tylko tych oczywistych.
Migracja danych to osobny temat, który zasługuje na osobny artykuł. W skrócie — nigdy nie jest tak prosta jak wygląda w ofercie dostawcy.
Jeśli stoisz przed wdrożeniem i chcesz mieć pewność że ktoś ogarnie całość — napisz do nas na bearstone.pl/kontakt, pomożemy zaplanować to porządnie.