Jak dobrze przy­go­to­wać się do pro­jek­tu aby nie wpaść w spi­ra­le kosztów?

WPROWADZENIE

Każdy kolej­ny rok to kolej­ne roz­po­czy­na­ne pro­jek­ty wdro­że­nio­we, ale tak­że i kolej­ne zakoń­czo­ne wdro­że­nia sys­te­mów infor­ma­tycz­nych (sys­tem). Warto pod­kre­ślić, że zakoń­czo­ne wdro­że­nie nie zawsze ozna­cza zre­ali­zo­wa­ny pla­no­wa­ny zakres wdro­że­nia (31% pro­jek­tów tak się koń­czy). Zakończone wdro­że­nie to tak­że bar­dzo czę­sto prze­rwa­ne wdro­że­nie (19% pro­jek­tó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 prze­rwa­ne pro­jek­ty powin­ny być pod­sta­wo­wym wyznacz­ni­kiem pla­no­wa­nia kolej­nych projektów. 

Najczęściej, jako głów­ne powo­dy pora­żek pro­jek­tów wdro­że­nio­wych poda­je się brak zain­te­re­so­wa­nia ze stro­ny spon­so­ra oraz źle okre­ślo­ne wyma­ga­nia. Kluczem jed­nak wyda­je się to ostat­nie. Słownik Języka Polskiego tak defi­niu­je to poję­cie wyma­ga­nie: waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpo­wia­dać. Pojęcie waru­nek zaś jako: (we wnio­sko­wa­niu impli­ka­cyj­nym) stan rze­czy, któ­ry musi zajść, aby mógł zaist­nieć inny stan rze­czy. Innymi sło­wy moż­na powie­dzieć, że wyma­ga­nia to zda­nia okre­śla­ją­ce co się powin­no stać aby stać mogło się coś.

I teraz klu­czo­we pyta­nie: pisząc o źle okre­ślo­nych wyma­ga­niach, mamy na myśli wyma­ga­nia wobec narzę­dzia pra­cy (sys­tem) czy wyma­ga­nia wobec orga­ni­za­cji? Poprawnym wyma­ga­niem jest ​„System powi­nien wysta­wiać fak­tu­ry VAT” czy może ​„Nasza orga­ni­za­cja powin­na pod­nieść efek­tyw­ność i jakość wysta­wia­nia fak­tur sprze­da­ży”? Pojęcie POWINNA jest tyl­ko reko­men­da­cją, więc nie jest to waru­nek! Warunek brzmi raczej „„Nasza orga­ni­za­cja MUSI pod­nieść efek­tyw­ność i jakość wysta­wia­nia fak­tur sprze­da­ży”, oczy­wi­ście o ile ktoś wcze­śniej uznał, że od tego coś zależy. 

Wymieniono poję­cia sys­tem i orga­ni­za­cja. Oznacza to, że mamy wyma­ga­nia wobec orga­ni­za­cji i wyma­ga­nia wobec sys­te­mu (tu rozu­mia­ne­go jako narzę­dzie – infor­ma­tycz­ne – wspo­ma­ga­ją­ce zarzą­dza­nie). To są dwa róż­ne zesta­wy wyma­gań. Oznacza to, że tak na praw­dę mamy dwa pro­jek­ty: ana­li­za orga­ni­za­cji i wyma­gań biz­ne­so­wych, 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 poja­wia się Projekt Rozwiązania. Jest nim tu nasz sys­tem. Kluczowe pyta­nie: kto ma zapro­jek­to­wać rozwiązanie? 

ZWINNA ORGANIZACJA

Kto powi­nien być agi­le czy­li zwin­ny i co to zna­czy? Podstawowe zna­cze­nie sło­wa zwin­ny (s.j.p.) to: wyko­nu­ją­cy szyb­kie, zręcz­ne ruchy. Jeżeli użyć tego sło­wa wobec pod­mio­tów na ryn­ku, to moż­na się domy­ślać, że cho­dzi o zacho­wa­nia rynkowe. 

Andrzej Olak w pod­su­mo­wa­niu swo­jej publi­ka­cji [patrz: Organizacja zwin­na – wyznacz­ni­ki oraz kie­run­ki stra­te­gii pro­wa­dzą­ce do zwin­no­ści przed­się­bior­stwa, E‑mentor nr 1 (68) / 2017] pisze: ​„Zwinność moż­na okre­ślić jako zdol­ność orga­ni­za­cji do szyb­kiej odpo­wie­dzi na zmia­ny zacho­dzą­ce w śro­do­wi­sku biz­ne­so­wym oraz do pro­ak­tyw­nych dzia­łań pro­wa­dzą­cych do wyko­rzy­sta­nia oka­zji pły­ną­cych z ryn­ku. Analiza lite­ra­tu­ry nauko­wej upraw­nia do sfor­mu­ło­wa­nia nastę­pu­ją­cych wniosków: 

• bada­cze piszą o róż­nych wyznacz­ni­kach zwin­nej orga­ni­za­cji, jed­nak każ­de z tych ujęć akcen­tu­je takie atry­bu­ty orga­ni­za­cji, jak szyb­kość i elastyczność, 
• naukow­cy są zgod­ni, że przed­sta­wio­ne przez nich wyznacz­ni­ki zwin­no­ści powin­ny pozo­sta­wać we wza­jem­nym sprzężeniu, 
• tyl­ko wszyst­kie razem zin­te­gro­wa­ne skła­do­we pro­wa­dzą do zwinności, 
• nie moż­na mówić o zwin­no­ści bez nawią­zy­wa­nia rela­cji mię­dzy­or­ga­ni­za­cyj­nych przez przedsiębiorstwo.” 

Jednym zda­niem: zwin­na orga­ni­za­cja to taka, któ­ra potra­fi natych­miast reago­wać na zmia­ny oto­cze­nia ryn­ko­we­go. Pojawia się kolej­ne pyta­nie: co tu zna­czy natych­miast? Jeszcze kil­ka lat temu dyrek­to­rzy finan­so­wi moich klien­tów mówi­li, że na rynek reagu­ją w kolej­nych budże­tach, czy­li w cyklu rocz­nym. Następnie, że kory­gu­ją budże­ty w cyklu kwar­tal­nym. Niedawno jeden z klien­tów zażą­dał pro­duk­tu (opro­gra­mo­wa­nie dla nowej usłu­gi) w trzy tygo­dnie! (uda­ło się). System w trzy tygodnie? 

W 2012 roku pisa­łem: ​„Podstawowym błę­dem, moim zda­niem, jest trak­to­wa­nie zaku­pu lub wytwo­rze­nia opro­gra­mo­wa­nia pla­no­wa­ne­go na ?dłu­gie uży­wa­nie? jako pro­jek­tu pro­gra­mi­stycz­ne­go. To nie pro­jekt, to pro­gram! Projektem jest wytwo­rze­nie pier­wot­nej wer­sji, potem pro­jek­ta­mi są kolej­no wpro­wa­dza­ne nowe funk­cjo­nal­no­ści lub zmia­ny. Całość to pro­gram.” [patrz: Jarosław Żeliński, ?Znaczenie ma nie wiel­kość pro­jek­tu, a cykl jego życia?,? 5 mar­ca 2012]. Cóż to zna­czy? To zna­czy, że 

sys­tem nie może ogra­ni­czać zwin­no­ści orga­ni­za­cji. To w kon­se­kwen­cji ozna­cza, że sys­tem powi­nien pozwa­lać na wpro­wa­dza­nie do nie­go zmian w ter­mi­nach rzę­du poje­dyn­czych miesięcy! 

Cztery lata temu pisa­łem: ​„Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ?water­fall?. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­ra­cyj­no-przy­ro­sto­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na ryn­ku.” [patrz: Jarosław Żeliński, ?Wymagania umar­ły. Rozwiązaniem jest cykl życia pro­duk­tu,? 13 stycz­nia 2017,]. Tak więc pro­ble­mem, jest roz­wią­za­nie (tu sys­tem) i jego archi­tek­tu­ra. Kluczową jego cechą musi być moż­li­wość wpro­wa­dza­nia zmian, czy­li tak­że roz­bu­do­wy, w cią­gu mie­sią­ca, a nie raz poje­dyn­czych tygodni. 

KOSZTY CZYLI CO I JAK CIĄĆ

Oprogramowanie ma trzy pod­sta­wo­we skład­ni­ki kosztowe: 

1. śro­do­wi­sko czy­li plat­for­ma sprzę­to­wo-sys­te­mo­wa: nie­zbęd­ne licen­cje i ich utrzymanie, 
2. bie­żą­ce kosz­ty pra­cy ludz­kiej zwią­za­nej z admi­ni­stra­cją platformy, 
3. kosz­ty pra­cy zwią­za­nej z roz­bu­do­wą funkcjonalności. 

Oprogramowanie, jako kon­kret­ne apli­ka­cje, to albo tak zwa­ne pro­duk­ty seryj­ne ​„z pół­ki” (ang. com­mer­cial off the shelf, COF) albo dedy­ko­wa­ne, czy­li wytwo­rzo­ne dla kon­kret­nej orga­ni­za­cji w celu roz­wią­za­nia okre­ślo­ne­go pro­ble­mu (speł­nie­nia okre­ślo­nych wymagań). 

Jak zapew­ne czy­tel­nik nie raz sły­szał, ceny opro­gra­mo­wa­nia COF są ​„niskie” z powo­du efek­tu ska­li (maso­wa pro­duk­cja). Słowo niskie świa­do­mie umie­ści­łem w cudzy­sło­wie, gdyż wie­lu pro­du­cen­tów opro­gra­mo­wa­nie sto­su­je meto­dy wyce­ny opar­ta na ​„suc­cess fee” czy­li ​„udzia­łu w korzy­ściach” (ceny na ryn­ku usług to mate­riał na osob­ny arty­kuł). Tu ogra­ni­czy­my się jedy­nie do fak­tu, że kosz­ty wytwo­rze­nia i roz­wo­ju opro­gra­mo­wa­nia COF roz­kła­da­ją się na wszyst­kich jego użyt­kow­ni­ków (z regu­ły są ich są co naj­mniej set­ki), kosz­ty wytwo­rze­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia pono­si w cało­ści jeden zamawiający. 

Jakie wnio­ski pły­ną z powyż­sze­go? Ideałem jest sytu­acja, w któ­rej wyma­ga­nia speł­ni dostęp­ne na ryn­ku opro­gra­mo­wa­nie. Jednak dorob­kiem wie­lu firm jest wła­sny, wypra­co­wa­ny mecha­nizm funk­cjo­no­wa­nia, dają­cy prze­wa­gę nad kon­ku­ren­cją, a to (roz­wią­za­nie speł­nia­ją­ce wyma­ga­nia) wyma­ga dedy­ko­wa­ne­go komponentu. 

Mamy więc sytu­ację, w której: 

1. oto­cze­nie ryn­ko­we zmie­nia się nawet w cyklach kwartalnych, 
2. w tak krót­kim okre­sie moż­li­we jest opra­co­wa­nie jed­nej, tak zwa­nej usłu­gi apli­ka­cyj­nej lub zmia­na istniejącej, 
3. im więk­sza, reali­zu­ją­ca wię­cej usług, apli­ka­cja tym wię­cej cza­su i pra­cy wyma­ga wpro­wa­dza­nie do niej zmian (czy­li koszt mody­fi­ka­cji opro­gra­mo­wa­nia jest pro­por­cjo­nal­ny do jego wielkości). 

Wnioski do co kosz­tów nasu­wa­ją się takie: 

1. jeże­li to tyl­ko moż­li­we, nale­ży uni­kać jakich­kol­wiek dedy­ko­wa­nych roz­wią­zań, sto­so­wać je tyl­ko gdy na praw­dę jest to konieczne,
2. żad­ne wdro­że­nie nie powin­no trwać dłu­żej niż rok, ide­ałem jest kwar­tał (to jest możliwe), 
3. krót­kie wdro­że­nia to mały ich zakres, nale­ży więc wdra­żać małe zesta­wy dzie­dzi­no­wych funk­cji (usług aplikacyjnych), 
4. duże sys­te­my, czy­li obej­mu­ją­ce znacz­ne obsza­ry orga­ni­za­cji, nale­ży pla­no­wać jako wie­lo­eta­po­we pro­jek­ty (pro­gra­my), wte­dy jed­nak nale­ży opra­co­wać stra­te­gię infor­ma­ty­za­cji cało­ści orga­ni­za­cji, stan­da­ry­za­cję infor­ma­cji i tak zwa­ną ​„archi­tek­tu­rę wyso­kie­go pozio­mu”, takie wdro­że­nia powin­ny się jed­nak mie­ścić w okre­sie 3 lat.

Warto tu zwró­cić uwa­gę na to, że audyt koń­czą­cy się listą wyma­gań biz­ne­so­wych to kwar­tał. Opracowanie pro­jek­tu tech­nicz­ne­go roz­wią­za­nia, to prak­tycz­nie zawsze w ok. 20% dedy­ko­wa­ne roz­wią­za­nie, łącz­na pra­co­chłon­ność to też kwar­tał. Te okre­sy nie wyni­ka­ją jed­nak z wiel­ko­ści orga­ni­za­cji. Te kwar­tal­ne okre­sy to dopa­so­wa­nie się do zmian na ryn­ku. Innymi sło­wy zakła­da­my np. kwar­tał na ana­li­zę biz­ne­so­wą, a dopie­ro w dru­giej kolej­no­ści dosto­so­wu­je­my jej szcze­gó­ło­wość tak, by był to tyl­ko kwartał. 

Czy to wodo­spa­do­we podej­ście? Nie, to jest podej­ście ite­ra­cyj­no-przy­ro­sto­we. Poprzedzanie zaś każ­de­go eta­pu imple­men­ta­cji pro­jek­to­wa­niem, chro­ni przed znacz­nie kosz­tow­niej­szym pro­to­ty­po­wa­niem (kosz­ty pra­cy zespo­łu deve­lo­per­skie­go są wyż­sze niż koszt pra­cy jed­ne­go projektanta). 

Kolejne pyta­nie: mono­li­tycz­ny sys­tem od jed­ne­go dostaw­cy, wdra­ża­ny eta­pa­mi, czy dzie­dzi­no­we dedy­ko­wa­ne pod­sys­te­my kupo­wa­ne i ich inte­gra­cja? Wdrożenia kom­plek­so­we (znacz­na część orga­ni­za­cji) trwa­ją znacz­nie ponad rok, a jak wspo­mnia­no na począt­ku, naj­dłuż­szym okre­sem względ­nej sta­bil­no­ści pla­nów jest rok budżetowy. 

PODSUMOWANIE

Patrząc na opis sytu­acji we Wprowadzeniu, opis warun­ków funk­cjo­no­wa­nia orga­ni­za­cji Zwinnej oraz na Koszty, wnio­sek nasu­wa się dość oczy­wi­sty: nale­ży dzie­lić duże pro­jek­ty na mniej­sze. W zna­ko­mi­tej więk­szo­ści przy­pad­ków rok budże­to­wy to zbyt krót­ko na duży mono­lit. W efek­cie pyta­nie nie brzmi czy dzie­lić, ale jak dzie­lić zakres pro­jek­tu. Przypominam, że wyma­ga­nia to warun­ki a te się zmie­nia­ją, więc w świe­tle tego napi­sa­no, nie mamy moż­li­wo­ści spi­sa­nia spe­cy­fi­ka­cji wyma­gań na duże pro­jekt. Co nam pozo­sta­je? Skupić się na stra­te­gii i uznać, że to jed­nak cykl życia sys­te­mu jest klu­czem, a nie jego – nie­moż­li­wa do opra­co­wa­nia – dokład­na specyfikacja. 

Każda zła decy­zja to dodat­ko­wy koszt. Co może­my więc zro­bić? Odkładać decy­zje na ​„ostat­ni moment”. Jaki więc sys­tem wybrać? taki, któ­ry na to pozwa­la. Bo to co opi­sa­łem to tak­że wyma­ga­nie: sys­tem powi­nien pozwa­lać na eta­po­we wdro­że­nie bez narzu­ca­nia z góry kolej­no­ści wdro­że­nia poszcze­gól­nych modu­łów oraz bez obo­wiąz­ku wdro­że­nia wszyst­kich, pla­no­wa­nych na począt­ku pro­jek­tu modułów. 

(Artykuł uka­zał się w rapor­cie Perspektywy ERP 2021 na por­ta­lu ERP-View, w lutym 2021, zawie­ra­ją­cym tak­że pro­gno­zy pre­zen­to­wa­ne przez mene­dże­rów czo­ło­wych dostaw­ców sys­te­mów ERP. )