Analiza przedwdrożeniowa

Na pewnej stronie przeczytałem ciekawy tekst, nie będę podawał źródła bo moim celem jest wskazanie pewnych ogólnych cech takich projektów, nie jest moim celem reklama strony, z której tekst pochodzi ani firmy jej właściciela .

Tekst pod tytułem „Czym jest analiza przedwdrożeniowa?” dość dokładnie opisuje co czeka nabywcę oprogramowania wspomagającego zarządzanie, pokazuje także pewne założenia jakie przyjmują dostawcy tego rodzaju oprogramowania: pierwszym jest to, że ocena przydatności odbędzie się po zakupie tegoż oprogramowania i o tym napisze kilka słów.  Ale po kolei…(cytaty ze strony tego dostawcy oznaczono kursywą)

Publikacja powstała w oparciu o specyfikę wdrożeń systemu XXX, jednak zawarte tutaj stwierdzenia można rozszerzyć na ogólnie rozumiane wdrożenia systemów informatycznych.

Ogólnie przyjętym standardem, który znajduje zastosowanie podczas wdrożeń systemów informatycznych jest realizacja projektu wg następujących etapów:

1. Analizowanie potrzeb i wymagań,

2. Budowanie koncepcji (wizji rozwiązań) dla systemu,

3. Stworzenie (implementacja) rozwiązań,

4. Wdrożenie opracowanych rozwiązań.

Co do tego nie mam wątpliwości, zadam jednak pytanie: kiedy (po którym etapie) powinien nastąpić wybór dostawcy i rozwiązania? Moim zdaniem po punkcie 2. czyli wiemy czego oczekujemy a więc pora na wizytę w sklepie. Ktoś może powiedzieć (i autor tekstu także tak sądzi), że dobry system może wszystko więc spokojnie można go kupić od razu. Autor tekstu (bedacego ofertą tego systemu!) pisze:

Zakres personalizacji systemu XXX pozwala na swobodne dostosowywanie systemu do indywidualnych potrzeb firmy. Gdy mowa o personalizacji systemu, termin ten należy rozumieć nie tylko jako właściwą konfigurację podstawowych parametrów w zakresie istniejących rozwiązań.

Po kilku krotnym przeczytaniu tego fragmentu jednak nie potrafię pozbyć się myśli, że zdanie drugie zaprzecza pierwszemu, co ciekawsze są to faktycznie sąsiadujące zdania. Skoro system pozwala swobodne dostosowywanie systemu do indywidualnych potrzeb firmy (pierwsze zdanie) to dlaczego jednak oznacza tylko konfigurację podstawowych parametrów w zakresie [tylko, przyp.] istniejących rozwiązań?

Zwracam tu uwagę na sformułowanie w zakresie istniejących rozwiązań czyli jeśli czegoś w rozwiązaniu nie ma to nie ma.

Powstanie zaakceptowanego dokumentu analizy przedwdrożeniowej […]umożliwia zbudowanie harmonogramu prac oraz zdefiniowanie kosztorysu projektu.

Powyższe zdanie jest dla mnie kluczowym wyzwaniem intelektualnym, bo skoro tak to na jakiej podstawie niektórzy dostawcy oprogramowania składają oferty zawierające termin i koszt wdrożenia tegoż oprogramowania, mimo iż analiza przedwdrożeniowa stanowi pierwszy punk oferty? Zagmatwane? Jeszcze raz: jak ocenić ofertę na dostarczenie i wdrożenie  oprogramowania, jeżeli analiza przedwdrożeniowa wchodzi w zakres tej oferty czyli nie została wykonana?

Czy mam rację? Otóż autor sam przyznaje, że podczas analizy przedwdrożeniowej i raporcie z niej:

należy wymienić również te dziedziny działalności firmy, które nie zostaną pokryte przez standardowe czy nawet rozszerzone (zmodyfikowane) moduły systemu XXX.

Jednak system nie robi wszystkiego… autor zna jednak metodę dochodzenia do prawdy:

Bardzo ważny w dokumencie analizy jest opis istniejących procesów biznesowych i wymagań podstawowych - niezależnie od tego, czy obowiązujący model pracy zostanie zachowany i odwzorowany w nowym systemie czy będzie modyfikowany. Opis taki dostarcza informacji o  powiązaniach między działami, istniejącym sposobie opisu dokumentów, nadrzędnych wymogach lub ograniczeniach.

Tak więc ten punkt jest w zasadzie obowiązkowy… niestety wiele firm pomija go, także nabywcy (!)oprogramowania, w sytuacji gdy należy „obciąć budżet”, ale to jest powszechnie nazywane „strzałem we własne kolano”.

