Historia pewnego wdrożenia systemu informatycznego

Informatyka jest już z nami wszędzie. Nic dziwnego więc, że ma także mocną pozycję w administracji i działach finansowych firm i instytucji. Uczestniczyłem ostatnio w warsztatach nt. zarządzania projektem, podczas których jeden z uczestników podesłał mi opis wdrożenia systemu finansowo-płacowego w jego instytucji. Projekt miał dofinansowanie zewnętrzne, więc był zorganizowany i zarządzany formalnie. Podczas jego realizacji wykorzystywano profesjonalną metodykę zarządzania projektami PRINCE. Wydawało się więc, że nic już nie stoi na przeszkodzie do szybkiego i spektakularnego sukcesu. Rzeczywistość jednak płata figle…

Poniżej opis wdrożenia wraz z moimi komentarzami (na czerwono). Historia jest prawdziwa, z tekstu usunięto jedynie pewne szczegóły umożliwiające identyfikację firmy. Podany poniżej opis pełen jest wniosków autora (kierownika projektu) co należałoby zrobić na przyszłość aby zmniejszyć ryzyko komplikacji. Niestety, podobnie jak to jest z budową własnego domu, drugiego razu najpewniej już nie będzie…

Polecałbym lekturę poniższego tekstu wszystkim tym, którzy w swoich działaniach zawodowych muszą od czasu do czasu zająć się realizacją projektów, czyli jednostkowych przedsięwzięć mających przynieść określony rezultat.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Doświadczenia w realizacji projektu IT – wdrożenie zintegrowanego systemu kadrowo-płacowego

(…w naszej instytucji…) został zrealizowany projekt (współfinansowany przez UE ze środków Europejskiego Funduszu Społecznego), którego jednym z działań było Zarządzanie kadrami i finansami obejmujące wdrożenie zintegrowanego systemu kadrowo-płacowego. Celem, była optymalizacja pracy w kilku obszarach przede wszystkim w obszarze kadr, płac, socjalnym.

Umowny czas trwania projektu: 15 miesięcy, faktyczny czas realizacji: 20 miesięcy.

Metodyka zarządzania projektem została określona w dokumencie zwanym dokumentem inicjalnym projektu (DIP), który szczegółowo określał zasady współpracy na poziomie operacyjnym pomiędzy zamawiającym (instytucjią) a wykonawcą. DIP zgodnie z umową na dostawę i wdrożenie zintegrowanego systemu kadrowo-płacowego opracowany został przez wykonawcę przy współpracy z naszą instytucją – podlegał akceptacji i odbiorowi przez zamawiającego. DIP zawierał między innymi strukturę organizacyjną projektu, produkty, zasady komunikacji, procedury zarządzania ryzykiem, zmianami i jakością w projekcie. A także, harmonogram i zasady odbioru zrealizowanych prac. Zarządzanie projektem zostało oparte na metodyce Prince2.
stosowano powszechnie uznaną (na skalę międzynarodową) metodykę zarządzania projektem PRINCE. Faktycznie dobre wykonanie projektu „wymyka się” w sporym stopniu metodykom formalnym. Sorry. Więc dlaczego się je stosuje? Bo nie ma nic lepszego. ALE wiele projektów bez PRINCE’a jest świetnie zarządzanych, a wiele projektów z PRINCE’m jest mniej udanych.

UWAGA: mam w swoim otoczeniu osobę, która „kocha wypełnianie tabelek” Systematyczne wypełnianie tabelek Prince’a nie kłóci się z totalnie nieudanym projektem !!!

Generalnym założeniem projektu było zbudowanie zintegrowanego systemu, zawierającego rzetelną i kompletną informację służącą do zarządzania personelem w oparciu o zdarzenia. A także usprawnienie obsługi procesów biznesowych i administracyjnych w obszarze kadrowo-płacowym.

