Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Jarosław Żeliński Date. (2021). Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go – aspek­ty eko­no­micz­ne: Recenzja. https://​doi​.org/​1​0​.​1​3​1​4​0​/​R​G​.​2​.​2​.​2​2​2​9​2​.​0​1​927

Wstęp

Publikacja Jędrzeja Wieczorkowskiego (dalej: recen­zo­wa­ne opra­co­wa­nie) o poniż­szym tytu­le uka­za­ła się w 2015 roku:

Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go: aspek­ty eko­no­micz­ne.

Autor recen­zo­wa­ne­go tek­stu odno­si sie do skut­ków eko­no­micz­nych, pomi­ja jed­nak cał­ko­wi­cie skut­ki praw­ne kasto­mi­za­cji kodu opro­gra­mo­wa­nia, któ­re mają wpływ na kosz­ty i ochro­nę war­to­ści inte­lek­tu­al­nych. Autor pisze we wstępie:

Celem niniej­sze­go opra­co­wa­nia jest ana­li­za moż­li­wych metod kasto­mi­za­cji sys­te­mów infor­ma­tycz­nych zarzą­dza­nia prze­pro­wa­dzo­na z eko­no­micz­ne­go punk­tu widze­nia, w tym w szcze­gól­no­ści opła­cal­no­ści sto­so­wa­nia opro­gra­mo­wa­nia stan­dar­do­we­go i wyko­rzy­sta­nia poszcze­gól­nych metod jego adap­ta­cji. […] Kastomizację sys­te­mu infor­ma­tycz­ne­go ogól­nie nale­ży rozu­mieć jako jego adap­ta­cję do potrzeb kon­kret­ne­go pod­mio­tu. M. Flasiński okre­ślił kasto­mi­za­cję, jako ?kon­fi­gu­ra­cję sys­te­mu, osa­dze­nie w sys­te­mie za pomo­cą prac pro­gra­mi­stycz­nych dodat­ko­wych funk­cjo­nal­no­ści oraz mody­fi­ka­cję ist­nie­ją­cych funk­cjo­nal­no­ści systemu?

Dostarczanie opro­gra­mo­wa­nia i jego wdra­ża­nie, wią­że się jego ewen­tu­al­nym dosto­so­wa­niem do potrzeb użyt­kow­ni­ka. Autor powyż­sze­go opra­co­wa­nia, sto­su­jąc nie­pre­cy­zyj­ne defi­ni­cje pojęć, wpro­wa­dza czy­tel­ni­ka w błąd, opi­su­jąc przy­czy­ny i kon­se­kwen­cje zwią­za­ne z sze­ro­ko poję­tym dosto­so­wa­niem opro­gra­mo­wa­nia do potrzeb użyt­kow­ni­ka. Niestety z tego doku­men­tu korzy­sta wie­lu praw­ni­ków, nazy­wa­jąc go nie raz nawet wykład­nią”.

Czytaj dalej… Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i reko­men­da­cje”

Analiza nie musi być przedwdrożeniowa

Wprowadzenie

W ramach jed­ne­go z moich nie­daw­nych pro­jek­tów badaw­czych celem ana­li­zy nie było opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie (tego typu pro­jek­ty to naj­wy­żej ok. 70% mojej aktyw­no­ści) a roz­wią­za­nie pew­nych pro­ble­mów infor­ma­cyj­nych. Z uwa­gi na ochro­nę know-how klien­ta, opis ten został moc­no okro­jo­ny do isto­ty pro­ble­mu oraz meto­dy jego roz­wią­za­nia, nie ma tu z oczy­wi­stych powo­dów opi­su roz­wią­za­nia (ale waż­ne jest to, że roz­wią­za­nie zna­le­zio­no). Wartość jed­nak ma to, że czy­tel­nik może się tu odna­leźć i sam prze­ko­nać, co jest źró­dłem pew­nych pro­ble­mów, czy i jak moż­na je rozwiązać. 

W poniż­szym tek­ście poję­cie sys­tem odno­si sie do sys­te­mu doku­men­tów i for­mu­la­rzy czy­li do infor­ma­cji i zarzą­dza­nia nią. 

Czytaj dalej… Analiza nie musi być przed­wdro­że­nio­wa”

Na co zwrócić uwagę przygotowując się do wyboru systemu w 2021?

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. )

Model referencyjny systemu ERPII czyli co?

Generalnie mode­le refe­ren­cyj­ne mają i dobrą i złą sła­wę. Nie są to wzor­ce pro­jek­to­we, czy­li dobre prak­ty­ki w posta­ci uni­wer­sal­nych abs­trak­cyj­nych meta-mode­li, są to naj­czę­ściej narzu­ca­ne goto­we archi­tek­tu­ry, pozo­sta­je pyta­nie: kto narzuca?. 

Procesy refe­ren­cyj­ne kry­ty­ko­wa­łem nie raz (Procesy refe­ren­cyj­ne czy­li kto żyw niech ucie­ka), refe­ren­cyj­ny model ERP ozna­czał­by, że ist­nie­je jakaś jedy­nie słusz­na archi­tek­tu­ra sys­te­mu ERPII. I wła­śnie dostaw­cy wie­lu sys­te­mów ERPII (szcze­gól­nie ci duzi, któ­rych pro­duk­ty mają wie­le lat) pro­mu­ją model opar­ty o jed­ną wspól­ną rela­cyj­ną bazę danych, wokół któ­rej są osa­dzo­ne dzie­dzi­no­we modu­ły, nazy­wa­ją taki model mode­lem refe­ren­cyj­nym. Biorąc pod uwa­gę fakt, że sys­te­my te wszyst­kie tak dzia­ła­ją, moż­na taki model nazwać refe­ren­cyj­nym w tej kate­go­rii. Promowana jest tu inte­gra­cja poprzez współ­dzie­le­nie danych. Taka inte­gra­cja jest nie­ste­ty kry­ty­ko­wa­nym od lat mono­li­tem, któ­ry jest też przy­czy­ną wie­lu nie­po­wo­dzeń wdro­żeń: wpro­wa­dza­nie jakich­kol­wiek zmian do takie­go sys­te­mu jest zawsze inge­ren­cją w cały sys­tem. Zarówno na moim blo­gu jak i w sie­ci zna­leźć moż­na wie­le mate­ria­łów na ten temat (np. Monolity vs. …).