wizje [wdrożenia - przyp. mój] tworzy się aby opisać np. sposób odzwierciedlenia informacji w systemie XXX lub proponowany model obiegu dokumentów.

Chyba nie da się uniknąć jednego: konsultanci dostawcy oprogramowania opracują dokumentację o tym „jak wdrożyć nasze oprogramowanie” a nie o tym „jakiego oprogramowania potrzebuje klient”.

Tym samym dokument analizy przedwdrożeniowej staje się elementem, na którym zostają oparte budżet i harmonogram projektu.

Pełna zgoda, znowu jednak pytanie: w takim razie na jakiej podstawie przygotowano pierwotną ofertę zawierającą jako pierwszy punkt tę analizę bez której kosztoru wykonac nie można? Wykonano jednak kosztorys bez analizy? A jak?

W tym miejscu należy jednak zaznaczyć, że osiągnięcie idealnego dokumentu analizy, obejmującego swym zakresem wszystkie wymagania i składowe projektu jest bardzo trudne. Z  naszej praktyki wynika, że często występują sytuacje takie, gdzie nie wszystkie potrzeby zostały wyartykułowane lub zostały przedstawione w niewłaściwym świetle -  wiele rozwiązań wymagało bardziej zaawansowanych prac niż było to pierwotnie zakładane. Tego typu sytuacje pociągają za sobą zmiany w zakresie prac, a tym samym przyczyniają się do zmian przyjętych harmonogramów i kosztorysów.

Jak widać nie jest to łatwe (lata wdrożeń i nadal taka praktyka?), dlatego warto zastanowić się nad wykonaniem wiarygodnej i mało ryzykownej analizy, ta jednak nie jest prostą operacją polegającą na wywiadach z pracownikami. Dobra analiza to pełne zrozumienie celu biznesowgo po konsultacjach z zarządem i kadrą kierowniczą (tez pracownicy ale nie Ci szeregowi), rzetelna analiza organizacji firmy i jej modelu biznesowego. Oddolna wizja pracowników firmy rzadko kiedy jest zgodna z celami biznesowymi firmy a skrajnym (ale pouczającym) przykładem mogą być niektóre związki zawodowe. Czy wyobrażamy sobie projekt wdrożenia systemu ERP, którego jednym z celów jest optymalizacja, opracowany na podstawie wywiadów ze związkami zawodowymi?

Wielu, może nawet większość, dostawców oprogramowania tak podchodzi do projektów. Zapytałem jednego z nich dlaczego nie dzielą umowy z klientami na dwie: umowa na analizę i umowa na wdrożenie? Na co usłyszałem: nie po to nasi handlowcy ponoszą koszty szukania klientów by ryzykować, że po analizie dostawę i wdrożenie zrobi kto inny, do umowy wpisuje się taki koszt by zarobić na wszystko o czym nie wiemy a klient jak usłyszy, że czegoś nie można to w końcu i tak zrezygnuje. Jest także inna strategia, przetargowa (kolejny cytat): Przetargi wygrywamy ceną, potem podczas analizy wywalamy z zakresu projektu wszystko co podnosi koszty żeby zmieścić się w budżecie, klient związany umowa z reguły to kupuje bo w projekcie często umieszcza szeregowych pracowników a ci nie dyskutują.

Dlatego, warto zacząć, od tego by przygotować opis nadający się do wykonania wyceny. Od dostawców oprogramowania i programistów wiem, że prosta lista wypunktowanych wymagań nie daje nic podobnie jak krawcowi nic nie da stwierdzenie „mam 182 cm wzrostu i chce czarny garnitur”. Dopiero szczegółowe pomiary, wskazanie gatunku materiału, jego wymaganej trwałości, liczby kieszeni, odporności na warunki atmosferyczne itp. pozwala na wycenę produktu krawca.  

Specyfikacja wymagań powinna dokładnie opisywać procesy, to jakie dane i gdzie są potrzebne, z jakimi innymi systemami należy się zintegrować i wiele innych, istotnych z punktu widzenia zamawiającego i jego infrastruktury oraz potencjalnych kosztów. Teraz dopiero dostawca może dokonać rzetelnej wyceny a specyfikacja wymagań będzie odzwierciedlała potrzeby zamawiającego a nie możliwości dostawcy.

(Zainteresowanym prześlę przykładowe dokumenty analizy).

Źródło: www.it-consulting.pl
Autor: Jarosław Żeliński