Spis treści
Bardzo często mówi się, że przyczyną porażek jest brak codziennego zaangażowania ze strony osób decyzyjnych. Jeżeli wdrożenie odbywa się „zwinnie” i bez przygotowania, faktycznie stałe zaangażowanie osób decyzyjnych jest niezbędne. Jeżeli wdrożenie jest przygotowane, nie. Zarząd jest wymagany tylko do zatwierdzenia dokumentu audytu, analizy i projektu, potem już tylko obserwuje. Kogo stać na zaangażowanie Zarządu w bieżące prace wdrożeniowe?
Najczęstszą przyczyną kłopotów jest uznanie, że dostawca oprogramowania sam wykona analizę przedwdrożeniową, opracuje wymagania i potem wdroży system.
Wstęp
Od czasu do czasu jestem proszony o audyty dokumentacji projektów. Ma to miejsce, gdy jestem angażowany do projektu będącego kolejnym podejściem do wdrożenia, często też na etapie sporów przedsądowych między dostawcą oprogramowania i zamawiającym. Kilka spostrzeżeń na ten temat w artykule: Kto winien porażki projektu?
Niestety problematyczne wdrożenia systemów ERP nie są rzadkością. Wiele moich zleceń od klientów to wyprowadzanie ich z impasu sporu z dostawcą a potem kontynuacja wdrożenia. Często bywa, że wdrożenie trzeba zarzucić, a zdobyte doświadczenie wykorzystać w prowadzonym od nowa projekcie.
Opisy skutecznych metod pracy i standardów, wraz z literaturą źródłową, znajdziecie Państwo na tych stronach bez problemu. Tu skupię sie na krótkim opisie sposobu postępowania w przypadku „ratowania” wdrożeń systemów informacyjnych.
Jak skutecznie zaplanować i przeprowadzić wdrożenie oprogramowania
Podstawą rozpoczęcia pracy jest schemat stanowiący fundament każdego wdrożenia oprogramowania wspomagającego zarzadzanie:

