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.).

Katastrofa_budowlana

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.
[?]

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Sławomir Niemiec

    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ą.

    1. Jarek Żeliński

      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”.

Możliwość dodawania komentarzy nie jest dostępna.