Ach ten wstrętny, wścibski analityk

Cóż, zastą­pie­nie pro­ce­su ana­li­zy i pro­jek­to­wa­nia wer­bal­ną komu­ni­ka­cją to dro­ga na skró­ty: czer­wo­na strzał­ka. Czy to zła dro­ga? Droga na skró­ty to wspo­mnia­ne na począt­ku ryzy­ko, ogrom­ne bo sta­ty­sty­ki wska­zu­ją sta­le, że ok. 70 – 80% pro­jek­tów pro­gra­mi­stycz­nych ma poważ­ne kło­po­ty. Statystyki te są takie same od lat.

Od lat zna­ny jest powyż­szy pro­ces i mimo to zawsze jest te 80% klien­tów i ich dostaw­ców, któ­rzy doga­du­ją się, że ana­li­za i pro­jek­to­wa­nia żad­ne­mu z nich nie słu­ży… tak jak to napi­sa­no na początku.

Po co to napi­sa­łem? By każ­dy z Państwa sam, świa­do­mie, oce­niał ryzy­ko swo­ich pro­jek­tów. Rezygnacja z ana­li­zy i pro­jek­to­wa­nia to pod­ję­cie pew­ne­go ryzy­ka, przez klien­ta. Niestety rezy­gna­cja z ana­li­zy i pro­jek­to­wa­nia ze stro­ny dewe­lo­pe­ra to cza­sem dodat­ko­wo sku­tek uzna­nia, że ana­li­za i pro­jek­to­wa­nie leży poza kom­pe­ten­cja­mi pro­gra­mi­stów (Ci obiek­to­wo kodu­ją) wiec wybie­ra­ją jest dro­ga na skróty.

Czytaj dalej Ach ten wstrętny, wścibski analityk

Czy wymagania opisują tylko to co” system ma robić?

Bardzo czę­sto tak wła­śnie defi­niu­je się pro­dukt ana­li­zy wyma­gań: wyma­ga­nia funk­cjo­nal­ne opi­su­ją to co ma sys­tem robić. W dys­ku­sjach (ile mam ich za sobą :)) z pro­gra­mi­sta­mi prze­bi­ja się teza, że ana­li­tyk spe­cy­fi­ku­je to co” sys­tem ma robić, a oni już zała­twia spra­wę tego jak” ma to robić. W czym pro­blem? W tym, że funk­cjo­nal­no­ści to test roz­wią­za­nia a nie wyma­ga­nia! […] Przypadki uży­cia sta­no­wią bar­dzo mier­ne przy­bli­że­nie rze­czy­wi­sto­ści. […] Tak więc doku­ment wyma­gań to nie tyl­ko przy­pad­ki uży­cia. Te są raczej testem popraw­no­ści roz­wią­za­nia, czy model jest popraw­ny (przy­po­mi­nam, że przy­pad­ki uży­cia, poza ich sce­na­riu­sza­mi, zawie­ra­ją stan począt­ko­wy i stan koń­co­wy akcji użyt­kow­ni­ka). […] Programiści, pro­szę, nie uda­waj­cie, że zna­cie się na zarzą­dza­niu, mar­ke­tin­gu, biz­ne­sie, sprze­da­ży, ryn­ku, pro­duk­cji itp. bo to (poza pew­nie ist­nie­ją­cy­mi wyjąt­ka­mi) nie praw­da, a pro­jek­to­wa­nie na zasa­dzie wyda­je mi się że rozu­miem” to dro­ga do poraż­ki. […] System ERP moż­na wybrać na bazie pro­jek­tu na wyż­szym pozio­mie abs­trak­cji. Analizy fir­my tak­że pole­ga tu na opra­co­wa­niu mode­li pro­ce­sów. Jednak w tym wypad­ku ich celem jest stwo­rze­nie raczej mode­lu filo­zo­fii dzia­ła­nia” fir­my a nie pro­jek­to­wa­nie sys­te­mu od zera. 

Czytaj dalej Czy wymagania opisują tylko to co” system ma robić?

Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Stosowanie ana­li­zy sys­te­mo­wej, mode­lo­wa­nia oraz for­mal­nych nota­cji do two­rze­nia mode­li, powo­du­je, że wyni­ki ana­liz są dale­ko bar­dziej wia­ry­god­ne. Z regu­ły celem pra­cy ana­li­ty­ka biz­ne­so­we­go czy pro­jek­tan­ta jest opra­co­wa­nie opi­su reko­men­do­wa­ne­go roz­wią­za­nia. Może nim być doce­lo­wy model orga­ni­za­cji czy też opis opro­gra­mo­wa­nia jakie nale­ży dostar­czyć (bo nie zawsze wytwo­rzyć!). W pro­ce­sie for­mal­nej ana­li­zy sys­te­mo­wej (nie jest to ana­li­za sys­te­mu infor­ma­tycz­ne­go, to ana­li­za dowol­ne­go sys­te­mu), powsta­ją mode­le, któ­re testu­je­my. Taki model to naj­pierw hipo­te­za, a po wery­fi­ka­cji, jest to opis roz­wią­za­nia (pro­jekt tego co ma powstać). Idealną sytu­acją była by taka, a któ­rej mamy narzę­dzia do mode­lo­wa­nia każ­dej ana­li­zo­wa­nej dzie­dzi­ny. W kla­sycz­nej inży­nie­rii jest to rysu­nek tech­nicz­ny i zasa­dy obli­cza­nia wytrzy­ma­ło­ści, sfor­ma­li­zo­wa­ny sys­tem two­rze­nia sche­ma­tów elek­trycz­nych i elek­tro­nicz­nych i wie­le innych (zależ­nie od dzie­dzi­ny), nota­cje UML w inży­nie­rii opro­gra­mo­wa­nia. W sfe­rze zarzą­dza­nia mie­li­śmy do nie­daw­na bia­ła pla­mę, teraz mamy już BMM czy ArchiMate. Moim zda­niem utrzy­my­wa­nie, że moż­na coś sku­tecz­nie ana­li­zo­wać meto­da­mi nie­for­mal­ny­mi świad­czy raczej o nie­wie­dzy i bra­ku kompetencji. 

