Jak dobrze przygotować się do projektu aby nie wpaść w spirale kosztów?
WPROWADZENIE
Każdy kolejny rok to kolejne rozpoczynane projekty wdrożeniowe, ale także i kolejne zakończone wdrożenia systemów informatycznych (system). Warto podkreślić, że zakończone wdrożenie nie zawsze oznacza zrealizowany planowany zakres wdrożenia (31% projektów tak się kończy). Zakończone wdrożenie to także bardzo często przerwane wdrożenie (19% projektów) [patrz: Henry Portman, Review Standish Group ? CHAOS 2020: Beyond Infinity, Henny Portman’s Blog – On Portfolio, Programme and Project Management, 06.01. 2021]. Uważam, że właśnie te przerwane projekty powinny być podstawowym wyznacznikiem planowania kolejnych projektów.
Najczęściej, jako główne powody porażek projektów wdrożeniowych podaje się brak zainteresowania ze strony sponsora oraz źle określone wymagania. Kluczem jednak wydaje się to ostatnie. Słownik Języka Polskiego tak definiuje to pojęcie wymaganie: warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać. Pojęcie warunek zaś jako: (we wnioskowaniu implikacyjnym) stan rzeczy, który musi zajść, aby mógł zaistnieć inny stan rzeczy. Innymi słowy można powiedzieć, że wymagania to zdania określające co się powinno stać aby stać mogło się coś.
I teraz kluczowe pytanie: pisząc o źle określonych wymaganiach, mamy na myśli wymagania wobec narzędzia pracy (system) czy wymagania wobec organizacji? Poprawnym wymaganiem jest “System powinien wystawiać faktury VAT” czy może “Nasza organizacja powinna podnieść efektywność i jakość wystawiania faktur sprzedaży”? Pojęcie POWINNA jest tylko rekomendacją, więc nie jest to warunek! Warunek brzmi raczej “”Nasza organizacja MUSI podnieść efektywność i jakość wystawiania faktur sprzedaży”, oczywiście o ile ktoś wcześniej uznał, że od tego coś zależy.
Wymieniono pojęcia system i organizacja. Oznacza to, że mamy wymagania wobec organizacji i wymagania wobec systemu (tu rozumianego jako narzędzie – informatyczne – wspomagające zarządzanie). To są dwa różne zestawy wymagań. Oznacza to, że tak na prawdę mamy dwa projekty: analiza organizacji i wymagań biznesowych, kończącą się Specyfikacją Wymagań Biznesowych, oraz Analiza Wymagań Wobec Rozwiązania kończąca się Specyfikacją Wymagań Wobec Rozwiązania. Na końcu pojawia się Projekt Rozwiązania. Jest nim tu nasz system. Kluczowe pytanie: kto ma zaprojektować rozwiązanie?
ZWINNA ORGANIZACJA
Kto powinien być agile czyli zwinny i co to znaczy? Podstawowe znaczenie słowa zwinny (s.j.p.) to: wykonujący szybkie, zręczne ruchy. Jeżeli użyć tego słowa wobec podmiotów na rynku, to można się domyślać, że chodzi o zachowania rynkowe.
Andrzej Olak w podsumowaniu swojej publikacji [patrz: Organizacja zwinna – wyznaczniki oraz kierunki strategii prowadzące do zwinności przedsiębiorstwa, E-mentor nr 1 (68) / 2017] pisze: “Zwinność można określić jako zdolność organizacji do szybkiej odpowiedzi na zmiany zachodzące w środowisku biznesowym oraz do proaktywnych działań prowadzących do wykorzystania okazji płynących z rynku. Analiza literatury naukowej uprawnia do sformułowania następujących wniosków:
- badacze piszą o różnych wyznacznikach zwinnej organizacji, jednak każde z tych ujęć akcentuje takie atrybuty organizacji, jak szybkość i elastyczność,
- naukowcy są zgodni, że przedstawione przez nich wyznaczniki zwinności powinny pozostawać we wzajemnym sprzężeniu,
- tylko wszystkie razem zintegrowane składowe prowadzą do zwinności,
- nie można mówić o zwinności bez nawiązywania relacji międzyorganizacyjnych przez przedsiębiorstwo.”
Jednym zdaniem: zwinna organizacja to taka, która potrafi natychmiast reagować na zmiany otoczenia rynkowego. Pojawia się kolejne pytanie: co tu znaczy natychmiast? Jeszcze kilka lat temu dyrektorzy finansowi moich klientów mówili, że na rynek reagują w kolejnych budżetach, czyli w cyklu rocznym. Następnie, że korygują budżety w cyklu kwartalnym. Niedawno jeden z klientów zażądał produktu (oprogramowanie dla nowej usługi) w trzy tygodnie! (udało się). System w trzy tygodnie?
W 2012 roku pisałem: “Podstawowym błędem, moim zdaniem, jest traktowanie zakupu lub wytworzenia oprogramowania planowanego na ?długie używanie? jako projektu programistycznego. To nie projekt, to program! Projektem jest wytworzenie pierwotnej wersji, potem projektami są kolejno wprowadzane nowe funkcjonalności lub zmiany. Całość to program.” [patrz: Jarosław Żeliński, ?Znaczenie ma nie wielkość projektu, a cykl jego życia?,? 5 marca 2012]. Cóż to znaczy? To znaczy, że
system nie może ograniczać zwinności organizacji. To w konsekwencji oznacza, że system powinien pozwalać na wprowadzanie do niego zmian w terminach rzędu pojedynczych miesięcy!
Cztery lata temu pisałem: “Rynek zmienia się szybko, więc nie ma sensu szczegółowe projektowanie czegokolwiek z uwagi na czas jaki zajmie takie projektowanie i ryzyko, że taki projekt stanie się szybko nieaktualny. Nikt rozsądny nie namawia dzisiaj do czegoś o wdzięcznej nazwie ?waterfall?. Co więc zrobić? Dla dużych projektów tworzymy architekturę, opisujemy mechanizmy działania, politykę rozbudowy i opis cyklu życia. Czyli to co pozwoli rozwijać rozwiązanie metodą iteracyjno-przyrostową, w razie potrzeby pozwoli na przeprojektowanie, ale jako całość nadal będzie spójne, nie będzie wymagało wymiany całości gdy zmienią się warunki na rynku.” [patrz: Jarosław Żeliński, ?Wymagania umarły. Rozwiązaniem jest cykl życia produktu,? 13 stycznia 2017,]. Tak więc problemem, jest rozwiązanie (tu system) i jego architektura. Kluczową jego cechą musi być możliwość wprowadzania zmian, czyli także rozbudowy, w ciągu miesiąca, a nie raz pojedynczych tygodni.
KOSZTY CZYLI CO I JAK CIĄĆ
Oprogramowanie ma trzy podstawowe składniki kosztowe:
- środowisko czyli platforma sprzętowo-systemowa: niezbędne licencje i ich utrzymanie,
- bieżące koszty pracy ludzkiej związanej z administracją platformy,
- koszty pracy związanej z rozbudową funkcjonalności.
Oprogramowanie, jako konkretne aplikacje, to albo tak zwane produkty seryjne “z półki” (ang. commercial off the shelf, COF) albo dedykowane, czyli wytworzone dla konkretnej organizacji w celu rozwiązania określonego problemu (spełnienia określonych wymagań).
Jak zapewne czytelnik nie raz słyszał, ceny oprogramowania COF są “niskie” z powodu efektu skali (masowa produkcja). Słowo niskie świadomie umieściłem w cudzysłowie, gdyż wielu producentów oprogramowanie stosuje metody wyceny oparta na “success fee” czyli “udziału w korzyściach” (ceny na rynku usług to materiał na osobny artykuł). Tu ograniczymy się jedynie do faktu, że koszty wytworzenia i rozwoju oprogramowania COF rozkładają się na wszystkich jego użytkowników (z reguły są ich są co najmniej setki), koszty wytworzenia dedykowanego oprogramowania ponosi w całości jeden zamawiający.
Jakie wnioski płyną z powyższego? Ideałem jest sytuacja, w której wymagania spełni dostępne na rynku oprogramowanie. Jednak dorobkiem wielu firm jest własny, wypracowany mechanizm funkcjonowania, dający przewagę nad konkurencją, a to (rozwiązanie spełniające wymagania) wymaga dedykowanego komponentu.
Mamy więc sytuację, w której:
- otoczenie rynkowe zmienia się nawet w cyklach kwartalnych,
- w tak krótkim okresie możliwe jest opracowanie jednej, tak zwanej usługi aplikacyjnej lub zmiana istniejącej,
- im większa, realizująca więcej usług, aplikacja tym więcej czasu i pracy wymaga wprowadzanie do niej zmian (czyli koszt modyfikacji oprogramowania jest proporcjonalny do jego wielkości).
Wnioski do co kosztów nasuwają się takie:
- jeżeli to tylko możliwe, należy unikać jakichkolwiek dedykowanych rozwiązań, stosować je tylko gdy na prawdę jest to konieczne,
- żadne wdrożenie nie powinno trwać dłużej niż rok, ideałem jest kwartał (to jest możliwe),
- krótkie wdrożenia to mały ich zakres, należy więc wdrażać małe zestawy dziedzinowych funkcji (usług aplikacyjnych),
- duże systemy, czyli obejmujące znaczne obszary organizacji, należy planować jako wieloetapowe projekty (programy), wtedy jednak należy opracować strategię informatyzacji całości organizacji, standaryzację informacji i tak zwaną “architekturę wysokiego poziomu”, takie wdrożenia powinny się jednak mieścić w okresie 3 lat.
Warto tu zwrócić uwagę na to, że audyt kończący się listą wymagań biznesowych to kwartał. Opracowanie projektu technicznego rozwiązania, to praktycznie zawsze w ok. 20% dedykowane rozwiązanie, łączna pracochłonność to też kwartał. Te okresy nie wynikają jednak z wielkości organizacji. Te kwartalne okresy to dopasowanie się do zmian na rynku. Innymi słowy zakładamy np. kwartał na analizę biznesową, a dopiero w drugiej kolejności dostosowujemy jej szczegółowość tak, by był to tylko kwartał.
Czy to wodospadowe podejście? Nie, to jest podejście iteracyjno-przyrostowe. Poprzedzanie zaś każdego etapu implementacji projektowaniem, chroni przed znacznie kosztowniejszym prototypowaniem (koszty pracy zespołu developerskiego są wyższe niż koszt pracy jednego projektanta).
Kolejne pytanie: monolityczny system od jednego dostawcy, wdrażany etapami, czy dziedzinowe dedykowane podsystemy kupowane i ich integracja? Wdrożenia kompleksowe (znaczna część organizacji) trwają znacznie ponad rok, a jak wspomniano na początku, najdłuższym okresem względnej stabilności planów jest rok budżetowy.
PODSUMOWANIE
Patrząc na opis sytuacji we Wprowadzeniu, opis warunków funkcjonowania organizacji Zwinnej oraz na Koszty, wniosek nasuwa się dość oczywisty: należy dzielić duże projekty na mniejsze. W znakomitej większości przypadków rok budżetowy to zbyt krótko na duży monolit. W efekcie pytanie nie brzmi czy dzielić, ale jak dzielić zakres projektu. Przypominam, że wymagania to warunki a te się zmieniają, więc w świetle tego napisano, nie mamy możliwości spisania specyfikacji wymagań na duże projekt. Co nam pozostaje? Skupić się na strategii i uznać, że to jednak cykl życia systemu jest kluczem, a nie jego – niemożliwa do opracowania – dokładna specyfikacja.
Każda zła decyzja to dodatkowy koszt. Co możemy więc zrobić? Odkładać decyzje na “ostatni moment”. Jaki więc system wybrać? taki, który na to pozwala. Bo to co opisałem to także wymaganie: system powinien pozwalać na etapowe wdrożenie bez narzucania z góry kolejności wdrożenia poszczególnych modułów oraz bez obowiązku wdrożenia wszystkich, planowanych na początku projektu modułów.
(Artykuł ukazał się w raporcie Perspektywy ERP 2021 na portalu ERP-View, w lutym 2021, zawierającym także prognozy prezentowane przez menedżerów czołowych dostawców systemów ERP. )