W trakcie realizacji i po wdrożeniu zidentyfikowano wiele ryzyk, z których duża część się zmaterializowała.
charakterystyczne jest to, że te ryzyka zidentyfikowano w trakcie realizacji projektu, a nawet po jego zakończeniu (po samym wdrożeniu). Tymczasem na 99% także w samym wniosku o dofinansowanie (pisanym – oczywiście – przed projektem) były identyfikowane ryzyka, była napisana tabela ryzyk itd. W 90% znanych mi przypadków w/w tabelka formalna jest wyłącznie „pro forma”. Tych najgroźniejszych ryzyk nie wypisuje się aby nie obniżać szans na uzyskanie dofinansowania albo dlatego że profilaktyka w tych kwestiach jest zbyt droga lub trudna do opisania.

 

  • ORGANIZACJA PRZETARGU
    Specyfikacja istotnych warunków zamówienia dla przetargu nieograniczonego (SIWZ) zawierała niespójny i nieprofesjonalny opis przedmiotu zamówienia. Kryteria wyboru wykonawcy, sprowadzały się jedynie do najniższej ceny. Wynikiem czego, najniższą ofertę przedstawiła nieznana na rynku firma, z wątpliwym doświadczeniem. Ostatecznie przetarg rozstrzygnięty został po postępowaniu przed Krajową Izbą Odwoławczą. Wyłoniony wykonawca był drugi pod względem kryterium ceny.
    słaby SIWZ (Specyficzne i Istotne Warunki Zamówienia – podstawowy dokument przy organizacji przetargu), wybór wykonawcy tylko wg ceny (to formalnie łatwe rozwiązanie, praca komisji nie prowokuje wątpliwości co do kryteriów wyboru, ale faktyczna korzyść z takiego wyboru jest często słaba; nie pomaga nawet postawienie wymogu referencji firmowych ani kwalifikacji kadry, bo oba te elementy można – zgodnie z prawem – pożyczać) spór w KIO to następstwo tej sytuacji – zamawiający nie chciał oferenta z najniższą ceną i nie ufał mu. Dopiero decyzja KIO (Krajowa Izba Odwoławcza) pozwoliła wybrać ofertę z „nie-najniższą” ceną

    Wnioski: Zatrudnienie specjalistów/ekspertów do przygotowania SIWZ przy współudziale osób merytorycznych. Prawidłowe zdefiniowanie wszystkich potrzeb i spójne uwzględnienie procesów w ramach integrowanych obszarów. Podjęcie decyzji na szczeblu zarządczym o kryteriach wyboru. I wyeliminowanie zasady „najtaniej” czyli „najlepiej”.

    Wnioski: Nieprzygotowanie organizacji (instytucji) do zmiany poprzez: – brak doświadczenia i przygotowania merytorycznego do wdrażania projektów IT, – brak wizji/koncepcji osób merytorycznych, – brak wykwalifikowanych specjalistów IT, – oszczędzanie na kosztach specjalistów, – realizacja projektu „własnymi siłami”, – nieprzygotowanie pracowników – niechęć i opór do zmiany.

Przed rozpoczęciem wdrożenia, należałoby przedstawić korzyści i zalety zmiany w organizacji, aby zniwelować wewnętrzną niechęć do zmian. Niezbędne jest również przeszkolenie kierownika projektu, koordynatorów/liderów merytorycznych lub zatrudnienie specjalistów. Doświadczenia pokazały, iż realizacja „własnymi siłami” zrodziła wiele problemów na wszystkich poziomach organizacyjnych.
niechęć i opór do zmian może być nieusuwalna (!!!) bo przecież ktoś straci na tym zapewne część kroków zapobiegawczych może być niemożliwa w instytucji danego typu (sztywna siatka płac, przepisy itp.) uzyskanie poparcia decydentów do większych wydatków – choć racjonalne merytorycznie i kosztowo – może być w praktyce nierealne 

Struktura organizacyjna instytucji kontra struktura organizacyjna projektu:

Sposób zarządzania nasza konkretnie instytucją można określić jako skostniały i oporny na zmiany
(opinia niektórych ekspertów) trzy najbardziej konserwatywne środowiska w PL: kler, mundurówka i uczelnie…. (niektórzy dodają także: służba zdrowia) „koń jaki jest, każdy widzi…

Projekt wdrożenia zintegrowanego systemu kadrowo-płacowego został zrealizowany na zasadzie „nie chcę, ale muszę” ze względu na ryzyko związane z funkcjonowaniem aplikacji dotychczasowych i koniecznością dostosowania się do zmieniającego otoczenia IT.
jeśli nawet u decydentów było (jeśli) podejście „nie chcę, ale muszę” – to co dopiero niżej… UWAGA OGÓLNA: każda zmiana, aby mieć szansę na sukces, musi mieć „właściciela”, odpowiednio umocowanego i zdeterminowanego do wdrożenia zmiany, choćby po ewentualnych poprawkach po drodze w/w jest warunkiem koniecznym, choć niewystarczającym

Powołany komitet sterujący projektu, był odpowiedzialny za osiągnięcie głównego celu projektu (koordynację całości prac z tym związanych) bez silnego i jednoznacznego umocowania w organizacji.

Wnioski: Umocowanie formalne komitetu sterującego z pełnomocnictwami do podejmowania strategicznych decyzji, aby wyeliminować/zniwelować lobbowanie na rzecz indywidualnych interesów jednostek.
jest to klasyczna sytuacja – często z tego powodu bierze się zewnętrznych doradców, bo wewnętrzni zawsze są uwikłani w interesy wewnętrzne własne i/lub obce

