Duże projekty informatyczne czyli jakie?

Konstrukcje mecha­nicz­ne mają cykl życia nadal liczo­ny w latach: są to mosty i domy czy­li dzie­się­cio­le­cia, ale tak­że poje­dyn­cze lata, a nie raz nawet mie­sią­ce (patrz tele­fo­ny komór­ko­we). Sama inży­nie­ria zaś sta­je się coraz bar­dziej inter­dy­scy­pli­nar­na. Kiedyś pral­ka była w 100% mecha­nicz­nym wyro­bem, obec­nie szkie­let to nadal obu­do­wa, wir­nik i sil­nik, ale np. pro­gra­ma­tor to już nie jest mecha­nizm zega­ro­wy a pro­ce­sor, pamięć i opro­gra­mo­wa­nie. To ostat­nie teraz decy­du­je o klu­czo­wych funk­cjo­nal­no­ściach pralki.

Duża organizacja to duży projekt

Jak to wyglą­da w przy­pad­ku orga­ni­za­cji? Bardzo podob­nie: szkie­let orga­ni­za­cji to jej zaso­by mate­rial­ne (budyn­ki, maszy­ny, itp.) i zatrud­nie­ni ludzie. Te zaso­by mają w orga­ni­za­cjach wie­lo­let­ni cykl życia. Jednak logi­ka biz­ne­so­wa to na bie­żą­co usta­la­ne zasa­dy, zmie­nia­ją­ce się pra­wo a nie raz reak­cje ad-hoc. Czym jest opro­gra­mo­wa­nie wspo­ma­ga­ją­ce pra­cę orga­ni­za­cji? To jak zawsze, sys­tem zarzą­dza­ją­cy infor­ma­cją, tu jed­nak obo­wią­zu­ją regu­ły biz­ne­so­we, któ­re zmie­nia­ją się coraz częściej.

Problem ana­li­zy i pro­jek­to­wa­nia dużych sys­te­mów infor­ma­tycz­nych wymy­ka się tra­dy­cyj­nej inży­nie­rii opro­gra­mo­wa­nia opar­tej na bazach danych i funk­cjach. Kluczowym powo­dem jest rosną­ca szyb­kość zmian na ryn­ku i to, że opro­gra­mo­wa­nie z zasa­dy słu­ży do reali­za­cji okre­ślo­nej logi­ki biz­ne­so­wej, a ta, jak widać, szyb­ko się zmie­nia. Niedawno 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. 1

Czy nadal mówi­my o zin­te­gro­wa­nym sys­te­mie? Tak. Czy zin­te­gro­wa­ny to to samo co sta­no­wią­cy jed­ną fizycz­ną całość? Nie.

Duże mono­li­tycz­ne sys­te­my powsta­wa­ły w cza­sach, gdy zmien­ność ryn­ku była rela­tyw­nie mała. Bazy danych skła­da­ją­ce się z tysię­cy powią­za­nych na sta­łe tablic, sta­no­wią sobą coś, cze­go nie da się zmie­nić ina­czej niż prze­pro­jek­to­wać i doko­nać migra­cji ze sta­rej do nowej struk­tu­ry. Tylko, że taki pro­ces to nawet nie mie­sią­ce a lata. Logika biz­ne­so­wa zaszy­ta w tych struk­tu­rach to coś na podo­bień­stwo mecha­nicz­ne­go pro­gra­ma­to­ra będą­ce­go inte­gral­ną czę­ścią sta­rej pralki.

Jak to robić lepiej? Po pierw­sze nie kupo­wać ?dużych i dro­gich zin­te­gro­wa­nych sys­te­mów? bo to duże ryzy­ko, kupo­wać mniej­sze, łatwiej­sze do opi­sa­nia, pro­jek­to­wać i two­rzyć te, któ­re są zbyt dużym ryzy­kiem w przy­pad­ku złe­go wybo­ru. Jeżeli już z powo­du ryzy­ka mamy poświę­cić duży budżet na kosz­tow­ne spe­cy­fi­ko­wa­nie opro­gra­mo­wa­nia to sygnał, że nale­ży je za te pie­nią­dze po pro­stu zapro­jek­to­wać i wyko­nać. 2