Więc jak inaczej?

Wewnętrzny łańcuch wartości

Zacznijmy od przy­po­mnie­nia, uzna­wa­ne­go nadal za stan­dard, mode­lu wewnętrz­ne­go łań­cu­cha war­to­ści M.E.Portera :

Łańcuch wartości M.E.Porter
Łańcuch war­to­ści M.E.Porter (Competitive Advantage, 1985)

Model ten dzie­li pro­ce­sy wewnątrz orga­ni­za­cji na dwie gru­py: wspie­ra­ją­ce i ope­ra­cyj­ne. Procesy wspie­ra­ją­ce to pro­ce­sy zapew­nia­ją­ce orga­ni­za­cji zaso­by nie­zbęd­ne do dzia­ła­nia. Procesy ope­ra­cyj­ne, to pro­ce­sy two­rzą­ce war­tość doda­ną pro­duk­tów i usług w ryn­ko­wym łań­cu­chu war­to­ści (to jaką war­tość doda­ną wno­si dana orga­ni­za­cja na ryn­ku). Schematycznie przed­sta­wio­no to poniżej: 

Rynkowy łań­cuch war­to­ści (źr. Model biz­ne­so­wy czy­li po co mi te pro­ce­sy przed wdro­że­niem ERP czy CRM?)

Marża budo­wa­na jest zarów­no w obsza­rze pro­ce­sów wspie­ra­ją­cych (mini­ma­li­zu­jąc kosz­ty sta­łe) jak i w obsza­rze pro­ce­sów ope­ra­cyj­nych (mar­ża na pro­duk­tach i usłu­gach czy­li wła­snej inwen­cji two­rzą­cej war­tość doda­ną na ryn­ku). W obsza­rze pro­ce­sów wspie­ra­ją­cych może­my kon­ku­ro­wać prak­tycz­nie tyl­ko w wewnętrz­nej efek­tyw­no­ści. W tym obsza­rze pro­ce­sy biz­ne­so­we i infor­ma­cje są dość ści­śle regu­lo­wa­ne pra­wem (księ­go­wość i finan­se, zatrud­nie­nie i wyna­gro­dze­nia, itp.). Zbudowanie tu prze­wa­gi ryn­ko­wej jest bar­dzo trud­ne, gdyż pra­wo doty­czy wszyst­kich pod­mio­tów – czy­li kon­ku­ren­tów tak­że – w jed­na­ko­wym stopniu. 

W obsza­rze pro­ce­sów ope­ra­cyj­nych mamy jed­nak nie­mal­że peł­ną swo­bo­dę. To tu budu­je­my war­tość doda­ną jaką jest ofe­ro­wa­ny pro­dukt lub usłu­ga (być może są one uni­kal­ne, chro­nio­ne pra­wem autor­skim lub paten­tem). Na pod­sta­wie powyż­sze­go moż­na stwo­rzyć pewien wzo­rzec: meta-model pro­ce­sów biz­ne­so­wych organizacji. 

Mapa pro­ce­sów: meta-model pro­ce­sów biz­ne­so­wych orga­ni­za­cji (opra­co­wa­nie własne).

Meta-model ten zbu­do­wa­ny został jako sys­tem pro­ce­sów end-2-end, czy­li pro­ce­sów, gdzie wej­ścia i wyj­ścia to zda­rze­nia na sty­ku orga­ni­za­cji z jej oto­cze­niem. W tej lub podob­nej posta­ci, dia­gram ten był nie raz oma­wia­ny na tym blo­gu, dla­te­go tu tyl­ko kil­ka ogól­nych uwag. 

W zależ­no­ści od spe­cy­fi­ki danej orga­ni­za­cji, poka­za­ne tu pro­ce­sy mogą wystę­po­wać jako mniej lub bar­dziej wewnętrz­nie roz­bu­do­wa­ne (mode­lu­je­my je pre­cy­zyj­nie z uży­ciem nota­cji BPMN), nie­któ­re mogą nie wystą­pić (np. fir­ma usłu­go­wa nie ma pro­duk­cji). Gdyby był to urząd, w miej­scu Obsługi zamó­wień poja­wi się obsłu­ga podań i decy­zje admi­ni­stra­cyj­ne (i podob­ne). To pro­ce­sy ope­ra­cyj­ne. Procesy wspie­ra­ją­ce, w tym obsłu­ga rachun­ko­wo­ści i zaso­by oso­bo­we, to cecha każ­dej orga­ni­za­cji czy urzę­du. Nawiązując do archi­tek­tu­ry biz­ne­so­wej, powyż­szy model to war­stwa środ­ko­wa na poniż­szym dia­gra­mie obra­zu­ją­cym pozio­my opi­su orga­ni­za­cji .