Atomizacja celu produktowego: 
Trzy obszary objęte wdrożeniem w strukturze organizacyjnej instytucji podporządkowane są różnym pionom i są zarządzane niezależnie od siebie. Natomiast celem produktowym była optymalizacja procesów w obszarze kadrowo-płacowym, poprawienie jakości obsługi klienta (pracownicy instytucji), integracja z systemami zewnętrznymi. Brak decyzji komitetu sterującego oraz władz instytucji doprowadził do atomizacji wdrożenia. Nie zostały podjęte decyzje wynikające z innego zadania projektowego – optymalizacja procesów w instytucji. Efektem braku decyzyjności było odzwierciedlenie istniejących nieoptymalnych procesów, których często podstawą było stwierdzenie „bo tak zawsze było”.
KLASYKA WDROŻEŃ IT: jeśli w instytucji lub firmie jest bałagan w procesach, to system IT zamrozi (=utrwali) ten bałagan. Wówczas ewentualna zmiana będzie 3x trudniejsza i droższa. CZYLI najpierw porządek w procesach, a dopiero potem „zamrożenie” ich poprzez wprowadzenie automatyzacji i informatyzacji Ominięcie etapu I to częsty grzech i nieopłacalna „niby-oszczędność” TAK JAKBY malowanie ścian bez wcześniejszego szpachlowania i wyrównania 

Wnioski:
Przed wdrożeniem lub w trakcie wyciągając wnioski z popełnianych błędów, należało zrealizować zalecenia wynikające z projektu optymalizacja procesów w organizacji. Należałoby zinwentaryzować i przeanalizować istniejące procesy, wewnętrzne akty prawne, aby uprościć i ułatwić życie pracowników w instytucji.
Ale do tego potrzeba na wczesnym etapie „silnego poparcia od samej góry” + okresowe wzmocnienia w trakcie + pomoc w „gaszeniu pożarów”  

Przed wdrożeniem należałoby przeprowadzić profesjonalną analizę obszaru integrowanego, systemów informatycznych, posiadanych zasobów ludzkich. Dopiero w takiej sytuacji termin 15 miesięcy byłby możliwy do zrealizowania.  – problemy w egzekwowaniu wymaganej dokumentacji wynikającej z harmonogramu i organizacji ogólnej projektu (niska jakość – w dokumentach pojawiały się nazwy innych firm), – brak wdrażania w trakcie projektu procedur, standardów, metodyki wdrażania aplikacji i systemu zarządzania jakością.

Wnioski: Konflikt personalny:
W trakcie wdrożenia pojawił się problem wewnątrz instytucji w relacjach międzyludzkich pomiędzy kierownikiem projektu (który jednocześnie był liderem zespołu roboczego obszaru kadry), liderem zespołu roboczego obszaru płace a liderem zespołu roboczego wsparcia IT.
Lider WP1 (=KP) Lider WP2 i Lider WP3 w konflikcie   [WP – Work Package, wydzielone zadanie w projekcie]                    [KP – Kierownik Projektu]

Wykonawca starał się realizować projekt jak najmniejszym kosztem, kierownik projektu był jednocześnie konsultantem i projektantem systemu. Wykorzystany został brak doświadczenia instytucji. Analiza przedwdrożeniowa została zrealizowana bardzo ogólnie, z powodu braku świadomości osób odpowiedzialnych (brak doświadczenia). Do tego doszła zmiana konsultantów po stronie wykonawcy. Pod hasłem konfiguracji systemu „pozwolono” wykonawcy nie realizować określonych w harmonogramie zadań. Wykonawca nie dostarczył skonfigurowanego systemu, a jedynie ogólną aplikację zasiloną częściowo zmigrowanymi danymi. Właściwa konfiguracja nastąpiła na etapie testowania, co było jedną z przyczyn wydłużenia realizacji projektu.

– trudności w egzekwowaniu zarządzania komunikacją oraz dokumentacją projektową.
– niedotrzymywanie terminów harmonogramu szczegółowego
– brak nadzoru kierownika projektu wykonawcy
– niemożność wyegzekwowania dostatecznej ilości kadry zaangażowanej bezpośrednio we wdrożeniu, pomimo spełnienia warunków umowy co do ilości i kwalifikacji osób ze strony wykonawcy. Występowała duża fluktuacja kadry. Inne osoby przeprowadzały analizę przedwdrożeniową, inne realizowały konfigurację systemu. Dodatkowo, nastąpiła zmiana kierownika projektu w 14 miesiącu realizacji,
Klasyka gatunku: zleceniodawca milcząco zakłada, że projekt zrobi wykonawca (w końcu za to bierze – duże – pieniądze!!!). Tymczasem projekt robi mieszany zespół, wykonawca + ludzie z wewnątrz. A ci ludzie maja swoje główne i codzienne obowiązki, a nierzadko wcale w głębi duszy nie popierają projektu!!! 