Powyższy diagram to szkielet każdej skutecznej metodyki prowadzenia analiz przedwdrożeniowych i wdrożeń, zarówno gotowych systemów ERP, już dostępnych na rynku, jak i projektowania i wdrażania rozwiązań dedykowanych: należy przeprowadzić audyt, opracować model procesów biznesowych i zaplanować ewentualne ich usprawnienia. Mając już taki model należy wskazać na nim wszystkie miejsca, które mają być wspierane przyszłym oprogramowaniem: to zakres projektu wdrożeniowego. Pozostaje już tylko zaprojektowanie tego systemu, znalezienie dostawcy i wdrożenie pod nadzorem.
Innymi słowy każdy taki projekt wymaga: (1) analizy i opracowania modelu procesów biznesowych organizacji w celu zrozumienia mechanizmu jej działania (więcej w artykule: Audyt organizacji i optymalizacja procesów biznesowych), (2) odwzorowanie tego mechanizmu w postaci projektu technicznego oprogramowania (więcej w artykule: Analiza i Opracowanie Wymagań na Oprogramowanie).
Projekty takie obecnie realizuje się metodą iteracyjno-przyrostową („od ogółu do szczegółu”), dlatego każdy z ww. dwóch kluczowych etapów, nie powinien trwać dłużej niż trzy miesiące, detale są opracowywane na bieżąco w toku wdrożenia (nadzór autorski). Co do zasady należy unikać kastomizacji gotowego kodu (to niszczy integralność gotowego już oprogramowania i powoduje, że przyszłe upgrade’y będą wymagały powtórzenia prac wdrożeniowych), na rzecz tworzenia dedykowanych modułów tam gdzie to okaże sie wymagane (patrz: Ochrona wartości intelektualnych i know-how w organizacji).
Kluczowe przyczyny problemów wdrożeniowych
Praktyka pokazuje (patrz Chaos Report), że kluczową przyczyną jest łamanie powyższych zasad i próby realizacji wdrożenia „drogą na skróty”, czyli bez przygotowania. Drugą główną przyczyną problemów jest ingerowanie w dostarczone gotowe oprogramowanie. Typowy system ERP to miliony linii kodu programu i setki skojarzonych wzajemnie tabel baz danych. Takie systemy powstają latami, testowanie ich u producenta trwa miesiącami. Każda ingerencja w strukturę tego kodu i tabel baz danych to ryzyko zaburzenia stabilności systemu i ogromna pracochłonność.
Kolejną przyczyną jest brak merytorycznego nadzoru nad wdrożeniem po stronie Zamawiającego. Dostawca oprogramowania ma ogromną przewagę kompetencyjną nad użytkownikami swoich produktów (dotyczy to zresztą każdego zaawansowanego technologicznie produktu). Oznacza to, że nabywca, bez wsparcia, nie jest w stanie merytorycznie nadzorować prace dostawcy (patrz: Kto winny porażki projektu).
ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem
Warto także wskazać przyczynę poza merytoryczną, jaką jest komunikacja w projekcie: korzystanie z poczty elektronicznej i prostych narzędzi biurowych to zmora zarządzania projektami: rozproszone i niekontrolowane dokumenty, brak jednolitego i kontrolowanego dostępu do nich, powoduje, że bardzo szybko zarządzanie projektem staje się serią przypadkowych kontaktów. Niekontrolowany wspólny dysk sieciowy (jeżeli jest) szybko staje się „śmietnikiem”.
Jak wyjść z impasu w projekcie?
Bardzo często elementem sporu jest kwestia pracochłonności i rozliczeń. Dlatego pierwszym etapem jest zawsze audyt dokumentów projektowych (umowa, bieżące zlecenia i ich rozliczenia). Ten etap ma na celu ustalenie stanu faktycznego i wypracowanie tak zwanego bilansu otwarcia.
Kolejny etap to opracowanie kluczowych zaległych dokumentów (patrz początek tego artykułu). Ich szczegółowość zależy od aktualnego stanu dokumentacji projektowej. Tu powstaje także tak zwana analiza luki (analiza „gap-fit”), czyli określenie na ile aktualny stan odbiega od stanu pożądanego. Ten etap kończą rekomendacje do dalszego toku prac, jest to opracowanie nowego harmonogramu i zasad współpracy (aneks do aktualnej umowy lub nowa umowa na wdrożenie). W skrajnym przypadku należy się liczyć z zaniechaniem kontynuacji projektu, ponownym rozpoczęciem wdrożenia tego samego produktu lub wyborem i wdrożeniem innego (patrz: LIDL, PUE, HERTZ).
Umowa ze mną obejmuje w takich przypadkach najczęściej:
- audyt: opracowanie modeli procesów biznesowych firmy i wskazanie na nich wymagań biznesowych i zakresu wdrożenia,
- ocenić różnicę pomiędzy planowanym stanem, „idealnym” a aktualnym faktycznym, opracowanie projektu rozwiązania,
- ustalenie z dostawcą formy zamknięcia aktualnego stanu: formą aneksu lub nowej umowy na dalsze prace (załącznikiem jest co do zasady produkt pierwszego i drugiego etapu powyżej: model procesów biznesowych i projekt rozwiązania jako wymaganie),
- przejęcie zarządzania zakresem projektu (wymagania i projektowanie ich realizacji): (mój) nadzór autorski na bazie opracowanej mapy procesów i wymagań, dostawca realizuje wyłącznie implementację i wdrożenie pod dyktando Zamawiającego (czyli także moje).
Na zakończenie
Spory w projektach wdrożeniowych oprogramowania wspomagającego zarządzenie są niestety nadal normą. Większość udaje są rozwiązać polubownie między stronami, często jednak straty i opóźnienia są tak duże, że angażowani są eksperci z zewnątrz w celu ich minimalizowania.
Jeżeli więc Państwo uznacie, że potrzebne Wam merytoryczne wsparcie, chętnie pomogę oferując doświadczenie zdobyte w ciągu 30 lat pracy nad projektowaniem i wdrażaniem takich systemów, jak i kilkunastu lat pracy naukowej w obszarze inżynierii systemów. Poniżej prosty formularz, który pomoże sformułować Wasze oczekiwania i pytanie do mnie.