19 błędow wdrożeniowych

19 błędow wdrożeniowych www.sxc.hu

Jakie są najczęstsze błędy popełniane w procesie wdrożenia systemu IT w organizacji - wyjaśnia Marek Wierzbicki, niezależny konsultant.

Brak wydzielenia poszczególnych faz projektu

Wdrożenie, z punktu widzenia odbiorcy, powinno być podzielone na pięciu kroków.

  • Określenie oczekiwań związanych z nowym systemem
  • Wybór dostawcy
  • Doprecyzowanie modelu współpracy, podpisanie umów
  • Faktyczne wdrożenie (instalacja, szkolenia)
  • Podsumowanie i wnioski

Powinny to być niezależne procesy i rozpoczynanie następnego kroku powinno nastąpić dopiero wtedy, gdy poprzedni jest w całości zakończony. Czasami łączy się dwa pierwsze punkty procesu dopasowując zmiany w firmie do możliwości dostawcy. Sami dostawcy stają się wtedy konsultantami, którzy poza dostawą systemu informatycznego zajmują się optymalizacją procesów biznesowych. Takie połączenie nie wnosi wartości dodanej dla klienta.

Złe określenie oczekiwań

Częstym błędem jest zakup systemu informatycznego nie w celu wyeliminowania problemów czy podniesienia funkcjonalności, a tylko dlatego, żeby go mieć. Konieczne jest określenie jakie działanie systemu uznamy za sukces. Najlepiej nadają się do tego miary ilościowe typu zwiększymy rotację do wyznaczonego poziomu czy zmniejszymy liczbę reklamacji lub zwrotów o określony procent.

Brak dokładnych analiz funkcjonalności systemu

System, który ma poprawić działanie przedsiębiorstwa musi być dokładnie przemyślany. Większość funkcji da się zasymulować z użyciem środków zastępczych. Jeśli przewidujemy zwiększenie szybkości pracy magazynu po wprowadzeniu jakiegoś ułatwienia przetestujmy wcześniej to ułatwienie za pomocą żółtych karteczek, Excela i telefonów komórkowych. Nie bójmy się pytać. Warto stracić dodatkowo kilka dni pytając o zdanie pracowników fizycznych, niż kilkaset tysięcy na poprawki wdrożenia.

Podobne artykuły:

Brak menedżera projektu

Kolejną ważną sprawą jest wyznaczenie osoby odpowiedzialnej za prowadzenie projektu. Jeśli wybieramy do tego osobę, która ma również inne obowiązki, to od razu skazujemy projekt na niepowodzenie. Sensowne wydaje się awansowanie wartościowego pracownika z firmy, odcinając go od dotychczasowego zadania. Sprawdza się też zatrudnienie nowego pracownika z zewnątrz, mającego odpowiednie doświadczenia w poprzedniej firmie lub zatrudnienie zewnętrznej firmy lub niezależnego konsultanta.

Za słabe umocowanie menedżera projektu

Klasyczny problem zarówno nowych osób (nie znają struktury i nieformalnych zwyczajów w firmie) jak i awansowanych (niedawno byłeś mało znaczący, a teraz chciałbyś wydawać polecenia). Menedżer od początku musi mieć bardzo mocną pozycję i silne wsparcie sponsora projektu (najczęściej zarządu). Brak takiej pozycji może spowodować ucieczkę ludzi do innych prac poza wdrożeniem.

Brak odpowiedniej liczby osób zaangażowanych w projekt

Jeśli przy wdrożeniu mają pracować osoby, które jednocześnie muszą zająć się bieżącymi sprawami, to na pewno najpierw będą wykonywać te bieżące sprawy, a później ... zabraknie czasu na wdrożenie. Pod żadnym pozorem nie można na tym oszczędzać.

Zła komunikacja wewnętrzna

Informatycy i przedstawiciele biznesu często mówią innymi językami. Jeśli menedżer projektu nie rozumie obu slangów należy zadbać o taką integrację przedstawicieli obu pionów, aby po wdrożeniu nie okazało się, że tylko jeden z działów jest zadowolony (najczęściej zupełnie nie ten, który miał w założeniu na tym zyskać).

Wybór złego dostawcy

