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… i 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:

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:

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:

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:

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…