Raportowanie finansowe - kody controllingowe

Czy implementacja controllingu jest trudna, skomplikowana i droga?

Bajka:

Mamy jakąś tam księgowość - praktycznie dowolną, dowolnej    
wielkości.
I chcemy wprowadzić klasyfikację kosztów, która w żaden sposób    
nie pasuje do stanu obecnego naszej ewidencji. Jak to zrobić szybko    
i bezboleśnie?

Oczywiście potrzebne są zmiany organizacyjne - musimy ustalić z    
księgowością, jak ma klasyfikować dokumenty według naszych    
controllingowych wymagań - wprowadzamy tzw. system kodów    
controllingowych:
Każdy dokument jest przyporządkowywany do naszych grup...
tylko GDZIE?
Otóż, najprościej, w polu TREŚĆ TRANSAKCJI
Ale JAK?
Jakkolwiek, byle można to było odczytać bazodanowo.
Tu, w naszej bajce, zastosowano 6 nowych wymiarów ewidencji:    
A,B,C,D,E,F, każdy wymiar ma 10 stanów, od 0 do 9.

Więc każdy koszt opisujemy:
:A7:F9 (czyli w wymiarze A ma wartość 7, a w wym. F wartość 9)
:A5:D4
:C5:E5:A9
:B6:D5
:C1:E1
:A8
:C6:F5
:B9:F0:C5
:B1:D6
:C6:F6:A1
:A4:E0
:D7

I... pyk...

Film:
http://afin.net/webcasts/Demo_ControllingCodes.swf

Niezła bajka, no nie?
Do wdrożenia bardzo szybko.
Technicznie - 1 dzień, największy problem to problem    
organizacyjny, w każdym razie, technicznie, to chwila.

Tu się, wbrew pozorom, dużo dzieje:
1. dane są zasysane do hurtowni
2. dane są uzupełniane i poprawiane (uszlachetniane)
3. budowana jest kostka OLAP naszych kodów księgowych

A raport po prostu się otwiera i jest.


I drugi przykład - na tej samej kostce i tych samych danych.
Tym razem bez zmiany danych, ale ze zmianą ich przyporządkowania    
do poszczególnych kodów controllingowych.

Film:
http://afin.net/webcasts/Demo_ControllingCodes_Changes.swf

Warto wspomnieć o takich szczegółach dodatkowych, jak:
1. konsolidowanie danych z wielu miesięcy, oddziałów, itp. -    
patrz: konsolidacja - temat rozpracowany
2. Nazewnictwo wymiarów (semantyka biznesowa) - temat również    
już przerabiany
3. Wielkość danych - w przypadku kostek OLAP, wielkość danych    
źródłowych jest praktycznie bez znaczenia - bardziej przeszkadza    
w odczycie dużej kostki, niż w procesie jej tworzenia. Przy    
szczególnie duzych danych, polecamy tworzyć tzw. Data Marty, czyli    
mniejsze kostki tematyczne lub wydzielone np. okresami (Raporty robi    
się przede wszystkim na okres bieżący, ale wszystkie są do    
natychmiastowej dyspozycji)