Od czasu do czasu w zakresie wymagań biznesowych pojawiają się (coraz częściej) potrzeby z obszaru szeroko rozumianego kontrolingu, który polega na zbieraniu danych w celu tworzenia wyrafinowanych raportów, bazujących na danych z wszystkich obszarów organizacji. Dzisiaj kilka słów na ten temat, bo z moich nieformalnych (rozmowy i dokumenty projektowe u klientów) badań, wyłania się obraz wielu nieudanych wdrożeń hurtowni i aplikacji zwanych Business Intelligence, nieudanych z powodu małej ich wydajności, małej przydatności (najczęściej, tak!) lub obu naraz. Artykuł podzieliłem na dwie części: Troszkę o teorii… i Troszkę o tym z czym się spotykamy… Pierwszą część można pominąć 😉 jak ktoś chce.

Troszkę o teorii i nie nie tylko…

W artykule z 2011 roku napisałem:

Nauka wykazała, że sama analiza danych historycznych nie stanowi żadnej prognozy. Do tak zwanej predykcji  wymagany jest model ?przedmiotu?, którego zachowania chcemy przewidywać. Czy to możliwe? Tak. Czy to łatwe? Znowu odpowiem: nie. Potrzebny jest więc model a nie tylko dane historyczne (te pozwalają wyłącznie na analizę tego co było), więcej o tym w artykule o metodach naukowych analizy. (Źródło: Hurtownie danych czyli ?Systemy od historii? | Jarosław Żeliński IT-Consulting).

Jest cała masa podręczników technologicznych o projektowaniu i budowaniu hurtowni danych, których autorzy poprzestają jednak na opisach struktury modeli danych i procesów mechaniki ich ładowania. Bardzo mało jest opisów, jak tworzyć użyteczną zawartość tych zbiorów danych. Jedne z wielu takich (poprawnych) opisów technicznych:

OLAP Tool FunctionalitiesBefore we speak about OLAP tool selection criterion, we must first distinguish between the two types of OLAP tools, MOLAP (Multidimensional OLAP) and ROLAP (Relational OLAP).

1. MOLAP: In this type of OLAP, a cube is aggregated from the relational data source (data warehouse). When user generates a report request, the MOLAP tool can generate the results quickly because all data is already pre-aggregated within the cube.

2. ROLAP: In this type of OLAP, instead of pre-aggregating everything into a cube, the ROLAP engine essentially acts as a smart SQL generator. The ROLAP tool typically comes with a ‘Designer’ piece, where the data warehouse administrator can specify the relationship between the relational tables, as well as how dimensions, attributes, and hierarchies map to the underlying database tables.

Right now, there is a convergence between the traditional ROLAP and MOLAP vendors. ROLAP vendor recognize that users want their reports fast, so they are implementing MOLAP functionalities in their tools; MOLAP vendors recognize that many times it is necessary to drill down to the most detail level information, levels where the traditional cubes do not get to for performance and size reasons.
(Źródło: Business Intelligence: OLAP Tools)

Generalnie, rzecz w tym, że systemy ROLAP (R – relational) oparte są na relacyjnych zbiorach danych transakcyjnych systemów ERP. Systemy MOLAP (M- multidimensional) oparte są na przetworzonych do postaci tak zwanej “analitycznej kostki wielowymiarowej”, zbiorach danych z redundancją, będących niezależną kopią danych źródłowych (np. z tych ERP).

Pierwszy problem: ROLAP zakłada, że wymagane i wystarczające do analizy dane, to ten jeden zbiór danych w modelu relacyjnym systemu ERP. Była by to prawda, gdy nic istotnego nie działo się (nie było rejestrowane) w firmie, poza tym systemem ERP. Problem drugi: model relacyjny to setki tablic, ich dynamiczne scalanie  to praca sama w sobie, zmiana ich struktury (np. upgrade systemu) wymaga ponownego projektowania takiej hurtowni (konkretnie systemu raportowania). Z tego powodu wielu producentów systemów ERP oferuje od razu wbudowane w nie systemy raportowe. Niestety są to z góry narzucone “uniwersalne” modele, niekoniecznie pasujące do konkretnej państwa firmy.