Tak więc na tym eta­pie pro­jek­tu inży­nie­ria opro­gra­mo­wa­nia to pro­jek­to­wa­nie archi­tek­tu­ry a nie tra­dy­cyj­nie rozu­mia­ne zbie­ra­nie wyma­gań. Taka archi­tek­tu­ra to dzie­dzi­no­we pod­sys­te­my, zin­te­gro­wa­ne na pozio­mie wymia­ny klu­czo­wych doku­men­tów, któ­re opi­sy­wa­łem tu już wielokrotnie:

Każda fir­ma, szu­ka­jąc spo­so­bu na uzy­ska­nie prze­wa­gi ryn­ko­wej, sta­ra się pew­ne obsza­ry ope­ra­cyj­ne budo­wać wg, wła­snej stra­te­gii. To mię­dzy inny­mi powo­du­je, że każ­de wdro­że­nie jest inne i nie ma jed­nej jedy­nie-słusz­nej archi­tek­tu­ry IT. 3

Zarządzanie projektem

Zarządzanie pro­jek­tem zwią­za­nym z wdra­ża­niem opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go pra­ce orga­ni­za­cji, ma dwa eta­py i wyma­ga podzia­łu na role. To co teraz napi­szę nie jest żad­ną tajem­ną wie­dzą, to raczej zbiór dobrych praktyk.

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ą? 4

Wydawcy stro­ny Business Process Trends Associates5 pre­zen­tu­ją od lat trój­war­stwo­wy model orga­ni­za­cji. Autorzy dzie­lą struk­tu­rę opi­su na trzy war­stwy: opis stra­te­gii ryn­ko­wej (rola orga­ni­za­cji na ryn­ku: pro­ce­sy end-2-end), opis wewnętrz­nej stra­te­gii (jak reali­zo­wa­na jest stra­te­gia ryn­ko­wa: wewnętrz­ne pro­ce­sy biz­ne­so­we) oraz imple­men­ta­cji (jakie zaso­by są wyko­rzy­sty­wa­ne: pro­ce­du­ry, regu­ły biz­ne­so­we i sys­te­my IT).

Małe wdro­że­nia (pro­jek­ty w jed­nej loka­li­za­cji o war­to­ści poni­żej 100 tys. zł net­to) z regu­ły doty­czą pew­nych okre­ślo­nych i wąskich obsza­rów dzia­ła­nia i wąskiej gru­py zaso­bów. Ich wdra­ża­nie naj­czę­ściej nie wyma­ga żad­nych inge­ren­cji w orga­ni­za­cję pra­cy orga­ni­za­cji, sta­no­wią one pew­ne ele­men­ty auto­ma­ty­za­cji okre­ślo­nej pracy.

Projekty sta­no­wią­ce wyzwa­nie to te, któ­re skut­ku­ją zmia­ną wewnętrz­nej stra­te­gii. Tu zwró­cę uwa­gę, że prak­tycz­nie każ­de kom­plek­so­we wdro­że­nie opro­gra­mo­wa­nia to zmia­na pro­ce­dur, nawy­ków, nie raz całych pro­ce­sów biz­ne­so­wych, bywa, że cał­ko­wi­te prze­mo­de­lo­wa­nie pro­ce­sów biz­ne­so­wych wewnątrz orga­ni­za­cji. Wynika to z tego, że wdra­ża­nie nowych narzę­dzi pra­cy wyma­ga zmia­ny pro­ce­sów ich wyko­rzy­sta­nia. Wprowadzenie ele­men­tów auto­ma­ty­za­cji bar­dzo czę­sto cał­ko­wi­cie zmie­nia nie­któ­re procesy.

