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…
Nie rozumiem dlaczego zatrzymujesz się ciągle na pierwszej stronie agilemanifesto. Agile to nie metodyka, tylko właśnie podejście. „Ponad” nie znaczy odrzucenia prawej strony, tylko wzmocnienie lewej, do tej pory (przed 2001) niedocenianej. Do tego manifest powstał jako uzgodniona część wspólna wielu różnych rozwiązań.
Moje obserwacje są w zgodne z Twoimi, organizacje wykorzystują plakietkę agile, aby zacząć odkrywać siebie na nowo, czasem przechodząc przez etap chaosu. To nie znaczy jednak, że sama idea jest nieracjonalna.
Dlaczego zatrzymuje się na pierwszej stronie Manifestu? Bo tam nic innego już nie ma…:(
Mi chodzi właśnie o to, że ten chaos jest niestety najczęściej spotykany… po drugie z perspektywy nabywców „odkrywanie” siebie przez firmę informatyczną powinno być kosztem tej firmy a nie kosztem kupującego… Co do „Ponad…” w 100% znanych mi przypadków zaskarżenia nierzetelnego wykonawcy do sądu, problemem był brak opisu tego co miało powstać dlatego większość tych sprawa kończyła się niestety niekorzystnie dla firm, które wydały swoje środki i nie otrzymując działającego oprogramowania. Osławione „klient nie wie czego chce” to czysta manipulacja firm developerskich, idąc do lekarza też „nie wiem czego chcę” (bo nie wiem na co choruję i jakie leki dostanę) ale wiem że chcę wyzdrowieć i lekarz podejmujący się leczenia bez badań analitycznych podający leki „na próbę, może coś zadziała” jest gorszy od znachora.
Postaraj się mnie zrozumieć, prawie 100% przypadków gdy jestem angażowany (ktoś w końcu ma budżet, o ile jeszcze go ma, na rzetelne analizy i projektowanie) to krajobraz po bitwie o rynkowej nazwie „Agile”, mam prawo nie wierzyć w „skuteczny chaos”.
Jeżeli tą ideą nazwiemy to, że każdy projekt jest inny, uznamy za bezsensowne tworzenie dokumentów które w danym przypadku do niczego nie służą ale są tworzone puste spisy treści bo wymaga tego „jakaś metodyka”, to ja także jestem za, jestem Agile, ale nigdy nie pominę etapu analizy problemu i projektowania rozwiązania… bo to jak wyjść w góry bez mapy a prognozę pogody poznać dopiero z własnej obserwacji… tak się robi raczej godzinne spacery blisko domu.
Wychodzę z założenia, że w większości tematów zgadzamy się. Strona manifestu nie zawiera wiele więcej, zakładam że umyślnie, po to żeby nie wchodzić w szczegóły, które nie do wszystkich pasują. Zwróć uwagę na kierunek powstania manifestu. To nie było tak, że najpierw powstał manifest, a potem metody pracy na nim oparte. Manifest jest syntezą wniosków z wcześniejszych lat doświadczeń.
Rozumiem, że w Twojej pracy znajomość agile może nie być konieczna. Jednak możesz użyć takiej wiedzy jako oręża w rozmowie z firmą, która deklaruje robienie projektów zgodnie z agile:
– domagając się transparencji metod pracy
– domagając się stabilnego procesu wytwórczego, pozwalającego na ocenę postępów pracy
– oczekując stabilnego kosztu zmiany wprowadzanej do systemu
– oczekując optymalizacji parametrów współpracy, które obie strony uznają za wymagające poprawy
– oczekując monitorowania ryzyk i informowania szybkiego informowania o zagrożeniach dla celów projektu
O, to jest to co robię i to czego oczekuję :), jeżeli do tego dodamy, że praca ma mieć przed jej rozpoczęciem: budżet, termin i zakres to jesteśmy w domu :). Być może zgadzamy się w 100% a problemem jest to, że słowo Agile po protu nie ma definicji (manifest to nie definicja… ale o czymś mówi).
Praca ma mieć budżet, termin i cele. Oraz powinna być ciągle monitorowana pod kątem stopnia osiągania celów. Używając Twojej analogii z lekarzem: przychodzisz nie dlatego że wiesz co lekarz ma zrobić, ale dlatego, że wiesz czego nie chcesz.
Jeżeli masz na starcie zdefiniowany zakres razem z budżetem i terminami, to masz projekt prosty albo skazany na niepowodzenie. Przez „prosty” rozumiem też projekt w którym rozwój oprogamowania nie jest głównym tematem, a trudności polegają na pogodzeniu interesów kilku interesariuszy. Trudny projekt, to taki, który wiesz jak zrobić dopiero po zakończeniu, albo dopiero po następnym projekcie.
Dotknęliśmy pewnego przemilczenia: każdy nietrywialny projekt powinien mieć dwie fazy: analiza i projektowanie (to w sumie praca badawcza) zakończone studium wykonywalności i implementacja. Faza „badawcza” jest bardzo zwinna ale też nie polega na tym, że „pracujemy aż skończymy”.
Biznesowo:
1. mam problem, jego rozwiązanie przyniesie firmie oszczędności milion zł w ciągu roku, zakładam zwrot inwestycji w ciągu roku więc budżet to 1 mln., termin realizacji 1 rok.
2. pierwsze pytanie, czy problem da się rozwiązać i jak, na to przeznaczam 100 tys. powstaje analiza i projekt (na uzgodnionym poziomie abstrakcji)
3. wyceniam implementację (w założonym czasie), jeżeli jej koszt wykracza poza 900 tys, zmieniam zakres lub całkowicie odrzucam projekt.
4. ryzykuję 100 tys. ratując potencjalnie pozostałe 900 tys. nie podejmuje projektu utopienia z nieznanym ryzykiem całego miliona.
Biznes ma twarde reguły, nie ma projektów „zaczynamy i zobaczymy co wyjdzie”, tak pracuje co najwyżej dział R&D albo PAN w grantach na badania podstawowe.