Dostawcy chcą się nam zaprezentować z jak najlepszej strony, aby sprzedać swój system. Większą wiedzę o dostawcach można zdobyć przez wizyty referencyjne u innych klientów i u samego dostawcy. Należy ocenić sumienność, czyli wywiązywanie się dostawcy z zobowiązań. Zewnętrzny konsultant może tu być pomocny, jeśli zna już część dostawców z naszej branży. Osoba, która prowadziła już różne procesy wdrożenia lub pracowała wcześniej u jakiegoś dostawcy wie natomiast, jak poprowadzić wizyty referencyjne, aby uniknąć, nieświadomego czasami, wprowadzenia w błąd przez klientów dopieszczonych przez dostawcę tuż przed wizytą.

Pozorne oszczędności

Często ze względów politycznych wybiera się opcję, która jest tańsza w chwili wdrożenia, jednak łączne koszty są większe. Te dodatkowe koszty można jednak ukryć i określić jako niezwiązane z wdrożeniem. Przykładem może być zakup tańszego oprogramowania na końcówki zamiast terminalowego, który wymaga wymiany stacji roboczych. Oszczędności na systemie nie rekompensują kosztów wymiany komputerów, jednak wykonuje się tą wymianę pozornie bez związku z zakupem systemu.

Wymuszenie na dostawcy prac, których nie chce się podjąć

Przy wyborze dostawcy ważne jest dokładne słuchanie tego, co dostawca chce nam zaoferować. Czasami propozycje dostawcy wynikają z większej niż nasza wiedzy o procesach biznesowych, a czasami z braku możliwości zaimplementowania pewnej funkcjonalności w swoim systemie. Generalnie największym błędem jest zmuszenie dostawcy (np. ceną) do podjęcia się realizacji funkcjonalności lub terminu, który z góry uważają oni za zagrożony. Niemal na pewno zaowocuje to błędami wdrożenia.

Założenie, że czas jest z gumy

Jeśli prowadzący lub sponsor projektu już przy jego starcie zakłada, że w razie opóźnień pracownicy podgonią pracując po godzinach, czy w soboty to na pewno projekt się przedłuży. Planując harmonogram należy zakładać ortodoksyjne podejście do czasu pracy. Nieprzewidzianych wypadków będzie na tyle dużo, że i tak trzeba będzie zaangażować ludzi ponad miarę.

Złe zapisy w umowach wdrożeniowych

W większości przypadków dostawcy starają się podpisywać umowy starannego wykonania, to znaczy (w dużym uproszczeniu), gwarantują najlepsze możliwe podejście do pracy, lecz wszędzie gdzie się da określają pracochłonność prac, a nie ich efekt. Dzięki temu dostawca stawiany jest w lepszej pozycji, to znaczy po wykonaniu zakontraktowanej liczy roboczogodzin może zażądać dodatkowych płatności za kontynuowanie prac. Wszędzie gdzie się da należy więc zamienić zapisy typu szkolenie z modułu xxx dla 3 osób będzie trwało 3 dni i będzie kosztować yyy na za yyy zostaną przeszkolone 3 osoby z modułu xxx. Kryterium ukończenia szkolenia będzie zzz. Dobre kryterium jest bardzo trudne do określenia, ale gwarantuje w przyszłości oszczędność czasu i sporów z dostawcą. Koniecznie należy ustalić wiarygodne kamienie milowe umożliwiające ocenę postępu prac wdrożeniowych Warto określić kary umowne.

Złe zapisy w umowach serwisowych

Należy bardzo uważać, które prace wykonuje dostawca w ramach gwarancji, a które w ramach płatnego serwisu. Dokładnie należy określić co jest błędem krytycznym, aby uniemożliwić dostawcy zakwalifikowanie najbardziej uciążliwych awarii do klasy błędów, które mogą być usuwane dużo dłużej.

Wewnętrzny bojkot nowego systemu

W trakcie wdrożenia równie silnie jak dostawcę należy kontrolować zachowanie we własnej firmie. Nawet najlepsze podejście dostawcy może zostać rozłożone przez grupę niechętnych zmianom pracowników. Pole do popisu będzie miał charyzmatyczny przywódca, który będzie potrafił pokazać podwładnym, że to co dobre dla firmy może być też dobre dla pracowników.

Zignorowanie znaczenie użytkowników kluczowych

