Przy piątku naszło mnie na zestawienie pewnych treści (cytaty).
Podczas codziennej „prasówki” wpadłem na artykuł „Najczęściej popełniane błędy podczas wdrożenia ERP”, oto cytat pierwszy:
– Największym błędem popełnianym przy wdrożeniach jest nieznajomość potrzeb firmy i niewłaściwe rozplanowanie etapów i zakresu wdrożenia… (Najczęściej popełniane błędy podczas wdrożenia ERP.).
W projektach IT mamy jednak najczęściej tylko dwie strony: inwestor (nabywca oprogramowania) oraz wykonawca (dostawca oprogramowania i wdrożeniowiec, z reguły wystawia także kierownika projektu).
Raport z 2011 roku na temat przyczyn niepowodzeń można podsumować tak:
Ponad 80% projektów programistycznych ma przekroczone termin i budżet. Największą trudnością w tych projektach okazało się jasne zrozumienie tego, czego tak naprawdę klient potrzebuje, oraz udokumentowanie jego wymagań. Do przechowywania wymagań użyty był głównie word i excel oraz email. Przyznajemy jednak, że diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami to modele procesów i prototypy, jednak nie stosujemy ich. ( 2011 State of Requirements Management Report.)
Innymi słowy: pomijamy rzetelne analizy i projektowanie poprzedzające realizacje projektu, nie mamy pewności czego potrzebuje zamawiający, nie mamy dokumentów na bazie których prowadzimy projekt. Owszem, wytworzenie ich to są pewne koszty, ale kto odnosi korzyść z takich „oszczędności”? Nie twierdze, że jest tak zawsze ale 80% projektów wadliwych to nie tak mało. Gdyby to były budowy, liczba ofiar na drogach to byłby przy nich przysłowiowy „pikuś”.
Inwestycje w oprogramowanie ERP (i nie tylko) są często, nie przypadkiem, porównywane z inwestycjami budowlanymi. Głównym powodem jest podobieństwo etapów, względnie porównywalne budżety i porównywalne ryzyko, kluczową różnicą jest to, że tylko katastrofa budowlana rodzi ogromne ryzyko ofiar.
Ustawodawca co prawda niestety nie chroni budżetów IT, chroni jednak życie swoich obywateli i powstało Prawo Budowlane, poniżej cytat. Proszę poniższe na spokojnie przeczytać i wyobrazić sobie, że prawo narzuciło analogicznie przepisy dla projektów IT, i zastanowić się, co jest przyczyną tego, że takie prawo w ogóle powstało i przed czym chroni inwestora. W szczególności polecam ostatni punkt.
Rozdział 3. Prawa i obowiązki uczestników procesu budowlanego. Artykuł 17-27
Dział: Prawo budowlane
Art. 17. Uczestnikami procesu budowlanego, w rozumieniu ustawy, są:
1) inwestor;
2) inspektor nadzoru inwestorskiego;
3) projektant;
4) kierownik budowy lub kierownik robót.
[…]Art. 18. 1. Do obowiązków inwestora należy zorganizowanie procesu budowy, z uwzględnieniem zawartych w przepisach zasad bezpieczeństwa i ochrony zdrowia, a w szczególności zapewnienie:
1) opracowania projektu budowlanego i, stosownie do potrzeb, innych projektów,
2) objęcia kierownictwa budowy przez kierownika budowy,
[?]Art. 20. 1. Do podstawowych obowiązków projektanta należy:
1) opracowanie projektu budowlanego w sposób zgodny z ustaleniami określonymi w decyzji o warunkach zabudowy i zagospodarowania terenu,
[?]
4) sprawowanie nadzoru autorskiego na żądanie inwestora lub właściwego organu [?]
[?]
Art. 22. Do podstawowych obowiązków kierownika budowy należy:
1) protokolarne przejęcie od inwestora i odpowiednie zabezpieczenie terenu budowy wraz ze znajdującymi się na nim obiektami budowlanymi, urządzeniami technicznymi i stałymi punktami osnowy geodezyjnej oraz podlegającymi ochronie elementami środowiska przyrodniczego i kulturowego;
2) prowadzenie dokumentacji budowy;Art. 24. 1. Łączenie funkcji kierownika budowy i inspektora nadzoru inwestorskiego nie jest dopuszczalne.
[?]
Miałem kiedyś przyjemność pracować w bardzo pouczającym międzynarodowym projekcie mającym na celu wdrożenie dużego systemu IT. Dla mnie, osoby z Polski, mającego doświadczenie i spostrzeżenia z „lokalnego podwórka IT” niesamowite było to, jak bardzo oddzielano grubą kreską etap analizy od kolejnych działań projektowych. Co więcej, warunkiem koniecznym wystartowania jakiego kolwiek projektu było przedstawienie sponsorowi/inwestorowi obecnego modelu realizacji danego procesu biznesowego i oczekiwanego modelu procesu po wdrożeniu wymaganego oprogramowania/funkcjonalności. W zależności od kraju modele te były tworzone wewnątrz organizacji lub zlecane zewnętrzym firmą.
Przyznam, że znam to z nie tylko z literatury (ale mam tu na myśli książki pisane przez „praktyków na emeryturze”) czy kuluarowych rozmów na konferencjach. Spotkałem się z tym kilka razy, pracując razem albo „po” „ludziach z zachodu”. Tam każdy kolejny etap pracy był dowodem słuszności rozpoczynania następnego. Swego czasu pewien niemiecki konsultant powiedział mi: „nie planuje wyłącznie ten kto nie rozumie tego co robi lub rozumie i boi się ujawnienia (niekorzystnych dla siebie) kolejnych etapów planu”.