Powyższe powo­du­je, że pro­jek­ty takie powin­ny być poprze­dza­ne ana­li­za­mi, pro­jek­to­wa­niem nowe­go sta­nu rze­czy i testo­wa­niem skut­ków tych zmian. Główne role w tego typu pro­jek­tach to: spon­sor i bene­fi­cjent czy­li orga­ni­za­cja, któ­ra wdra­ża nowe roz­wią­za­nia oraz fir­ma wdra­ża­ją­ca. Sponsor naj­czę­ściej zna swój pro­blem i cel biz­ne­so­wy, ale z regu­ły nie ma kom­pe­ten­cji do opi­sa­nia (zapro­jek­to­wa­nia) roz­wią­za­nia, dostaw­ca roz­wią­za­nia zaś musi wie­dzieć co ma dostar­czyć. Pojawia się potrze­ba zaan­ga­żo­wa­nia nowej, trze­ciej kom­pe­ten­cji: ana­li­tyk pro­jek­tant roz­wią­zań. Któż to jest?

Potocznie ta rola nazy­wa­na jest Analityk Biznesowy6, jed­nak pro­dukt jaki powi­nien powstać na tym eta­pie to naj­pierw opis dzia­ła­nia orga­ni­za­cji (pro­ce­sy i regu­ły biz­ne­so­we, struk­tu­ry zarzą­dza­nej infor­ma­cji) a potem pro­jekt (opis) roz­wią­za­nia czy­li tego jak, co wdro­żyć, jak zmie­nić orga­ni­za­cję, by osią­gnąć cele biz­ne­so­we zało­żo­ne przez spon­so­ra pro­jek­tu. Całość moż­na przed­sta­wić tak:

Sponsor to kie­ru­ją­cy orga­ni­za­cją, te moż­na opi­sać na trzech pozio­mach jak na powyż­szym dia­gra­mie. Pierwszy etap to ana­li­za i mode­lo­wa­nie orga­ni­za­cji (pro­ce­sy i regu­ły biz­ne­so­we), zwień­cze­niem tego eta­pu jest pro­jekt roz­wią­za­nia sta­no­wią­ce­go spo­sób osią­gnię­cia celu biz­ne­so­we­go zde­fi­nio­wa­ne­go przez Sponsora. Tym roz­wią­za­niem czę­sto jest model wyma­ga­ne­go opro­gra­mo­wa­nia rozu­mia­ny jako spe­cy­fi­ka­cja usług jakie ma ono świad­czyć i logi­ka ich rela­cji (opro­gra­mo­wa­nie opi­sa­ne jako Platform Independent Model).

Zakresy dużych pro­jek­tów sta­no­wią sobą opis archi­tek­tu­ry całe­go sys­te­mu oraz opis role poszcze­gól­nych jego kom­po­nen­tów (pamię­ta­my, że mamy tak­że opis logi­ki biz­ne­so­wej). Powyższy dia­gram obra­zu­je spo­sób reali­za­cji duże­go projektu:

  1. Sponsor, wska­zu­jąc cel biz­ne­so­wy, zle­ca Analitykowi ana­li­zę biz­ne­so­wą i pro­jekt rozwiązania.
  2. Powstała doku­men­ta­cja słu­ży jako mate­riał do wyło­nie­nia dostaw­cy opi­sa­ne­go roz­wią­za­ne­go, ten jako pierw­szy krok, opra­co­wu­je Studium wyko­nal­no­ści (Koncepcję wdrożenia).
  3. Treść kon­cep­cji zawie­ra (powin­na) har­mo­no­gram wdro­że­nia poszcze­gól­nych kom­po­nen­tów roz­wią­za­nia, z uwa­gi na to, że całość trwa w cza­sie, pro­ces ten jest reali­zo­wa­ny ite­ra­cyj­nie (przy­ro­sto­wo).

