Hurtownie danych i analizy – jak je robić?

Od cza­su do cza­su w zakre­sie wyma­gań biz­ne­so­wych poja­wia­ją się (coraz czę­ściej) potrze­by z obsza­ru sze­ro­ko rozu­mia­ne­go kon­tro­lin­gu, któ­ry pole­ga na zbie­ra­niu danych w celu two­rze­nia wyra­fi­no­wa­nych rapor­tów, bazu­ją­cych na danych z wszyst­kich obsza­rów orga­ni­za­cji. Dzisiaj kil­ka słów na ten temat, bo z moich nie­for­mal­nych (roz­mo­wy i doku­men­ty pro­jek­to­we u klien­tów) badań, wyła­nia się obraz wie­lu nie­uda­nych wdro­żeń hur­tow­ni i apli­ka­cji zwa­nych Business Intelligence, nie­uda­nych z powo­du małej ich wydaj­no­ści, małej przy­dat­no­ści (naj­czę­ściej, tak!) lub obu naraz. Artykuł podzie­li­łem na dwie czę­ści: Troszkę o teo­rii…Troszkę o tym z czym się spo­ty­ka­my… Pierwszą część moż­na pomi­nąć 😉 jak ktoś chce.

Troszkę o teorii i nie nie tylko…

W arty­ku­le z 2011 roku napisałem:

Nauka wyka­za­ła, że sama ana­li­za danych histo­rycz­nych 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 więc 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. (Źródło: Hurtownie danych czy­li ?Systemy od histo­rii? | Jarosław Żeliński IT-Consulting).

Jest cała masa pod­ręcz­ni­ków tech­no­lo­gicz­nych o pro­jek­to­wa­niu i budo­wa­niu hur­tow­ni danych, któ­rych auto­rzy poprze­sta­ją jed­nak na opi­sach struk­tu­ry mode­li danych i pro­ce­sów mecha­ni­ki ich łado­wa­nia. Bardzo mało jest opi­sów, jak two­rzyć uży­tecz­ną zawar­tość tych zbio­rów danych. Jedne z wie­lu takich (popraw­nych) opi­sów technicznych:

OLAP Tool FunctionalitiesBefore we spe­ak abo­ut OLAP tool selec­tion cri­te­rion, we must first distin­gu­ish betwe­en the two types of OLAP tools, MOLAP (Multidimensional OLAP) and ROLAP (Relational OLAP).

1. MOLAP: In this type of OLAP, a cube is aggre­ga­ted from the rela­tio­nal data sour­ce (data ware­ho­use). When user gene­ra­tes a report requ­est, the MOLAP tool can gene­ra­te the results quic­kly becau­se all data is alre­ady pre-aggre­ga­ted within the cube.

2. ROLAP: In this type of OLAP, inste­ad of pre-aggre­ga­ting eve­ry­thing into a cube, the ROLAP engi­ne essen­tial­ly acts as a smart SQL gene­ra­tor. The ROLAP tool typi­cal­ly comes with a «Designer» pie­ce, whe­re the data ware­ho­use admi­ni­stra­tor can spe­ci­fy the rela­tion­ship betwe­en the rela­tio­nal tables, as well as how dimen­sions, attri­bu­tes, and hie­rar­chies map to the under­ly­ing data­ba­se tables.

Right now, the­re is a conver­gen­ce betwe­en the tra­di­tio­nal ROLAP and MOLAP ven­dors. ROLAP ven­dor reco­gni­ze that users want the­ir reports fast, so they are imple­men­ting MOLAP func­tio­na­li­ties in the­ir tools; MOLAP ven­dors reco­gni­ze that many times it is neces­sa­ry to drill down to the most deta­il level infor­ma­tion, levels whe­re the tra­di­tio­nal cubes do not get to for per­for­man­ce and size reasons.
(Źródło: Business Intelligence: OLAP Tools)

Generalnie, rzecz w tym, że sys­te­my ROLAP (R – rela­tio­nal) opar­te są na rela­cyj­nych zbio­rach danych trans­ak­cyj­nych sys­te­mów ERP. Systemy MOLAP (M- mul­ti­di­men­sio­nal) opar­te są na prze­two­rzo­nych do posta­ci tak zwa­nej ana­li­tycz­nej kost­ki wie­lo­wy­mia­ro­wej”, zbio­rach danych z redun­dan­cją, będą­cych nie­za­leż­ną kopią danych źró­dło­wych (np. z tych ERP).

Pierwszy pro­blem: ROLAP zakła­da, że wyma­ga­ne i wystar­cza­ją­ce do ana­li­zy dane, to ten jeden zbiór danych w mode­lu rela­cyj­nym sys­te­mu ERP. Była by to praw­da, gdy nic istot­ne­go nie dzia­ło się (nie było reje­stro­wa­ne) w fir­mie, poza tym sys­te­mem ERP. Problem dru­gi: model rela­cyj­ny to set­ki tablic, ich dyna­micz­ne sca­la­nie to pra­ca sama w sobie, zmia­na ich struk­tu­ry (np. upgra­de sys­te­mu) wyma­ga ponow­ne­go pro­jek­to­wa­nia takiej hur­tow­ni (kon­kret­nie sys­te­mu rapor­to­wa­nia). Z tego powo­du wie­lu pro­du­cen­tów sys­te­mów ERP ofe­ru­je od razu wbu­do­wa­ne w nie sys­te­my rapor­to­we. Niestety są to z góry narzu­co­ne uni­wer­sal­ne” mode­le, nie­ko­niecz­nie pasu­ją­ce do kon­kret­nej pań­stwa firmy.

Systemy MOLAP nie mają powyż­szych wad, jed­nak są to sys­te­my zewnętrz­ne, wyma­ga­ją więc dodat­ko­we­go zaku­pu, ana­li­zy i wie­dzy jak zapro­jek­to­wać wie­lo­wy­mia­ro­we mode­le danych do ana­li­zy (ale nie zapo­mi­naj­my, że dodat­ko­wy moduł ana­li­tycz­ny w pakie­cie ERP też trze­ba doku­pić). W przy­pad­ku gdy fir­ma ma wię­cej apli­ka­cji niż jed­ną (czy­li powo­li raczej nor­ma), nie ma innej moż­li­wo­ści pro­wa­dze­nia ana­liz, niż z pomo­cą zewnętrz­ne­go sys­te­mu agre­gu­ją­ce­go dane z wszyst­kich istot­nych dzie­dzi­no­wych apli­ka­cji w firmie.

Jak to wygląda?

Górny dia­gram to przy­kład mode­lu danych dla hur­tow­ni danych [przyp. MOLAP]. 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ę (jej ter­mi­no­lo­gię). 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, przez nie­spe­cja­li­stę, 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 nadal ?wie­dza tajem­na? i nikt z ?biz­ne­su? sam tego nie zro­bi. (Źródło: Hurtownie danych czy­li ?Systemy od histo­rii? | Jarosław Żeliński IT-Consulting)

Z per­spek­ty­wy biz­ne­so­wej znacz­nie wygod­niej­szy jest model wie­lo­wy­mia­ro­wy obiek­to­wy. Obiektami są tu byty biz­ne­so­we” (np. fak­tu­ra) a nie abs­trak­cyj­ne poję­cia z mode­li danych (po nor­ma­li­za­cji dane – ani tabli­ce ani kolum­ny – nie opi­su­ją już wprost żad­ne­go bytu/obiektu biznesowego!).

Jak to wyglą­da od stro­ny stan­da­ry­za­cji? Organizacja [[OMG]] opra­co­wa­ła i opu­bli­ko­wa­ła w 2003 roku meta-model hur­tow­ni danych. Wygląda on tak:

Common Warehouse Metamodel (CWM) Specification
Common Warehouse Metamodel
(CWM)

Mamy tu dwie głów­ne kolum­ny: lewa to pro­ces two­rze­nia (pro­jek­to­wa­nia) mode­lu ana­li­tycz­nych, pra­wa to jego uży­cie. W tym momen­cie inte­re­su­je nas głów­nie pro­ces pro­jek­to­wa­nia. W wer­sji obiek­to­wej bazu­je na infor­ma­cji biz­ne­so­wej, wer­sja rela­cyj­na na (posia­da­nym) mode­lu danych. Do same­go rapor­to­wa­nia (pra­wa kolum­na) wyko­rzy­sty­wa­ne są mode­le wie­lo­wy­mia­ro­we jed­nak waż­ne jest to, że w mode­lu rela­cyj­nym tak zwa­ne kost­ki ana­li­tycz­ne” są two­rzo­ne dyna­micz­nie (ich struk­tu­ra jest sta­tycz­na ale ich zawar­tość jest gene­ro­wa­na ad-hoc z danych w mode­lu rela­cyj­nym). Model obiek­to­wy tu jest natu­ral­nie wie­lo­wy­mia­ro­wy (kopia danych w dedy­ko­wa­nej struk­tu­rze wyko­na­na do celów ana­li­tycz­nych), to pra­ca z dany­mi bez potrze­by ich prze­twa­rza­nia w locie” (pra­co­chłon­ne).

Dokument [[Common Warehouse Metamodel]] zawie­ra meta­mo­de­le wer­sji rela­cyj­nej i wie­lo­wy­mia­ro­wej. Już samo tyl­ko przej­rze­nie obu tych mode­li poka­zu­je róż­ni­ce pomię­dzy zło­żo­no­ścią struk­tu­ry mode­lu rela­cyj­ne­go (ponad 30 stron doku­men­ta­cji) a wie­lo­wy­mia­ro­we­go (10 stron): ten dru­gi jest znacz­nie prostszy.

Troszkę o tym z czym się spotykamy…

Na począ­tek hasło Rachunkowość Zarządcza, bo nim posłu­gu­je się wie­le firm wdra­ża­ją­cych roż­ne­go rodza­ju hur­tow­nie danych i sys­te­my rapor­to­wa­nia (pole­cam cały cyto­wa­ny we frag­men­cie tekst):

Rachunkowość zarząd­cza, nie­kie­dy okre­śla­na rów­nież mia­nem rachun­ko­wo­ści mene­dżer­skiej to jeden z czło­nów rachun­ko­wo­ści (obok rachun­ko­wo­ści finan­so­wej i podat­ko­wej) słu­ży celom wewnętrz­nym przed­się­bior­stwa, dostar­cza danych w przed­się­bior­stwie nie­zbęd­nych do podej­mo­wa­nia decy­zji bie­żą­cych i roz­wo­jo­wych oraz infor­ma­cji, któ­re uła­twia­ją podej­mo­wa­nie decy­zji stra­te­gicz­nych, tak­tycz­nych, ope­ra­cyj­nych, pla­no­wa­nie i kon­tro­lę poprzez wyspe­cja­li­zo­wa­ne tech­ni­ki i pro­ce­du­ry, jak np. budże­ty, wzor­ce, odpo­wied­nio dobra­ne mode­le rachun­ku kosz­tów i przy­cho­dów, ana­li­zę zacho­wa­nia się kosz­tów i infor­mo­wa­nia o doko­na­niach. Kierując się aktu­al­nym usta­le­nia­mi Międzynarodowej Federacji Rachunkowości (IFAC) oraz lite­ra­tu­rą w tej dzie­dzi­nie, może­my przy­jąć, że: rachun­ko­wość zarząd­cza jest sys­te­mem gro­ma­dze­nia, agre­ga­cji, kla­sy­fi­ka­cji, ana­li­zy i pre­zen­to­wa­nia infor­ma­cji finan­so­wych i nie­fi­nan­so­wych wspo­ma­ga­ją­cych kie­row­nic­two przed­się­bior­stwa w podej­mo­wa­niu decy­zji i kon­tro­li ich reali­za­cji. (Źródło: Rachunkowość zarząd­cza ? Encyklopedia Zarządzania)

Wytłuszczenie moje. O tym co wyróż­nio­no kolo­rem czer­wo­nym w dal­szej części.

Można więc uznać, że:

Rachunkowość pole­ga­ją­ca wyłącz­nie na reje­stro­wa­niu fak­tów finan­so­wych nie jest rachun­ko­wo­ścią zarządczą.

To zna­czy, że infor­ma­cje zbie­ra­ne tyl­ko z pomo­cą pla­nu kont nie są taką infor­ma­cją, wbrew temu co mówi bar­dzo wie­lu kon­sul­tan­tów” firm wdra­ża­ją­cych opro­gra­mo­wa­nie ERP czy tyl­ko FK.

Plan kont wśród wie­lu innych grup zawie­ra dwie: Zespół 4 Koszty według rodza­ju i ich roz­li­cza­nie oraz Zespół 5 Koszty według typów dzia­łal­no­ści i ich roz­li­cza­nie. Rachunek kosz­tów rodza­jo­wy jest pro­sty” i powszech­nie sto­so­wa­ny, tak zwa­ny rachu­nek kosz­tów ABC wart jest kil­ku słów. Najpierw definicja:

Rachunek kosz­tów dzia­łań ABC (kal­ku­la­cja ABC)[…]. 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). […] Powinny one być pro­por­cjo­nal­ne do kosz­tów gene­ro­wa­nych przez okre­ślo­ne dzia­ła­nia [aktyw­no­ści, pro­ce­sy, przyp. mój], któ­rych kosz­ty pod­le­ga­ją roz­li­cze­niu. 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 kosz­tów. (Źródło: Rachunek kosz­tów dzia­łań ? Encyklopedia Zarządzania).

Do tego celu słu­żą kon­ta zespo­łu 5. Popatrzmy jak to działa:

Kontroling i rachunkowość zarządcza Konta 4 i 5

Mamy tu czte­ry przy­kła­do­we kosz­ty ponie­sio­ne (ozna­czo­ne wiel­ki­mi lite­ra­mi). Standardowo księ­go­wa­ne są rodza­jo­wo na kon­ta zespo­łu 4 (wier­sze). te same kosz­ty moż­na księ­go­wać jed­no­cze­śnie na kon­tach zespo­łu 5 (kolum­ny). Gdybyśmy mie­li wyłącz­nie kon­ta zespo­łu 4 nie wie­dzie­li­by­śmy ile nasz kosz­tu­ją kam­pa­nie pro­mo­cyj­ne łącz­nie. Wiedzielibyśmy ile wyda­je­my na usłu­gi (obce) u pod­wy­ko­naw­ców, ale nie wie­dzie­li­by­śmy dokład­nie, któ­re dzia­ła­nia były w ten spo­sób wspie­ra­ne. Oba przy­kła­dy poka­zu­ją, że wie­dza gro­ma­dzo­na na kon­tach zespo­łu 4 to za mało do podej­mo­wa­nia decy­zji biz­ne­so­wych, w pierw­szym przy­pad­ku np. o udzia­le w tar­gach a w dru­gim np. o out­so­ur­cin­gu wybra­nych działań.

Kolejna waż­na rzecz (nie poka­za­na na powyż­szym dia­gra­mie): jak nie trud­no się domy­śleć, suma war­to­ści w każ­dej gru­pie kont musi sta­no­wić 100% kosz­tów. Zakładanie kont nazwa­nych Inne wydat­ki” to nie­ste­ty uzna­nie, że są kosz­ty nad któ­ry­mi nie panu­je­my, dla­te­go war­to poświę­cić się i prze­pro­wa­dzić ana­li­zę swo­jej dzia­łal­no­ści w celu opra­co­wa­nia porząd­nej tak­so­no­mii kosz­tów w obu tych gru­pach, tak by nie było kont o wdzięcz­nej nazwie Inne wydat­ki”, bo to świad­czy o nie­mo­cy w ana­li­zie wła­snych kosz­tów.

Powyższe to nic inne­go jak dwu­wy­mia­ro­wa kost­ka” ana­li­tycz­na, gdzie fak­tem” jest każ­dy dowód księ­go­wy a wymia­ry są dwa nośni­ki kosz­tów: nazwa miej­sca i nazwa dzia­ła­nia (pro­ce­su). Z takim dwu­wy­mia­ro­wym mode­lem, ogra­ni­czo­nym do fak­tów jaki­mi są dowo­dy księ­go­we, moż­na sobie pora­dzić dys­po­nu­jąc wyłącz­nie Księgą Główną”. Tu dodam, że dzi­wi mnie to, że nie­któ­rzy dostaw­cy opro­gra­mo­wa­nia ERP twier­dzą, że ich roz­wią­za­nie wspie­ra rachun­ko­wość zarząd­czą mimo tego, że ich roz­wią­za­nie nie prze­wi­du­je kont zespo­łu 5 w pla­nie kont.

Idźmy dalej. Definicja mówi, że rachun­ko­wość zarząd­cza jest sys­te­mem gro­ma­dze­nia, agre­ga­cji, kla­sy­fi­ka­cji, ana­li­zy i pre­zen­to­wa­nia infor­ma­cji finan­so­wych i nie­fi­nan­so­wych. 

Czyli same dowo­dy księ­go­we to za mało. Co to są fak­ty nie­fi­nan­so­we? No np. fakt poja­wie­nia się rekla­ma­cji, fakt poja­wie­nia się zapy­ta­nia ofer­to­we­go, fakt wysła­nia ofer­ty itp. Jest wie­le dzia­łań w orga­ni­za­cjach (podob­no 80%), któ­re nie są doku­men­to­wa­ne dowo­dem księ­go­wym. Co z nimi? No nie­ste­ty sama księ­go­wość to za mało, potrzeb­ne są jesz­cze inne informacje:

Fakty i Źródła danych o faktach

Jak widać poza finan­sa­mi” dzie­je wie­le innych rze­czy. Dopiero wzię­cie ich wszyst­kich pod uwa­gę, pozwa­la mówić nam o wdra­ża­niu [[Rachunkowości zarząd­czej]]. No i teraz widać, że dane z kont to za mało. Powyżej poka­za­no tak­że Fakty ana­li­zo­wa­ne, cóż to jest? To są wła­śnie nasze kost­ki ana­li­tycz­ne” ale mają­ce wię­cej niż dwa wymia­ry (np. opi­sa­ne wyżej kosz­ty rodza­jo­we i kosz­ty dzia­łań), model taki (wie­lo­wy­mia­ro­wy a nie rela­cyj­ny) wyglą­da tak:

Model wielowymiarowy dla hurtowni danych

W cen­trum jest tabli­ca zwa­na tabli­ca fak­tów. Reprezentuje ona poszcze­gól­ne fak­ty (zda­rze­nia), zawie­ra cechy tych fak­tów (ColumnX). Ramiona to wymia­ry, czy­li dzie­dzi­no­we ele­men­ty powią­za­ne z fak­ta­mi zapi­sa­ny­mi w tabli­cy fak­tów, te tak­że mają cechy (atry­bu­ty). Tablica fak­tów słu­ży do inte­gra­cji (koja­rze­nia) zda­rzeń z odręb­nych dzie­dzi­no­wo obsza­rów. Np. by obsłu­żyć zapy­ta­nie ofer­to­we, w kil­ku dzia­łach rów­no­le­gle podej­mo­wa­ne są samo­dziel­ne pra­ce zwią­za­ne z opra­co­wa­niem tre­ści ofer­ty, kal­ku­la­cji, przy­go­to­wa­niem dru­ków, wysył­ką, opra­co­wa­niem pro­jek­tu i inne, fakt opra­co­wa­nia i wysła­nia takiej ofer­ty wią­że pra­cę tych wie­lu komó­rek w jako wymia­ry tego same­go fak­tu jakim jest wysła­nie tej oferty.

Taki model pozwa­la zebrać w jed­nym miej­scu (hur­tow­nia danych) logicz­nie powią­za­ne infor­ma­cje, Opisują one to samo zda­rze­nie ale z róż­nych per­spek­tyw, koszt (dowód księ­go­wy) jest tu tyl­ko jed­nym w wie­lu moż­li­wych wymia­rów, mogą być istot­ne np. cię­żar, czas trwa­nia, KPI pro­ce­su (aktyw­ność) powią­za­ne­go i wie­le innych. Innymi sło­wy zbie­ra­jąc dane z wie­lu apli­ka­cji, w jed­nym miej­scu do posta­ci wie­lo­wy­mia­ro­wej bazy, zbie­ra­my z róż­nych miejsc orga­ni­za­cji udo­ku­men­to­wa­ne zda­rze­nia i kojarz­my jest ze sobą okre­ślo­ny­mi (wybra­ny­mi do tego celu) fak­ta­mi (stąd cen­tral­na tabe­la to tabe­la faktów).

Tych wymia­rów może być oczy­wi­ście wię­cej niż czte­ry (mniej też ;)). Dopiero taka baza (hur­tow­nia danych) pozwa­la np. sko­ja­rzyć sprze­daż pro­duk­tów z pora­mi roku, powo­dzia­mi, pro­mo­cja­mi, wpro­wa­dze­niem na rynek innych pro­duk­tów (np. oce­na kani­ba­li­za­cji sta­rych pro­duk­tów przez nowe) i masę innych.… Teraz może­my powie­dzieć, że spraw­nie zarzą­dza­my orga­ni­za­cją, bo może­my ana­li­zo­wać inne niż tyl­ko finan­so­we aspek­ty dzia­łal­ność. A war­to nie zapo­mi­nać, że finan­se fir­my to skut­ki a nie przyczyny :).

Czy moż­na dobrze zapro­jek­to­wać taką hur­tow­nię na bazie ad-hoc gene­ro­wa­nych pomy­słów, pod­czas burzy mózgów, zbie­ra­nia potrzeb pod­czas wywia­dów? Nie! Model wie­lo­wy­mia­ro­wy MUSI być spój­ny, kom­plet­ny i nie­sprzecz­ny a tego nie da nam żad­na burza mózgów czy lista życzeń… Samej meto­dy ABC nie wdro­ży­my bez spój­ne­go mode­lu pro­ce­sów biz­ne­so­wych (tam są czyn­no­ści). Rachunkowości zarząd­czej nie wdroż­my bez peł­ne­go mode­lu organizacji…

Procesy biznesowe lepiej z regułami biznesowymi i zasobami

Kolejne szko­le­nia za mną, pro­jek­ty tak­że. Od cza­su do cza­su audyt (lub ciche opi­nie) cudzych pro­jek­tów. Stale widzę dwa poważ­ne pro­ble­my w wie­lu tych dokumentach:

  1. utra­ta pano­wa­nia nad złożonością,
  2. algo­ryt­mi­za­cja.

W 2005 roku napi­sa­łem na zakoń­cze­nie arty­ku­łu dot. modelowania:

Artykuł ten napi­sa­łem głów­nie po to by mogli Państwo tak­że sami oce­nić pra­cę firm, któ­rym pła­ci­cie za tego typu usłu­gi. Na pew­no mode­lo­wa­nie wyma­ga dłu­gich stu­diów i doświad­cze­nia ale efek­ty muszą być zro­zu­mia­łe. Nie jest ono moż­li­we bez udzia­łu wyż­szej kadry fir­my. Bieganie z ankie­ta­mi po fir­mie to doku­men­to­wa­nie sta­nu obec­ne­go a nie mode­lo­wa­nie. Dokumentowanie pro­ce­dur jest przy­dat­ne jako kolej­ny etap przy­go­to­wań do napi­sa­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia ale jest nie potrzeb­ne przed wdro­że­niem goto­we­go sys­te­mu, któ­ry tyl­ko pod­le­ga para­me­try­za­cji. Po dru­gie przed wdro­że­niem czy napi­sa­niem sys­te­mu koniecz­ne jest zbu­do­wa­nie mode­lu fir­my choć­by po to by upew­nić się, że jest on opty­mal­ny. W prze­ciw­nym wypad­ku może­my dopro­wa­dzić do utrwa­le­nia w sys­te­mie złych i nie­efek­tyw­nych pro­ce­sów a w skraj­nym przy­pad­ku panu­ją­ce­go w niej bała­ga­nu. ( Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

od tam­tej pory nie­ste­ty w zasa­dzie nic sie nie zmie­ni­ło na rynku.

Pierwszy pro­blem obja­wia się lawi­no­wo rosną­cą licz­bą deta­li na dia­gra­mach i licz­bą dia­gra­mów. Są nawet tacy, któ­rzy uwa­ża­ją, że popraw­ny model pro­ce­sów biz­ne­so­wych całej fir­my, to set­ki dia­gra­mów. Bzdura. Dlaczego?

Czym jest model?

Model [łac. modu­lus ?mia­ra?, ?wzór?], meto­dol. poję­cie ozna­cza­ją­ce zarów­no teo­re­tycz­ny, jak i fizycz­ny obiekt, któ­re­go ana­li­za lub obser­wa­cja umoż­li­wia pozna­wa­nie cech inne­go bada­ne­go (mode­lo­wa­ne­go) zja­wi­ska, pro­ce­su lub obiek­tu. (źr. słow­nik j.p. PWN).

Tak więc cechą dobre­go mode­lu jest moż­li­wość jego testo­wa­nia. Dobry model to uprosz­cze­nie rze­czy­wi­sto­ści odwzo­ro­wu­ją­ce jej ogra­ni­cze­nia w wybra­nym aspek­cie. Jeżeli więc testu­je­my np. współ­czyn­nik opo­ru powie­trza pro­jek­to­wa­ne­go samo­cho­du, wyma­ga­ny (i wystar­cza­ją­cy) model, to repre­zen­ta­cja kształ­tu karo­se­rii a nie kom­plet­na minia­tu­ra z sil­ni­kiem i siedzeniami.

Analizując orga­ni­za­cję, two­rzy­my model w celu… i tu powin­na paść nazwa kon­kret­ne­go aspek­tu, per­spek­ty­wy, któ­rą chce­my badać. Analiza orga­ni­za­cji to ele­ment np.:

  1. pla­nu budo­wy nowe­go sys­te­mu zarzą­dza­nia kosz­ta­mi (np. [[meto­da ABC t.j. zarzą­dza­nia kosz­ta­mi działań]]),
  2. pla­nu wdro­że­nia sys­te­mu Business Inteligence ([[model biz­ne­so­wy jako narzę­dzie pro­jek­to­wa­nia wie­lo­wy­mia­ro­we­go mode­lu hur­tow­ni danych]]),
  3. [[opra­co­wa­nia wyma­gań na opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie]] (ma dwa głów­ne aspek­ty: [[wybór goto­we­go opro­gra­mo­wa­nie]] oraz [[spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie dedykowane]]).

Podstawową decy­zją jaką nale­ży pod­jąć jest to, cze­go nie ujmo­wać na tych mode­lach, a każ­dy powy­żej ma inny kon­tekst. Każdy pro­jekt, zawie­ra­ją­cy etap mode­lo­wa­nia (mode­lo­wa­nie nie jest celem samym w sobie!) war­to roz­po­czy­nać od audy­tu. Jego celem jest spraw­dze­nie jaką wie­dzę o sobie samej posia­da orga­ni­za­cja czy­li ile z tego, co się dzie­je w orga­ni­za­cji, jest udo­ku­men­to­wa­ne. Nie musi to być wszyst­ko. Dobrze zarzą­dza­na orga­ni­za­cja panu­je nad swo­ją cią­gło­ścią dzia­ła­nia”, to jest rozu­mie jak dzia­ła i nie posia­da punk­tu, któ­ry jako jeden decy­du­je o być albo nie być fir­my. Typowym przy­kła­dem takie­go pun­ku jest jeden czło­wiek, sku­pia­ją­cy na sobie klu­czo­we dla funk­cjo­no­wa­nia fir­my, kom­pe­ten­cje (np. szef pro­duk­cji). Z natu­ry rze­czy ma to miej­sce w każ­dej małej fir­mie, jed­nak im więk­sza fir­ma tym ryzy­ko jej funk­cjo­no­wa­nia powin­no być mniej­sze. Podstawowym ele­men­tem zro­zu­mie­nia mecha­ni­zmu funk­cjo­no­wa­nia orga­ni­za­cji są regu­ły biz­ne­so­we i zdol­no­ści (wie­dza) posia­da­nych zaso­bów. Opisałem to tak­że w arty­ku­le Jak wyłu­skać isto­tę rze­czy.

Złożoność i algo­ryt­mi­za­cja. Typowy anty-przy­kład: pro­ces zawar­cia umo­wy, w któ­rym udział bie­rze mię­dzy inny­mi praw­nik oraz Zarząd. Celem jest (mię­dzy inny­mi) opi­nia praw­na o tre­ści umo­wy, uzgod­nie­nie jej tre­ści, na koń­cu pozy­ska­nie wła­ści­wych pod­pi­sów (np. wyma­ga­ne dwa a mamy pię­ciu człon­ków zarzą­du). W tym miej­scu poja­wia­ją się zawi­łe dia­gra­my opi­su­ją­ce jaki­mi to ścież­ka­mi prze­miesz­cza się doku­ment (nie ma uwag – OK, są uwa­gi, ode­ślij do praw­ni­ka, uzu­peł­nij, prze­ślij zno­wu do Zarządu, …, następ­nie pozy­skaj pod­pis Prezesa, jeże­li pre­zes jest nie­do­stęp­ny, to…). Nawet nie mam ambi­cji nary­so­wa­nia tego potwo­ra, jakim był­by taki dia­gram. Jak to mogło by wyglą­dać? Po pierw­sze potrzeb­na jest spe­cy­fi­ka­cja sta­no­wisk (ról w pro­ce­sach) i kom­pe­ten­cji tych ludzi. Po dru­gie lista reguł (pra­wo, zarzą­dza­nia wewnętrz­ne, pro­ce­du­ry itp.). W efek­cie powyż­szy pro­ces to pro­sty prze­pływ: kon­sul­ta­cja tre­ści umo­wy (praw­nik ma wie­dzę praw­ni­czą, w ramach swo­ich upraw­nień ma pra­wo do spo­tkań z Zarządem np. w celu skon­sul­to­wa­nia tre­ści umo­wy. Po uzgod­nie­niu tre­ści umo­wy, np. Asystent Zarządu, który(a) zna pro­ce­du­ry i pra­wo (kolej­na rola i kom­pe­ten­cje) zdo­by­wa wła­ści­we pod­pi­sy na umo­wie. Koniec! Gdzie szcze­gó­ły? Są! Proces jest, zakre­sy kom­pe­ten­cji są, pra­wo i zarzą­dze­nia są. Tą meto­dą, wte­dy jest to audyt, moż­na spraw­dzić spój­ność zakre­sów obo­wiąz­ków i zarzą­dzeń wewnętrz­nych z pra­wem oraz stra­te­gią firmy.

W wie­lu fir­mach sys­tem zarzą­dza­nia jest tak nie­spój­ny, że jedy­nym spo­so­bem funk­cjo­no­wa­nia tych firm, jest łama­nie zasad przez jej pra­cow­ni­ków. Niestety pierw­sza wpad­ka czę­sto powo­du­je zała­ma­nie się całe­go sys­te­mu (a nie raz i fir­my). Wiele Zarządów firm nie zda­je sobie nawet spra­wy z tego, jak duże jest ryzy­ko cią­gło­ści funk­cjo­no­wa­nia ich firm. 

Tak więc model pro­ce­su to nie algo­rytm dzia­ła­nia fir­my, wyka­za­no nie raz, że algo­ryt­mi­za­cja pra­cy ludzi jest nie­ce­lo­wa (wte­dy sto­su­je­my roboty).

Znaczna część tego co robią ludzie to efekt ich kom­pe­ten­cji, wie­dzy i doświad­cze­nia, a nie dyk­to­wa­nia im jak mają wyko­ny­wać swo­ja pracę.

Jeżeli wybie­rze­my dro­gę mode­lo­wa­nia tego wszyst­kie­go dia­gra­ma­mi, to ilość tych dia­gra­mów szyb­ko prze­kro­czy gra­ni­cę sen­sy całe­go pro­jek­tu: nie będą czy­ta­ne. Ich war­tość będzie żadna.

W pro­ce­sie dobrze przy­go­to­wa­nej ana­li­zy (jakiej­kol­wiek) mode­le two­rzy się by je badać, a nie tyl­ko po to by powsta­ły za pie­nią­dze spon­so­ra projektu.

Na koniec cie­ka­wy arty­kuł, opi­su­ją­cy jak sto­so­wać regu­ły biz­ne­so­we w mode­lo­wa­niu procesów.

In cre­ating a via­ble busi­ness solu­tion, you need both a busi­ness pro­cess model and busi­ness rules ? not just one or the other. The trick is not to get them entan­gled, to rema­in cle­ar abo­ut which is which. The good news is that by sepa­ra­ting them you can sim­pli­fy your busi­ness pro­cess models dra­ma­ti­cal­ly ? often by an order of magni­tu­de or more. This discus­sion expla­ins how. (za Business Processes: Better with Business Rules).

P.S.

Widzę pew­ną kore­la­cję: naj­czę­ściej obec­ni lub daw­ni pro­gra­mi­ści robią naj­gor­sze mode­le orga­ni­za­cji: mają ten­den­cje to tech­no­kra­tycz­nej algo­ryt­mi­za­cji opi­su pra­cy ludzi, igno­ru­ją czyn­nik ludz­ki w mode­lach, patrzą na pro­ce­sy w fir­mach przez pry­zmat ogra­ni­czeń roz­wią­zań i tech­no­lo­gii, któ­re ofe­ru­ją ich pra­co­daw­cy. Podobne ten­den­cje mają tak­że ci, któ­rzy pod­cho­dzą do two­rze­nia mode­li pro­ce­sów jak do spi­sa­nia meto­da­mi obraz­ko­wy­mi tego co mówią pra­cow­ni­cy pod­czas wywia­dów”. To tak­że bar­dzo złe mode­le, zary­zy­ku­ję tezę, że gor­sze od tych z rąk programistów.

Należy też nabrać poko­ry: więk­szość orga­ni­za­cji spraw­nie funk­cjo­nu­je nie mając żad­nych mode­li pro­ce­sów, więc teza, że ich brak szko­dzi jest nie do obro­ny. Po co więc te mode­le? Żeby zro­zu­mieć dla­cze­go tak jest i co się sta­nie, gdy zechce­my wpro­wa­dzać zmiany.

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.

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.

Knowledge Management – systemy wspomagające zarządzanie wiedzą GigaCon

Mamy przy­jem­ność zapro­sić Państwa na II edy­cję bez­płat­nej kon­fe­ren­cji, któ­ra jest szan­są na uzy­ska­nie lep­szych wyni­ków i prze­wa­gi nad konkurencją.

Konferencję Knowledge Management ? sys­te­my wspo­ma­ga­ją­ce zarzą­dza­nie wie­dzą GigaCon kie­ru­je­my do osób decy­du­ją­cych o spo­so­bie funk­cjo­no­wa­nia przed­się­bior­stwa, odpo­wie­dzial­nych za zarzą­dza­nie prze­pły­wem infor­ma­cji, zarzą­dza­nie wie­dzą oraz dobór roz­wią­zań i tech­no­lo­gii słu­żą­cych wspie­ra­niu tych pro­ce­sów; osób odpo­wie­dzial­nych za opty­mal­ne wyko­rzy­sta­nie posia­da­nych zaso­bów wiedzy.
Tematyka kon­fe­ren­cji:
- Systemy zarzą­dza­nia doku­men­ta­mi (docu­ment management)
- Systemy obie­gu pra­cy (work­flow)
- Systemy wspo­ma­ga­nia pra­cy gru­po­wej (gro­upwa­re)
- Hurtownie danych (data warehouse)
- Portale kor­po­ra­cyj­ne (enter­pri­se portals)
- Intranet – wewnętrz­ny internet
- Systemy wspo­ma­ga­nia decy­zji, sys­te­my ekspertowe
- Systemy do zarzą­dza­nia naucza­niem na odle­głość (e‑learning, wide­okon­fe­ren­cje, dyskusje
on-line)
- Systemy do zarzą­dza­nia bez­pie­czeń­stwem i ochro­na informacji
Nasza kon­fe­ren­cja przy­bli­ży suk­ces Państwa firmy.
WSTĘP BEZPŁATNY!
Rejestracja na stronie: 
Partner kon­fe­ren­cji:
DYSANT Software
Firmy zain­te­re­so­wa­ne pre­zen­ta­cją roz­wią­zań pod­czas kon­fe­ren­cji pro­si­my o kon­takt z organizatorem.
Kontakt:
Sławomir Krajewski
tel. 22/427 32 82
slawomir.krajewski@software.com.pl