Najlepszą według mnie metodą nauki nowego systemu jest tzw. wdrożenie metodą kluczowych użytkowników. Przez dostawcę szkolone są tylko niektóre osoby, które później przekazują wiedzę dalej. Najczęściej osoby takie w przyszłości otrzymują wyższe uprawnienia do systemu i spośród nich wyłaniani są administratorzy funkcjonalni mający np. uprawnienia do anulowania dokumentów. W trakcie wdrożenia to użytkownicy kluczowi powinni uczestniczyć w kontroli, czy funkcjonalność zamówiona u dostawcy jest realizowana we wdrażanych modułach. Oznacza to, że powinni mieć świadomość idei działania nowego systemu. Użytkowników tych warto wyłonić już na etapie określania oczekiwań w stosunku do systemu, wtedy zapewne włączą się w tworzenie projektu i łatwiej będzie im dokonywać tej kontroli, gdyż będą to ich oczekiwania.

Nieprzemyślany spsób wdrażania systemu szytego na miarę

Systemy, które są dopasowywane do naszych potrzeb przez parametryzację, modyfikację skryptów bądź tworzenie nowych funkcjonalności mogą być wdrażane na dwa sposoby. Pierwszy to wdrożenie typu "as is", czyli dostawca wdraża u klienta system w wersji standardowej, a następnie modyfikuje system w locie. Druga metoda to czekanie na wykonanie wszystkich zmian i wdrażanie systemu dopasowanego. Oba rozwiązania mają podobną siłę wad i zalet, więc decyzję o wyborze metody należy podejmować w kontekście własnej sytuacji. Na pewno warto wdrażać część modułów metodą "as is" jak najszybciej, aby umożliwić import danych masowych (indeksy towarowe, dostawcy itp.). Należy się raczej wstrzymywać z wdrażaniem modułów, które po modyfikacji będą realizować całkowicie odmienną funkcjonalność.

Brak mierników postępu

Należy dokładnie określić momenty przełomowe projektu. Jeśli dostawca miał wykonać 3 podobne moduły za pomocą tego samego zespołu w 3 miesiące i deklarował, że każdy z modułów zajmie mu miesiąc to nie wolno w trakcie wdrożenia przyjąć do wiadomości tłumaczenia, że pierwszy moduł jest najtrudniejszy, a później będzie się wykorzystywało fragmenty napisane wcześniej. Gdyby tak było, dostawca powinien nam to powiedzieć zanim zacznie pracę. Skoro tego nie zrobił to oznacza, że szuka na siłę usprawiedliwienia. Jest to właściwy moment na natychmiastową próbę podjęcia działań restrukturyzacyjnych zamiast czekać do końca wyznaczonego czasu.

Brak planu awaryjnego

Jeśli termin wdrożenia systemu informatycznego skorelowany jest z innymi działaniami (budowa magazynu, otwarcie centrum handlowego, itp.) należy przewidzieć plan awaryjny na wypadek, gdyby oprogramowanie nie było gotowe na czas. Plan awaryjny musi powstać razem z planem głównym, gdyż przygotowanie do realizacji tego planu może przebiegać niemal bezkosztowo razem z planem głównym i bardzo drogo w przypadku spóźnionej realizacji. Przykładem może być niemożność skorzystania z sieci bezprzewodowej i konieczność położenia dodatkowych kabli sieciowych. Przy pracach razem z innymi kablami to tylko koszt kabla. Konieczność zrywania wykładzin, kucia ścian i podłóg aby doprowadzić te kable w wykończonym, budynku to nie tylko pieniądze ale i czas.

Brak wniosków powdrożeniowych

Częstym błędem jest brak wniosków wyciąganych z wdrożenia. Jakkolwiek sytuacja, gdy dana firma dokonuje wielu wdrożeń jedno po drugim jest bardzo rzadka, jednak wdrożenie jest projektem jak każdy inny. Innym rodzajem wniosków mogą być podwyżki, awanse, zatrudnienia nowych pracowników lub (przykre ale prawdziwe) zwolnienia. Częstym błędem zarządu, który generalnie nie wymaga wielkich nakładów, jest brak gratulacji i publicznych pochwał zarówno dla osób uczestniczących w projekcie jak i dla całej załogi, że przetrwała ten trudny okres.


Autor: Marek Wierzbicki - obecnie niezależny konsultant. Wcześniej dyrektor działu wdrożeń LSI Software S.A., szef IT w OSDW Azymut i dostawca oprogramowania dla banków i biur maklerskich.

Tekst pierwotnie ukazał się w "Kompendium Oprogramowanie dla biznesu 2007"


Marek Wierzbicki Nowoczesna Firma S.A.