Ujarzmić dane – ale po co ich aż tyle?

Moim zda­niem hur­tow­nie danych i wszel­kie­go typu sys­te­my BI mogą być sku­tecz­ne jako wykry­wa­nie cze­goś” w histo­rii, na pew­no spraw­dza­ją się jako zło­żo­ne sys­te­my rapor­to­wa­nia, ale nie sądzę by jaka­kol­wiek hur­tow­nia danych plus sys­tem BI odkry­ła cokol­wiek nowe­go lub sku­tecz­nie pro­gno­zo­wa­ła. […] Budowanie mode­li na bazie małych par­tii danych jest po pierw­sze wia­ry­god­niej­sze (para­dok­sal­nie) niż pro­ste wnio­sko­wa­nie sta­ty­stycz­ne, po dru­gie daje szan­se odkry­cia cze­goś nowe­go. W czym pro­blem? To dru­gie jest nie moż­li­we z pomo­cą deter­mi­ni­stycz­nej maszy­ny jaką jest kom­pu­ter. To wyma­ga czło­wie­ka, ten jed­nak nie daje się pro­du­ko­wać maso­wo… ;), kor­po­ra­cja na nim nie zarobi.

Hm… czy przy­pad­kiem pro­mo­wa­nie sys­te­mów hur­tow­ni danych, BI, pra­cy z tera­baj­ta­mi danych itp.. to nie two­rze­nie sobie ryn­ku przez dostaw­ców tych technologii?

Warto więc za każ­dym razem, zanim zain­we­stu­je­my w roz­wią­za­nia ope­ru­ją­ce na tera­baj­tach danych, prze­my­śleć co chce­my osią­gnąć. W zasa­dzie nie ma uza­sad­nie­nia dla trzy­ma­nia wszyst­kich danych, waż­ne jest okre­śle­nie jaki pro­blem chce­my roz­wią­zać. Jeżeli są to pro­ble­my zwią­za­ne z ana­li­zą danych histo­rycz­nych, bada­nia sta­ty­stycz­ne mogą być sku­tecz­ne, do tego pod­da­ją się auto­ma­ty­za­cji. Jeżeli jed­nak pro­blem tkwi w pla­no­wa­niu zmian, pro­gno­zo­wa­niu, odkry­wa­niu, pole­cam raczej czło­wie­ka i budo­wa­nie hipotez.

Czytaj dalej Ujarzmić dane – ale po co ich aż tyle?

Analiza biznesowa

Stosowanie opi­sa­nych tu for­ma­li­zmów to uzna­nie, że dobre i spraw­dzo­ne stan­dar­dy pozwa­la­ją zmi­ni­ma­li­zo­wać ryzy­ko pro­jek­tów analitycznych.

Analiza to nie zbie­ra­nie danych o fir­mie i ich sor­to­wa­nie, bo czy to nie brzmi jak eko­lo­gicz­ne zbie­ra­nie śmie­ci? Analiza to porząd­ko­wa­nie zebra­nej wie­dzy o orga­ni­za­cji, korzy­sta­jąc z wypra­co­wa­nych sys­te­mów poję­cio­wych, czy­li przy­po­rząd­ko­wy­wa­nie wszyst­kie­go co wie­my do skoń­czo­nej licz­by pojęć, oraz uzu­peł­nia­nie lub napra­wia­nie wszyst­kie­go cze­go zabra­nie w tak opra­co­wa­nym mode­lu. Kluczem dobrej ana­li­zy jest uogól­nia­nie czy­li wychwy­ty­wa­nie rze­czy istot­nych oraz odsie­wa­nie infor­ma­cji zbęd­nych, nie mają­cych wpły­wu na cel pro­jek­tu a zaciem­nia­ją­cych go. Analiza to odkry­wa­nie i rozu­mie­nie reguł, pano­wa­nie nad zło­żo­no­ścią organizacji.

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach złe i nie­kom­plet­ne wyma­ga­nia” czy zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia” to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich analiz.

Czytaj dalej Analiza biznesowa

Raport: Zarządzanie wymaganiami 2011