Systemy MOLAP nie mają powyższych wad, jednak są to systemy zewnętrzne, wymagają więc dodatkowego zakupu, analizy i wiedzy jak zaprojektować wielowymiarowe modele danych do analizy (ale nie zapominajmy, że dodatkowy moduł analityczny w pakiecie ERP też trzeba dokupić). W przypadku gdy firma ma więcej aplikacji niż jedną (czyli powoli raczej norma), nie ma innej możliwości prowadzenia analiz, niż z pomocą zewnętrznego systemu agregującego dane z wszystkich istotnych dziedzinowych aplikacji w firmie.

Jak to wygląda?

Górny diagram to przykład modelu danych dla hurtowni danych [przyp. MOLAP]. Jest prosty, w praktyce skomentowany ?po ludzku?, jako metadane, jest czymś, z czym może pracować każdy, kto tylko zna daną dziedzinę (jej terminologię). Taki model danych (tak zwana gwiazda) odwzorowuje w prosty sposób znane biznesowe pojęcia. Diagram niżej, to model danych niewielkiego systemu biznesowego (model danych systemu ERP, mający nawet tysiące relacyjnych, nic nie mówiących zwykłemu śmiertelnikowi tabel,  byłby w tej proporcji zwykłą kolorową nieczytelną plamą?). Wykonanie samodzielnie, przez niespecjalistę, jakiegokolwiek raportu z tego drugiego systemu tabel graniczy z cudem. Można przygotować (administrator bazy) tak zwane ?widoki? dla użytkowników co nie zmienia faktu, że  ich opracowanie to nadal ?wiedza tajemna? i nikt z ?biznesu? sam tego nie zrobi. (Źródło: Hurtownie danych czyli ?Systemy od historii? | Jarosław Żeliński IT-Consulting)

Z perspektywy biznesowej znacznie wygodniejszy jest model wielowymiarowy obiektowy. Obiektami są tu “byty biznesowe” (np. faktura) a nie abstrakcyjne pojęcia z modeli danych (po normalizacji dane – ani tablice ani kolumny – nie opisują już wprost żadnego bytu/obiektu biznesowego!).

Jak to wygląda od strony standaryzacji? Organizacja [[OMG]] opracowała i opublikowała w 2003 roku meta-model hurtowni danych. Wygląda on tak:

Mamy tu dwie główne kolumny: lewa to proces tworzenia (projektowania) modelu analitycznych, prawa to jego użycie. W tym momencie interesuje nas głównie proces projektowania. W wersji obiektowej bazuje na informacji biznesowej, wersja relacyjna na (posiadanym) modelu danych. Do samego raportowania (prawa kolumna) wykorzystywane są modele wielowymiarowe jednak ważne jest to, że w modelu relacyjnym tak zwane “kostki analityczne” są tworzone dynamicznie (ich struktura jest statyczna ale ich zawartość jest generowana ad-hoc z danych w modelu relacyjnym). Model obiektowy tu jest naturalnie wielowymiarowy (kopia danych w dedykowanej strukturze wykonana do celów analitycznych), to praca z danymi bez potrzeby ich przetwarzania “w locie” (pracochłonne).

Dokument [[Common Warehouse Metamodel]] zawiera metamodele wersji relacyjnej i wielowymiarowej. Już samo tylko przejrzenie obu tych modeli pokazuje różnice pomiędzy złożonością struktury modelu relacyjnego (ponad 30 stron dokumentacji) a wielowymiarowego (10 stron): ten drugi jest znacznie prostszy.

Troszkę o tym z czym się spotykamy…

Na początek hasło Rachunkowość Zarządcza, bo nim posługuje się wiele firm wdrażających rożnego rodzaju hurtownie danych i systemy raportowania (polecam cały cytowany we fragmencie tekst):

