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.
złodziej

Backup – chmura czy u siebie?

W ubie­głym tygo­dniu mia­ła miej­sce kon­fe­ren­cja, na któ­rej zapo­wia­da­łem swój refe­rat. Niestety z powo­dów zdro­wot­nych nie mogłem się poja­wić na tej kon­fe­ren­cji (za co bar­dzo prze­pra­szam, wszyst­kich na tej kon­fe­ren­cji i tych któ­rzy zakła­da­li, że mnie na niej spotkają).

Postanowiłem jed­nak podzie­lić się tu jed­nym z wąt­ków moje­go refe­ra­tu, a mia­no­wi­cie jed­ny­mi z częst­szych przy­czyn: oce­ny ryzy­ka i kosz­tów kopii zapa­so­wych in house” (lokal­nie we wła­snej fir­mie) i w chmu­rze (kopia zapa­so­wa jako usłu­ga dostęp­na zdal­nie na cudzej infrastrukturze).

Najczęściej pod­no­szo­ne róż­ni­ce pomię­dzy wyko­ny­wa­niem i prze­trzy­my­wa­niem kopii zapa­so­wych lokal­nie i w chmurze:

Slajd8

Porównanie kosz­tów (linia czer­wo­na to kosz­ty wdrożenia):

Slajd7

Biorąc pod uwa­gę fakt, że kopie zapa­so­we to raczej dłu­go­ter­mi­no­we inwe­sty­cje, powyż­sze skła­nia do tezy, by mieć swo­je”, jed­nak jed­nym z ryzyk jest kra­dzież lub pożar. Zasoby w chmu­rze” są jed­nak w dłu­giej per­spek­ty­wie najkosztowniejsze.

To tyl­ko mały frag­ment moje­go refe­ra­tu jed­nak chcia­łem się podzie­lić pew­nym pomy­słem, któ­ry poja­wił się nie­daw­no na ryn­ku. Skoro klu­czo­we ryzy­ka to:

Slajd11

System bac­kup odpor­ny na kra­dzież i pożar i mimo to u siebie”

Na ryn­ku poja­wi­ło się cie­ka­we roz­wią­za­nie: WOOXO. System mamy u sie­bie”, więc mamy do dys­po­zy­cji wła­sną admi­ni­stra­cję i brak ogra­ni­cze­nia na prze­pu­sto­wość łączą (nie pła­ci­my dodat­ko­wo za usłu­gę, mamy do dys­po­zy­cji pasmo sie­ci lokal­nej). Warto tak­że pamię­tać, że wyko­ny­wa­nie kopii zapa­so­wych lokal­nie uwal­nia od wie­lu pro­ble­mów praw­nych (np. dane oso­bo­we) jak i czy­sto stra­te­gicz­nych (dostęp do danych sta­no­wią­cych tajem­ni­ce przedsiębiorstwa).

Z co z kra­dzie­żą i poża­rem? Urządzenie wytrzy­mu­je: pożar (843 st. Celsjusza przez 30 minut), moco­wa­nie do pod­ło­ża wytrzy­mu­je 4 tony cią­gu (co na to zło­dzie­je?:)). Wytrzymuje tak­że 8 godz. pod wodą (głę­bo­kość 60 cm) i upa­dek z 9 metrów. Oprogramowanie urzą­dze­nia zapew­nia bar­dzo duży poziom auto­ma­ty­za­cji i kom­pa­ty­bil­no­ści (stan­da­ry­za­cja), róż­ne mode­le archi­tek­tu­ry pra­cy w sie­ci (tak­że chmu­ra, w tym pry­wat­na). (źr. infor­ma­cji o WOOXO: przed­sta­wi­ciel pro­du­cen­ta: Łukasz Wróblewski, stro­na pro­du­cen­ta: WOOXO).

Nieudane wdrożenie wielkiego systemu informatycznego w USA – a co u nas?

Jakiś czas temu pisa­łem o swo­ich prze­my­śle­niach po roz­mo­wie z pew­nym dyrek­to­rem finan­so­wym jed­ne­go z moich klien­tów. Powiedział mię­dzy inny­mi, że albo pro­jekt zosta­nie zre­ali­zo­wa­ny w roku jed­nym budże­to­wym, albo on nie wyda na zgo­dy na jego roz­po­czę­cie. W czym pro­blem? Ano w tym, że przy obec­nym tem­pie zmian na ryn­ku, pro­gno­za wykra­cza­ją­ca w przy­szłość dalej niż rok to wró­że­nie z fusów… Skutek? Jak oce­nić sto­pę zwro­tu z inwe­sty­cji w coś, co jest naj­bar­dziej płyn­nym, podat­nym na zmia­ny wyma­gań, zaso­bem w orga­ni­za­cji, czy­li sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie nią?

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go ?super sys­te­mu? ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci ?goto­wej? tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. (czy­taj Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP).

Co z tym zro­bić? Dzielić, jak to mawia­ją nie­któ­rzy kie­row­ni­cy pro­jek­tów: czło­wiek może zjeść nawet sło­nia, jak? Kęs po kęsie. Tak więc duży pro­jekt nale­ży podzie­lić na samo­dziel­ne” pod­sys­te­my, jed­nak ta samo­dziel­ność ma dwa aspek­ty: każ­dy pod­sys­tem musi sam z sie­bie do cze­goś słu­żyć, powi­nien wno­sić war­tość doda­ną. Drugi: każ­dy pro­jek­to­wa­ny pod­sys­tem powi­nien być zapla­no­wa­ny jako poten­cjal­nie samo­dziel­ne narzę­dzie (inwe­sty­cja) na wypa­dek gdy­by pozo­sta­łe nie zosta­ły nigdy wytwo­rzo­ne np. z powo­du zmian na rynku.

Ale o tym pisa­łem wię­cej już wcze­śniej. Kolejnym pro­ble­mem jest nie­ste­ty jakość projektowania:

Według fir­my ana­li­tycz­nej Gartner oko­ło 60 proc. wdro­żeń wiel­kich sys­te­mów infor­ma­tycz­nych koń­czy się klę­ską. Przyczyną jest m.in. nie­umie­jęt­ność prze­ło­że­nia pro­ce­sów dzia­ła­ją­cych w fir­mie na dzia­ła­nie sys­te­mu infor­ma­tycz­ne­go, brak dosta­tecz­ne­go wspar­cia ze stro­ny pra­cow­ni­ków i kie­row­nic­twa fir­my (cza­sem nawet jaw­ny opór), złe przy­go­to­wa­nie wdro­że­nia lub jego pro­wa­dze­nie. (za Serwis Nauka w Polsce – PAP SA).

Jak widać, jakość pro­jek­to­wa­nia jest klu­czem, zresz­tą nie tyl­ko w przy­pad­ków dużych sys­te­mów ale w każ­dym przy­pad­ku. Różnica jest taka, że jeże­li nie­jed­na fir­ma świa­do­mie ryzy­ku­je kil­ka­set tysię­cy rezy­gnu­jąc z eta­pu nie­za­leż­nej ana­li­zy i pro­jek­to­wa­nia war­tej ok. 10 – 20% tej kwo­ty, to podob­ne podej­ście pro­jek­ty war­te milio­nów jest już raczej nieracjonalne…

Po raz kolej­ny już spraw­dza się teza, że wdra­ża­nie jed­ne­go wiel­kie­go ERP inte­gru­ją­ce­go wszyst­ko” jest mrzon­ką… prak­ty­ka poka­zu­je, że kil­ka sys­te­mów dzie­dzi­no­wych, zin­te­gro­wa­nych ze sobą jest po pierw­sze mniej ryzy­kow­ne a po dru­gie, para­dok­sal­nie, tańsze.

Tak więc: jak dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża). (Nigdy wię­cej ERP w jed­nym kawał­ku!).

Raport z Badania polskich projektów informatycznych 2010

Na stro­nie PMResearch​.pl poja­wi­ło się cie­ka­we bada­nie Raport zawie­ra rezul­ta­ty ana­li­zy 80 sta­ran­nie wyse­lek­cjo­no­wa­nych pro­jek­tów IT. Wyniki pre­zen­tu­je w zwię­zły, syn­te­tycz­ny spo­sób. Pobierz raport (za Informacje o wyni­kach bada­nia pol­skich pro­jek­tów infor­ma­tycz­nych).

Wyniki bada­nia bar­dzo pole­cam, uczą poko­ry. Pytanie moje do auto­rów: jak zde­fi­nio­wa­no meto­dy­kę Agile? Pobieżna nawet bada­nie” zaso­bów w Internecie poka­zu­je, że nie ist­nie­je jed­na defi­ni­cja tego podej­ścia”. Na stro­nie agi​le​ma​ni​fe​sto​.org czytamy:

Wytwarzając opro­gra­mo­wa­nie i poma­ga­jąc innym w tym zakresie,

odkry­wa­my lep­sze spo­so­by wyko­ny­wa­nia tej pracy.

W wyni­ku tych doświad­czeń przedkładamy:

Ludzi i inte­rak­cje ponad pro­ce­sy i narzę­dzia.

Działające opro­gra­mo­wa­nie ponad obszer­ną doku­men­ta­cję.

Współpracę z klien­tem ponad for­mal­ne usta­le­nia.

Reagowanie na zmia­ny ponad podą­ża­nie za pla­nem.

Doceniamy to, co wymie­nio­no po pra­wej stronie,

jed­nak bar­dziej ceni­my to, co po lewej.

Można by odnieść wra­że­nie, że igno­ro­wa­ne jest wszyst­ko co naka­zu­je roz­są­dek (pogru­bie­nie moje). Paradoksalnie, obser­wu­jąc pro­jek­ty, mam wra­że­nie, że zwin­ność jest jed­nak czę­sto ina­czej rozu­mia­na, nie jako igno­ro­wa­nie zło­te­go trój­ką­ta” pro­jek­to­we­go (zakres, ter­min, budżet). Ja w każ­dym razie zawsze pytam: czym jest tu Agile. Niestety sły­szę nie raz, ze tego się nie defi­niu­je”… co wywo­łu­je u mnie odruch nie defi­niu­je się zakre­su pro­jek­tu” a to pro­wa­dzi do wnio­sku, że suk­ce­sem jest sam fakt roz­po­czę­cia projektu…