Czytaj dalej Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Wymagania na oprogramowanie ERP a analiza przedwdrożeniowa – gdzie różnica?

Tak więc ana­li­za wyma­gań to jest pra­ca wyko­na­na by opi­sać cze­go ocze­ku­je­my i doko­nać wybo­ru. Analiza przed­wdro­że­nio­wa to pra­ca wyko­ny­wa­na przez dostaw­cę, któ­re­go wybra­no, w celu opra­co­wa­nia spe­cy­fi­ka­cji prac jakie nale­ży wyko­nać by wdro­żyć dany pro­dukt. Dobrze wyko­na­ny model nie zawie­ra infor­ma­cji nad­mia­ro­wych, któ­re zawsze pod­no­szą koszt wyko­na­nia mode­lu a tak­że nie raz sta­no­wią zbęd­ne ogra­ni­cze­nia. Użycie takie­go mode­lu jako narzę­dzia wybo­ru sys­te­mu ERP jest bar­dzo sku­tecz­ne: wystar­czy go roze­słać do dostaw­ców i zapy­tać po pierw­sze czy ich sys­tem pasu­je do nie­go, jeże­li tak to ile kosz­tu­je ten pro­dukt rok po roku. Z takim mode­lem kupu­ją­cy nie musi udo­wad­niać, że jego ocze­ki­wa­nia mają sens (co nie raz zda­ją się pod­wa­żać dostaw­cy) a dostaw­ca musi zde­kla­ro­wać, że jego pro­dukt pasu­je do modelu. 

Czytaj dalej Wymagania na oprogramowanie ERP a analiza przedwdrożeniowa – gdzie różnica?

Kto jest winny porażki wdrożenia ERP

Artykuł jaki ukazał się w COMPUTERWORLD skłonił mnie do konfrontacji moich doświadczeń i obserwacji z jego treścią, uwagami innych doświadczonych specjalistów. Być może warto pokusić się o pewne wnioski i sugestie... Wina klienta Według niego…

Czytaj dalej Kto jest winny porażki wdrożenia ERP

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

celem dostaw­cy goto­we­go sys­te­mu ERP jest wdro­żyć go bez żad­nych mody­fi­ka­cji bo (jej kosz­ty) zja­da­ją mar­żę dostaw­cy. Celem kupu­ją­ce­go opro­gra­mo­wa­nie ERP, jest wspar­cie swo­ich pro­ce­sów biz­ne­so­wych a nie kopia cudzych. To dwa sprzecz­ne inte­re­sy. Silna fir­ma wymu­si na dostaw­cy ERP zmia­ny, sła­ba nie raz pod­da­je się wie­rząc tezom dostaw­cy, że nowy sys­tem upo­rząd­ku­je stan ich orga­ni­za­cji i da prze­wa­gę nad kon­ku­ren­cją. Kto tu ma rację?

Czytaj dalej Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

SaaS c.d.

?Termin SaaS pochodzi z języka angielskiego i jest skrótem wyrażenia ?Software as a Service?. W języku polskim jego odpowiednikiem jest termin ?Oprogramowanie jako usługa?. SaaS polega na zdalnym udostępnieniu oprogramowania…

Czytaj dalej SaaS c.d.

W co inwestować w kryzysie c.d. – SOA

Podstawową więc wyż­szo­ścią, dają­cą prze­wa­gę na ryn­ku, jest zwin­ność orga­ni­za­cji mają­cej luź­no powią­za­ne ele­men­ty (zaso­by, w tym infor­ma­tycz­ne) współ­pra­cu­ją­ce ze sobą na bazie ?kon­trak­tów?. SOA to nic inne­go jak taka wła­śnie struk­tu­ra sys­te­mu infor­ma­tycz­ne­go: spe­cja­li­zo­wa­ne apli­ka­cje, kom­po­nen­ty, insta­lo­wa­ne (wdra­ża­ne) do reali­za­cji kon­kret­nych potrzeb zaso­bów takich jak pra­cow­ni­cy księ­go­wo­ści, pra­cow­ni­cy sprze­da­ży, pra­cow­ni­cy pro­duk­cyj­ni, itp.. W tym kon­tek­ście moż­li­we jest osza­co­wa­nie zwro­tu z inwe­sty­cji w SOA jako wdro­że­nie spo­so­bu reali­za­cji stra­te­gii infor­ma­ty­za­cji fir­my. SOA jako pro­jekt tech­no­lo­gicz­ny bez pod­bu­do­wy zarząd­czej moim zda­niem nie ma żad­ne­go sen­su gdyż to stra­te­gia zarzą­dza­nia jest w sta­nie poka­zać jakim kosz­tem jest sens tą stra­te­gie wdra­żać. Pytanie o zwrot z inwe­sty­cji w SOA bez tej wie­dzy moim zda­niem pozo­sta­nie bez odpo­wie­dzi z powo­du bra­ku danych.

Czytaj dalej W co inwestować w kryzysie c.d. – SOA