Rachunkowość zarządcza, niekiedy określana również mianem rachunkowości menedżerskiej to jeden z członów rachunkowości (obok rachunkowości finansowej i podatkowej) służy celom wewnętrznym przedsiębiorstwa, dostarcza danych w przedsiębiorstwie niezbędnych do podejmowania decyzji bieżących i rozwojowych oraz informacji, które ułatwiają podejmowanie decyzji strategicznych, taktycznych, operacyjnych, planowanie i kontrolę poprzez wyspecjalizowane techniki i procedury, jak np. budżety, wzorce, odpowiednio dobrane modele rachunku kosztów i przychodów, analizę zachowania się kosztów i informowania o dokonaniach. Kierując się aktualnym ustaleniami Międzynarodowej Federacji Rachunkowości (IFAC) oraz literaturą w tej dziedzinie, możemy przyjąć, że: rachunkowość zarządcza jest systemem gromadzenia, agregacji, klasyfikacji, analizy i prezentowania informacji finansowych i niefinansowych wspomagających kierownictwo przedsiębiorstwa w podejmowaniu decyzji i kontroli ich realizacji. (Źródło: Rachunkowość zarządcza ? Encyklopedia Zarządzania)

Wytłuszczenie moje. O tym co wyróżniono kolorem czerwonym w dalszej części.

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

Rachunkowość polegająca wyłącznie na rejestrowaniu faktów finansowych nie jest rachunkowością zarządczą.

To znaczy, że informacje zbierane tylko z pomocą planu kont nie są taką informacją, wbrew temu co mówi bardzo wielu “konsultantów” firm wdrażających oprogramowanie ERP czy tylko FK.

Plan kont wśród wielu innych grup zawiera dwie: Zespół 4 Koszty według rodzaju i ich rozliczanie oraz  Zespół 5 Koszty według typów działalności i ich rozliczanie. Rachunek kosztów rodzajowy jest “prosty” i powszechnie stosowany, tak zwany rachunek kosztów ABC wart jest kilku słów. Najpierw definicja:

Rachunek kosztów działań ABC (kalkulacja ABC)[…]. Zgodnie z koncepcją ABC koszty pośrednie rozlicza się na produkty w przekroju działań i procesów generujących te koszty, a nie w przekroju podmiotów produkcyjnych (np. wydziałów). […] Powinny one być proporcjonalne do kosztów generowanych przez określone działania [aktywności, procesy, przyp. mój], których koszty podlegają rozliczeniu. W praktyce można zdefiniować dużą liczbę procesów gospodarczych prowadzących do powstania produktu na “wyjściu”, poczynając od działań ogólnych, a kończąc na działaniach w mikroskali. Kalkulacja typu ABC, określana jako kalkulacja oparta na działaniach lub elementarnych procesach, jest przeciwstawną metodą w stosunku do tra­dycyjnych systemów kalkulacji kosztów. (Źródło: Rachunek kosztów działań ? Encyklopedia Zarządzania).

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

Mamy tu cztery przykładowe koszty poniesione (oznaczone wielkimi literami). Standardowo księgowane są rodzajowo na konta zespołu 4 (wiersze). te same koszty można księgować jednocześnie na kontach zespołu 5 (kolumny).  Gdybyśmy mieli wyłącznie konta zespołu 4 nie wiedzielibyśmy ile nasz kosztują kampanie promocyjne łącznie. Wiedzielibyśmy ile wydajemy na usługi (obce) u podwykonawców, ale nie wiedzielibyśmy dokładnie, które działania  były w ten sposób wspierane. Oba przykłady pokazują, że wiedza gromadzona na kontach zespołu 4 to za mało do podejmowania decyzji biznesowych, w pierwszym przypadku np. o udziale w targach a w drugim np. o outsourcingu wybranych działań.

Kolejna ważna rzecz (nie pokazana na powyższym diagramie): jak nie trudno się domyśleć, suma wartości w każdej grupie kont musi stanowić 100% kosztów. Zakładanie kont  nazwanych “Inne wydatki” to niestety uznanie, że są koszty nad którymi nie panujemy, dlatego warto poświęcić się i przeprowadzić analizę swojej działalności w celu opracowania porządnej taksonomii kosztów w obu tych grupach, tak by nie było kont o wdzięcznej nazwie “Inne wydatki”, bo to świadczy o niemocy w analizie własnych kosztów.

