Jakiś czas temu pisałem o swoich przemyśleniach po rozmowie z pewnym dyrektorem finansowym jednego z moich klientów. Powiedział między innymi, że albo projekt zostanie zrealizowany w roku jednym budżetowym, albo on nie wyda na zgody na jego rozpoczęcie. W czym problem? Ano w tym, że przy obecnym tempie zmian na rynku, prognoza wykraczająca w przyszłość dalej niż rok to wróżenie z fusów… Skutek? Jak ocenić stopę zwrotu z inwestycji w coś, co jest najbardziej płynnym, podatnym na zmiany wymagań, zasobem w organizacji, czyli system wspomagający zarządzanie nią?

Rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego ?super systemu? ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci ?gotowej? tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. (czytaj  Biznes wychodzi z objęć systemu ? monolitycznego ERP).

Co z tym zrobić? Dzielić, jak to mawiają niektórzy kierownicy projektów: człowiek może zjeść nawet słonia, jak? Kęs po kęsie. Tak więc duży projekt należy podzielić na “samodzielne” podsystemy, jednak ta samodzielność ma dwa aspekty: każdy podsystem musi sam z siebie do czegoś służyć, powinien wnosić wartość dodaną. Drugi: każdy projektowany podsystem powinien być zaplanowany jako potencjalnie samodzielne narzędzie (inwestycja) na wypadek gdyby pozostałe nie zostały nigdy wytworzone np. z powodu zmian na rynku.

Ale o tym pisałem więcej już wcześniej. Kolejnym problemem jest niestety jakość projektowania:

Według firmy analitycznej Gartner około 60 proc. wdrożeń wielkich systemów informatycznych kończy się klęską. Przyczyną jest m.in. nieumiejętność przełożenia procesów działających w firmie na działanie systemu informatycznego, brak dostatecznego wsparcia ze strony pracowników i kierownictwa firmy (czasem nawet jawny opór), złe przygotowanie wdrożenia lub jego prowadzenie. (za Serwis Nauka w Polsce – PAP SA).

Jak widać, jakość projektowania jest kluczem, zresztą nie tylko w przypadków dużych systemów ale w każdym przypadku. Różnica jest taka, że jeżeli niejedna firma świadomie ryzykuje kilkaset tysięcy rezygnując z etapu niezależnej analizy i projektowania wartej ok. 10-20% tej kwoty, to podobne podejście projekty warte milionów  jest już raczej nieracjonalne…

Po raz kolejny już sprawdza się teza, że wdrażanie jednego wielkiego ERP integrującego “wszystko” jest mrzonką… praktyka pokazuje, że kilka systemów dziedzinowych, zintegrowanych ze sobą jest po pierwsze mniej ryzykowne a po drugie, paradoksalnie, tańsze.

Tak więc: jak dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że ?z kompletu? przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ? ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża). (Nigdy więcej ERP w jednym kawałku!).

Raport z Badania polskich projektów informatycznych 2010

Na stronie PMResearch.pl pojawiło się ciekawe badanie  Raport zawiera rezultaty analizy 80 starannie wyselekcjonowanych projektów IT. Wyniki prezentuje w zwięzły, syntetyczny sposób. Pobierz raport (za Informacje o wynikach badania polskich projektów informatycznych).

Wyniki badania bardzo polecam, uczą pokory. Pytanie moje do autorów: jak zdefiniowano metodykę Agile? Pobieżna nawet “badanie” zasobów w Internecie pokazuje, że nie istnieje jedna definicja tego “podejścia”. Na stronie agilemanifesto.org czytamy:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie,

odkrywamy lepsze sposoby wykonywania tej pracy.

W wyniku tych doświadczeń przedkładamy:

 Ludzi i interakcje ponad procesy i narzędzia.

Działające oprogramowanie ponad obszerną dokumentację.

Współpracę z klientem ponad formalne ustalenia.

Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie,

jednak bardziej cenimy to, co po lewej.

Można by odnieść wrażenie, że ignorowane jest wszystko co nakazuje rozsądek (pogrubienie moje). Paradoksalnie, obserwując projekty, mam wrażenie, że zwinność jest jednak często inaczej rozumiana, nie jako ignorowanie “złotego trójkąta” projektowego (zakres, termin, budżet). Ja w każdym razie zawsze pytam: czym jest tu Agile. Niestety słyszę nie raz, ze “tego się nie definiuje”… co wywołuje u mnie odruch “nie definiuje się zakresu projektu” a to prowadzi do wniosku, że sukcesem jest sam fakt rozpoczęcia projektu…