Role w projekcie:

  1. Analityk pro­jek­tant, jako autor roz­wią­za­nia, nad­zo­ru­je reali­za­cję zarzą­dza­jąc zmia­na­mi w pro­jek­cie i uzu­peł­nia­jąc go o opra­co­wy­wa­ne w toku reali­za­cji i wdro­że­nia szcze­gó­ły. Z regu­ły jest to jed­na oso­ba spra­wu­ją­ca nad­zór merytoryczny.
  2. Dostawca roz­wią­za­nia to cały zespół spe­cja­li­stów (kie­row­nik pro­jek­tu, kon­sul­tan­ci, pro­gra­mi­ści, wdro­że­niow­cy, teste­rzy itd.) odpo­wie­dzial­ny za wdrożenie.
  3. Sponsor spra­wu­je pie­czę nad cało­ścią, zabez­pie­cza środ­ki i bie­żą­cy dostęp do wyma­ga­nych mate­ria­łów na temat orga­ni­za­cji (pamię­ta­my, że czas pły­nie a takie wdro­że­nia trwa­ją prze­cięt­nie od trzech do pię­ciu lat).

Podsumowanie

Opisałem tu spo­sób w jaki reali­zu­ję pro­jek­ty. Jest to, jak widać, zna­ne w lite­ra­tu­rze podej­ście. Taki podział na eta­py i role pozwa­la na jed­no­znacz­ne okre­śle­nie odpo­wie­dzial­no­ści. Osobiście nie nie mam prze­ko­na­nia do dużych zespo­łów kon­sul­tan­tów dorad­ców po stro­nie Sponsora, gdyż szy­bo docho­dzi do rywa­li­za­cji pomię­dzy nimi a człon­ka­mi zespo­łu dostaw­cy roz­wią­za­nia. Z dru­giej jed­nak stro­ny dostaw­ca powi­nien mieć świa­do­mość, że jego rola to wyko­na­nie imple­men­ta­cji roz­wią­za­nia a nie jego pro­jek­to­wa­nie. Cały pro­jekt to dwie stro­ny: Sponsor czy­li zama­wia­ją­cy wraz z Analitykiem pro­jek­tan­tem, oraz dostaw­ca roz­wią­za­nia. Taki podział uprasz­cza zarzą­dza­nie pro­jek­tem i jasno wska­zu­je odpo­wie­dzial­ność stron. Pierwszym pro­duk­tem jest model CIMPIM7 a dru­gim dostar­czo­ne zgod­nie z pro­jek­tem i i udo­ku­men­to­wa­ne roz­wią­za­nie. To są tyl­ko dobre i spraw­dzo­ne na świe­cie praktyki…

________________________________
1.
Zelinski J. Wymagania umar­ły. Rozwiązaniem jest cykl życia pro­duk­tu | | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//2017/01/13/wymagania-umarly-rozwiazaniem-jest-cykl-zycia-produktu/. Published January 13, 2017. Accessed October 9, 2018.
2.
Zelinski J. Wymagania na coś duże­go ? w czym pro­blem? | | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//2012/03/26/wymagania-na-cos-duzego-w-czym-problem/. Published March 2, 2015. Accessed October 9, 2018.
3.
Zelinski J. Komponenty sys­te­mów ERP | | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//2016/08/01/podsystemy-systemow-erp/. Published August 1, 2016. Accessed October 9, 2018.
4.
Zelinski J. Porażka za 2 mld zł. Lidl wyco­fu­je się z wdro­że­nia SAP | | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting – Analiza Biznesowa i Systemowa, Wymagania. https://it-consulting.pl//2018/08/11/porazka-za-2-mln-zl-lidl-wycofuje-sie-z-wdrozenia-sap/. Published August 11, 2018. Accessed October 9, 2018.
5.
BPTrends. BPTrends Associates. http://​www​.bptrend​sas​so​cia​tes​.com. Published October 9, 2018. Accessed October 9, 2018.
6.
Becoming a BA – IIBA | International Institute of Business Analysis . IIBA | International Institute of Business Analysis . http://​www​.iiba​.org/​C​a​r​e​e​r​s​/​B​e​c​o​m​i​n​g​-​a​-​B​u​s​i​n​e​s​s​-​A​n​a​l​y​s​t​.​a​spx. Published October 9, 2018. Accessed October 9, 2018.
7.
Model Driven Architekture. OMG​.org. https://​www​.omg​.org/​m​d​a​/​s​p​e​c​s​.​htm. Published October 9, 2018. Accessed October 9, 2018.
image_print(wydruk PL)

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.