Big data ? czy na pewno więcej znaczy lepiej?

Nagromadzenie danych to jesz­cze nie jest nauka (Galileusz)

Duże bazy danych na okre­ślo­ny temat – naj­czę­ściej mowa o zacho­wa­niach klien­tów ? to ostat­nio temat pierw­szych, naj­da­lej dru­gich, stron gazet. BigData to temat prze­wod­ni kon­fe­ren­cji i arty­ku­łów na pierw­szych stro­nach perio­dy­ków bran­ży IT. W 2011 roku arty­kuł na podob­ny temat koń­czy­łem pytając:

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 tech­no­lo­gii? (Ujarzmić dane – ale po co ich aż tyle?). Ale po kolei. Jednak pro­blem nadal jest. Redakcja COMPUTERWORLD tak zachę­ca do udzia­łu w swo­jej kon­fe­ren­cji z BigData w tytu­le (frag­ment):

Big Data nie jest tyl­ko kolej­nym hasłem mar­ke­tin­go­wym dostaw­ców IT. To anty­cy­pa­cja zja­wi­ska prze­kro­cze­nia masy kry­tycz­nej wiel­ko­ści, róż­no­rod­no­ści, licz­by i dyna­mi­ki źró­deł gro­ma­dzo­nych w przed­się­bior­stwie danych. Gdy mamy ich napraw­dę dużo, gdy pocho­dzą one z wie­lu róż­nych miejsc, gdy są sta­le aktu­ali­zo­wa­ne i cią­gle ich przy­by­wa, wte­dy moż­li­wo­ści ana­li­tycz­ne i poten­cjał wyko­rzy­sta­nia wie­dzy zgro­ma­dzo­nej w tych danych rośnie wykład­ni­czo. Ale wyma­ga to cał­kiem nowych plat­form tech­no­lo­gicz­nych i zesta­wów kompetencji.

Wniosek jaki wysnu­to: potrzeb­na nowa, ?lep­sza? tech­no­lo­gia. Czy aby na pew­no? Jeżeli jed­nak BigData ma nie być kolej­nym hasłem mar­ke­tin­go­wym to zna­czy, że nie jest naj­lep­szym roz­wią­za­niem kupie­nie kolej­ne­go jesz­cze więk­sze­go i jesz­cze szyb­sze­go ?sprzę­tu?. Moim zda­niem w dal­szej czę­ści zapro­sze­nia zwró­co­no uwa­gę na kie­ru­nek dają­cy więk­sze szan­se powodzenia:

Liczba danych gro­ma­dzo­nych w biz­ne­sie przy­ra­sta rocz­nie o 50 pro­cent. Więcej jed­nak wca­le nie zna­czy lepiej – by hasło Big Data prze­ło­ży­ło się na Big Business potrze­ba nowych umie­jęt­no­ści, odpo­wied­nich narzę­dzi i odpo­wied­niej stra­te­gii zarzą­dza­nia infor­ma­cją. (źr. Zaproszenie na kon­fe­ren­cję BigData COMPUTERWORLD luty 2013)

Pada hasło stra­te­gia, na któ­rym posta­ram się sku­pić w dal­szej czę­ści. Wcześniej jed­nak zde­fi­niuj­my poję­cie BigData by wia­do­mo było o czym tu będę traktował:

W 2001 roku META Group (obec­nie Gartner) opu­bli­ko­wa­ła raport, któ­ry opi­su­je big data w mode­lu 3V. Wskazuje on na dużą ilość danych (Volume), dużą zmien­ność danych (Velocity) oraz dużą róż­no­rod­ność danych (Variety). W 2012 roku Gartner uzu­peł­nił poda­ną wcze­śniej defi­ni­cję wska­zu­jąc, iż ?big data to zbio­ry infor­ma­cji o dużej obję­to­ści, dużej zmien­no­ści i/lub dużej róż­no­rod­no­ści, któ­re wyma­ga­ją nowych form prze­twa­rza­nia w celu wspo­ma­ga­nia podej­mo­wa­nia decy­zji, odkry­wa­nia nowych zja­wisk oraz opty­ma­li­za­cji pro­ce­sów?. (źr. BigData WIKI)

Tak wiec mamy defi­ni­cję: big data to zbio­ry infor­ma­cji o dużej obję­to­ści, dużej zmien­no­ści i/lub dużej róż­no­rod­no­ści. Resztę pomi­ną­łem zda­nia pomi­ną­łem, gdyż to cze­go BigData wyma­ga nie jest przed­mio­tem defi­ni­cji pojęcia.

Na czym pole­ga pro­blem biz­ne­so­wy? Generalnie ludzie (o heu­ry­sty­kach już pisa­łem) sto­su­ją meto­dy induk­cyj­ne jako narzę­dzie wycią­ga­nia wnio­sków. Indukcja to w naukach empi­rycz­nych meto­da pole­ga­ją­ca na wpro­wa­dze­niu uogól­nień na pod­sta­wie eks­pe­ry­men­tów i obser­wa­cji fak­tów, for­mu­ło­wa­niu i wery­fi­ka­cji hipo­tez. Zaczątki induk­cji w sen­sie nowo­żyt­nym stwo­rzył F. Bacon, któ­ry uznał, że induk­cja i eks­pe­ry­ment to dwie sku­tecz­ne meto­dy usta­la­nia praw­dy. Słowo klucz tu to ?fak­ty?. Z induk­cją mają do czy­nie­nia wszy­scy, któ­rzy korzy­sta­ją z ana­li­zy tren­dów (np. ana­li­za tech­nicz­na w przy­pad­ku ana­li­zy kur­sów walut czy akcji).

Problem z induk­cją, jako meto­dą, pole­ga na tym, że w zasa­dzie spro­wa­dza się do pró­by oce­ny tego, z jakim praw­do­po­do­bień­stwem powtó­rzy się histo­ria bada­ne­go zja­wi­ska. Metoda ta nie pro­wa­dzi do nowych odkryć, pro­wa­dzi do mode­li opi­su­ją­cych praw­do­po­do­bień­stwo powtó­rze­nia się fak­tów, o któ­rych mamy wie­dzę, że wystąpiły.

Firmy, w mia­rę roz­wo­ju tech­no­lo­gii i roz­bu­do­wy swo­ich pro­ce­sów biz­ne­so­wych, gro­ma­dzą coraz więk­sze ilo­ści danych o zna­nych im fak­tach ze swo­jej histo­rii. Rejestrowane są coraz dokład­niej i ?gęściej? w cza­sie, wszel­kie zda­rze­nia na fir­mo­wych stro­nach WWW, wszel­ka wie­dza o zda­rze­niach w pro­wa­dzo­nej dzia­łal­no­ści. Firmy popy­cha do tego wia­ra w to, że im wię­cej danych tym lep­sze wnio­ski. Praktyka jed­nak poka­zu­je, że rosną­ca dokład­ność ?prób­ko­wa­nia? np. zacho­wań klien­tów nie pro­wa­dzi do pro­por­cjo­nal­ne­go wzro­stu zamó­wień. Owszem, pozna­jąc te zacho­wa­nia moż­na lepiej zaadre­so­wać ofer­tę, to praw­da ale nie jest to zależ­ność liniowa.

Do 2015 roku ponad 85 proc. firm skla­sy­fi­ko­wa­nych w ran­kin­gu Fortune 500 nie będzie potra­fi­ło efek­tyw­nie wyko­rzy­stać posia­da­nych zbio­rów danych, bowiem wystą­pi efekt tzw. big data. Co więc z tymi dany­mi robić? Ignorować je trosz­kę. Jeżeli praw­dą jest, że dziś, w cią­gu zale­d­wie dwóch dni pro­du­ku­je­my tyle danych, ile ludz­kość wytwo­rzy­ła od zara­nia dzie­jów do roku 2003, to porów­nu­jąc to z postę­pem doko­na­nym w cią­gu ostat­niej deka­dy z postę­pem ostat­nich dwóch tysię­cy lat, wnio­sek nasu­wa się jeden: raczej nie ilość danych decy­du­je o wie­dzy i postę­pie. Więc co?

W opo­zy­cji do induk­cji jako meto­dy pozna­nia (epi­ste­mo­lo­gia) stoi deduk­cja. Dedukcja to rozu­mo­wa­nie pole­ga­ją­ce na wypro­wa­dza­niu z prze­sła­nek (zdań) uzna­nych za praw­dzi­we na pod­sta­wie fak­tów, następ­stwa będą­ce­go logicz­nym i praw­dzi­wym wnio­skiem. Innymi sło­wy, deduk­cja pole­ga posta­wie­niu hipo­te­zy na pod­sta­wie pew­nej ogra­ni­czo­nej licz­by danych (fak­tów), udo­wod­nie­niu jej słusz­no­ści (poprzez brak fak­tów prze­czą­cych tej tezie – nie­uda­na fal­sy­fi­ka­cja) i wycią­ga­niu wnio­sków o przy­szło­ści. Jak dowo­dzi się takiej hipo­te­zy? Testuje się spraw­dza­jąc, czy popraw­nie opi­su­je zna­ny z histo­rii fak­ty. Innymi sło­wy: jeże­li nie odkry­to fak­tów oba­la­ją­cych tezę (poka­zu­ją­cych, że jest nie­praw­dzi­wa) uzna­je się ją za poprawną.

