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.

Architektura korporacyjna z OMG​.org

Swego cza­su, gdy dowie­dzia­łem się, że nota­cja ArchiMate ma jed­nak być chro­nio­na pra­wa­mi autor­ski­mi przez The Open Group a koszt cer­ty­fi­ka­cji TOGAF to cał­kiem nie­zły haracz, napisałem:

Przyznaję, że rezy­gnu­ję z tej nota­cji jak i z TOGAF?a jako meto­dy­ki. W dwóch pro­jek­tach spraw­dzi­ła się moja hipo­te­za: mode­lo­wa­nie i ana­li­za war­stwy biz­ne­so­wej i IT oraz oce­na wza­jem­nych zależ­no­ści nie wyma­ga nowej nota­cji a dobrze wyko­na­ne­go mode­lu w już zna­nych, wystar­czą nota­cje BMM, BPMN, UML oraz narzę­dzie potra­fią­ce zarzą­dzać rela­cja­mi pomię­dzy obiek­ta­mi na tych mode­lach? zary­zy­ku­ję tezę, że jest to efek­tyw­niej­sze niż two­rze­nie kolej­nych dzie­sią­tek dia­gra­mów ArchiMate. (Pokazać wię­cej z sen­sem? ).

Podstawowym powo­dem jest to, że skąd­inąd dobry pomysł, jakim jest sama archi­tek­tu­ra kor­po­ra­cyj­na, jest obkła­da­ny ide­olo­gią (mar­ke­ting?!) i opła­ta­mi, któ­rych nie rozu­miem (albo raczej rozu­miem, ale nie mam ocho­ty ich pono­sić ;)), moi klien­ci nie raz tak­że nie).

Cóż to jest ta Architektura Korporacyjna (dalej Architektura lub AK)? Ogólnie:

Based on this bro­ade­ning of sco­pe, Enterprise Architecture now covers:

  • Business Architecture
  • Data Architecture
  • Application Architecture
  • Infrastructure Architecture

(pole­cam cały, krót­ki wpis na Business Analyst Interview Questions | Modern Analyst > What is Enterprise Architecture?).

Przytoczę tu pro­stą i bar­dzo dobrą moim zda­niem defi­ni­cję zaczerp­nię­tą z refe­ra­tu [[dr. Andrzeja Sobczaka (SGH)]]:

Architektura kor­po­ra­cyj­na – for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji (obej­mu­ją­cych ludzi, pro­ce­sy, infor­ma­cje i tech­ni­kę), wza­jem­nych rela­cji pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­pia i wytycz­ne odno­śnie do zarzą­dza­nia pro­jek­to­wa­niem i zarzą­dza­nia zmia­ną tych kom­po­nen­tów w czasie.

Moim zda­niem nie trze­ba nic wię­cej doda­wać. Dla porząd­ku przy­to­czę defi­ni­cję sło­wa pryn­cy­pium ze słow­ni­ka j.polskiego:

pryn­cy­pium, prin­ci­pium [wym. princ-ipium] ?naj­waż­niej­sza dla kogoś lub dla cze­goś zasa­da albo war­tość? (Portal Wiedzy PWN – słow­ni­ki, ency­klo­pe­die, pod­ręcz­ni­ki aka­de­mic­kie, książ­ki spe­cja­li­stycz­ne, repe­ty­to­ria, porad­ni­ki, prze­wod­ni­ki).

Te pryn­cy­pia, to moim zda­niem uzna­nie for­ma­li­zmu w budo­wie mode­li i sfor­ma­li­zo­wa­ne zarzą­dza­nie ich zmianą.

Narzędzia OMG​.org

Co mamy w skrzyn­ce narzę­dzio­wej OMG” (www​.omg​.org)? Ludzie i pro­ce­sy to nic inne­go jak BPMN i struk­tu­ra orga­ni­za­cyj­na (ta dru­ga w BPMN lub jako sfor­ma­li­zo­wa­ny [[orga­ni­gram]]). Informacje i tech­ni­ka to nic inne­go jak UML i dia­gra­my struk­tu­ral­ne. Nie roz­wo­dząc się, całość wyglą­da ogól­nie tak:

Architektura korporacyjna - struktura

Powyższy dia­gram obrazuje:

  • kolej­ne wyma­ga­ne w AK war­stwy (doda­no na szczy­cie tak zwa­ną moty­wa­cję biznesową),
  • mapo­wa­nie zstępujące

W efek­cie, mają zasto­so­wa­nie wska­za­ne narzę­dzia (dia­gra­my, mode­le). Z ich pomo­cą może­my nie tyl­ko opra­co­wać model Architektury Korporacyjnej ale tak­że nad­zo­ro­wać go, budu­jąc macie­rze mapowania.

Tu poja­wia się poję­cie prag­ma­ty­ki w sto­so­wa­niu języ­ka (nota­cji). Ta prag­ma­ty­ka to wspo­mnia­ne już pryn­cy­pia pro­ce­so­we i obiek­to­we, oraz wska­za­ne na dia­gra­mie powy­żej uży­cie pojęć w każ­dej z wymie­nio­nych nota­cji, czy­li co i na co mapu­je­my. Mapowanie wyma­ga dopre­cy­zo­wa­nia seman­ty­ki mode­li czy­li defi­ni­cji pojęć. Jak? Najprościej nie kom­bi­no­wać np. z przy­pad­ka­mi uży­cia na biz­ne­so­we, sys­te­mo­we i inne bo to zupeł­nie nie potrzeb­ne i nie pozwa­la na pro­ste mapowanie.

Jawne mapowanie na diagramach pomiędzy warstwami

Notacja ArchiMate ma moż­li­wość (taki jest jej pośred­ni cel) jaw­ne­go poka­za­nia mapo­wa­nia pomię­dzy obiek­ta­mi warstw na dia­gra­mach. W przy­pad­ku UML też jest to for­mal­nie moż­li­we od wer­sji 2.0, zaś mapo­wa­nia BPMN->UML doko­nu­je się w doku­men­ta­cji (typo­we śla­do­wa­nie Czynność -> Przypadek użycia).

Otóż mapo­wa­nie moż­na poka­zać na wie­le spo­so­bów. Moim zda­niem robie­nie tego na dia­gra­mach, po pierw­sze nie­co je zaciem­nia, po dru­gie i tak nie eli­mi­nu­je przy­dat­no­ści stwo­rze­nia macie­rzy mapo­wa­nia. Ta dru­ga może być wyge­ne­ro­wa­na auto­ma­tycz­nie, jeże­li tyl­ko uży­wa­my dobre­go narzę­dzia CASE (bez nie­go zresz­tą nie wyobra­żam sobie wyko­na­nia żad­ne­go więk­sze­go mode­lu przy zacho­wa­niu roz­sąd­nej pracochłonności).

Po dru­gie nawet śred­ni model, mają­cy kil­ka­dzie­siąt obiek­tów, będzie wyma­gał dużej ilo­ści dodat­ko­wych dia­gra­mów obra­zu­ją­cych samo mapo­wa­nie, któ­re to dodat­ko­we dia­gra­my nie wno­szą war­to­ści doda­nej do pro­jek­tu, bo macierz gene­ro­wa­na auto­ma­tycz­nie z repo­zy­to­rium narzę­dzia CASE i tak jest łatwiej­sza w uży­ciu i per­cep­cji, sta­no­wi też nie­ja­ko auto­ma­tycz­ny wali­da­tor” czy jest ono – mapo­wa­nie – popraw­ne i kompletne.

TOGAF – subiektywnych słów kilka

O tym krót­ko. Wiem, że sta­no­wi swe­go rodza­ju gotow­ca”, ale czy skór­ka war­ta wypraw­ki? Celem budo­wa­nia AK nie jest wdro­że­nie TOGAF”a” (czy też Siatki Zachmann’a), celem jest … no wła­śnie co? O tym na końcu.

W przy­pad­ku TOGAF v 8.x mamy czte­ry obsza­ry modelowania:

  • Business Architecture
  • Data Architecture
  • Applications Architecture
  • Technology Architecture

(źr. The Open Group Architecture Framework Version 8.1.1., nowa wer­sja TOGAF 9, w porów­na­niu z powyż­szym, roz­cią­ga się na ele­men­ty moty­wa­cji biznesowej).

Nie będę się roz­pi­sy­wał na temat wszyst­kich warstw. Kilka słów o jed­nej: Architektura Danych.

TOGAF i ArchiMate (jak ja rozu­miem obie spe­cy­fi­ka­cje) ope­ru­je poję­ciem danych, oddzie­lo­nych od logi­ki biz­ne­so­wej. Obecnie sto­so­wa­ne meto­dy i narzę­dzia w pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia opar­te są na para­dyg­ma­cie obiek­to­wym, któ­ry kom­plet­nie igno­ru­je poję­cie wydzie­lo­nych danych jako takich. Mam tu na myśli bazy danych (w szcze­gól­no­ści rela­cyj­ne). Bazy danych, w meto­dach obiek­to­wych, to ele­men­ty imple­men­ta­cji, więc są one poza obsza­rem ana­li­zy i pro­jek­to­wa­nia. Przedmiotem prze­twa­rza­nia w para­dyg­ma­cie obiek­to­wym są obiek­ty biz­ne­so­we wraz z ich wewnętrz­ną logi­ką i zachowaniami.

Jaki jest więc sens brnię­cia wstecz do cza­sów ana­li­zy struk­tu­ral­nej (odręb­nie ana­li­zo­wa­ne i imple­men­to­wa­ne dane i funk­cje ich przekształcania)?

Przypomnę tu tyl­ko deli­kat­nie, że np. celem pro­ce­su sprze­da­ży nie są dane zapi­sa­ne na Fakturze VAT a pozy­ska­nie środ­ków ze sprze­da­ży pro­duk­tów, obiekt biz­ne­so­wy Faktura VAT wraz z regu­ła­mi nali­cza­nia podat­ku, to jakaś mate­ria­li­za­cja tego fak­tu a nie cel sam w sobie. Powoływanie się więc na dane” w moich oczach nie jest żad­nym postę­pem”.

Na zakończenie

Mamy więc pomysł o wdzięcz­nej nazwie Architektura Korporacyjna. Jej defi­ni­cję, moim zda­niem, moż­na spro­wa­dzić do treści:

Architektura Korporacyjna to model i jego doku­men­ta­cja, zawie­ra­ją­cy całą i wystar­cza­ją­cą wie­dzę o tym, co ma wpływ na dostar­cza­nie pro­duk­tu (J.Żeliński)

Po nam to? Po co nam taka doku­men­ta­cja? Przykłady korzy­ści z jej posiadania:

  • mamy na tacy” model sys­te­mu zależ­no­ści (w tym ana­li­za wpły­wu) pozwa­la­ją­cy natych­miast oce­nić ryzy­ka zwią­za­ne z wza­jem­nym wpły­wem na sie­bie pro­ce­sów, ludzi, zaso­bów (np. jakie skut­ki będzie mia­ło wyłą­cze­nie kon­kret­ne­go ser­we­ra czy spóź­nie­nie do pra­cy kon­kret­ne­go pracownika),
  • mamy na tacy” wyma­ga­nia na opro­gra­mo­wa­nie, bez nie­po­trzeb­ne­go zwin­ne­go” ich poszu­ki­wa­nia meto­dą prób i błę­dów, nie­za­leż­nie od tego czy kupu­je­my nowe czy wymie­nia­my (nie­ste­ty, tak zwa­ne zwin­ne meto­dy to nie raz bar­dzo duże kosz­ty zarzu­co­nych bocz­nych ście­żek” odkry­wa­nych burzą mózgów),
  • od razu zauwa­ży­my, że idea posia­da­nia mono­li­tycz­ne­go sys­te­mu ERP II nie bar­dzo ma sens, usztyw­nia orga­ni­za­cje oraz two­rzy potęż­ny [[„sin­gle point of failu­re”]] (zło­śli­wi doda­ją sin­gle point of big cost” :)),
  • i naj­waż­niej­sze: jak tyl­ko prze­pro­wa­dzi­my ana­li­zę i wyko­na­my model AK, szyb­ko wychwy­ci­my tak zwa­ne osie­ro­co­ne wyma­ga­nia na opro­gra­mo­wa­nie, osie­ro­co­ne sta­no­wi­ska pra­cy, osie­ro­co­ne pro­ce­du­ry, … (osie­ro­co­ne: nie­wy­ko­rzy­sty­wa­ne), to nie raz źró­dło samo w sobie – eli­mi­na­cja sie­rot” – ogrom­nych oszczęd­no­ści juz na samym począt­ku projektu,
  • i inne …

Jak tym zarzą­dzać? Na pew­no nie ręcz­nie, bez opro­gra­mo­wa­nia CASE w zasa­dzie nie­re­al­ne. Czy to kosz­tow­ne? Hm… kła­nia się ana­li­za ROI, każ­da orga­ni­za­cja ma swój próg ren­tow­no­ści. Jednak od sie­bie powiem tak: oszczęd­no­ści poja­wia­ją się natych­miast w posta­ci iden­ty­fi­ka­cji sie­rot”. Kolejny etap oszczęd­no­ści to reor­ga­ni­za­cja kosz­tów i ryzyk zarzą­dza­nia orga­ni­za­cją, kosz­tów posia­da­nia opro­gra­mo­wa­nia, kosz­tów jego roz­wo­ju, kosz­tów zaku­pu i two­rze­nia. Dobra wia­do­mość: począ­tek każ­dy już ma w posta­ci pro­wa­dzo­nej doku­men­ta­cji w dzia­le HR.

Jak więc wyglą­da­ją narzę­dzia rodem z OMG, któ­re w zupeł­no­ści wystarczą??

Jest to zestaw nota­cji (BMM, BPMN, UML), któ­ry ma nie­mal­że każ­dy pakiet CASE. Notację ArchiMate mają nie­ste­ty tyl­ko nie­któ­re z nich, a jak The Open Group zacznie egze­kwo­wać opła­ty licen­cyj­ne to będzie chy­ba tyl­ko gorzej (co cie­ka­we sami twó­cy ArchiMate piszą, że uszcze­gó­ło­wie­nie mode­lu AK wyko­na­ne­go z pomo­cą ArchiMate wyma­ga uży­cia nota­cji UML). Koszty jed­nej licen­cji pakie­tu CASE (nie raz wystar­czy mieć jed­ne­go Architekta w orga­ni­za­cji) w wie­lu przy­pad­kach nie prze­kra­cza­ją 1000USD. Jeżeli więc uda się unik­nąć kolej­nej ana­li­zy wyma­gań za kil­ka­dzie­siąt tysię­cy to już ROI mamy w kieszeni.

A po co te for­ma­li­zmy (pryn­cy­pia)? Na eta­pie ana­li­zy i mode­lo­wa­nia pozwa­la­ją wery­fi­ko­wać popraw­ność mode­li i całej struk­tu­ry. Na eta­pie zarzą­dza­nia zmia­ną pano­wać nad kosz­ta­mi zmian i ryzy­ka­mi w rodza­ju i czasopisma”…:)

Druga dobra wia­do­mość: spo­koj­nie moż­na to (rola Architekta) out­so­ur­so­wać, będzie jesz­cze taniej.