Problemy ze strony wykonawcy:

Wnioski:
Harmonogram wdrożenia został zdefiniowany w umowie, zaproponowany przez wykonawcę i zatwierdzony przez zamawiającego. Założony okres realizacji na to zadanie był bardzo krótki 15 miesięcy (ze względu na dofinansowanie z UE). Przy jednoczesnym braku przygotowania wstępnego instytucji, braku doświadczenia, wykwalifikowanej kadry, a także problemów po stronie wykonawcy zadanie było trudne do wykonania. Ostatecznie projekt został zrealizowany w ciągu 20 miesięcy.
nie da się zrobić projektu SZYBKO   DOBRZE   I TANIO prace wstępne musiałyby być wcześniej

Lider IT miał odmienne koncepcje zarządzania w projekcie, interpretował w inny sposób zapisy umowy i obowiązującej dokumentacji, pomimo ich literalnego brzmienia. Jego sposób zarządzania zespołem IT i koordynowania pracami doprowadził do problemów, które między innymi miały związek z przygotowaniem i zmigrowaniem danych. Co miało wpływ na harmonogram całego projektu. Był od początku negatywnie nastawiony do wykonawcy. Przyjął bierną postawę, ograniczył się do akceptowania (podpisywania) i rekomendowania zadań cząstkowych w projekcie. Prawdopodobnie wynikało to z faktu przedstawienia przez niego władzom instytucji zrealizowania autorskiego zintegrowanego systemu kadrowo-płacowego, która to propozycja nie została przyjęta. Jak sobie radzić z opornym partnerem?
Klasyka gatunku (formalizacja styku z nim + nie dawanie mu kluczowych zadań, ale uciążliwość pozostaje i tak

Wnioski na przyszłość

    • Ostatecznie w trakcie wdrożenia doszło do rozstania lidera IT z instytucjią.
      im szybciej to się stało, tym lepiej. A straconego czasu szkoda i tak
  • Generalną zasadą powinno być wyciąganie wniosków z popełnionych już błędów. Środowisko, w której działa nasza instytucja ma silnie osadzoną kulturę organizacji i ogólną niechęć do zmian. Stwierdzenie „bo tak zawsze było” jest wygodne, ale w dzisiejszym otoczeniu nie da się już tak dłużej funkcjonować. Zmiany aktów prawnych stanowiących podstawę funkcjonowania instytucji, ich narastająca ilość oraz zmiany technologiczne, konkurencyjność rynku wymuszają na instytucjiach zmiany. Istnieje konieczność wprowadzania w instytucji procesów zarządzania zmianą.
    kadencyjność władz instytucji sprzyja konserwatyzmowi: „przyjdzie (kiedyś) koza do woza…

    Przygotowanie instytucji do określonych zmian – informowanie, wskazanie korzyści, tu się – często – po prośbie, nie da. Trzeba odwagi silnej decyzji + władzy. Będzie wielu niezadowolonych . To częsty dylemat liderów, nie tylko na instytucjiach. ALE kropla drąży skałę nie siłą lecz częstością padania…

 

  • Przy kolejnych wdrożeniach IT w instytucji należałoby wziąć pod uwagę:
  • Zoptymalizowanie istniejących procesów, a dopiero potem ich ustawianie w aplikacji – nie wdrażać „bałaganu organizacyjnego”,
  • Oszacowanie kosztu projektu i zabezpieczenie realnych środków finansowych – należy zapomnieć o wdrażaniu tanio „własnymi siłami”, czy „jakoś damy radę” – nie można oszczędzać na zadaniu strategicznym,
  • Przeanalizowanie okresu wdrażania, lepiej dłużej i dokładniej niż „gonić terminy narzucone”,
  • Powołanie komitetu sterującego (umocowanego formalnie z możliwością podejmowania decyzji), który strategicznie myśli o instytucji, pracownikach, o przyszłości,
  • Powołanie kierownika projektu, znającego instytucjię a jednocześnie posiadającego doświadczenie – udzielenie jemu pełnego wsparcia i umocowania. Powinna to być osoba komunikatywna, posiadająca umiejętności zarządzania zespołem i projektami,
  • Stworzenie profesjonalnego zespołu wdrożeniowego – należy wykorzystać zasoby istniejące, posiadające wiedzę o organizacji, ale należy nie bać się zatrudniać specjalistów/ekspertów,
  • Szkolenie i uświadamianie wszystkich osób zaangażowanych w projekt.
  • Wyciąganie wniosków z popełnionych błędów.

 

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany.