Jak wdrożyć system informatyczny.

Piotr Ukowski

Zdaję sobie sprawę, że artykuł pod takim tytułem, napisany przez przedstawiciela firmy IT, od razu brzmi podejrzanie. Zgadza się – w procesach wdrożenia systemów informatycznych jestem stroną. Czy zatem stać mnie na obiektywizm? Pewnie nie do końca, choć postaram się. Poniższego tekstu nie należy traktować jako recepty na wszystko, myślę jednak, że warto się z nim zapoznać i wzbogacić swą wiedzę o kolejny (zorientowany biznesowo, a nie technologicznie) głos praktyka. Tytuł artykułu celowo kończy kropka. Założyłem, że postaram się o odpowiedzi, a nie o pytania. Użyłem też trybu dokonanego, bo wdrożyć jest jednak nieco trudniej, niż wdrażać.

Na początek pytanie fundamentalne: co to jest wdrożenie systemu informatycznego? Zanim podam moją definicję, napiszę czym według mnie wdrożenie nie jest:

Za Wikipedią: "Wdrożenie systemu – etap cyklu życia systemu, polegający na instalacji i dostosowaniu oprogramowania do wymagań użytkownika, a także migracji danych oraz testowaniu i uruchomieniu systemu informatycznego." (z dnia 2015-12-10)
Prawdopodobnie jest to odpowiedź prawdziwa od strony technicznej, ale według mnie z gruntu zła biznesowo. We wdrożeniu nie chodzi o fakt uruchomienia systemu, chodzi o zysk z tego uruchomienia.

Wdrożenie systemu informatycznego to zmiana organizacji z wykorzystaniem tego systemu.

Oczywiście w założeniu zmiana na lepsze. Powyższe zdanie posłuży jako motto i punkt odniesienia do całego tekstu.

Po pierwsze cel

Zanim pojawi się dostawca, konsultant, audytor warto (trzeba!) odpowiedzieć sobie na pytanie dlaczego chcemy wdrożyć system IT. Jeśli firma ma dobrze ułożone procesy, tylko nieefektywnie je realizuje, to celem będzie usprawnienie pracy. Taki projekt jest stosunkowo prosty do zdefiniowania – wiemy co robimy, chcemy robić to sprawniej. Jeśli natomiast celem jest przeorganizowanie działania firmy czy jej części, to system IT staje się tylko trybikiem w dużo szerszym projekcie.
Bywa też, że celem jest zyskanie punktów we wniosku o dofinansowanie innej, większej inwestycji czy „wydanie pieniędzy bo przepadną”. OK, tak bywa, ale naprawdę warto to sobie na wstępnie powiedzieć w gronie osób decyzyjnych w organizacji i mniej dziwić się, że projekt, którym nikt się poważnie nie zajmuje, nie może zrewolucjonizować działania firmy.

Cel to taka latarnia na horyzoncie. Czasem się skręca, czasem trzeba obejść jakąś przeszkodę, czasem nawet cofnąć, ale koniec końców pozwala wrócić na właściwy tor.

Dlatego szczerze zachęcam do zapisania celu projektu, do jak najlepszego zdefiniowania oczekiwanego rezultatu. I do stałej kontroli kierunku prac względem tego punktu odniesienia.

Po drugie zespół projektowy

"Wybierzmy profesjonalnego dostawcę, żeby wdrożył nam system". W praktyce czasem takie podejście nawet się udaje, ale jest wyjątkowo trudne. To przedsiębiorstwo wdraża system. Dostawca pomaga, doradza, proponuje, konfiguruje, szkoli. Dostawca nie wprowadza zmian organizacyjnych, bo nie ma do tego żadnego umocowania.

Poza wszystkim, w większości przypadków, cele klienta i dostawcy mogą się różnić. Tak, jak różni się moja i wikipediowa definicja wdrożenia. Dla jednych kluczowe jest dostarczenie, skonfigurowanie i uruchomienie systemu, dla drugich poprawa działalności. Oczywiście oba podejścia mają wspólne części, ale różniące je szczegóły mogą być niezmiernie istotne.

Dlatego konieczne jest powołanie zespołu projektowego, który będzie w stanie merytorycznie i zarządczo ogarnąć całość zagadnienia. Na jego czele powinien stanąć kierownik projektu z pełnomocnictwami do podejmowania decyzji, ugruntowaną pozycją w organizacji i wsparciem decydentów.

Rola kierownika projektu po stronie klienta jest nie do przecenienia. Z jednej strony jest głównym interfejsem dla dostawcy, z drugiej motywuje, mobilizuje i koordynuje działania wewnątrz firmy.

Celem kierownika projektu nie powinno być wyciśnięcie wszystkiego, co się da, z dostawcy. Celem kierownika projektu jest skuteczne wdrożenie systemu w założonym budżecie i czasie. A "wyciskanie dostawcy" bywa narzędziem do osiągnięcia tego celu. Z doświadczenia dodam, że rzadko kiedy skutecznym...

Konkludując ten punkt – jeśli do realizacji projektu nie zostanie powołany zespół z kompetentnym i umocowanym kierownikiem, to ewentualny sukces zależał będzie tylko od szczęścia. A liczenie na szczęście to słaby plan.

Po trzecie dostawca

Przed wyborem dostawcy rozwiązania trzeba wiedzieć czego szukamy. Plan maksimum to znajomość sposobu rozwiązania problemów organizacji, plan minimum, to identyfikacja tychże problemów.

Wybór dostawcy to trudny proces. Nie zmieszczę jego opisu w tak krótkim tekście. Ale postaram się o kilka wskazówek:

• Identyfikacja problemów i zdefiniowanie celów wdrożenia
• Sformułowanie zapytania ofertowego
• Prezentacje rozwiązań różnych dostawców
• Weryfikacja dostawców (referencje, wizyty referencyjne, prezentacja konkretnych procesów na systemie)
• Decyzja czy projekt pisany pod klucz czy bardziej standardowe rozwiązanie
• Negocjacje i dobra umowa

Doświadczenie dostawcy jest ważną wartością dodaną – jego znajomość branży, procesów, zagadnień pozwala optymalniej zaplanować i przeprowadzić wdrożenie. Ale stwierdzenie "jako profesjonalna firma wiecie najlepiej jak to powinno działać" jest niebezpieczne. Wdrożenie IT nie ma sprowadzić działalności przedsiębiorstwa do utartych schematów, nie może zniwelować indywidualnych cech i przewag konkurencyjnych. Dlatego z doświadczenia dostawcy należy czerpać, inspirować się nim, należy go oczekiwać, ale nie warto na nim bezkrytycznie budować zakresu i sposobu wdrożenia we własnej organizacji.

Po czwarte umowa i budżet

Stara zasada mówi, że "umowę podpisuje się na wypadek wojny, a nie pokoju". Jeśli wszystko idzie dobrze, to istotna jest w zasadzie tylko tabelka z kwotami i harmonogram. Na wypadek problemów umowa musi precyzować:

• Zakres projektu
• Procedury odbiorowe
• Obsługę ewentualnych opóźnień 
• Zarządzanie zmianą i kosztami dodatkowymi
• Obowiązki dostawcy i klienta
• Harmonogram i kwoty oraz zasady fakturowania i płatności

Na dwa elementy chciałbym dodatkowo zwrócić uwagę. Pierwszy to przeciąganie negocjacji. Jeśli projekt chcemy koniecznie skończyć np. w 8 miesięcy, a na negocjacje umowy przeznaczamy połowę tego czasu, to na starcie bardzo istotnie zmniejszamy szanse na powodzenie. Drugi to dążenie do przerzucenia całej odpowiedzialności i ryzyka na dostawcę. Oczywiście trzeba zabiegać o swoje interesy i dążyć do podpisania jak najlepszej umowy, ale umowę bardzo jednostronną i niekorzystną podpisują z reguły dostawcy-desperaci bądź dostawcy niekompetentni. Czy naprawdę warto z takimi współpracować, nawet na podstawie świetnej umowy?

I jeszcze wskazówka. Warto przewidzieć dodatkowy budżet na zmiany. Niech on będzie niedostępny dla dostawcy, ale niech daje kierownikowi projektu pole do działania. W trakcie trwania wdrożenia IT zawsze wychodzi coś nieprzewidzianego – nawet przy pełnym zaangażowaniu, profesjonalizmie i świetnym przygotowaniu. Posiadanie nawet skromnego, ale zaakceptowanego budżetu niezwykle usprawnia pracę.

Po piąte analiza

Kiedy już wiemy co chcemy osiągnąć (cel), kim (zespół projektowy), przy użyciu jakiego narzędzia (dostawca) trzeba odpowiedzieć konkretnie na pytanie "w jaki sposób?". Służy temu analiza przedwdrożeniowa, często przeprowadzana na osobnej umowie przed podpisaniem umowy wdrożeniowej.

Analiza nie odpowie na każde pytanie, nie powinna też utknąć na szczegółach, zwłaszcza że podczas wdrażania i tak będą zmiany. Dobra analiza przedwdrożeniowa:

• Definiuje zakres wdrożenia
• Określna jego etapy, harmonogram i aktorów
• Daje wycenę i zamknięty budżet
• Odpowiada na pytanie jak system będzie działał w konkretnych obszarach i jak zostanie zrealizowany cel wdrożenia
• Definiuje kryteria odbioru
• Opisuje interfejsy integracyjne
• Jest stworzona na podstawie spotkań analitycznych z wszystkimi zainteresowanymi zarówno po stronie klienta jak i dostawcy

Po szóste komunikacja

Bez dobrej komunikacji nie ma sprawnie przeprowadzonego wdrożenia. Kanały informacyjne należy udrożnić zarówno wewnątrz organizacji, jak i z dostawcą.

Zespół projektowy musi mieć aktualną wiedzę na temat zakresu i terminów, zarząd musi mieć bieżące raportowanie z postępów, uczestnicy wdrożenia muszą wiedzieć czego i kiedy będzie się od nich oczekiwało, muszą mieć też możliwość zaplanowania swojej pracy i przekazania uwag.

Kierownik projektu powinien być w stałym kontakcie z kierownikiem po stronie dostawcy, kluczowe uzgodnienia muszą mieć formę pisemną (choćby email).

Dodatkowo niezmiernie istotne jest zapanowanie nad przepływem informacji w projektach integracyjnych, kiedy mamy do czynienia z łączeniem systemów różnego autorstwa.

Po siódme podział na etapy

Wdrożenie systemu informatycznego nie jest przedmiotem działalności przedsiębiorstwa, jest środkiem usprawniającym tę działalność. Nie powinno więc zbytnio obciążać i odciągać od prowadzenia własnego biznesu.

Jestem zdeklarowanym zwolennikiem etapowego wdrażania i uruchamiania systemu. Pozwala to zmniejszyć ryzyka, rozłożyć w czasie szkolenia użytkowników, uniknąć katastrofalnego dla normalnej działalności firmy skumulowania obciążenia wdrożeniem i ewentualnych przestojów, a wreszcie już na stosunkowo wczesnym etapie osiągać pierwsze korzyści z wdrożenia.

Są też wady: trzeba to zaplanować. Podzielić projekt na części, które można (z sensem) uruchamiać etapowo, skoordynować prace. Ale warto.

Po ósme zarządzanie zmianą

Wspominałem, że zmiana jest nieodłącznym elementem projektu wdrożeniowego. Można się na to obrażać albo to przewidzieć i zaplanować. To planowanie jest szczególne istotne podczas:

• Badania dostawców – pozwoli sprawdzić ich podejście do zarządzania zmianą
• Tworzenia analizy przedwdrożeniowej – zabezpieczy interesy w nieprzewidzianych szczegółach
• Podpisywania umowy – pozwoli okiełznać koszty dodatkowe

Oczywiście mówimy tu o stosunkowo drobnych zmianach, których wprowadzenia nie podważa całości projektu, a ma na celu lepsze dojście do celu.

Duże zmiany zawsze będą kosztowne. Ale im wcześniej zdiagnozowane, tym tańsze.

Po dziewiąte testy i dokumentacja

Po stronie klienta też muszą być przewidziane i przeprowadzane testy na bieżąco podczas odbierania kolejnych etapów projektu. Nie chodzi o to, że dostawca może przekazać niedotestowany bubel, którego działanie weryfikuje dopiero użytkownik. Testy poprawnego i spójnego działania systemu są oczywiście po stronie dostawcy.

Ale to klient powinien sprawdzić przed produkcyjnym uruchomieniem, czy przekazywany etap spełnia jego oczekiwania; powinien oczekiwać opisu funkcjonalności, np. w formie opisu testów akceptacyjnych bądź instrukcji stanowiskowych (warto mieć ten wymóg zapisany w umowie).

Oznacza to stworzenie i utrzymywanie dwóch środowisk – testowego i produkcyjnego oraz planowanie i przeprowadzanie testów akceptacyjnych.

Po dziesiąte współpraca

Warto przyjąć założenie, że skoro przeszły już trudne etapy wyboru dostawcy, negocjacji i podpisania umowy, to teraz gramy w tej samej drużynie, a celem jest sprawne zakończenie wdrożenia. Kierownik projektu, który rozumie dostawcę i stara się spojrzeć na zagadnienie również jego oczyma niekoniecznie powinien być podejrzewany o działanie na szkodę własnej firmy. Dostawca, który elastycznie podchodzi do problemów i stara się przede wszystkim o dobry efekt wdrożenia niekoniecznie jest pozbawiony rozumu.

Wdrożenie systemu IT jest bardzo trudnym zagadnieniem. Nie zmienią tego faktu reklamy "gotowe prosto z pudełka" czy "uruchomisz to sam w tydzień". Trudnym, ale nie niemożliwym do sprawnej realizacji. Mam na to liczne dowody.