Powyższe to nic innego jak dwuwymiarowa “kostka” analityczna, gdzie “faktem” jest każdy dowód księgowy a wymiary są dwa nośniki kosztów: nazwa miejsca i nazwa działania (procesu). Z takim dwuwymiarowym modelem, ograniczonym do faktów jakimi są dowody księgowe, można sobie poradzić dysponując wyłącznie  “Księgą Główną”. Tu dodam, że dziwi mnie to, że niektórzy dostawcy oprogramowania ERP twierdzą, że ich rozwiązanie wspiera rachunkowość zarządczą mimo tego, że ich rozwiązanie nie przewiduje kont zespołu 5 w planie kont.

Idźmy dalej. Definicja mówi, że rachunkowość zarządcza jest systemem gromadzenia, agregacji, klasyfikacji, analizy i prezentowania informacji finansowych i niefinansowych. 

Czyli same dowody księgowe to za mało. Co to są fakty niefinansowe? No np. fakt pojawienia się reklamacji, fakt pojawienia się zapytania ofertowego, fakt wysłania oferty itp. Jest wiele działań w organizacjach (podobno 80%), które nie są dokumentowane dowodem księgowym. Co z nimi? No niestety sama księgowość to za mało, potrzebne są jeszcze inne informacje:

Jak widać poza “finansami” dzieje wiele innych rzeczy. Dopiero wzięcie ich wszystkich pod uwagę, pozwala mówić nam o wdrażaniu [[Rachunkowości zarządczej]]. No i teraz widać, że dane z kont to za mało. Powyżej pokazano także Fakty analizowane, cóż to jest? To są właśnie nasze “kostki analityczne” ale mające więcej niż dwa wymiary (np. opisane wyżej koszty rodzajowe i koszty działań), model taki (wielowymiarowy a nie relacyjny) wygląda tak:

W centrum jest tablica zwana tablica faktów. Reprezentuje ona poszczególne fakty (zdarzenia), zawiera cechy tych faktów (ColumnX). Ramiona to wymiary, czyli dziedzinowe elementy powiązane z faktami zapisanymi w tablicy faktów, te także mają cechy (atrybuty). Tablica faktów służy do integracji (kojarzenia) zdarzeń z odrębnych dziedzinowo obszarów. Np. by obsłużyć zapytanie ofertowe, w kilku działach równolegle podejmowane są samodzielne prace związane z opracowaniem treści oferty, kalkulacji, przygotowaniem druków, wysyłką, opracowaniem projektu i inne, fakt opracowania i wysłania takiej oferty wiąże pracę tych wielu komórek w jako wymiary tego samego faktu jakim jest wysłanie tej oferty.

Taki model pozwala zebrać w jednym miejscu (hurtownia danych) logicznie powiązane informacje, Opisują one to samo zdarzenie ale z różnych perspektyw, koszt (dowód księgowy) jest tu tylko jednym w wielu możliwych wymiarów, mogą być istotne np. ciężar, czas trwania, KPI procesu (aktywność) powiązanego i wiele innych. Innymi słowy zbierając dane z wielu aplikacji, w jednym miejscu do postaci wielowymiarowej bazy, zbieramy z różnych miejsc organizacji udokumentowane zdarzenia i kojarzmy jest ze sobą określonymi (wybranymi do tego celu) faktami (stąd centralna tabela to tabela faktów).

Tych wymiarów może być oczywiście więcej niż cztery (mniej też ;)). Dopiero taka baza (hurtownia danych) pozwala np. skojarzyć sprzedaż produktów z porami roku, powodziami, promocjami, wprowadzeniem na rynek innych produktów (np. ocena kanibalizacji starych produktów przez nowe) i masę innych…. Teraz możemy powiedzieć, że sprawnie zarządzamy organizacją, bo możemy analizować inne niż tylko finansowe aspekty działalność. A warto nie zapominać, że finanse firmy to skutki a nie przyczyny :).

Czy można dobrze zaprojektować taką hurtownię na bazie ad-hoc generowanych pomysłów, podczas burzy mózgów, zbierania potrzeb podczas wywiadów? Nie! Model wielowymiarowy MUSI być spójny, kompletny i niesprzeczny a tego nie da nam żadna burza mózgów czy lista życzeń…  Samej metody ABC nie wdrożymy bez spójnego modelu procesów biznesowych (tam są czynności). Rachunkowości zarządczej nie wdrożmy bez pełnego modelu organizacji…