Ponad 80% pro­jek­tów pro­gra­mi­stycz­nych ma prze­kro­czo­ne ter­min i budżet. Największą trud­no­ścią w tych pro­jek­tach oka­za­ło się jasne zro­zu­mie­nie tego, cze­go tak napraw­dę klient potrze­bu­je, oraz udo­ku­men­to­wa­nie jego wyma­gań. Do prze­cho­wy­wa­nia wyma­gań uży­ty był głów­nie word i excel oraz ema­il. Przyznajemy jed­nak, że dia­gra­my naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi to mode­le pro­ce­sów i pro­to­ty­py, jed­nak nie sto­su­je­my ich. ( 2011 State of Requirements Management Report.)

Jak widać brzmi zna­jo­mo z dwóch powo­dów: pro­ble­my zna­ne każ­de­mu i powo­dy nie­ste­ty tak­że. Ciśnie mi się na usta a nie mówiłem”…

Czyli jed­nak wie­my że pro­ble­mem pro­jek­tów z zakre­su inży­nie­rii opro­gra­mo­wa­nia są zbyt pro­ste meto­dy i narzę­dzia zarzą­dza­nia wyma­ga­nia­mi (pakiet biu­ro­wy), któ­re w więk­szo­ści są sto­so­wa­ne. Wiemy, że mode­lo­wa­nie jest naj­sku­tecz­niej­sza meto­dą ana­li­zy i pro­jek­to­wa­nia a mimo to nie sto­su­je się tych metod szu­ka­jąc sta­le dro­gi na skróty”.

Dlaczego dostaw­cy opro­gra­mo­wa­nia nie sto­su­ją metod powszech­nie jed­nak uzna­wa­nych za skuteczne? 

Czytaj dalej Raport: Zarządzanie wymaganiami 2011

Agilian nowa wersja. Burza mózgów sformalizowana …

Po co nam CASE?

Bo

Dzięki narzę­dziom CASE pro­jek­ty two­rzy się dokład­niej, a pra­ca nad dia­gra­ma­mi, spraw­dza­nie ich popraw­no­ści oraz śle­dze­nie wyko­na­nych testów jest prost­sze i szyb­sze. (wie­cej: http://​www​.eio​ba​.pl)

Tak więc gorą­co pole­cam sto­so­wa­nie narzę­dzi (lista narzę­dzi CASE). 

Z zasa­dy nie rekla­mu­je opro­gra­mo­wa­nia. Uważam, że jego sprze­da­wa­nie to inna kom­pe­ten­cja. Jednak nie da się ukryć jestem użyt­kow­ni­kiem cze­goś”. Czym to jest? Pakiet typu [[CASE]] [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgra­de i… mamy burzę mózgów :):

Czytaj dalej Agilian nowa wersja. Burza mózgów sformalizowana …

BPM 2.0 czyli nowe mity…

Powyższego nie­ste­ty nie zro­zu­mia­łem (co to zna­czy moż­li­wo­ści wyko­rzy­sta­nia róż­nych metod do rela­tyw­nie łatwej inte­gra­cji z inny­mi wyko­rzy­sty­wa­ny­mi sys­te­ma­mi”), nie licząc tego, że fak­tycz­nie dobrze wdro­żo­ne sys­te­my wspo­ma­ga­ją­ce zarzą­dza­nie prze­pły­wem pra­cy i doku­men­tów, jest swe­go rodza­ju sys­te­mem pra­cy gru­po­wej. Integracja, jej łatwość i koszt zaś nie zale­ży od sys­te­mu BPM a tych inte­gro­wa­nych sys­te­mów ERP czy CRM.

Tak więc nie sądzę by moż­li­we było pro­jek­to­wa­nie i wdro­że­nie sys­te­mu bez służ infor­ma­tycz­nych”. Jednak dobrze zapro­jek­to­wa­ny i już wdro­żo­ny sys­tem BPM może pozwa­lać na kom­po­no­wa­nie kolej­nych nowych lub zmia­nę sta­rych pro­ce­sów, jed­nak tu moż­li­we jest jedy­nie uży­wa­nie wstęp­nie zapro­jek­to­wa­nych i zaim­ple­men­to­wa­nych pro­ce­sów i obiek­tów danych” jak z klocków.

Czytaj dalej BPM 2.0 czyli nowe mity…

Edukacja

Masz dużo czasu? Czytaj bloga, szukaj w Internecie! Nie masz czasu? Kup go ode mnie! Moje motto to: "Ludzie powinni się dzielić wiedzą. Zarabiać na życie powinni na tym co…

Czytaj dalej Edukacja

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ć?