Typowym przy­kła­dem induk­cji jest pro­gno­zo­wa­nie pogo­dy na bazie zna­nych z histo­rii fak­tów: pro­gno­za była uzna­niem, że powtó­rzy się okre­ślo­na sytu­acja zaob­ser­wo­wa­na w prze­szło­ści (np. nisko lata­ją­ce jaskół­ki zapo­wia­da­ją desz­cze). Obecne pro­gno­zy to deduk­cja: na bazie okre­ślo­nej par­tii danych opra­co­wa­no tezę: model fizycz­ny atmos­fe­ry i zja­wisk w niej zacho­dzą­cych. Model ten, po poda­niu danych o sta­nie obec­nym atmos­fe­ry, pozwa­la na wnio­sko­wa­nie (wyli­cze­nie) jego sta­nu na dzień lub tydzień następ­ny (tu krót­ko i śred­nio­ter­mi­no­wa pro­gno­za). Co cie­ka­we, ta meto­da (deduk­cja) pozwa­la na prze­wi­dy­wa­nie fak­tów, któ­re nie zaszły w prze­szło­ści (z praw­do­po­do­bień­stwem wyni­ka­ją­cym z jako­ści uży­te­go mode­lu i kosz­tu obliczeń).

Dedukcję jako meto­dę pozna­nia (meto­da dowo­dze­nia poprzez sta­wia­nie hipo­tez i ich fal­sy­fi­ka­cję) opi­sał Karl Popper. Nosi ona obec­nie nazwę ?meto­dy naukowej?.

Jak to się ma do nasze­go BigData? Moim zda­niem BigData to śle­pa ulicz­ka. Rosnące nakła­dy na sprzęt i opro­gra­mo­wa­nie zmniej­sza­ją jedy­nie błąd sta­ty­stycz­ny obli­czeń nie wno­sząc nic do ich jako­ści w rozu­mie­niu ?jako­ści pro­gno­zo­wa­nia?. Co do ?odkry­wa­nia? cze­go­kol­wiek nie ma mowy, udo­wod­nio­no, że meto­da­mi induk­cyj­ny­mi nie da się nicze­go nowe­go odkryć, moż­na co naj­wy­żej udo­ku­men­to­wać trend. Owszem, pozo­sta­je kwe­stia ana­li­zy kore­la­cyj­nej, czy­li wykry­wa­nia związ­ków pomię­dzy fak­ta­mi (np. czy pora dnia wpły­wa na decy­zje zaku­po­we). Tego typu ana­li­zy nie są niczym nowym, są zna­ne wśród spe­cja­li­stów z zakre­su Business Inteligence od dawna.

Tak więc klu­czo­wą stra­te­gią wyda­je się tu być tak zwa­ny pro­gram reten­cyj­ny, czy­li stra­te­gia wybo­ru danych do prze­cho­wy­wa­nia (i usu­wa­nie pozo­sta­łych), bo nie da się zapa­mię­tać? wszyst­kie­go. Jednym z ?mod­nych? ele­men­tów stra­te­gii sprze­da­żo­wych są tak zwa­ne pro­gra­my part­ner­skie. Maciej Tesławski (eks­pert z zakre­su mar­ke­tin­gu) na swo­im blo­gu pisze:

Programy reten­cyj­ne mogą być B2B, B2C i mul­ti­part­ner­skie, lojal­no­ścio­we mogą być tyl­ko B2C bo w biz­ne­sie decy­zje zaku­po­we podej­mu­je się w znacz­nym stop­niu racjo­nal­nie a nie emo­cjo­nal­nie. Jeśli cho­dzi o oce­nę dzia­ła­ją­cych pro­gra­mów reten­cyj­nych, to pod­sta­wo­wy błąd jaki widzę to nie­wy­ko­rzy­sty­wa­nie bazy infor­ma­cji o uczest­ni­kach pro­gra­mu przez fir­my. To jest potęż­ny zbiór infor­ma­cji o zacho­wa­niach poszcze­gól­nych kon­su­men­tów, w połą­cze­niu z dany­mi demo­gra­ficz­ny­mi pozwa­la na ?pozna­nie? pro­fi­lu naj­bar­dziej war­to­ścio­wych kon­su­men­tów. Nie zauwa­ży­łem aby kto­kol­wiek to wyko­rzy­sty­wał. Dzieje się tak zapew­ne dla­te­go, że bazy danych rosną w postę­pie geo­me­trycz­nym i prze­ra­sta­ją moż­li­wo­ści ich bie­żą­ce­go wykorzystywania.

Skoro tak, to wie­my co ? pozo­sta­je jak. Jak zauwa­żo­no na począt­ku, przy­ra­sta­ją­ca ilość danych, a raczej korzy­sta­nie z nich, wyma­ga cał­kiem nowych plat­form tech­no­lo­gicz­nych i zesta­wów kom­pe­ten­cji. Platformy tech­no­lo­gicz­ne są, postęp tech­nicz­ny nam je zapew­nia. Wydaje się, że klu­czem jest ?nowy zestaw kompetencji?.

Moim zda­niem duży­mi kro­ka­mi nad­cho­dzi czas, gdy z ana­li­zy sta­ty­stycz­nej nale­ży się prze­rzu­cić na ana­li­zę sys­te­mo­wą ? deduk­cję, oraz odpo­wied­nie stra­te­gie reten­cji danych. W nie­daw­nej prze­szło­ści stwier­dzo­no, że rosną­ca ilość danych i dal­sze uszcze­gó­ło­wia­nie danych o zmia­nach tem­pe­ra­tu­ry, ciśnie­nia, wiel­ko­ści opa­dów nie popra­wia­ją jako­ści pro­gnoz pogo­dy. Zmieniono podej­ście i jak widać uda­ło się, pro­gno­zy pogo­dy nigdy nie były tak dokład­ne jak w ostat­niej deka­dzie a nie jest to efekt BigData.

Od tech­no­lo­gii teraz nie ocze­ki­wał bym ogrom­nych pojem­no­ści a mocy obli­cze­nio­wej, tu widzę dro­gę do suk­ce­su: ana­li­za ogra­ni­czo­nej ilo­ści fak­tów, budo­wa­nie mode­li zacho­wań np. kon­su­men­tów, pro­gno­zo­wa­nie tych zacho­wać. Myślę też, że pew­ne­go pro­gu jako­ści pro­gnoz nie prze­kro­czy­my. Filozofia dowo­dzi, że nie da się stwo­rzyć w świe­cie real­nym demiur­ga (w filo­zo­fii Platona okre­śla­no tak budow­ni­cze­go świa­ta nada­ją­ce­go kształ­ty wiecz­nej, bez­kształt­nej mate­rii według wzor­ców, jakie sta­no­wią dosko­na­łe idee; w filo­zo­fii nowo­żyt­nej demon potra­fią­cy obli­czyć przy­szły stan świa­ta na pod­sta­wie wie­dzy o wszyst­kich ato­mach i pra­wach nimi rzą­dzą­cych). Praktyka poka­zu­je, że nie ist­nie­je i dłu­go nie powsta­nie taka moc obli­cze­nio­wa by choć trosz­kę się do demiur­ga zbliżyć.

A czym jest ta ana­li­za sys­te­mo­wa i mode­lo­wa­nie? Wyobraźmy sobie kogoś, kto chce prze­wi­dy­wać zacho­wa­nia kul pod­czas gry w sno­oke­ra. Problem ten może zostać opi­sa­ny fak­ta­mi opi­su­ją­cy­mi grę powierz­chow­nie: ?Gracz ude­rza bia­łą kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­ną odle­głość w pew­nym kie­run­ku.? Można sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać z dowol­na dokład­no­ścią para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzy­my nawet dość dobrej symu­la­cji. Aby stwo­rzyć na praw­dę dobrą symu­la­cję, nale­ży zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li znacz­nie łatwiej prze­wi­dzieć sku­tek każ­de­go ude­rze­nia.? (na pod­sta­wie Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997).

P.S.

W ramach uzu­peł­nie­nia dys­ku­sji o induk­cji zamiesz­czam cytat z Karla Poppera, jed­na z wie­lu obec­nych opi­nii o induk­cji jako metodzie:

indukcja, trendy, wnioskowanie, popper, hume

Polecam teą arty­ku­ły wcześnijesze:

Symulacja procesów i działań w BPMN

Rok temu wspo­mnia­łem o rachun­ku kosz­tów dzia­łań i roli mode­li pro­ce­sów biz­ne­so­wych w tych ana­li­zach. Generalnie cho­dzi o to, że rachu­nek kosz­tów dzia­łań wyma­ga wyso­kiej jako­ści (spój­nej i kom­plet­nej!) spe­cy­fi­ka­cji tych­że dzia­łań (czyn­no­ści). Aż się pro­si by użyć mode­lu pro­ce­sów biz­ne­so­wych jako źró­dła dla opra­co­wa­nia tej spój­nej i kom­plet­nej spe­cy­fi­ka­cji działań.

Dalej będzie pole­mi­ka z sen­sow­no­ścią korzy­sta­nia z narzę­dzie (opcji) symu­lo­wa­nia pro­ce­sów biz­ne­so­wych. Najpierw jed­nak poku­si­łem się o krót­kie poszu­ki­wa­nie w sie­ci, pierw­szy z brze­gu wpis o meto­dzie ABC zarzą­dza­nia kosztami:

Rachunek kosz­tów dzia­łań ABC (kal­ku­la­cja ABC) okre­śla nową struk­tu­rę i zasa­dy kal­ku­la­cji kosz­tów pośred­nich, słu­ży zatem do dokład­ne­go usta­le­nia wiel­ko­ści kosz­tów pośred­nich przy­pa­da­ją­cych na dany pro­dukt. Zgodnie z kon­cep­cją ABC kosz­ty pośred­nie roz­li­cza się na pro­duk­ty w prze­kro­ju dzia­łań i pro­ce­sów gene­ru­ją­cych te kosz­ty, a nie w prze­kro­ju pod­mio­tów pro­duk­cyj­nych (np. wydziałów).

Rachunek ten stano­wi nową meto­dę pomia­ru i kal­ku­la­cji kosz­tów. Zgodnie z nią kosz­ty po­średnie są roz­li­cza­ne na pro­duk­ty za pomo­cą wie­lu róż­nych pod­staw rozli­czeń (cost dri­vers). Niektóre z nich mogą być pro­por­cjo­nal­ne do wiel­ko­ści pro­duk­cji, inne zaś nie muszą pozo­sta­wać w bez­po­śred­nim związ­ku przy­czy­­no­wo-skut­ko­wym z ilo­ścią wytwo­rzo­nych produktów.

Podstawy roz­li­cze­nia kosz­tów słu­żą do roz­dzie­la­nia kosz­tów pośred­nich na pro­duk­ty, spowodo­wanych róż­ny­mi wewnętrz­ny­mi dzia­ła­nia­mi lub pro­ce­sa­mi (acti­vi­ties), nie­zbędnymi do wytwo­rze­nia i sprze­da­ży okre­ślo­nych pro­duk­tów znaj­du­ją­cych się w pro­gra­mie pro­duk­cyj­nym przed­się­bior­stwa. Podstawy te słu­żą jedno­cześnie do pomia­ru roz­mia­rów okre­ślo­nych dzia­łań. Powinny one być pro­por­cjo­nal­ne do kosz­tów gene­ro­wa­nych przez okre­ślo­ne dzia­ła­nia, któ­rych kosz­ty pod­le­ga­ją rozliczeniu.

W prak­ty­ce moż­na zde­fi­nio­wać dużą licz­bę pro­ce­sów gospo­dar­czych pro­wa­dzą­cych do powsta­nia pro­duk­tu na wyj­ściu”, poczy­na­jąc od dzia­łań ogól­nych, a koń­cząc na dzia­ła­niach w mikro­ska­li. Kalkulacja typu ABC, okre­śla­na jako kal­ku­la­cja opar­ta na dzia­ła­niach lub ele­men­tar­nych pro­ce­sach, jest prze­ciw­staw­ną meto­dą w sto­sun­ku do tra­dycyjnych sys­te­mów kal­ku­la­cji kosztów.

(za Rachunek kosz­tów dzia­łań ? Encyklopedia Zarządzania).

Zwrócę tu uwa­gę, że celem kon­tro­lin­gu jest mię­dzy inny­mi zarzą­dza­nie kosz­ta­mi, ich śle­dze­nie (reali­za­cja budże­tu) i ich wcze­śniej­sza symu­la­cja (pro­gno­zo­wa­nie budżetu).

Raz po raz spo­ty­kam się z dedy­ko­wa­ny­mi narzę­dzia­mi lub roz­sze­rze­nia­mi, słu­żą­cy­mi do symu­la­cji kosz­tów (nie raz tak­że cza­su trwa­nia) pro­ce­sów biz­ne­so­wych wprost na bazie ich mode­li. Z regu­ły two­rzo­ne są nie­for­mal­ne roz­sze­rze­nia na dia­gra­mach pro­ce­sów (np. dość czę­sto spo­ty­ka­ny [[dia­gram alo­ka­cji BPMN]] i róż­ne jego wcie­le­nia, któ­re­go po pro­stu nie ma w spe­cy­fi­ka­cji i doda­wa­nie tu akro­ni­mu BPMN jest pew­nym nad­uży­ciem. two­rzo­ne dia­gra­my są następ­nie bar­dzo kom­pli­ko­wa­ne co nie raz czy­ni je wręcz nie­przy­dat­ny­mi (słu­żą tak­że do komu­ni­ko­wa­nia) z uwa­gi na nie­czy­tel­ność (lub ogrom­ną trud­ność w czy­ta­niu). Diagramy takie są tak­że bar­dzo pra­co­chłon­ne w wykonaniu. 

Wielokrotnie spo­ty­ka­łem w pro­jek­tach ludzi zaj­mu­ją­cych się kon­tro­lin­giem i w zasa­dzie zawsze uwa­ża­ją, że to (symu­la­cje na mode­lu pro­ce­sów) to duża pra­co­chłon­ność ich two­rze­nia i zero­wa przy­dat­ność, gdyż wyznacz­ni­kiem do podej­mo­wa­nia decy­zji i tak są narzę­dzia kon­tro­lin­go­we opar­te (nie raz) na hur­tow­niach danych i sys­te­mach [[Business Inteligence]] (z resz­tą mię­dzy inny­mi w tym celu one powstały).

Na ryn­ku jest bar­dzo wie­le, bar­dzo dobrze dopra­co­wa­nych narzę­dzi kon­tro­lin­go­wych. Narzędzia do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych wzbo­ga­ca­ne o modu­ły symu­la­cji to co naj­wy­żej namiast­ka ich moż­li­wo­ści. Owszem, na pew­nym wyso­kim pozio­mie ogól­no­ści taka symu­la­cja z pomo­cą pro­ce­su BPMN może dać obraz zja­wi­ska, ale nie trak­to­wał bym tego jako alter­na­ty­wy dla kon­tro­lin­gu rozu­mia­ne­go jako kom­pe­ten­cja w obsza­rze zarzą­dza­nia i finansów.

Symulatory w narzę­dziach do mode­lo­wa­nia z uży­ciem BPMN dosko­na­le nada­ją się do testo­wa­nia two­rzo­nych dia­gra­mów (zaklesz­cza­nie się mode­lu, testy w ana­li­zach cią­gło­ści dzia­ła­nia pro­ce­su itp.) ale raczej nie widzę sen­su kon­ku­ro­wa­nia z sys­te­ma­mi BI. Owszem, model pro­ce­sów daje bar­dzo dobry wsad” w posta­ci listy wymia­rów dla BI, ale nie jest to w moich oczach kon­ku­ren­cyj­ne rozwiązanie.

W dużym skró­cie: nie war­to dublo­wać kom­pe­ten­cji bo to nomen omen powie­la­nie ich kosz­tów. Jeżeli fir­ma ma wdro­żo­ne pro­ce­du­ry kon­tro­lin­go­we, to natu­ral­nym jest prze­ka­za­nie danych (pro­duk­tu) mode­lo­wa­nia i opty­ma­li­za­cji pro­ce­sów, zamiast wza­jem­ne kon­ku­ro­wa­nie, tym bar­dziej, że dane z kon­tro­lin­gu zawsze – jak sądzę – zosta­ną uzna­ne za bar­dziej wia­ry­god­ne . Bardzo dobrym narzę­dziem” łączą­cym kon­tro­ling, mode­lo­wa­nie pro­ce­sów i zaso­by (nie tyl­ko IT) jest archi­tek­tu­ra kor­po­ra­cyj­na, ale to mate­riał na kolej­ny artykuł ;).

Jak bronić się przed zalewem danych? Ignorować je… troszkę

Najpierw anons prasowy:

Do 2015 roku ponad 85 proc. firm skla­sy­fi­ko­wa­nych w ran­kin­gu Fortune 500 nie będzie potra­fi­ło efek­tyw­nie wyko­rzy­stać posia­da­nych zbio­rów danych, bowiem wystą­pi efekt tzw. big data. Eksperci pro­gno­zu­ją, że zarzą­dza­nie tymi ogrom­ny­mi zbio­ra­mi danych będzie jed­ną z klu­czo­wych kom­pe­ten­cji firm w cią­gu naj­bliż­szych 3 – 5 lat. A ci, któ­rzy zain­we­stu­ją w odpo­wied­nie roz­wią­za­nia, mogą osią­gnąć trwa­łą prze­wa­gę kon­ku­ren­cyj­ną na ryn­ku. Mogą tak­że zwięk­szyć zysk ope­ra­cyj­ny nawet do 60 proc. (za Jak fir­my mogą bro­nić się przed zale­wem danych?. wnp​.pl | Informatyka. Informatyka dla prze­my­słu.).

Jak widać gro­zi nam nie­moc! Ale czy aby na pew­no tak jest albo musi być? Czy na pew­no nale­ży wyda­wać ogrom­ne środ­ki na sys­te­my wspo­ma­ga­nia decyzji?

A teraz próba ugryzienia tematu

Analiza zda­rzeń gospo­dar­czych (zda­rzeń z histo­rii), w celu wykry­cia jakiej­kol­wiek pra­wi­dło­wo­ści zakła­da, że pra­wi­dło­wość taka ist­nie­je. Wobec tego zakła­da­my, że bada­my coś ist­nie­ją­ce­go (zależ­ność) a rze­czy­wi­ste zda­rze­nia gospo­dar­cze (nasze dane) są pozna­ny­mi fak­ta­mi, pomia­ra­mi. Najpierw więc malut­ka prób­ka tego jak bada się zda­rze­nia loso­we (moż­na to pominąć):

Charakterystyczną cechą nie­pew­no­ści przy­pad­ko­wych jest to, że na koń­co­wy błąd poje­dyn­cze­go pomia­ru skła­da się suma wie­lu małych, nie­za­leż­nych przy­czyn­ków, tzw. błę­dów ele­men­tar­nych. W rezul­ta­cie, przy kil­ka­krot­nym wyko­ny­wa­niu pomia­rów tej samej wiel­ko­ści uzy­sku­je się róż­ne wyni­ki. Wyniki te gru­pu­ją się wokół war­to­ści praw­dzi­wej, zaś ich roz­rzut może być mia­rą dokład­no­ści pomia­ru. Samej war­to­ści praw­dzi­wej nie zna­my, może­my jed­nak uzy­skać war­tość przy­bli­żo­ną, oraz sta­ty­stycz­ną oce­nę jej dokładności.

(za Pomiary i nie­pew­no­ści pomia­ro­we).

Na powyż­szym dia­gra­mie czer­wo­na linia to krzy­wa Gaussa, istot­na jest nie­bie­ska: dys­try­bu­an­ta. Jak widać jest to funk­cja nie­li­nio­wa, jej pochod­ną jest krzy­wa Gaussa. Maksimum krzy­wej Gaussa poka­zu­je hipo­te­tycz­ne opty­mal­ne tra­fie­nie” w nasza zależ­ność”. Dystrybuanta poka­zu­je, że na brze­gach zakre­su pomia­ro­we­go bada­na zmien­ność zbli­ża się do zera (czy­li istot­ne są wyni­ki bli­skie war­to­ści czę­ści środ­ko­wej (moż­na zanie­dbać te skrajne).

A teraz nasze dane

Rozbieramy pro­blem (tu dro­ga na skró­ty, pro­szę mi wyba­czyć), two­rzy­my dwie krzywe:

Powyższy dia­gram bazu­je na pew­nych uprosz­cze­niach ale coś trze­ba upro­ścić ;). Wyobraźmy sobie hipo­te­tycz­ne miej­sce ide­al­nej ana­li­zy: zero­wy błąd w wyni­ku prze­two­rze­nia nie­skoń­czo­nej ilo­ści danych. Krzywa zie­lo­na poka­zu­je, jak rośnie pew­ność w mia­rę wzro­stu licz­by bada­nych danych, czer­wo­na jak rośnie koszt tego bada­nia. Jak nie­trud­no się teraz domy­śleć ist­nie­je pewien punkt, od któ­re­go nakła­dy na wyko­na­nie ana­li­zy rosną szyb­ciej niż korzy­ści z rosną­cej dokład­no­ści wyni­ków ana­li­zy (przy­po­mi­nam dys­try­bu­an­tę powy­żej). Gdybyśmy na ten wykres nało­ży­li opi­sa­ną wyżej dys­try­bu­an­tę, oka­za­ło by się, że zarów­no zbyt mała jak i zbyt duża licz­ba pomia­rów nie wno­si wie­le. Zbyt mała licz­ba danych daje mało wia­ry­god­ny wynik, zbyt duża nie czy­ni wyni­ku wie­le wia­ry­god­niej­szym. Zaznaczam, że mowa o ana­li­zach sta­ty­stycz­nych, są tak­że inne potrze­by o czym dalej.

I teraz wnioski

Technologia IT pozwa­la zapi­sy­wać ogrom­ne ilo­ści danych. W cyto­wa­nym na począt­ku arty­ku­le nama­wia się nas na inwe­sty­cje w tech­no­lo­gie, któ­re dają szan­se na prze­ro­bie­nie” tego. A czy aby na pew­no musi­my gro­ma­dzić to wszyst­ko? Mózg ludz­ki ma dosko­na­łą obro­nę przed nad­mia­rem infor­ma­cji – zapo­mi­na­nie. Jak wie­my radzi­my sobie cał­kiem nie­źle mimo tego, że wie­le rze­czy zapo­mi­na­my, jed­nak wycią­ga­my wnio­ski a te zapa­mię­tu­je­my – zbie­ra­my doświad­cze­nie. To milio­ny lat ewo­lu­cji stwo­rzy­ły ten mecha­nizm! Wystarczy go naśladować.

Zmierzam do tego, że pro­jek­to­wa­nie sys­te­mów infor­ma­tycz­nych to tak­że pro­jek­to­wa­nie tego jaki­mi dany­mi zarzą­dzać, któ­re i jak zacho­wy­wać np. w hur­tow­ni danych. Gdyby nasza fir­ma zawie­ra­ła nie­skoń­czo­ną ilość trans­ak­cji sprze­da­ży rocz­nie (:)) czy musi­my ana­li­zo­wać wszyst­kie by oce­nić udzia­ły w ryn­ku, podział na regio­ny, naj­lep­szych i naj­gor­szych sprze­daw­ców, nad­uży­cia w trans­por­cie? Nie! Wystarczy mieć dane repre­zen­ta­tyw­ne, zacho­wać do ana­liz tyl­ko usta­lo­ną część ([[reten­cja danych]]). Niestety nie jest łatwo pod­jąć decy­zję, któ­ra to część i to jest (powin­no być) tak na praw­dę waż­ną czę­ścią ana­li­zy wyma­gań. Należy oce­nić racjo­nal­ność kosz­tów prze­twa­rza­nia wszyst­kich” tych danych. Nie daj­my się zwa­rio­wać z wydat­ka­mi na rosną­ce pojem­no­ści sys­te­mów skła­do­wa­nia i prze­twa­rza­nia danych.

Retencja danych z innej stro­ny. Powodów mamy nie­ma­ło: wyma­ga­ją tego prze­pi­sy, wyma­ga tego potrze­ba biz­ne­so­wa. Czym innym są dane gro­ma­dzo­ne w celach sta­ty­stycz­nych (te są czę­sto agre­go­wa­ne), a czym innym fak­ty, o któ­rych wie­dzę chce­my posia­dać. Będziemy pew­nie mie­li nie raz do czy­nie­nia z tre­ścia­mi war­ty­mi zacho­wa­nia („wie­dza”). Państwo (admi­ni­stra­cja) radzi sobie z tym usta­la­jąc kate­go­rie doku­men­tów (róż­ne doku­men­ty są nisz­czo­ne po róż­nym cza­sie, nie­któ­re nigdy). W biz­ne­sie np. fak­tu­ry trzy­ma­my 6 lat, doku­men­ty doty­czą­ce pra­cow­ni­ków – 20, lat, ale doku­men­ty spół­ki tak dłu­go jak ona ist­nie­je i jesz­cze trochę…

Dla jed­ne­go z klien­tów opra­co­wa­łem spe­cjal­ny typ (model) hur­tow­ni: drą­że­nie danych pro­wa­dzi­ło nie tyl­ko do kon­kret­nych fak­tów, ale tak­że do doku­men­tów powią­za­nych z tymi fak­ta­mi… ale to temat na inny arty­kuł 🙂 o tym jak moż­na spryt­nie inte­gro­wać sys­te­my ana­li­tycz­ne BI z repo­zy­to­ria­mi dokumentów.

Na zakoń­cze­nie pole­cam ubie­gło­rocz­ny arty­kuł Ekonomia myśle­nia, na temat ana­li­zy danych w sys­te­mach CRM.

Hurtownie danych czyli Systemy od historii”

Wczoraj mia­ła miej­sce kon­fe­ren­cja: Business Intelligence GigaCon 2011. Więcej tu: Hurtownie danych jako stan­dar­do­we modu­ły COTS (Commercial off the shelf) nowo­pro­jek­tow­nych sys­te­mów dedy­ko­wa­nych December 6th.

Poruszyłem mię­dzy inny­mi pro­ble­ma­ty­kę: aspek­ty pro­jek­to­we sys­te­mów dedy­ko­wa­nych i dosto­so­wy­wa­nych oraz ?core doma­in? i poję­cie COTS (Szczegółowe infor­ma­cje http://​giga​con​.org/​b​i​_​2​011).

Nie jest moim celem powie­la­nie tu refe­ra­tu, dla­te­go tyl­ko kil­ka kwe­stii a potem mała uwa­ga na temat metod argu­men­ta­cji osób rekla­mu­ją­cych swo­je pro­duk­ty, ale po kolei.

Hurtownia danych jako skład historii

W swo­im refe­ra­cie wska­za­łem na hur­tow­nie danych i meto­dy skła­do­wa­nia tam danych oraz na poję­cie sys­tem dedy­ko­wa­ny”. I tak:

  1. MIT: Oprogramowanie dedy­ko­wa­ne to kosz­tow­ne, dłu­go wyko­ny­wa­ne i ryzy­kow­ne, pro­jek­ty two­rze­nia opro­gra­mo­wa­nia od zera dla klienta,
  2. PRAWDA: Oprogramowanie dedy­ko­wa­ne to opro­gra­mo­wa­nie (System) zapro­jek­to­wa­ne na bazie dobrze opi­sa­nych wyma­gań, zło­żo­ne z kom­po­nen­tów (typo­we goto­we kom­po­nen­ty to ERP, CRM, SCM, inne).

To zna­czy, że doce­lo­wo – jako sys­tem dedy­ko­wa­ny – klient otrzy­ma zestaw zin­te­gro­wa­nych kom­po­nen­tów (pod­sys­te­mów, apli­ka­cji). Możliwe jest, że nie­któ­re zosta­ną opra­co­wa­ne i wyko­na­ne spe­cjal­nie dla nie­go. Pełny Zintegrowany System wspo­ma­ga­ją­cy zarzą­dza­nie (wszyst­kie apli­ka­cje w fir­mie) naj­czę­ściej nawet w 90% skła­da się z opro­gra­mo­wa­nia goto­we­go (COTS ? Commercial of the shelf).

Kolejnym mitem jest teza, że koszt inte­gra­cji jest duży. Powiem tak: zły pro­jekt zawsze koń­czy się wyso­ki­mi kosz­ta­mi, pro­jekt inte­gra­cyj­ny także.

Praktyka poka­zu­je, że popraw­nie posta­wio­ne wyma­ga­nia oraz pro­jekt wyko­na­ny przed wybo­rem roz­wią­za­nia, to naj­czę­ściej pro­jek­ty, w któ­rych kosz­ty inte­gra­cji są wie­lo­krot­nie niż­sze od kosz­tów kasto­mi­za­cji sys­te­mów zin­te­gro­wa­nych ERP i para­dok­sal­nie trwa to krócej.

Po trze­cie wdra­ża­nie eta­pa­mi (apli­ka­cja po apli­ka­cji) pozwa­la na to, by te poszcze­gól­ne pod­sys­te­my pra­co­wa­ły na sie­bie bez cze­ka­nia na cał­ko­wi­te zakoń­cze­nie wdro­że­nia cało­ści, jak to ma miej­sce naj­czę­ściej pod­czas wdra­ża­nia duże­go i zin­te­gro­wa­ne­go sys­te­mu. Warto tak­że zauwa­żyć, że taka – tak zwa­na kom­po­nen­to­wa – archi­tek­tu­ra jest łatwa w mody­fi­ka­cji (moż­li­wa jest wymia­na dowol­ne­go skład­ni­ka bez szko­dy dla innych cze­go nie moż­na powie­dzieć o dużych sys­te­mach ERP). Przykład z sys­te­ma­mi BI (Business Inteligence), któ­re będę tu zwał Raportowaniem.

Ogólnie wyma­ga­nia na sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie maja taką strukturę:

Diagram Przypadek uzycia

Diagram jest pro­sty. Chcę zwró­cić uwa­gę na to, że wie­le funk­cjo­nal­no­ści (może nawet wszyst­kie) sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie moż­na na takie dwie kate­go­rie podzie­lić. Przypomnę, że dia­gra­my przy­pad­ków uży­cia to nie pro­jek­ty sys­te­mu” a ich spis tre­ści”. Projektem, na wyso­kim pozio­mie abs­trak­cji (ang. HLD czy­li [[Hihg Level Design]]), jest dopie­ro to:

Model komponentow

Załóżmy, że archi­tekt sys­te­mu stwo­rzył powyż­szy model. Decyzja pro­jek­to­wa: sys­tem trans­ak­cyj­ny obsłu­gu­je naszą spe­cy­fi­kę biz­ne­so­wą, jest odpo­wie­dzią na wyma­ga­nie: Obsługa tego co się teraz dzie­je. Opracowano dokła­da­nie wyma­ga­nia, na ryn­ku nie zna­le­zio­no wyma­ga­nych funk­cjo­na­li­ści i ta część sys­te­mu zosta­nie wytworzona.

W ramach wyma­gań jed­nak, jak widać na poprzed­nim dia­gra­mie, mamy tak­że wyma­ga­nie: Pokaż co wyda­rzy­ło się kie­dyś. Są to funk­cjo­nal­no­ści rapor­to­we. Raportowanie jako funk­cja sys­te­mu jest dość dobrze opa­no­wa­na, są na ryn­ku goto­we pro­duk­ty (jest ich wie­le). Więc z pro­jek­tu deve­lo­per­skie­go (opro­gra­mo­wa­nie pro­jek­to­wa­ne) wyłą­czo­no ten zakres i kupio­no pod­sys­tem, popu­lar­nie zwa­ny hur­tow­nia danych. Większość tego typu apli­ka­cji ma bar­dzo dobre, uni­wer­sal­ne inter­fej­sy, więc ich inte­gra­cja nie sta­no­wi żad­ne­go problemu.

System trans­ak­cyj­ny, pro­jek­to­wa­ny, w ogó­le nie zaj­mu­je się histo­rią, prze­twa­rza wyłącz­nie dane bie­żą­ce dzię­ki cze­mu stał się znacz­nie prost­szy, czy­taj tań­szy w wyko­na­niu. Wszelkie dane o histo­rycz­nych sta­nach naszych danych są w hur­tow­ni danych a tę mamy już goto­wą, taniej niż koszt wytwo­rze­nia podob­ne­go systemu.

I tak: ta część, któ­ra opi­su­je spe­cy­fi­kę naszej orga­ni­za­cji (ozna­czo­na na nie­bie­sko), to tak zwa­ne core doma­in” czy­li głów­ny ele­ment dzie­dzi­ny sys­te­mu. Jeżeli nie znaj­dzie­my na ryn­ku pro­duk­tu, któ­ry w 100% mu odpo­wia­da nale­ży wydzie­lić taki frag­ment i stwo­rzyć sobie dedy­ko­wa­ny. Kastomizacja goto­we­go pro­duk­tu zawsze jest kom­pro­mi­sem, naj­czę­ściej bar­dzo kosz­tow­nym. (wię­cej o prak­ty­ce pro­jek­to­wa­nia zwa­nej DDD).

Pojecie [[COTS (Commercial off the shelf)]], o któ­rym już na blo­gu nie raz wspo­mi­na­łem, to tu nasz goto­wy kom­po­nent: hur­tow­nia danych. W efek­cie wszel­kie funk­cjo­nal­no­ści zwią­za­ne z rapor­to­wa­niem imple­men­tu­je­my w tej hur­tow­ni, pozo­sta­łe musi­my wytwo­rzyć. To dodat­ko­wa korzyść: baza danych sys­te­mu trans­ak­cyj­ne­go sta­je się dużo prost­sza, czy­taj tań­sza, bo model danych nie musi obsłu­gi­wać historii”.

Jeżeli potrzeb­ne nam zaawan­so­wa­ne meto­dy rapor­to­wa­nia i ana­liz nale­ży raczej zaku­pić apli­ka­cję z rodza­ju Business Inteligence zamiast zle­cać dostaw­cy sys­te­mu (np. ERP) kolej­ne imple­men­to­wa­nie wyra­fi­no­wa­nych – kosz­tow­nych w opra­co­wa­niu i utrzy­ma­niu – raportów.

Przy oka­zji: uży­cie hur­tow­ni danych w tle”, to nic inne­go jak clo­ud com­pu­ting :), tu tak zwa­na chmu­ra prywatna”.

Demagogia na konferencji

Z ust oso­by pro­mu­ją­cej pewien pro­dukt zali­czo­ny do Business Intelligence padło stwier­dze­nie: Nasz pro­dukt jest pro­sty, pobie­ra dane do rapor­tów bez­po­śred­nio z sys­te­mu ERP, nie musi­my więc dodat­ko­wo inwe­sto­wać w pośred­ni­czą­cy sys­tem hur­tow­ni danych, kto­ry może mieć dane nie­ak­tu­al­ne. Tezę tę miał poprzeć dia­gram podob­ny do tego:

Demagodia OLAP vs Proste BI

U góry mam skom­pli­ko­wa­ny sys­tem BI” a na dole nasz pro­sty i łatwy w obsłu­dze sys­tem”. To jak by usu­nąć zie­lo­ny kom­po­nent z powyż­sze­go dia­gra­mu kom­po­nen­tów. Gdzie haczyk? Ano tu:

Model danych ERP vs OLAP

Górny dia­gram to przy­kład mode­lu danych dla hur­tow­ni danych. Jest pro­sty, w prak­ty­ce sko­men­to­wa­ny po ludz­ku”, jako meta­da­ne, jest czymś, z czym może pra­co­wać każ­dy, kto tyl­ko zna daną dzie­dzi­nę, taki model danych (tak zwa­na gwiaz­da) odwzo­ro­wu­je w pro­sty spo­sób zna­ne biz­ne­so­we pojęcia.

Diagram niżej to model danych nie­wiel­kie­go sys­te­mu biz­ne­so­we­go (model danych sys­te­mu ERP, mają­cy nawet tysią­ce rela­cyj­nych, nic nie mówią­cych zwy­kłe­mu śmier­tel­ni­ko­wi tabel, był­by w tej pro­por­cji zwy­kłą kolo­ro­wą nie­czy­tel­ną pla­mą…). Wykonanie samo­dziel­nie jakie­go­kol­wiek rapor­tu z tego dru­gie­go sys­te­mu tabel gra­ni­czy z cudem. Można przy­go­to­wać (admi­ni­stra­tor bazy) tak zwa­ne wido­ki” dla użyt­kow­ni­ków co nie zmie­nia fak­tu, że ich opra­co­wa­nie to wie­dza tajem­na” i nikt z biz­ne­su” sam tego nie zro­bi. I naj­waż­niej­sze: dostęp do peł­ne­go mode­lu danych naj­czę­ściej wyma­ga zła­ma­nia zasad bez­pie­czeń­stwa to jest udo­stęp­nie­nia danych z pomi­nię­ciem mecha­ni­zmów kon­tro­l­nych apli­ka­cji ERP.

Hurtownia danych to model stwo­rzo­ny pod kątem prze­twa­rza­nia fak­tów histo­rycz­nych na pro­stym mode­lu danych (dia­gram powy­żej, gór­ny, to tak zwa­na kost­ka OLAP). Opracowanie takie­go mode­lu wyma­ga spe­cjal­nej ana­li­zy i pro­jek­tu, ale nie zapo­mi­naj­my: ana­li­zę się robi raz a rapor­ty sta­le… tu prze­szko­lo­ny użyt­kow­nik biz­ne­so­wy sam daje radę bez problemu.

Tak więc sza­now­ni Państwo. Jeśli tyl­ko Wasza fir­ma jest bli­żej czo­łów­ki niż ogo­na ran­kin­gu ryn­ku w Waszej bran­ży, nie daj­cie się namó­wić na jeden zin­te­gro­wa­ny ERP i jakiś model refe­ren­cyj­ny, bo nawet jak uda się go wdro­żyć, to zmia­na cze­go­kol­wiek będzie trud­na a upgra­de do now­szej wer­sji nie­moż­li­wy. Opracowanie pro­jek­tu sys­te­mu skła­da­ją­ce­go się z kom­po­nen­tów, pozwo­li Wam dobrać naj­le­piej speł­nia­ją­ce Wasze wyma­ga­nia apli­ka­cje. Jak z kloc­ków LEGO moż­na zło­żyć dedy­ko­wa­ny sys­tem” poma­ga­ją­cy utrzy­mać prze­wa­gę na ryn­ku, a nie cofa­ją­cy Waszą fir­mą do pozio­mu innych pod­mio­tów w bran­ży”.

Prognozowanie

Problem w tym, że z tych samych danych róż­ne fir­my ana­li­tycz­ne potra­fią wycią­gnąć róż­ne wnio­ski. Nie mam wąt­pli­wo­ści, że w naj­bliż­szych cza­sie cze­ka nas wysyp firm spe­cja­li­zu­ją­cych się w ana­li­zie danych pły­ną­cych z inter­ne­tu, ale póki co, wnio­ski są fru­stru­ją­ce: nie potra­fi­my wia­ry­god­nie prze­wi­dy­wać tren­dów ryn­ko­wych. (Piotr Podleśny, pre­zes fir­my Atena, źr. Prognozy wyma­ga­ją zro­zu­mie­nia danych – Computerworld).

Nauka wyka­za­ła, że sama ana­li­za danych histo­rycz­nie nie sta­no­wi żad­nej pro­gno­zy. Do tak zwa­nej pre­dyk­cji wyma­ga­ny jest model przed­mio­tu”, któ­re­go zacho­wa­nia chce­my prze­wi­dy­wać. Czy to moż­li­we? Tak. Czy to łatwe? Znowu odpo­wiem: nie. Potrzebny jest model a nie tyl­ko dane histo­rycz­ne (te pozwa­la­ją wyłącz­nie na ana­li­zę tego co było), wię­cej o tym w arty­ku­le o meto­dach nauko­wych ana­li­zy.

Analiza danych i podejmowanie decyzji: pięta achillesowa współczesnych organizacji

Zaczęło się od pro­wo­ka­cyj­ne­go arty­ku­łu Chrisa Andersona ?The End of Theory: The Data Deluge Makes the Scientific Method Obsolete? . Redaktor naczel­ny mie­sięcz­ni­ka Wired udo­wad­niał w nim, że zalew dany­mi (okre­śla­ny po angiel­sku mia­nem ?data delu­ge? lub ?big data?) wywo­ła­ny, z jed­nej stro­ny sta­łym spad­kiem kosz­tów prze­cho­wy­wa­nia infor­ma­cji, a z dru­giej, upo­wszech­nie­niem ser­wi­sów Web 2.0, słu­żą­cych kre­owa­niu i współ­dzie­le­niu wie­dzy, wkrót­ce zmu­si nowo­cze­sne orga­ni­za­cje do rezy­gna­cji z wyra­fi­no­wa­nych narzę­dzi do ana­li­zy sta­ty­stycz­nej. A w dal­szej per­spek­ty­wie może ozna­czać wery­fi­ka­cję dotych­cza­so­wych metod nauko­wych i badaw­czych. (źr. Blog Jacka Murawskiego dyrek­to­ra gene­ral­ne­go pol­skie­go oddzia­łu Microsoft.)

Jest to kolej­ny głos mówią­cy o zale­wie śmie­cio­wych danych. Pisałem swe­go cza­su o pro­ble­mach z migra­cją danych pod­czas wdra­ża­nia nowych sys­te­mów. Problemem nie jest sama migra­cja (prze­nie­sie­nie danych ze sta­re­go sys­te­mu do nowe­go) a to, co prze­nieść. Niestety naj­czę­ściej z bra­ku pomy­słu” prze­no­si się wszyst­ko” co powo­du­je, że rośnie licz­ba śmie­ci zaś rela­tyw­nie spa­da odse­tek danych fak­tycz­nie przydatnych.

W efek­cie ma miej­sce para­dok­sal­ne zja­wi­sko: rosną kosz­ty zarzą­dza­nia dany­mi a ich war­tość (przy­dat­ność) male­je. Np. dane księ­go­we i podob­ne – struk­tu­ral­ne – moż­na prze­no­sić do hur­tow­ni danych. Tu pro­ces ich czysz­cze­nia roz­wią­zu­je część pro­ble­mu, bo to tyl­ko ich porząd­ko­wa­nie. Pozostaje pro­blem cze­go nie prze­no­sić”. Dochodzi pro­blem danych nie­struk­tu­ral­nych takich jak róż­ne­go rodza­ju doku­men­ty (ofer­ty, robo­cze doku­men­ta­cje pro­jek­to­we itp.).

Cały ten pro­blem ma nazwę: [[reten­cja danych]]. Pojawiają się gło­sy by w fir­mach wpro­wa­dzić pro­ces zna­ny z urzę­dów i sys­te­mu Archiwów Państwowych: nada­wa­nie kate­go­rii archi­wal­nej każ­dej dokumentacji.

Problem nie jest pro­sty, mam wra­że­nie, że czę­sto igno­ro­wa­ny bo dys­ki twar­de tanie­ją”, jed­nak nie ma pro­ble­mu z tym by coś wynieść na strych, pro­blem w tym by to po kil­ku latach odna­leźć”. Kolejny pro­blem to psy­cho­lo­gia i czy­sta ludz­ka wyobraź­nia: po latach mamy nie raz wra­że­nie, że coś co zacho­wa­li­śmy kie­dyś nadal ma war­tość taką jak w dniu zacho­wa­nia, co z regu­ły oka­zu­je się nie­praw­dą. Rzecz w tym, że war­tość danych ope­ra­cyj­nych male­je z upły­wem cza­su (dez­ak­tu­ali­zu­ją się dane o cenach, warun­kach han­dlo­wych itp.). Można zary­zy­ko­wać tezę, że po roku więk­szość z nich (szcze­gó­ły) jest nie­przy­dat­na. Co naj­wy­żej war­tość ma sam fakt, że do jakichś kon­tak­tów docho­dzi­ło, jaki był ich cel itp.

Jak sobie z tym radzić? Narzędzie poma­ga­ją­ce w tym, zawar­te jest w więk­szo­ści dobrych sys­te­mów zarzą­dza­nia prze­pły­wem pra­cy i doku­men­tów. Każdy taki sys­tem ma tak zwa­ne [[repo­zy­to­rium doku­men­tów]]. Jest to archi­wum pli­ków (doku­men­ty, zdję­cia, pli­ki źró­dło­we, itp.), dużą war­to­ścią repo­zy­to­riów jest to, że maja tak zwa­ny sys­tem meta­da­nych. [[Metadane]] to struk­tu­ral­ny opis nie­struk­tu­ral­nej zawar­to­ści prze­cho­wy­wa­nych plików.

Właściwy pro­jekt tych meta­da­nych ([[tak­so­no­mia]]) pozwa­la na stwo­rze­nie dwóch dodat­ko­wych cech przy­dat­nych w sys­te­mach [[busi­ness inteligence]]:

  1. meta­da­ne (jako dane struk­tu­ral­ne) mogą być migro­wa­ne do hur­tow­ni danych,
  2. meta­da­ne nadal zacho­wu­ją klu­czo­we infor­ma­cje po usu­nię­ciu pli­ków źró­dło­wych (z regu­ły dużych i nie­przy­dat­nych, np. po latach nadal będzie­my wie­dzie­li jak czę­sto kon­tak­to­wał się z nami klient i po co, mimo bra­ku dostę­pu do już bez­war­to­ścio­wych danych o szcze­gó­łach tych kontaktów).

Warto two­rzyć dobrze prze­my­śla­ne sys­te­my meta­da­nych dla sys­te­mów archi­wi­za­cji doku­men­tów, gdyż pozwa­la to z jed­nej stro­ny spiąć” archi­wum doku­men­tów z hur­tow­nią danych z dru­giej pozbyć się” śmie­ci. Tempo przy­ro­stu danych sta­le rośnie gdyż biz­ne­so­we opro­gra­mo­wa­nie, auto­ma­ty­zu­jąc wie­le naszych czyn­no­ści, wytwa­rza je w tem­pie w jakim czło­wiek nigdy nie był by w sta­nie. Po dru­gie nara­sta zja­wi­sko powie­la­nia, co nazy­wam to syn­dro­mem copy&paste”. Wiele doku­men­tów (o zgro­zo tak­że tych podob­no autor­skich”) powsta­je coraz czę­ściej meto­dą powie­la­nia tego co znaj­dzie się w fir­mo­wych archi­wach (wie­dza kor­po­ra­cyj­na czy­li po pro­stu jej zanik, bo wie­dza to umie­jęt­ność napi­sa­nia cze­goś a nie sko­pio­wa­nia) czy w sieci.

Moja prak­ty­ka (to co dosta­je do audy­tu u klien­tów) poka­zu­je, że doku­men­ty wytwo­rzo­ne od zera” prak­tycz­nie zawsze mają więk­szą war­tość mery­to­rycz­ną niż te wytwo­rzo­ne na bazie tak zwa­nej wie­dzy kor­po­ra­cyj­nej”. Do tego docho­dzi ryzy­ko prze­nie­sie­nia, pod­czas kopio­wa­nia, tre­ści nie­chcia­nych. Kopiując dzie­siąt­ki stron sta­rej ofer­ty” lub poprzed­nie­go opra­co­wa­nia dorad­cze­go”, two­rząc w ten spo­sób kolej­ne indy­wi­du­al­ne autor­skie opra­co­wa­nie” nara­zić się moż­na nie tyl­ko na ujaw­nie­nie tajem­ni­cy, ale tak­że na zwy­kłe ośmie­sze­nie. Dlatego nie tyl­ko sys­tem zarzą­dza­nia doku­men­ta­mi i wie­dzą nale­ży dobrze zapro­jek­to­wać, ale tak­że pro­ces two­rze­nia nowych tre­ści. W prze­ciw­nym wypad­ku nara­ża­my się na budo­wę wiel­kie­go, ośmie­sza­ją­ce­go fir­mę, śmietnika.

Terminem bli­sko sko­ja­rzo­nym z ana­li­zą dzie­dzi­ny i pro­jek­to­wa­niem tak­so­no­mii jest [[onto­lo­gia]]. Tu dla uła­twie­nia cytat z wikipedii:

Termin onto­lo­gia” w infor­ma­ty­ce i podej­ściu systemowym

Termin onto­lo­gia” cie­szy się coraz to wiek­szą popu­lar­no­ścią w infor­ma­ty­ce (np. w budo­wie sie­ci seman­tycz­nych) oraz bada­niach nad sztucz­ną inte­li­gen­cją gdzie ozna­cza to co jest” i może slu­życ jako plat­for­ma ter­mi­no­lo­gicz­na do for­mal­nej budo­wy infor­ma­cji, pre­fe­ren­cji i wie­dzy (Model IPK).

Ontologia” w kon­tek­ście infor­ma­tycz­nym poja­wi­ła się już w roku 1967 w bada­niach doty­czą­cych mode­lo­wa­nia danych, ale dopie­ro w dobie zale­wu infor­ma­cją dostęp­ną w Internecie i koniecz­no­ścią jej prze­twa­rza­nia zysku­je szer­sze zain­te­re­so­wa­nie. Według Gadomskiego, onto­lo­gia w uogól­nio­nym sen­sie sys­te­mo­wym zaj­mu­je się opi­sy­wa­niem ?tego co jest? lub ?moze być? w danej dzie­dzi­nie zain­te­re­so­wa­nia Meta-teo­ria TOGA, w pew­nym frag­men­cie rze­czy­wi­sto­ści lub w ramach jakiejs teo­rii, mniej lub bar­dziej dokład­nie okre­ślo­nym dla dane­go agen­ta inte­li­gent­ne­go lub robo­ta dla osia­gnie­cia zada­ne­go celu. Aby zapew­nić jed­no­znacz­ność prze­ka­zu wie­dzy na temat okre­ślo­nej rze­czy­wi­sto­ści, na zada­nym pozio­mie og?lnosci, wyko­rzy­stu­je się kate­go­ry­za­cję oraz hie­rar­chi­za­cję. W niniej­szym kon­tek­ście, poję­cia te moż­na zde­fi­nio­wać następująco:

  • kate­go­ry­za­cja ? zdol­ność przy­po­rząd­ko­wa­nia sym­bo­lu wystę­pu­ją­ce­go w komu­ni­ka­cie do okre­ślo­nej gru­py obiek­tów wystę­pu­ją­cych w zada­nej dzie­dzi­nie np. ?kot? ? kla­sa kotów, poję­cie kot.
  • hie­rar­chi­za­cja ? umiej­sco­wie­nie okre­ślo­nej kla­sy w hie­rar­chicz­nej struk­tu­rze. Instancja kla­sy poza oczy­wi­sty­mi cha­rak­te­ry­sty­ka­mi wyni­ka­ją­cy­mi z przy­na­leż­no­ści do kla­sy posia­da tak­że cechy dzie­dzi­czo­ne z klas nadrzędnych.

W uje­ciach sys­te­mo­wym, kogni­tyw­nym i infor­ma­tycz­nym poję­cie «onto­lo­gia» jest poję­ciem rela­tyw­nym, naj­ogol­niej, dana onto­lo­gia zale­ży od dzie­dzi­ny, agen­ta inte­li­gent­ne­go kto­ry ją uży­wa i jego celu.

Aby wyraź­niej pod­kre­ślić cechy cha­rak­te­ry­stycz­ne tzw. top-onto­lo­gii (onto­lo­gii uniwersalnej/ogolnej, onto­lo­gii świa­ta), nale­ży przed­sta­wić kil­ka obec­nie dys­ku­to­wa­nych postu­la­tów doty­czą­cych jej funk­cjo­nal­nych cech :

  1. nie sta­no­wi listy, kata­lo­gu czy tak­so­no­mii obiek­tów, stwa­rza nato­miast for­mal­ne prze­słan­ki, wedle któ­rych tako­we mogą być budowane
  2. jest ode­rwa­na od teo­rii pozna­nia (epi­ste­mo­lo­gii), powią­za­na jest z obiek­tem, a nie jego subiek­tyw­nym odbiorem
  3. musi uchwy­cić rze­czy­wi­stość na róż­nych pozio­mach ato­mi­za­cji, jak rów­nież rela­cje pomię­dzy tymi warstwami
  4. uzna­nie bra­ku moż­li­wo­ści stwo­rze­nia jed­nej ogól­nej onto­lo­gii, ist­nie­nie wie­lu ontologii
  5. w prze­ci­wień­stwie do nauki rela­cje mię­dzy obiek­ta­mi nie są uję­te funk­cyj­nie (zależ­no­ści nie są ilościowe)
  6. nauka roz­po­czy­na pro­ces od mie­rze­nia i pre­dyk­cji, onto­lo­gia zaś od budo­wa­nia taksonomii

(za Ontologia ? Wikipedia, wol­na ency­klo­pe­dia.)

Ekonomia myślenia – brzytwa Ockhama

fin_tableRegularnie czy­tam blog Filozofia mar­ke­tin­gu pisa­ny przez [[Macieja Tesławskiego]]. Wśród wie­lu powo­dów, dla któ­rych to robię są: sto­so­wa­nie w pra­cy Brzytwy Ockhama (zwa­nej nie raz eko­no­mia myśle­nia, choć on sam chy­ba tego tak na swo­im blo­gu nie nazy­wa) oraz to, że to co pisze o mar­ke­tin­gu jest logicz­ne co bar­dzo lubię u ludzi (nie zno­szę zaś pozba­wio­ne­go kon­kre­tów beł­ko­tu, któ­re­go nie­ste­ty nie bra­ku­je). Czytając kolej­ny wpis na jego blo­gu tra­fi­łem na coś co pchnę­ło mnie to pew­nych reflek­sji i zastanowienia:

Programy reten­cyj­ne mogą być B2B, B2C i mul­ti­part­ner­skie, lojal­no­ścio­we mogą być tyl­ko B2C bo w biz­ne­sie decy­zje zaku­po­we podej­mu­je się w znacz­nym stop­niu racjo­nal­nie a nie emocjonalnie.

Jeśli cho­dzi o oce­nę dzia­ła­ją­cych pro­gra­mów reten­cyj­nych, to pod­sta­wo­wy błąd jaki widzę to nie­wy­ko­rzy­sty­wa­nie bazy infor­ma­cji o uczest­ni­kach pro­gra­mu przez fir­my. To jest potęż­ny zbiór infor­ma­cji o zacho­wa­niach poszcze­gól­nych kon­su­men­tów, w połą­cze­niu z dany­mi demo­gra­ficz­ny­mi pozwa­la na ?pozna­nie? pro­fi­lu naj­bar­dziej war­to­ścio­wych kon­su­men­tów. Nie zauwa­ży­łem aby kto­kol­wiek to wyko­rzy­sty­wał. Dzieje się tak zapew­ne dla­te­go, że bazy danych rosną w postę­pie geo­me­trycz­nym i prze­ra­sta­ją moż­li­wo­ści ich bie­żą­ce­go wyko­rzy­sty­wa­nia. (źr. Do znu­dze­nia o tej lojal­no­ści? | Filozofia marketingu.)

Celowo cytu­ję tak obszer­ny frag­ment (liczę na wyba­cze­nie u auto­ra) by zacho­wać kon­tekst tego co wytłu­ści­łem. W czym pro­blem? W [[brzy­twie Ockhama]] i tym…

…czy aby na pewno trzeba analizować te miliony zdarzeń.

Jak to się ma do sys­te­mów CRM? Prawdą jest, że lawi­no­wo przy­by­wa danych w bazach sys­te­mów CRM, któ­rych prze­twa­rza­nie poten­cjal­nie może przy­nieść korzy­ści jed­nak nie praw­dą jest, że zawsze im wię­cej tych danych tym lepiej. Mam cichą nadzie­ję, że ten krót­ki arty­kuł posze­rzy tezy przy­to­czo­ne­go cytatu.

Marketingiem zaj­mu­je się nie­ja­ko z innej stro­ny: mode­lu­ję zja­wi­ska nim rzą­dzą­ce i muszę go rozu­mieć (stąd Tesławski jako jed­na z klu­czo­wych lek­tur po M.E.Porterze). Zgodnie z zasa­dą Arystotelesa: pod­sta­wą zro­zu­mie­nia jest pozna­nie przy­czyn. Analiza zja­wisk, np. zwią­za­nych z zacho­wa­nia­mi klien­tów, nie wyma­ga więc pozna­nia setek czy milio­nów przy­pad­ków ich zacho­wań. Wymaga pozna­nia i rozu­mie­nia tego czym się ci klien­ci kie­ru­ją, co spo­wo­do­wa­ło takie a nie inne ich zacho­wa­nia. Celem dzia­łań mar­ke­tin­go­wych (w rozu­mie­niu ana­li­zy ryn­ku) nie jest ana­li­za histo­rii a pro­gno­zo­wa­nie. Historie ana­li­zu­je­my by móc prze­wi­dy­wać jej dal­szy ciąg i ana­li­za histo­rii to narzę­dzie a nie cel sam w sobie. Po dru­gie ana­li­za i pro­gno­zo­wa­nie to nie wyrę­cza­nie mene­dże­rów od podej­mo­wa­nia decy­zji (co wie­lu mam wra­że­nie jed­nak robi) a jedy­nie wspo­ma­ga­nie ich w ich podejmowaniu.

Przykład pokrew­ny: popra­wa jako­ści pro­gnoz pogo­dy ma swo­je źró­dło nie w rosną­cej ilo­ści danych zebra­nych o pogo­dzie a w jako­ści mode­lu pro­gno­stycz­ne­go. Kiedyś pro­gno­zy pogo­dy pole­ga­ły na wyszu­ka­niu w histo­rii sytu­acji naj­bliż­szej sta­no­wi obec­ne­mu, spraw­dze­niu co było potem” i uzna­wa­niu, że teraz też tak będzie”. Jednak to moż­na spro­wa­dzić to pro­gno­zo­wa­nia na bazie jak dłu­go Indianie zbie­ra­li chrust” by oce­nić nad­cho­dzą­cą zimę. Obecne pro­gno­zy pogo­dy są two­rzo­ne na bazie mode­li atmos­fe­ry i zja­wisk atmos­fe­rycz­nych: moż­li­we jest prze­wi­dy­wa­nie cze­goś co nigdy w histo­ria nie zaszło. Dane histo­rycz­ne posłu­ży­ły do stwo­rze­nia tego mode­lu, potem do jego testo­wa­nia (i nadal jest ulepszany…).

Inny przy­kład: jeże­li chce prze­wi­dzieć co się sta­nie gdy ude­rzę kulę kijem bilar­do­wym, wystar­czy dosłow­nie kil­ka obser­wa­cji, kolej­ne już nicze­go nowe­go nie wnio­są to stwier­dze­nia, że kula prze­mie­ści się w kie­run­ku zbli­żo­nym do kie­run­ku ude­rze­nia. Ktoś zapew­ne zauwa­żył sło­wo zbli­żo­ny” i mógł­by for­so­wać tezę, że nale­ży powięk­szyć licz­bę obser­wa­cji. Tu zacytuję:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­ną odle­głość w pew­nym kie­run­ku.” Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzysz nawet dość dobrej symu­la­cji. Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre opro­gra­mo­wa­nie.” (źr. Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997)

Tak więc owszem, zbie­ra­nie danych np. o tym jakie, za co i kto zbie­ra punk­ty kupu­jąc coś w skle­pie ma sens tyl­ko do pew­ne­go pozio­mu. Jeżeli chce­my na praw­dę prze­wi­dzieć skut­ki naszych dzia­łań musi­my zro­zu­mieć zja­wi­sko i zbu­do­wać jego model.

Tak więc sko­ro „… potęż­ny zbiór infor­ma­cji o zacho­wa­niach poszcze­gól­nych kon­su­men­tów, w połą­cze­niu z dany­mi demo­gra­ficz­ny­mi pozwa­la na ?pozna­nie? pro­fi­lu naj­bar­dziej war­to­ścio­wych kon­su­men­tów”. Ten pro­fil, jeśli powsta­je, to wła­śnie model (ja to tak postrze­gam). Jeśli będzie popraw­ny, będzie­my w sta­nie z bar­dzo dużym praw­do­po­do­bień­stwem prze­wi­dy­wać zacho­wa­nia kon­su­men­tów. Czy tych danych musi być dużo? Czy rosną­ca ilość tych danych wpły­nie na popra­wę jako­ści pro­gnoz zacho­wań? Nie sądzę, gdyż pro­gno­zy bazu­ją­ce na ana­li­zie tren­dów pole­ga­ją tyl­ko na oce­nie tego, z jakim praw­do­po­do­bień­stwem powtó­rzy się histo­ria. Jeżeli chce­my oce­nić nową kam­pa­nię, dane te – jako trend – są w zasa­dzie bez­war­to­ścio­we: nigdy nie dadzą jako efekt nicze­go nowe­go, tyl­ko coś, co już kie­dyś było.

Dlatego hur­tow­nie danych i tak zwa­ne sys­te­my [[Business Inteligence]], wszel­kie sys­te­my wspo­ma­ga­nia decy­zji, to albo ana­li­za histo­rii albo pro­gno­zo­wa­nie opar­te na mode­lach. W kwe­stii mar­ke­tin­gu lepiej jest, moim zda­niem, opra­co­wać model zja­wi­ska, a do tego nie potrzeb­ne są duże ilo­ści danych a jedy­nie mini­mal­ny [[zestaw danych repre­zen­ta­tyw­nych]] i to się nazy­wa zasa­dą eko­no­mii myśle­nia. Wielką zaś sztu­ką pro­jek­to­wa­nia hur­tow­ni danych dla sys­te­mów BI nie jest samo gro­ma­dze­nie danych a wła­śnie ich odsie­wa­nie, dla­te­go sys­te­my ana­li­tycz­ne inte­gro­wa­ne z sys­te­ma­mi CRM, te prze­ła­do­wa­ne dany­mi, bywa­ją cza­sem bar­dziej szko­dli­we niż pomocne.