Strona główna > O firmie, publikacje naszych specjalistów > Najczęstsze błędy wdrożeniowe

---

Najczęstsze błędy wdrożeniowe

Marek Wierzbicki

Artykuł opublikowany oryginalnie w kompendium Nowoczesna Firma - oprogramowanie dla biznesu.

Według różnych badań, w zależności od rodzaju projektu i oczekiwanego celu, od 20 do 80 procent wdrożeń systemów informatycznych nie przynosi spodziewanych efektów. Spróbuję zwrócić uwagę na najczęstsze błędy wdrożeniowe popełniane przez klientów.

Lista najczęstszych błędów wdrożeniowych

1. Zła organizacja całego projektu, brak wydzielenia poszczególnych faz projektu.

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

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

Powinny to być niezależne proces z ustawienie między nimi kamieni milowych i rozpoczynanie następnego kroku 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. Uważam, że takie połączenie nie wnosi wartości dodanej dla klienta. Brak podziału powoduje przypadki, że np. już mamy podpisaną umowę z dostawcą, a jeszcze do końca nie wiemy co ma on nam dostarczyć.

2. 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ć (np. w niektórych przedsiębiorstwach państwowych, żeby się lepiej sprzedać lub dlatego, że konkurencja też to robi). Konieczne jest określenie jakie działanie systemu uznamy za sukces. Najlepiej nadają się do tego miary ilościowe typu zwiększymy rotację do poziomu czy zmniejszymy liczbę reklamacji lub zwrotów o określony procent.

3. 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. Jeśli po dwóch dniach testów nie zmienimy nic w swoim pomyśle, to albo jesteśmy genialni, albo zbyt zadufani w sobie. Poza tym 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.

4. 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 zaczynamy kopać grób dla tego projektu. Sensowne są następujące rozwiązania:

1. Awansowanie wartościowego pracownika z firmy, odcinając go od dotychczasowego zadania. Najprostszym rozwiązaniem jest miesięczny lub dłuższy urlop, z zakazem używania firmowej komórki. Taki urlop ma kilka zalet. Wartościowy człowiek najprawdopodobniej jest nadmiernie wykorzystywany i trzeba zapobiec jego wypaleniu, a długa nieobecność wymusza na jego następcy szybkie wdrożenie się w nowe obowiązki. Zaletą jest duża znajomość firmy, wadą chęć zwracania się do niego w sprawach, które wcześniej obsługiwał.
2. Zatrudnienie nowego pracownika z zewnątrz, mającego odpowiednie doświadczenia w poprzedniej firmie. Zalety to brak dotychczasowego powiązania z pracami w firmie i świeże spojrzenie, wada to konieczność zgrania się z firmą
3. Zatrudnienie zewnętrznej firmy lub niezależnego konsultanta. Zaleta to niezależność (prezes nie wyśle takiego człowieka do ratowania starego systemu w innej części firmy) i duże doświadczenie w podobnych pracach. Wada to pozornie wysokie koszty takiej operacji (pozornie, gdyż konsultant z dużym doświadczeniem może wynegocjować lepszy kontrakt z dostawcą, zaproponować większą optymalizację procesów czy szybciej zakończyć wdrożenie).

5. Za słabe umocowanie menedżera

Klasyczny problem zarówno nowych osób (nie znają struktury i nieformalnych zwyczajów w firmie) jak i awansowanych (niedawno byłeś małoznaczą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.

6. 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ć.

7. 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ć).

8. Wybór złego dostawcy

Dostawcy chcą się nam zaprezentować z jak najlepszej strony, aby sprzedać swój system. W ramach prezentacji spotykamy się z najlepszymi showmenami. Z wody lanej hektolitrami należy wywnioskować co dany dostawca jest nam w stanie realnie zaproponować. 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 (choć może tu zadziałać mechanizm rutyny i uprzedzeń wynikający z dawnych złych kontaktów). 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ą.

9. 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.

10. Wymuszenie na dostawcy prac, których się nie chce 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.

11. 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ę.

12. 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, ale ... w końcu nie chodzi nam o kary, tylko o wdrożenie systemu.

13. 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.

14. 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.

15. 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.

16. 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ść.

17. Brak mierników postępu

Należy dokładnie określić momenty przełomowe (kamienie milowe) 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.

18. 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.

19. Brak wniosków powdrożeniowych

Częstym błędem jest brak audytu powdrożeniowego i wyciągania wniosków. Jakkolwiek sytuacja, gdy dana firma dokonuje wielu wdrożeń jedno po drugim jest bardzo rzadka, jednak wdrożenie jest projektem jak każdy inny (np. wprowadzenie nowego modelu do sprzedaży). 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.

Podsumowanie

Mam nadzieję, że moje uwagi wniosły nową wiedzę w proces wdrażania oprogramowania. Oczywiście trudno w takim krótkim tekście przekazać doświadczenia z kilkunastu lat pracy. Starałem się wymienić najważniejsze czynniki, które wpływają w największym stopniu na udane wdrożenie. Wiele z nich ma jednak miękki charakter i są trudno kodowalne oraz bardzo zależą od kontekstu sytuacji.