(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

System informacyjny

Pewnym zasko­cze­niem dla czy­tel­ni­ka naj­praw­do­po­dob­niej będzie to, że archi­tek­tu­ra opro­gra­mo­wa­nia wca­le nie musi odwzo­ro­wy­wać powyż­szej mapy pro­ce­sów. Zaryzykuje tezę, że nie mia­ło by to sen­su. Dlaczego? Bo apli­ka­cje to narzę­dzia prze­twa­rza­ją­ce dane a nie uczest­ni­cy pro­ce­sów. pro­ce­sy biz­ne­so­we są nie­za­leż­ne od sys­te­mów IT .

Modelowanie sys­te­mów IT jako torów w mode­lach pro­ce­sów to jeden z naj­częst­szych błę­dów w analizach!

Po dru­gie pro­ce­sy biz­ne­so­we sku­pia­ją się na tre­ści doku­men­tów i celu ich two­rze­nia, apli­ka­cje trak­tu­ją je ina­czej: ich deta­licz­na treść ma zna­cze­nie tyl­ko cza­sa­mi i rzad­ko kie­dy cała. Dokumenty two­rzo­ne są w apli­ka­cjach dzie­dzi­no­wych, bar­dzo czę­sto, po powsta­niu, ich treść prze­twa­rza­na jest w innym pro­ce­sie i w innym celu. Nie każ­dy doku­ment ma ści­słą struk­tu­rę. Np. dowo­dy księ­go­we to ści­śle struk­tu­ral­ne doku­men­ty i powsta­ją w dedy­ko­wa­nych apli­ka­cjach, jed­nak zarów­no zapy­ta­nia, ofer­ty czy rekla­ma­cje, tak­że np. umo­wy (w tym umo­wy o pra­cę), to doku­men­ty o dość swo­bod­nej struk­tu­rze i zarzą­dza­my nimi raczej z pomo­cą wybra­nych ich cech (meta­da­ne), bar­dzo rzad­ko ktoś poza czło­wie­kiem wczy­tu­je się w ich treść (maszy­na nie). W efek­cie archi­tek­tu­ra sys­te­mu infor­ma­tycz­ne­go nie będzie odwzo­ro­wy­wa­ła mapy pro­ce­sów, mimo tego, że intu­icyj­nie takie są ocze­ki­wa­nia od dostaw­ców analiz

Narzędzia w skrzyn­ce narzę­dzio­wej sto­la­rza nie noszą nazw eta­pów pro­duk­cji mebli! Aplikacje to dzie­dzi­no­we narzę­dzia pra­cy, przy czym dzie­dzi­ną nie są tu pro­ce­sy biz­ne­so­we (cel biz­ne­so­wy) a struk­tu­ra danych i ich zna­cze­nie. Innymi sło­wy zarów­no wnio­ski urlo­po­we jak i zapy­ta­nia od klien­tów, to prze­pływ pra­cy i archi­wum doku­men­tów. Wystawienie fak­tu­ry czy doku­men­tu maga­zy­no­we­go, to two­rze­nie spe­cja­li­stycz­nych for­mu­la­rzy, jed­nak ich dal­sze prze­ka­zy­wa­nie (albo przyj­mo­wa­nie np. fak­tur kosz­to­wych) to już tak­że prze­pływ pra­cy i zarzą­dza­nie doku­men­ta­mi jako byta­mi archi­wal­ny­mi. Tu dzie­dzi­no­wość nie pole­ga na tym co i po co robi­my (pro­ce­sy biz­ne­so­we) a na tym, jakie­go rodza­ju dane prze­cho­wu­je­my i prze­twa­rza­my (meta­da­ne). Np. Faktura dla klien­ta, ramo­wa umo­wa na raba­ty z nim, jego rekla­ma­cje, to histo­ria kon­tak­tów z tym klien­tem. Detale struk­tur tych doku­men­tów nie maja tu zna­cze­nia (nie są po raz dru­gi ani zmie­nia­ne ani wery­fi­ko­wa­ne, te doku­men­ty już powsta­ły w apli­ka­cjach im dedy­ko­wa­nych). Dlatego pew­nym ogól­nym wzor­cem archi­tek­tu­ry sys­te­mu IT orga­ni­za­cji, będzie poniż­szy dia­gram :

Ogólna archi­tec­tu­re sys­te­mu IT orga­ni­za­cji (opra­co­wa­nie własne)

Można to z powo­dze­niem nazwać: System ERP II. Nie jest to mono­lit, wdra­żać moż­na te modu­ły prak­tycz­nie w dowol­nej kolej­no­ści, są zin­te­gro­wa­ne, dane wpro­wa­dza­my tyl­ko raz. Obecna na ryn­ku stan­da­ry­za­cja powo­du­je, że inte­gra­cja nie sta­no­wi pro­ble­mu. Modułów tych może być wię­cej, a wdro­że­nie takie na pew­no moż­na nazwać zwinnym. 

Na zakończenie

Obserwacja ryn­ku poka­zu­je, że podaż dedy­ko­wa­nych modu­łów jest bar­dzo duża, wybór jed­ne­go mono­li­tycz­ne­go sys­te­mu – mimo, że nadal popu­lar­ny – jest dzi­siaj nie­ra­cjo­nal­ny, choć­by z uwa­gi na zmien­ność i ryn­ku i pro­fi­li dzia­ła­nia firm oraz zmien­ność pra­wa. Drugim powo­dem, dla któ­re­go decy­do­wa­nie się na mono­li­tycz­ne sys­te­my jest dużym ryzy­kiem, jest to, że jest to tak­że decy­zja o wdra­ża­niu wszyst­kie­go naraz i z jed­ne­go źró­dła”, co bar­dzo rzad­ko ma obec­nie sens i sta­no­wi ogrom­ne ryzy­ko .

Źródła

OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
Street, K. (2006). Building a Service Oriented Architecture with BPM and MDA. 2(1), 8.
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
BPTrends Associates. (2020). BPTrends Associates | BPM ana­ly­sis, opi­nion and insi­ght. http://​www​.bptrend​sas​so​cia​tes​.com/
Fill, H.-G. (2020). Enterprise Modeling: From Digital Transformation to Digital Ubiquity. 1 – 4. https://​doi​.org/​1​0​.​1​5​4​3​9​/​2​0​2​0​F​001
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.

Kto winien porażki projektu? Zamawiający!

Od cza­su do cza­su jestem pro­szo­ny o audy­ty doku­men­ta­cji pro­jek­tów. Ma to miej­sce, albo gdy jestem anga­żo­wa­ny do pro­jek­tu będą­ce­go kolej­nym podej­ściem do wdro­że­nia, albo w spo­rach przed­są­do­wych mię­dzy dostaw­cą opro­gra­mo­wa­nia i zama­wia­ją­cym. Tu razem kil­ka spo­strze­żeń z tych analiz.

Na mar­gi­ne­sie. W spo­rach przed­są­do­wych i sądo­wych wynik eks­per­ty­zy abso­lut­nie nie może być zamó­wio­ny”, cze­go nie­ste­ty czę­sto ocze­ku­ją, nie raz wręcz żąda­ją pod groź­bą odmo­wy zapła­ty za tę usłu­gę, zama­wia­ją­cy takie eks­per­ty­zy. Bywa to tym bar­dziej żenu­ją­ce, że rosz­cze­nia takie wysu­wa­ją praw­ni­cy zle­ca­ją­cych, czy­li oso­by zna­ją­ce pra­wo i – teo­re­tycz­nie – sto­su­ją­cy zasa­dy ety­ki w swo­jej pracy.

Wiele lat uwa­ża­łem, że win­ni są dostaw­cy, któ­rzy powin­ni wyka­zać się moż­li­wie naj­wyż­szym pro­fe­sjo­na­li­zmem, a tego nie robią. Jakiś czas temu zmie­ni­łem jed­nak zda­nie (nie o pro­fe­sjo­na­li­zmie dostawców). 

Poza reali­zo­wa­ny­mi pro­jek­ta­mi, pro­wa­dzę tak­że szko­le­nia oraz zaję­cia ze stu­den­ta­mi stu­diów nie­sta­cjo­nar­nych i pody­plo­mo­wych: to nie raz doświad­cze­ni prak­ty­cy. Na wykła­dach i ćwi­cze­niach sta­ram się poka­zać jak to robić dobrze”, jed­nym z ele­men­tów tego jak to robić dobrze” jest jak nie robić tego źle” i dys­ku­sje na ten temat. 

Dlaczego zmie­ni­łem zda­nie? I wła­sne doświad­cze­nie i dys­ku­sje ze stu­den­ta­mi prze­ko­na­ły mnie, że gene­ral­nie celem dostaw­cy jest mak­sy­ma­li­za­cja zysków. Co mi sta­le mówią uczą­cy się u mnie prak­ty­cy? Klient nasz pan, mamy robić wszyst­ko co chce klient bo on za to pła­ci, a to, czy to co klient chce ma sens, nie ma zna­cze­nia bo to pro­blem klien­ta (chy­ba każ­dy pro­gra­mi­sta sły­szy to od swo­je­go prze­ło­żo­ne­go raz dziennie). 

Jak klient nie wie cze­go chce, to na jego koszt pró­bu­je­my.

W 2018 arty­kuł o poraż­ce wdro­że­nia w LID koń­czy­łem słowami: 

Dziwi mnie, że wszyst­kie te, doświad­czo­ne poraż­ką, fir­my mają dostęp do tej samej wie­dzy co np. ja, a mimo to zarzą­dy tych firm wie­rzą bez­gra­nicz­nie dostaw­com opro­gra­mo­wa­nia i wie­rzą, że opi­sy­wa­ne od lat przy­czy­ny pora­żek u nich nie wystą­pią? (źr.: Porażka za 2 mld zł. Lidl wyco­fu­je się z wdro­że­nia SAP – Jarosław Żeliński IT-Consulting)

więc win­ny jest zamawiający… 

Ten arty­kuł to krót­ka ana­li­za warun­ków praw­nych i prak­tycz­nych reali­za­cji pro­jek­tów wdrożeniowych. 

Umowa efektu a staranne działanie

Poniższy tekst, to treść, któ­rą w róż­nych for­mach umiesz­czam jako wstęp do ekspertyz. 

W pra­wie cywil­nym wyróż­nio­no dwie pod­sta­wo­we for­my świad­cze­nia zamó­wio­nej usługi:

  1. Umowa o dzieło
  2. Umowa zle­ce­nia

Scharakteryzowane zosta­ły w nastę­pu­ją­cy sposób:

Umowa o dzieło

Art. 627. Przez umo­wę o dzie­ło przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się do wyko­na­nia ozna­czo­ne­go dzie­ła, a zama­wia­ją­cy do zapła­ty wynagrodzenia.

Zlecenie

Art. 734. § 1. Przez umo­wę zle­ce­nia przyj­mu­ją­cy zle­ce­nie zobo­wią­zu­je się do doko­na­nia okre­ślo­nej czyn­no­ści praw­nej dla dają­ce­go zlecenie.

§ 2. W bra­ku odmien­nej umo­wy zle­ce­nie obej­mu­je umo­co­wa­nie do wyko­na­nia czyn­no­ści w imie­niu dają­ce­go zle­ce­nie. Przepis ten nie uchy­bia prze­pi­som o for­mie pełnomocnictwa.

.

W powszech­nej i utrwa­lo­nej opi­nii praw­ni­ków i w orzecz­nic­twie przyj­mu­je się, że:

Umowa zle­ce­nia jest umo­wą sta­ran­ne­go dzia­ła­nia. Zleceniobiorca zobo­wią­zu­je się do sta­ran­ne­go dzia­ła­nia i za to wła­śnie odpo­wia­da, a nie, jak w przy­pad­ku umo­wy o dzie­ło, za rezul­tat pra­cy. W umo­wie nale­ży więc dokład­nie opi­sać czyn­no­ści, jakie ma wyko­ny­wać zle­ce­nio­bior­ca, by póź­niej moż­na było oce­nić, czy zle­ce­nie zosta­ło wyko­na­ne oraz czy zosta­ło wyko­na­ne w spo­sób sta­ran­ny.” . A tak­że, że „…moż­na stwier­dzić, iż w zobo­wią­za­niach sta­ran­ne­go dzia­ła­nia dłuż­nik zobo­wią­zu­je się jedy­nie do doło­że­nia nale­ży­tej sta­ran­no­ści w zmie­rza­niu do usta­lo­ne­go celu, z tym że jego osią­gnię­cie pozo­sta­je poza tre­ścią sto­sun­ku zobo­wią­za­nio­we­go. Natomiast w przy­pad­ku zobo­wią­za­nia rezul­ta­tu na dłuż­ni­ku cią­ży powin­ność osią­gnię­cia ozna­czo­ne­go z góry, spre­cy­zo­wa­ne­go rezul­ta­tu, przy czym ten rezul­tat to okre­ślo­ny fakt, w nastą­pie­niu któ­re­go wie­rzy­ciel jest zain­te­re­so­wa­ny, praw­ny i eko­no­micz­ny sku­tek ozna­czo­ny w tre­ści zobo­wią­za­nia, nie zaś sama czyn­ność, któ­rą dłuż­nik powi­nien pod­jąć.” .

Podsumowując moż­na stwier­dzić, że

  1. Umowa o dzie­ło to umo­wa, w któ­rej dają­cy zamó­wie­nie z góry opi­su­je to co chce otrzy­mać (dzie­ło), a przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się to dostar­czyć (wyko­nać dzieło).
  2. Zlecenie to umo­wa, w któ­rej przyj­mu­ją­cy zle­ce­nie dzia­ła w imie­niu dają­ce­go zle­ce­nie, w kon­se­kwen­cji za efekt zle­co­nej pra­cy odpo­wia­da dają­cy zlecenie.

Znakomita więk­szość umów na dostar­cze­nie opro­gra­mo­wa­nia to, umo­wy sta­ran­ne­go dzia­ła­nia, a tak zwa­ne umo­wy agi­le” mają taki cha­rak­ter z zasa­dy. Tu za uzy­ska­ny efekt zawsze odpo­wia­da Zamawiający.

A jeże­li dostaw­ca jest nie­rze­tel­ny? Jest takie ryzy­ko, jed­nak odpo­wie­dzial­no­ścią zama­wia­ją­ce­go jest tak­że nad­zór na pra­ca­mi wykonawcy!

Proces dostarczenia oprogramowania

Inżynieria opro­gra­mo­wa­nia, na tle innych obsza­rów inży­nie­rii, jest mło­dą dzie­dzi­ną, któ­ra nie wykształ­ci­ła dedy­ko­wa­ne­go pra­wo­daw­stwa, tak jak np. inży­nie­ria budow­la­na, któ­ra ma swo­je” pra­wo budow­la­ne. Z tego też powo­du, jedy­nym źró­dłem opi­sów postę­po­wa­nia są tak zwa­ne dobre prak­ty­ki, stan­dar­dy oraz ana­lo­gie, sto­so­wa­ne tak­że – w obsza­rze inży­nie­rii – do pra­wa budowlanego.

Na diagramie 'Iteracyjno-przyrostowy proces tworzenia oprogramowania' zobrazowano standardowy proces dostarczania rozwiązania jakim jest oprogramowanie (Dennis et al., 2012). Obecnie, z uwagi na tempo zmian w gospodarce, zaleca się by jedna 'pętla iteracyjna rozwoju i utrzymania' nie przekraczała w czasie jednego roku budżetowego, jednak preferowanym okresem jest pół roku z uwagi na to, że sztywne uzależnianie wdrażania oprogramowania wspomagającego zarządzanie, od rygorów rocznych okresów budżetowych było by znaczącym utrudnienie w toku wdrażania zmian w firmach. Projekty małe to projekty będące pojedynczą iteracją. Dobrą praktyką postępowania dla projektów większych jest dzielenie ich na przyrostowe iteracje (w kolejnych cyklach pętli iteracji wdrażane są kolejne funkcjonalności lub moduły) (Larman, 2004). Z reguły robi to wtedy wykonawca przyjmujący zamówienie(Maciaszek, 2001). Co do zasady, za specyfikowanie wymagań i jakość tej specyfikacji, w każdym rodzaju inżynierii, odpowiada zamawiający (Hay, 2003). Zamawiający jest jedynym tu podmiotem, znającym swój cel biznesowy, jako podmiot zamawia u dostawcy produkt a nie efekt biznesowy jaki ma zamiar osiągnąć (Ackoff i in., 2007). W tym miejscu, należy zwrócić uwagę na bardzo ważny fakt, że w przypadku umowy efektu, kolejne iteracje to uszczegółowienie i implementacja funkcjonalności opisanych w umowie, a nie kolejne nowe funkcjonalności.
Iteracyjno-przy­ro­sto­wy pro­ces two­rze­nia oprogramowania

Na dia­gra­mie «Iteracyjno-przy­ro­sto­wy pro­ces two­rze­nia opro­gra­mo­wa­nia» zobra­zo­wa­no stan­dar­do­wy pro­ces dostar­cza­nia roz­wią­za­nia jakim jest opro­gra­mo­wa­nie . Obecnie, z uwa­gi na tem­po zmian w gospo­dar­ce, zale­ca się by jed­na «pętla ite­ra­cyj­na roz­wo­ju i utrzy­ma­nia» nie prze­kra­cza­ła w cza­sie jed­ne­go roku budże­to­we­go, jed­nak pre­fe­ro­wa­nym okre­sem jest pół roku z uwa­gi na to, że sztyw­ne uza­leż­nia­nie wdra­ża­nia opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, od rygo­rów rocz­nych okre­sów budże­to­wych było by zna­czą­cym utrud­nie­nie w toku wdra­ża­nia zmian w fir­mach. Projekty małe to pro­jek­ty będą­ce poje­dyn­czą ite­ra­cją. Dobrą prak­ty­ką postę­po­wa­nia dla pro­jek­tów więk­szych jest dzie­le­nie ich na przy­ro­sto­we ite­ra­cje (w kolej­nych cyklach pętli ite­ra­cji wdra­ża­ne są kolej­ne funk­cjo­nal­no­ści lub modu­ły) . Z regu­ły robi to wte­dy wyko­naw­ca przyj­mu­ją­cy zamó­wie­nie . Co do zasa­dy, za spe­cy­fi­ko­wa­nie wyma­gań i jakość tej spe­cy­fi­ka­cji, w każ­dym rodza­ju inży­nie­rii, odpo­wia­da zama­wia­ją­cy . Zamawiający jest jedy­nym tu pod­mio­tem, zna­ją­cym swój cel biz­ne­so­wy, jako pod­miot zama­wia u dostaw­cy pro­dukt a nie efekt biz­ne­so­wy jaki ma zamiar osią­gnąć, za efekt efekt biz­ne­so­wy z zasa­dy odpo­wia­da biz­nes” 

W tym miej­scu, nale­ży zwró­cić uwa­gę na bar­dzo waż­ny fakt: w przy­pad­ku umo­wy efek­tu, kolej­ne ite­ra­cje to uszcze­gó­ło­wie­nie i imple­men­ta­cja funk­cjo­nal­no­ści opi­sa­nych w umo­wie, a nie kolej­ne nowe funk­cjo­nal­no­ści. Nowe funk­cjo­nal­no­ści powsta­ją w toku roz­wo­ju JUŻ WDROŻONEGO I POPRAWNIE DZIAŁAJĄCEGO oprogramowania. 

Podsumowanie

Projekty wdro­że­nio­we (dostar­cza­nie opro­gra­mo­wa­nia) mogą być reali­zo­wa­ne przez bie­żą­ce zle­ca­nie kon­kret­nych prac usłu­go­daw­cy, lub poprzez opi­sa­nie ocze­ki­wa­ne­go efek­tu jako wyma­ga­ne­go roz­wią­za­nia i zawar­cie Umowy o dzie­ło z przyj­mu­ją­cym zamó­wie­nie, co zobra­zo­wa­no na dia­gra­mie Podsumowanie sta­nu wie­dzy. W obu przy­pad­kach Zamawiający pono­si skut­ki swo­jej decy­zji bo:

  1. jako zle­ce­nio­daw­ca (umo­wy T&M) sam usta­la co i jak ma zostać wykonane,
  2. jako zama­wia­ją­cy okre­ślo­ny efekt (umo­wy o dzie­ło), sam usta­la ocze­ki­wa­ny efekt (pro­dukt) w dniu zawar­cia umo­wy (jako opis przed­mio­tu zamówienia).

Odpowiedzialność przyj­mu­ją­ce­go zamó­wie­nia pole­ga albo na sta­ran­nym dzia­ła­niu, albo na zgod­no­ści tego co dostar­czy z tym co zamó­wio­no, w rozu­mie­niu ocze­ki­wa­ne­go efek­tu. Jeżeli przed­mio­tem zamó­wie­nia jest opro­gra­mo­wa­nie, czy­li narzę­dzie pra­cy zama­wia­ją­ce­go, tyl­ko zama­wia­ją­cy pono­si odpo­wie­dzial­ność za skut­ki wdro­że­nia tego co zamó­wił . Dostawca odpo­wia­da wyłącz­nie za przed­miot umo­wy .

Tak więc zama­wia­ją­cy zawsze dosta­nie to co chce, ale nie koniecz­nie to co jest mu fak­tycz­nie potrzeb­ne. Innymi sło­wy, na ryn­ku rzą­dzo­nym przez docho­dy i zyski, dostaw­ca opro­gra­mo­wa­nia zawsze będzie pra­co­wał pod dyk­tan­do zama­wia­ją­ce­go (lub za jego zgo­dą) i będzie to robił do wyczer­pa­na budże­tu zamawiającego. 

Bardzo cie­ka­we są blo­gi dostaw­ców opro­gra­mo­wa­nia. Wielu ich auto­rów fak­tycz­nie sta­ra się, ale cóż… jeden z cie­kaw­szych wpi­sów na ten temat jest zaty­tu­ło­wa­ny The art (and scien­ce) of col­lec­ting requ­ire­ments: top 3 mista­kes ven­dors make”. Autor z per­spek­ty­wy dostaw­cy, zwra­ca uwa­gę na trzy klu­czo­we przy­czy­ny pora­żek: uzna­nie, że to użyt­kow­nik odpo­wia­da za wyma­ga­nia, mie­sza­nie wyma­gań z pomy­sła­mi na ich reali­za­cję, nie­do­ce­nia­nia macie­rzy śla­do­wa­nia. To, popeł­nia­nie tych błę­dów, nie­ste­ty jest naj­czę­ściej spo­ty­ka­ną cechą ana­liz pro­wa­dza­nych wła­śnie przez dostaw­ców opro­gra­mo­wa­nia, a za wszyst­ko i tak pła­ci nabyw­ca. W bar­dziej nauko­wy spo­sób (szcze­gól­nie kry­ty­ku­jąc wyma­ga­nia pisa­ne języ­kiem natu­ral­nym przez zama­wia­ją­ce­go) opi­sa­li to bar­dzo dokład­nie Šenkýř i Kroha .

Konkluzja jest taka, że za nie­uda­ne wdro­że­nia odpo­wia­da zawsze zamawiający. 

Główną winą zama­wia­ją­ce­go jest to, że zama­wia usłu­gi, któ­rych isto­ty nie rozu­mie więc pozo­sta­wia wyko­naw­cę prak­tycz­nie bez nad­zo­ru, odda­jąc mu nie­mal­że nie­ogra­ni­czo­ne upraw­nie­nia co do zakre­su pro­jek­tu. Pierwszym zaś samo­bój­czym kro­kiem jest zle­ce­nie ana­li­zy wyma­gań i pro­jek­to­wa­nie wybra­ne­mu wcze­śniej dostaw­cy opro­gra­mo­wa­nia. Biorąc pod uwa­gę ryn­ko­wy kon­flikt inte­re­su dostaw­cy i odbior­cy (zama­wia­ją­cy mak­sy­ma­li­zu­je żąda­nia a dostaw­ca mak­sy­ma­li­zu­je zysk), jest to pro­sta dro­ga do poraż­ki, jaką jest tak­że znacz­ne przepłacenie. 

Pytani pra­cow­ni­cy dostaw­ców zawsze odpo­wia­da­ją, że prze­cież celem jest dowie­zie­nie pro­jek­tu”, nie­ste­ty nie jest jed­nak żad­ną sztu­ką w koń­cu dostar­czyć opro­gra­mo­wa­nie”. Sztuką jest to zro­bić zgod­nie z obiet­ni­cą daną pierw­sze­go dnia pro­jek­tu, a z wła­sne­go wie­lo­let­nie­go doświad­cze­nia wiem, że to moż­li­we. Sztuką jest tak­że to, by dal­szy roz­wój i utrzy­ma­nie nie były naj­droż­szym pro­jek­tem świata.

Szanowni pań­stwo: pod­pi­su­jąc z dostaw­cą opro­gra­mo­wa­nia umo­wę czas i mate­riał”, i zle­ca­jąc temu dostaw­cy tak­że ana­li­zę wyma­gań, kopie­cie sobie grób. 

Za co odpo­wia­da dostaw­ca? Za sta­ran­ne dzia­ła­nie, jed­nak sto­so­wa­nie nie­ade­kwat­nych metod nie jest dzia­ła­niem nie­sta­ran­nym, i dla­te­go w sądach z regu­ły prze­gry­wa­ją zama­wia­ją­cy a nie dostaw­cy opro­gra­mo­wa­nia. Wykazanie sta­ran­ne­go dzia­ła­nia przez dostaw­cę opro­gra­mo­wa­nia jest bar­dzo pro­ste: comie­sięcz­ne opła­co­ne fak­tu­ry za pra­cę” dostaw­cy opro­gra­mo­wa­nia są tak napraw­dę uzna­niem jego sta­ran­ne­go dzia­ła­nia przez zama­wia­ją­ce­go. Pozostaje tu jedy­nie kwe­stia ety­ki dostaw­cy, ale to temat na osob­ne opracowanie. 

Tak więc podej­mu­jąc decy­zję o wdro­że­niu pomy­śl­cie Państwo o ryzyku:

ryzyko, popper, decyzje
Karl Popper Ryzyko i decyzje

Kontynuacja wąt­ku: Myślenie życze­nio­we.…

Źródła

Wiegers, K. E., & Beatty, J. (2013). Software requ­ire­ments (Third edi­tion). Microsoft Press, s divi­sion of Microsoft Corporation.
Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu. https://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006
Larman, C. (2005). Applying UML and pat­terns: an intro­duc­tion to object-orien­ted ana­ly­sis and design and ite­ra­ti­ve deve­lop­ment (3rd ed). Prentice Hall PTR, c2005.
Agaronian, A., Freyer, C. W. S., Bierbooms, C. G., Hoeijmakers, T. P. H., Jansen, T., Kafoe, T., Makantasis, I., Mankevic, K., Sinx, R. D., & Smits, I. M. (2019). Software Requirements Document. 133.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems ana­ly­sis and design (5th ed). John Wiley.

Przyczyny nieplanowanych kosztów wdrożeń

Zarządzanie ryzy­kiem to pro­za życia kie­row­ni­ków pro­jek­tów. Z jed­nej stro­ny doświad­czo­ny kie­row­nik pro­jek­tu powi­nien dosko­na­le radzić sobie z ryzy­kiem, z dru­giej zaś stro­ny prak­ty­ka pro­jek­tów poka­zu­je, że efek­ty są nie­ste­ty sła­be bo ok. 90% IT na świe­cie ma prze­kro­co­zne budże­ty i ter­mi­ny .

Jednym z cie­kaw­szych narzę­dzi zarzą­dza­nia ryzy­kiem jest mało popu­lar­ny tak zwa­ny sto­żek nie­pew­no­ści. Ogólna zasa­da pla­no­wa­nia mówi, że im bar­dziej w przy­szłość wybie­ga­ją pro­gno­zy tym bar­dziej są one nie­pew­ne. Jest nie tyl­ko intu­icyj­ne ale i udo­wod­nio­ne mate­ma­tycz­nie. Stożek nie­pew­no­ści to wykres poka­zu­ją­cy zwią­zek pomię­dzy kosz­ta­mi pro­jek­tu a posia­da­ną wie­dzą na eta­pie ini­cja­cji pro­jek­tu np. imple­men­ta­cji (dostar­cze­nia) opro­gra­mo­wa­nia. Poniżej jeden z przy­kła­dów jego zobrazowania:

Stożek nie­pew­no­ści

Stożek ten (sto­żek nie­pew­no­ści) to narzę­dzie empi­rycz­ne (!), obra­zu­je spo­dzie­wa­ne kon­se­kwen­cje jaki­mi są kosz­ty, gene­ro­wa­ne przez nie­pew­ność (przed­wcze­sne, nie­uda­ne pro­to­ty­py, wpro­wa­dza­nie zmian po przed­wcze­snym roz­po­czę­ciu prac imple­men­ta­cyj­nych i wdro­że­nio­wych, itp.). 

Na powyż­szym wykre­sie, czer­wo­na linia obra­zu­je kosz­ty eta­pu prac bez ana­liz i pro­jek­to­wa­nia (agi­le) a zie­lo­na kosz­ty prac poprze­dzo­nych ana­li­za­mi i pro­jek­to­wa­niem. Linie te spo­ty­ka­ją w punk­cie, w któ­rym wie­dza o osta­tecz­nej wer­sji pro­duk­tu jest już taka sama. Punkty ozna­czo­ne dia­men­tem” to kamie­nie milo­we pro­jek­tu. Wartość kosz­tu odnie­sie­nia 1.0 to sytu­acja, w któ­rej w momen­cie roz­po­czę­cia pro­jek­tu nie było­by żad­nych nie­wia­do­mych (ryzy­ko zakre­su pro­jek­tu = zero). Całkowity koszt pro­jek­tu to pola pod krzy­wy­mi (pomię­dzy daną krzy­wą a pozio­mem zero lewej osi). Praktyka poka­zu­je więc, że brak pla­no­wa­nia i pro­jek­to­wa­nia pod­no­si kosz­ty pro­jek­tu śred­nio czterokrotnie.

W przy­pad­ku apli­ka­cji będą­cej mono­li­tem wykres repre­zen­tu­je cały pro­jekt („water fall”, meto­da wodo­spa­do­wa), czy­li pro­jekt trwa­ją­cy nie raz kil­ka lat. Prawdopodobieństwo, że reali­za­cja deta­licz­nie zapla­no­wa­ne­go np. na 5 lat pro­jek­tu będzie wyma­ga­ła korek­ty pla­nów lub wpro­wa­dza­nia zmian do pro­jek­tu, gra­ni­czy obec­nie z pewnością:

W przy­pad­ku zasto­so­wa­nia metod obiek­to­wych, zorien­to­wa­nych na komponenty/mikroserwisy, wykres Stożek nie­pew­no­ści repre­zen­tu­je dostar­cze­nie jed­nej usłu­gi apli­ka­cyj­nej (przy­pa­dek uży­cia, imple­men­to­wa­nej jako kom­po­nent, patrz tak­że ite­ra­cyj­no-przy­ro­sto­we dostar­cza­nie opro­gra­mo­wa­nia jako kolej­nych usług apli­ka­cyj­nych, MVP: Minimum Value Product). Implementacja jed­nej takiej usłu­gi z regu­ły mie­ści się w jed­nym kwar­ta­le. W efek­cie prak­tycz­nie eli­mi­nu­je­my skut­ki nie­pew­no­ści, pla­nu­jąc reali­za­cję pro­jek­tu tak, by żad­ne pla­ny nie wybie­ga­ły zbyt dale­ko w przy­szłość (z regu­ły gra­ni­ca jest rok budże­to­wy). Jest to moż­li­we dzię­ki odej­ściu od mono­li­tycz­nej archi­tek­tu­ry apli­ka­cji. Realizacja pro­jek­tu wytwa­rza­nia apli­ka­cji o kom­po­nen­to­wej (np. mikro­ser­wi­sy) archi­tek­tu­rze wyglą­da jak poniżej:

Warto tu zwró­cić uwa­gę, że apli­ka­cje zbu­do­wa­ne w opar­ciu o jed­ną i cen­tral­ną bazę danych w mode­lu rela­cyj­nym (RDBMS) są wła­śnie typo­wy­mi mono­li­ta­mi, np. więk­szość powszech­nie zna­nych dużych sys­te­mów ERP. Duże sys­te­my rela­cyj­nych baz danych są z tego powo­du od daw­na krytykowane:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

W tym przy­pad­ku ofer­ty (obiet­ni­ce) dostaw­ców tego typu sys­te­mów (mono­li­ty) to zie­lo­na linia na dia­gra­mie Stożek nie­pew­no­ści, a fak­tycz­ne kosz­ty tych wdro­żeń, pole­ga­ją­ce na bie­żą­cej, pro­wa­dzo­nej ad-hoc adap­ta­cji, to linia czer­wo­na, co potwier­dza­ją sta­ty­sty­ki .

Źródła

Little, T. (2006). Schedule esti­ma­tion and uncer­ta­in­ty sur­ro­un­ding the cone of uncer­ta­in­ty. Software, IEEE, 23, 48 – 54. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​6​.82
Cook, S., & Daniels, J. (1994). Designing object sys­tems: object-orien­ted model­ling with Syntropy. Prentice Hall.