Wszystkie teksty umieszczane na Linkedin lub naszych stronach internetowych są naszą opinią. Prosimy nie traktować ich jako porady prawnej w konkretnej sprawie, ponieważ konkretna sprawa zawsze wymaga indywidualnej analizy.
Wdrożenia systemów informatycznych to zdecydowanie jedne z najbardziej skomplikowanych przedsięwzięć w branży IT. Ta oczywista oczywistość znajduje swoje potwierdzenie chociażby w kosztach związanych z realizacją wdrożeń oraz skalą ryzyka wynikającą z ewentualnego niepowodzenia projektów wdrożeniowych.
Dla każdego, kto choć raz brał udział w tego rodzaju przedsięwzięciu, nie stanowi już zaskoczenia długość prowadzonych – w ramach wdrożeń – negocjacji, czy grubość dokumentacji towarzyszącej projektowi wdrożeniowemu. Z tych samych względów, wdrożenia informatyczne stosunkowo rzadko kończą się pełnym sukcesem.
Jak wynika z publikowanego przez The Standish Group raportu za rok 2013 tylko 39% wdrożeń IT zostało pomyślnie zrealizowanych, jednocześnie 18% zakończyło się całkowitą klęską, a aż 43% zostało zrealizowanych z tzw. problemami (przekroczony budżet, przekroczony harmonogram, rezultat końcowy nieodpowiadający wymaganiom).
Skutki takich nieudanych lub problematycznych wdrożeń najlepiej pokazać na konkretnych przykładach oraz towarzyszących im liczbach, które w sposób najbardziej dosadny, żeby nie powiedzieć drastyczny, przemawiają do naszej wyobraźni.
Pierwszy przykład to absolutny światowy rekord w skali kosztów poniesionych w związku z nieudanym wdrożeniem informatycznym.
Rzecz dotyczy rozwiązania o nazwie Lorenzo, wdrażanego na zamówienie National Health Service (NHS) – związku systemów służby zdrowia Wielkiej Brytanii, finansowanych ze środków publicznych. Realizowany przez niemal 10 lat projekt, którego celem było polepszenie warunków świadczenia usług medycznych dla pacjentów, poprzez m.in. usprawnienie obiegu dokumentacji medycznej pomiędzy placówkami, zakończył się całkowitym fiaskiem. Zanim to się jednak stało, zdążył wydrenować kieszeń angielskiego podatnika na kwotę 12 miliardów GBP (odpowiednio: 19.413.360.665,62 USD, 64.398.000.000,00 PLN (!)). Dość powiedzieć, że koszty poniesione w związku z nieudanym wdrożeniem pozwoliłyby na wypłatę wynagrodzenia dla 60 tysięcy angielskich pielęgniarek przez okres 10 lat, albo pokrycie (i to podwójnie) kosztów interwencji i stacjonowania wojsk angielskich w Iraku i Afganistanie.
Kolejne przykłady związane są z jednym z najbardziej magicznych miejsc na Ziemi, a mianowicie z Nowym Yorkiem.
Pierwszy z nich to system informatyczny New York City Automated Payroll System, nad którym prace wystartowały jeszcze w 1999 r., a planowana data startu produkcyjnego została wyznaczona na rok 2011. Systemu nie uruchomiono do dzisiaj, a planowany pierwotnie budżet w wysokości 66 mln. USD zdążył osiągnąć pułap 360 mln. USD, ponad 5,5 krotnie przewyższając początkowe założenia.
Drugi z przykładów dotyczy systemu CityTime, kolejnej klęski wdrożeniowej, która przed ostatecznym fiaskiem, zdążyła pochłonąć 10 lat pracy oraz ponad dziesięciokrotnie przewyższyć pierwotnie planowany budżet, sięgając ostatecznie kwoty w wysokości 700 mln. USD, wobec początkowo planowanych 63 mln. USD. To właśnie w efekcie tych porażek, władze miasta Nowego Yorku wydały uchwałę, zgodnie z którą, w każdym przypadku, w którym realizacja projektu IT przekroczy o 10% zakładany pierwotnie budżet, kierownictwo projektu ma obowiązek natychmiastowego poinformowania o tym fakcie Radę Miasta Nowego Yorku.
Ostatni przypadek, jest – o ironio – związany z wymiarem sprawiedliwości i właśnie dlatego, zważywszy na kontekst tego artykułu, nie mógł nie pojawić się w tym zestawieniu. Tym razem rzecz dotyczy kalifornijskiego systemu sądowniczego, którego kierownictwo zamówiło wdrożenie systemu informatycznego mającego na celu poprawę jakości działań administracyjnych, usprawnjących zwykłemu Johnowi Smithowi niełatwe co do zasady zetknięcie się z trybami wymiaru sprawiedliwości. Pomimo szlachetnych pobudek oraz wysokiej rangi zamawiającego projekt zakończył się całkowitą klęską. Nim to się jednak stało, zdążył wyciągnąć z kieszeni kalifornijskiego podatnika kwotę w wysokości 643 mln. USD, czyli o 50% większą wobec początkowo planowanej w budżecie.
W obliczu tych ryzyk rola prawnika w projektach wdrożeniowych często sprowadza się do pytania, co mogę zrobić, aby klienta przed tymi ryzykami uchronić. Odpowiedź na to pytanie zależy jednak w dużej mierze od wybranego modelu (metodologii) w jakim dane wdrożenie będzie realizowane, bo te właśnie modele w sposób zasadniczy wpływają na rodzaj, zakres oraz prawdopodobieństwo wystąpienia ryzyk związanych z realizacją projektów wdrożeniowych. Zanim więc o roli prawnika, przyjrzyjmy się dwóm konkurującym ze sobą modelom realizacji projektów IT.
Generalnie rzecz biorąc, metodologia realizacji projektów wdrożeniowych w modelu Waterfall sprowadza się do założenia, że spodziewany końcowy rezultat wdrożenia jest precyzyjnie opisany już na samym jego początku. Przyjmujemy za pewnik, że w przygotowanej analizie przedwdrożeniowej przewidziane zostały między innymi wszystkie wymagania, funkcjonalności oraz parametry techniczne niezbędne dla powodzenia projektu. Innymi słowy, już na samym starcie wiemy dokładnie, co będzie na mecie.
Umawiamy się również, że to, co chcemy uzyskać będzie realizowane w wyraźnie odrębnych, kaskadowo (stąd Wodospad) po sobie następujących etapach:
Planowanie › analiza › wytworzenie kodu › testy › wdrożenie/start produkcyjny.
Warto dodać, że poza tym, że wiemy „co” i „kiedy”, najczęściej wiemy też „za ile”. W zasadzie więc wiemy wszystko, co prawnikowi do szczęścia potrzeba. A zatem w czym problem … Po kolei.
Miał rację Steve Jobs, który pojawi się jeszcze na łamach tego cyklu, kiedy twierdził, że ludzie nie wiedzą czego chcą, dopóki tego nie zobaczą. Wyobraźmy sobie naszą reakcję, gdyby jakiś czas temu ktoś nam powiedział, że wszystko czego potrzebujemy do szczęści,a to coś co jest trochę większe od naszego telefonu i trochę mniejsze od naszego laptopa, aaa i dodatkowo nie można z tego do nikogo zadzwonić. Cóż, wyniki sprzedaży iPada zdają się mówić same za siebie. Kiedy już go zobaczyliśmy, część z nas zaczęła zadawać sobie pytanie natury czysto egzystencjalnej – czym było moje życie bez iPada? Inni zaczęli traktować jego zakup jako wyraźną cenzurę na życie przed i po zakupie urządzenia firmy Apple.
Podobny przykład związany jest z legendarnym Henrym Fordem, który z właściwym sobie poczuciem humoru stwierdził, że gdyby na początku swojej kariery zapytał klientów, czego chcą, wszyscy byliby zgodni: chcemy szybszych koni. Więc ich nie pytałem – dodał Ford.
Te dwa przykłady wydają się być dobrą ilustracją dla tezy, że „to” czego naprawdę chcemy, wiemy dopiero wtedy kiedy „to” zobaczymy.
Pierwsze kontrakty dla wdrożeń informatycznych realizowanych w modelu Waterfall powstały już na początku lat 80-tych ubiegłego stulecia. Jednocześnie sama metodologia sekwencyjnej, kaskadowej realizacji projektów informatycznych czerpie swoje założenia jeszcze z czasów Rewolucji Przemysłowej i właściwych tym czasom metodom produkcji, których piewcami byli wspominany już wcześniej Henry Ford czy Frederick Taylor.
To jasne, że 30 lat, jakie dzielą nas aktualnie od lat 80-tych ubiegłego stulecia, to lata świetlne w kontekście rozwoju rynku IT i rozwiązań informatycznych. Co więcej, sama dynamika i szybkość z jaką te zmiany następują, jest obecnie o niebo większa, niż chociażby w latach 90-tych ubiegłego stulecia. Nie zanosi się na to, aby ten trend miał się zmienić.
Czym to skutkuje?
Mianowicie tym, że to co sobie na początku projektu ustaliliśmy w zakresie wymagań lub funkcjonalności projektowanego rozwiązania, może się, ze względu na średni czas realizacji wdrożenia, kompletnie rozmijać z realnymi potrzebami biznesowymi zamawiającego.
Zgodnie z ostatnimi badaniami przeprowadzonymi przez Uniwersytet Missouri pod kierownictwem prof. Ala Goernera, coraz szybsze tempo rozwoju technologicznego skutkuje coraz wyższym współczynnikiem erozji wymagań zawartych w analizie przedwdrożeniowej pomiędzy etapem ich ustalenia a faktyczną implementacją.
Badacze z Uniwersytetu Missouri analizując stopień erozji (dezaktualizacji) analizy przedwdrożeniowej wykorzystali pojęcie tzw. czasu połowicznego zaniku (z ang. half-life), jakie odnosi się do średniego czasu, po jakim aktywność izotopu promieniotwórczego spada do połowy swojej początkowej wartości. Innymi słowy, pozwala to zmierzyć, po jakim czasie połowa zawartych w analizie przedwdrożeniowej ustaleń przestanie być aktualna. I tak, o ile w latach 80-tych ubiegłego stulecia half-life analizy przedwdrożeniowej wynosił 10-12 lat, to w roku 2000 wynosił już tylko 2-3 lata, aby obecnie spaść do 6 miesięcy. Tym samym połowa wymagań objętych analizą dezaktualizuje się już po 6 miesiącach, połowa z pozostałej połowy stanie się nieaktualna jeszcze przed upływem 12 miesięcy, połowa z pozostałej już ćwiartki będzie nic nie warta zanim skończy się 18 miesiąc od startu projektu, i tak dalej. Wygląda zatem na to, że nim przekroczymy 18 miesiąc od daty sporządzenia analizy przedwdrożeniowej, tylko 12,5% jej zawartości pozostanie w dalszym ciągu aktualna.
Wygląda na to, że w obecnych realiach rynkowych (ultra szybka dynamika rozwoju technologicznego) oraz właściwych dla gatunku homo sapiens cechach poznawczych (wiem co chcę dopiero, jak to zobaczę) kurczowe trzymanie się metody kaskadowej we wdrożeniach informatycznych, może w optymistycznym scenariuszu pozwolić nam na uzyskanie tego, co (teoretycznie) chcemy i co oczywiście wcale nie musi być tym, czego akurat właśnie potrzebujemy (o tym dalej), w najgorszym zaś scenariuszu doprowadzi do fiaska projektu, gigantycznych kosztów, procesów sądowych i masy nerwów.
A co mówią statystyki?
Ponad połowa (51,8%) przypadków, w których wdrożenie nie zostało zrealizowane albo zostało zrealizowane z problemami to niewłaściwa lokalizacja wymagań zawarta w analizie przedwdrożeniowej lub zmiana potrzeb zamawiającego w trakcie realizacji wdrożenia. Na koniec warto podać przykład, który z matematyczną precyzją ilustruje i obnaża wady metodologii sekwencyjnej. Przypadek dotyczy Departamentu Obrony USA, który w samym tylko 1995 roku wydał na zakup IT kwotę rzędu 35,7 miliardów USD. Jak jednak wykazał przeprowadzony audyt, okazało się, że jedynie 2% zakupionych rozwiązań IT nadawało się do wykorzystania. 75% zakupionej technologii – w konsekwencji źle przeprowadzonej analizy lub zmieniających się w toku wdrożenia potrzeb zamawiającego – okazało się całkowicie bezużyteczne. Pozostałe 23% zakupionych rozwiązań zostało podanych gruntownym modyfikacjom przed ich produkcyjnym zastosowaniem. Odwołując się zatem do żargonu wojskowego, zaledwie 750 mln USD stanowiło trafiony wydatek, w pozostałej zaś części (niemal 35 miliardów USD) Departament Obrony istotnie przestrzelił.
Zatem wydaje się, że leżąca u samych podstaw modelu Waterfall zasada, zgodnie z którą przed rozpoczęciem procesu produkcyjnego powinniśmy precyzyjnie określić jego końcowy rezultat, jest zakodowanym w proces wdrożeniowy wirusem generującym realne ryzyka, o trudnych do przecenienia konsekwencjach.
O tym, jak Agile odpowiedział na sygnalizowane powyżej problemy i jak to przełożyło się na konstrukcję umów wdrożeniowych oraz rolę prawnika w projektach informatycznych, już w następnym artykule.