Diskuze

Nasazení manažerského systému MIK ve společnosti ARAMARK

Případová studie popisuje nasazení manažerského informačního systému ve společnosti, která působí v oblasti hromadného stravování. Studie popisuje požadavky, specifika reportingu u této společnosti a způsob jejich řešení v modelu založeném na technologii MIK-OLAP.

Pojem OLAP (On-Line Analytical Processing) se ve světě informačních technologií objevil v devadesátých letech minulého století a od té doby se vžil hlavně v souvislosti s řešeními Business Intelligence (BI). Jedná se o software na podporu rozhodování, jenž dovoluje uživateli rychle analyzovat informace sumarizované do vícerozměrných pohledů a hierarchií.

Nejdůležitější pojmy v technologii OLAP:

  • KOSTKA - Vícerozměrný datový prostor. Rozměr (dimenzionalitu) a strukturu tohoto prostoru určují dimenze. Kostka uvádí tyto dimenze do souvislostí. V kostce se pro účely analýzy slučují data, která jsou strukturována stejným způsobem. Strukturována stejným způsobem znamená, že data jsou stejně dimenzována.
    Příklad: Údaje o obratu lze načítat do jedné kostky z různých zdrojů, protože se pravděpodobně sledují ze stejných hledisek – roky, období, produkty, teritoria, prodejci, ...).
  • DIMENZE - Hierarchická struktura složená z elementů stejného druhu. Tyto hierarchické vztahy mohou být víceúrovňové.
    Příklad: V dimenzi Období (viz obrázek 1) budou v jedné úrovni elementy I. čtvrtletí, II. čtvrtletí atd., o úroveň níž budou Leden, Únor atd. V dimenzi Prodejní oblasti budou Jižní Čechy, Vysočina, Praha, Brno atd.
  • ELEMENT - Prvek dimenze. Dále nedělitelná jednotka strukturní informace. Element má v rámci dimenze jednoznačný název. Reference představuje element, jenž se aktivně neúčastní adresace datových buněk v kostce, nýbrž se odkazuje na jiný element a přebírá z něj svůj datový obsah. (Viz obrázek 1 – s postfixem "(ref.)".) Jde o případy, kdy je potřeba analyzovat stejná data v různých místech hierarchické struktury dimenze.

Jednotlivé elementy v dimenzi obsahují podniková data, ze kterých se v kostce tj. po uvedení více dimenzí do vzájemné souvislosti, stávají informace relevantní pro rozhodovací procesy.

Podél hierarchie dimenze probíhá agregace dat od elementů na nejnižší úrovni k elementům na úrovních vyšších. Načítání dat probíhá na nejnižší úrovni hierarchie – na úrovni tzv. bázových elementů (viz obrázek 1 – jednotlivé měsíce). Zadávání dat na agregovaných úrovních (např. Rok, I. Čtvrtletí atd.) je v rozporu se základním principem technologie OLAP.

Obrázek 1 – Dimenze období
(Klikněte na obrázek pro zvětšení)

Uživatel má k dispozici různé způsoby navigace, aby se v datových kostkách OLAP dostal k žádoucím informacím:

  • DRILL DOWN Pohyb v datech vertikálně směrem dolů v protisměru agregace. Je tedy možné dostat se na detailnější úrovně dimenze například pro zjištění příčin odchylky, která se projevila na některé vyšší úrovni agregace dat.
    Příklad: Prodeje za čtvrtletí - prodeje za měsíce.
  • ROLL UP - Jde o protiklad Drill Down – pohybujeme se strukturou dimenze vertikálně zdola nahoru k vyšším úrovním agregace.
  • SLICE & DICE - Získávání "výřezu" dat z kostky. Například chceme vidět hodnoty prodejů pouze za jeden měsíc – z kostky "vyřízneme" datový "plátek" (slice) dle dimenze období. Přetáčení kostky (dice) za účelem změny pohledu na data. Prakticky se děje záměnou dimenzí v náhledu.

Importovaná data musí být k dispozici na požadovaném stupni detailu, jenž je dán strukturou dimenzí cílových kostek, potažmo potřebami cílových analýz. Každý importovaný záznam musí obsahovat položky shodné se strukturou kostky tak, aby každá dimenze byla pokryta, čímž je zajištěno jednoznačné přiřazení v rámci datového prostoru definovaného kostkou. Například analyzuji-li data o prodejích z pohledu pěti dimenzí – roky, období, prodejci, regiony, produkty – musím mít ve zdrojovém souboru všechny tyto údaje zastoupeny.

Obrázek 2 – Kostka (3 dimenze)

Model, ve kterém se uživatel pohybuje, abstrahuje od původního rozvrstvení dat podle zdrojových funkčních oblastí (různé systémy, moduly či různé věcně i fyzicky oddělené zdroje) a nahrazuje jej pohledem vycházejícím z podnikatelské logiky zobrazované skutečnosti. Tento pohled se neomezuje na původní funkční oblasti, nýbrž dává celkový "bezešvý" obrázek ve více dimenzích. Nástroje OLAP mají multidimenzionalitu a schopnost integrace dat z více zdrojů jako své základní vlastnosti.

Nasazení nástrojů OLAP mění kvalitu řídících procesů, umožňuje objevit skryté skutečnosti a trendy, protože manažer ještě nikdy neviděl svůj podnik popsán tímto způsobem, a jít tak až za hranice manažerské intuice. Objevovat a potvrzovat ekonomické souvislosti – to je vytvářet business knowledge a intelligence.

Systémy OLAP byly historicky zaměřeny výhradně na analýzu agregovaných veličin, vztahů mezi nimi a vývojových trendů tj. získání celkového obrázku o analyzované skutečnosti při abstrakci od atomických dat. Na rozdíl od obvyklých relačních databází tedy nejde u databáze OLAP o práci s detailními daty ale o celkový pohled na souvislosti.

Data warehouse a nástroje OLAP částečně řeší letitý problém vedoucího pracovníka: rozpor mezi potřebou získat celkový obrázek a nutností pohybovat se na úrovni detailu. Dává možnost pohybovat se na obou úrovních, protože je založen na kvantu detailních dat, jež agreguje a zobrazuje z mnoha různých podnikatelských perspektiv (dimenzí).

OLAP dokáže být v rukou schopného uživatele mocným nástrojem, který výrazně zkvalitní a zefektivní rozhodovací procesy.

Příklad využití OLAP v řízení podniku

Typický analytický model může mít například tyto kostky:

  • ÚČETNICTVÍ/FINANCE - Zdrojem dat jsou účetní transakce hlavní knihy. Výstupem jsou zůstatky účtů k určitému datu, obraty na účtech, vypočtené ukazatele. Zmíněné výstupy lze sledovat agregované za celou firmu, jakož i z pohledů a úrovní daných zúčastněnými dimenzemi.
  • OBCHOD - Zdrojem dat je obchodní aplikace. Sledování výše, struktury a vývoje prodejů v čase, podle výrobních řad, skupin či individuálních výrobků, prodejních teritorií, prodejců atd. Výpočet příslušných ukazatelů.
  • VÝROBA - Sledování kvantitativních a kvalitativních charakteristik výroby – např. počty průchodů výrobků v různé fázi rozpracovanosti kontrolními body, plánované a skutečné kalkulace, počty, typy a náklady na výrobní odchylky a zmetky, vyhodnocované časové údaje apod. Zdrojem dat je výrobní systém nebo modul.
  • MĚNY - Speciální druh kostky; představuje úložiště měnových kursů pro přepočet hodnot a ukazatelů v kostkách FINANCE a OBCHOD. Jsou v ní zastoupeny všechny měny užívané firmou. Jedna z nich je vybrána jako hlavní – koncernová – a kursy všech ostatních měn jsou vyjádřeny ve vztahu k ní.

Typické společné dimenze (dimenze využité ve více kostkách) budou tyto:

  • ROKY - Elementy dimenze: 2003, 2004, 2005, 2006 atd.
  • OBDOBÍ - Dimenzi období jdoucí na úroveň měsíců obsahuje obrázek 1.
  • TYPY DAT - Tato dimenze znásobuje datový prostor pro možnost zadávání plánových či simulačních hodnot paralelně ke skutečnosti. Elementy např.: skutečnost, plán 1, plán 2 (různé verze plánu), simulace, kalkulace.
  • MĚNY - Obsahuje měny používané účetní jednotkou – např. CZK, EUR, USD.

Specifické dimenze použité v relevantních kostkách:

  • DIMENZE PROMĚNNÝCH - Jádrem každé datové kostky je dimenze proměnných, v níž se nachází vlastní předmět zkoumání analýzy – proměnné (ukazatele). Tyto analyzujeme z pohledu ostatních dimenzí obsažených v kostce.
    • Kostka ÚČETNICTVÍ/FINANCE - Náplní dimenze proměnných bude účtový rozvrh jdoucí na úroveň analytických účtů. V paralelní větvi budou finanční ukazatele vypočtené – ať už formou agregací pomocí referenčních elementů (např. celkové tržby z účtů 601, 602 a 604) nebo pomocí vzorců (např. ukazatele likvidity, aktivity, rentability apod.) – ze zdrojových účtů finančního účetnictví. V dalších paralelních větvích mohou být hierarchické struktury položek statutární Rozvahy a Výkazu zisku a ztráty s údaji rovněž získávanými pomocí odkazů do účtového rozvrhu (viz obrázek 3 – ve větvi "Finanční účetnictví" je účtový rozvrh).
    • Kostka OBCHOD - V dimenzi proměnných budou např. obchodní ukazatele, prodeje, tržby, podíly na trhu.
    • Kostka VÝROBA - Počty výrobků v různých stádiích rozpracovanosti, počty průchodů kontrolními body, průběžné časy, počty vad.

    Obrázek 3 – Dimenze proměnných
    (Klikněte na obrázek pro zvětšení)

  • MÁ DÁTI/DAL - Tato dimenze zdvojuje pohled na účetní transakce podle principu podvojného účetnictví. Konečný zůstatek analytického nebo syntetického účtu se získá na úrovni nejvyššího elementu (KZ = MD – D). Existence této dimenze rovněž umožňuje kontrolu podvojnosti účetních zápisů – agregace na nejvyšším elementu (za celou hierarchii finančních účtů) a za celou účetní jednotku by měl být roven nule. Obsažena bude v kostce Účetnictví.
  • ORGANIZAČNÍ STRUKTURA - Členění firmy na závody, divize, útvary, oddělení, nákladová střediska. Jsou-li účetní transakce touto informací opatřeny, bude mít význam v kostce Účetnictví.
  • PRODUKTOVÉ PORTFOLIO - Struktura výrobních řad, skupin a v příp. potřeby a proveditelnosti až na úroveň individuálních výrobků. Bude součástí kostky Výroba. Nebo lze zapracovat pohled tržní podle prodejních balíčků. Taková dimenze bude přiřazena obchodní kostce.
  • PRODEJNÍ KANÁLY - Může obsahovat formy prodeje provozované firmou (vlastní obchody, smluvní partneři, zásilková služba, ostatní) a tím umožnit analýzu z tohoto pohledu. Bude rovněž součástí obchodní kostky.
  • ZÁKAZNÍCI - Hierarchická struktura zákazníků společnosti. Již v rámci této dimenze lze elementy členit dle různých klasifikací či teritoria. Takovéto členění však může být přímo v dimenzi v rámci její struktury zapracováno jen jedno. Po zvážení všech okolností může být účelnější pro tyto pohledy založit samostatné dimenze – viz dále. Tato a další dvě dimenze typicky najdou uplatnění v kostce Obchod.
  • KLASIFIKACE ZÁKAZNÍKŮ - Seskupování zákazníků dle různých kritérií vycházející z metodiky užívané společností.
  • TERITORIA - Teritoriální struktura odběratelů.
  • KONTROLNÍ BODY - Pohled na výrobu dle kontrolních bodů implementovaných při vyřizování zakázky – přijetí zakázky, kontrola vstupního materiálu, výrobní stupeň 1, výrobní stupeň 2, výstupní kontrola aj.
  • VÝROBNÍ VADY - Druhy vad výrobků procházejících kontrolními body. V hierarchii možno kategorizovat podle části výrobku či charakteru vady (znečištění, fyzické poškození, nesprávné rozměry atd.).
  • Jakékoliv další dle potřeby.

Počet dimenzí v kostce není neomezený (např. v MIK-OLAP max. 16). Tímto faktem se však nemusíme cítit omezeni, protože analýzu je vždy možno strukturovat jinak a rozdělit do více kostek. Samostatnou kostku vytváříme pro logicky vymezenou homogenní část analýzy – ukazatele zobrazující stejně strukturovanou oblast podnikové činnosti, analyzovanou stejnými uživateli v rámci jednoho analytického procesu. Stejně strukturovanou znamená stejně dimenzovanou – dává smysl analyzovat každý ukazatel z pohledu všech dimenzí v kostce a každá dimenze je ve vstupních datech zastoupena.
Příklad: Je chybou pokoušet se slučovat kostky Účetnictví a Obchod. Každá má jiné ukazatele, jiné dimenze, jiný jejich počet. Prostým množinovým součtem všech těchto položek a vytvořením jedné velké kostky si můžeme způsobit značné problémy při její tvorbě, při tvorbě grafických a tabelárních analýz, při samotném jejich užití a při práci s takovou kostkou.

Pokud tedy z důvodu velké komplexity zadání narazíme na meze technologie MIK-OLAP, neznamená to, že tato technologie je nedostatečná. Spíše to ukazuje na nedostatky analýzy a z toho vyplývající značnou komplexitu výsledného datového modelu. Takový model nemusí uživateli nezbytně podat kompletní informace. Spíše mu celou strukturu zneprůhlední a ztíží jejich získání. Méně je více a je lepší provést na počátku tvorby modelu dobrou analýzu, rozčlenit zadání na logické celky a klidně vytvořit více kostek. Budeme-li chtít využít data z jedné kostky v jiné, při dodržení určitých pravidel, vyplývajících z různé dimenzionality kostek, existuje možnost přenosu dat mezi nimi.

Další typická funkcionalita OLAP nástrojů:

  • Měnová funkcionalita umožňuje okamžitý přepočet a zobrazení peněžních částek v jiné měně. Podmiňuje ji existence měnové kostky a měnové dimenze v modelu.
  • Některé OLAP nástroje (vč. MIK-OLAP) umožňují zápis do databáze, tj. možnost plánování, vytváření scénářů, prognóz apod. Konkrétně se tak děje díky dimenzi Typy dat, která umožňuje vytvořit více paralelních vrstev pro zápis a srovnání různých typů dat.

Řešení MIKsolution+

MIKsolution+ je databázový systém, plně založený na vícedimenzionální technologii OLAP, realizovaný v architektuře klient-server. Používá se jako technologická základna pro optimalizaci plánování, analýzy dat a automatizaci výkaznictví. Vícevrstvá architektura umožňuje současnou práci více uživatelů.

Data uložená v databázi MIK-OLAP mohou být zobrazena a analyzována ve více aplikacích uživatelského rozhraní. Dvě nejtypičtější jsou MIK-ONE a MIK-XLREPORT.

MIK-ONE je interaktivní controllingové rozhraní společnosti MIK AG pro profesionální prezentaci informací pro řízení. Poskytuje grafy, tabulky, semafory a plánovací funkce s vysokou vypovídací schopností se zaměřením na podnikovou ekonomiku a je tak nástrojem pro pracovníky controllingu a manažery. Standardní funkcionalita analýz tohoto druhu jako např. srovnání plán-skutečnost, meziroční srovnání aj. je pevnou součástí technologie MIK-OLAP a do uživatelského rozhraní je odpovídajícím způsobem zapracována.

MIK-ONE má z hlediska exekutivního uživatele tu výhodu, že pro jeho zprovoznění, nastavení a vytváření analýz nejsou nikterak třeba programátorské dovednosti. Systém je dále možno prostřednictvím veřejných a neveřejných témat (množina analýz) personalizovat a diferencovat tak přístup různých uživatelů k různým informacím.

Obrázek 4 - MIK-ONE (obsahově koresponduje s obr. 5)
(Klikněte na obrázek pro zvětšení)

MIK-XLREPORT představuje propojení dat uložených v databázi MIK-OLAP s programem, s nímž drtivá většina typických cílových uživatelů běžně pracuje - Microsoft Excel. Tento kancelářský software je rozšířen o funkce, které umožňují plnohodnotnou práci s daty a strukturami uloženými v databázi, včetně zápisu do ní. Analýzy jsou s databází stále dynamicky propojeny, takže v každém okamžiku obsahují aktuální data. Data lze do pracovních sešitů samozřejmě vkládat i bez propojení, a tak vytvářet statické excelové tabulky pro další zpracování. Microsoft Excel zde slouží pouze jako prohlížeč dat, nikoliv k jejich ukládání. Náhledy aktuálních dat lze ovšem ukládat jako statické tabulky obvyklým způsobem.

MIK-XLREPORT může pracovat ve dvou módech: MIK vzorce a MIK prohlížeč. Prvně jmenovaný se příliš neliší od principu práce běžného v tomto software (zadávání vzorců, analýza dat, vytváření tabulek atd.), zatímco druhý umožňuje provádět operace drill-down, roll-up a slice & dice. Stejně jako v MIK-OLAP, vytváření nových či modifikace stávajících analýz je prosto programování.

Obrázek 5 - MIK-XLREPORT (obsahově koresponduje s obr. 4)
(Klikněte na obrázek pro zvětšení)

Veškeré elementy dimenzí jsou zobrazeny s označením srozumitelným pro uživatele. Mimoto může být každý element (interně v systému) opatřen klíčem, kterých systém MIK-OLAP dovoluje přiřadit až 20. Klíč představuje vazbu mezi zdrojovými systémy a analýzou v MIS. V databázích různých provozních systémů může být např. nákladové středisko evidováno různě - čísly, písmeny či jejich kombinacemi. Uživatel MIS však chce vidět srozumitelný název střediska a jeho číslo či jiný kód leda jako doplňkovou informaci.

MIK-OLAP dále umožňuje každému objektu databáze (kostka, dimenze, element, atribut atp.) přiřadit až 10 aliasů tj. alternativních názvů. Takto lze implementovat např. vícejazyčnost uživatelského rozhraní.

Modifikace dimenzí jsou v zásadě realizovatelné jednoduše a v krátkém čase. Lze je provádět ručně (u spíše statických a méně rozsáhlých dimenzí) nebo dynamicky formou automatické aktualizace načtením.

Databáze MIK-OLAP je implementována ve formě souborů organizovaných v adresářovém stromu na disku. Operace zálohování tedy nepředstavuje nic jiného než zkopírování a přejmenování jednoho adresáře o velikosti řádově desítek MB.

Standardní nástroje versus nástroje OLAP v reportingu

Pro účely reportingu a analýz dat nabízejí podnikové IS nástroje kategorizovatelné do těchto skupin:

  • předdefinované reporty, u pokročilejších systémů včetně generátoru reportů,
  • prostředí pro uživatelskou definici SQL dotazů do relační databáze,
  • předdefinované manažerské výstupy založené na OLAP nadstavbě relační databáze (např. MS SQL OLAP),
  • manažerské rozhraní - doplněk do MS Excel obsahující funkce pro přístup k datům v relační databázi (obraty a stavy účtů, obchodní data, ukazatele),
  • předdefinované elementární ukazatele finanční analýzy či pyramidové struktury ukazatelů s možností vytvoření tabulek a grafů z nich.

Všechny tyto nástroje mají jedno společné - jsou pevně předdefinovány tj. dodány dodavatelem na základě jeho předpokladů nebo specifických požadavků uživatele. Má-li uživatel nějakou možnost ovlivnit výstup, pak je to vždy v rámci určitých mezí daných programátorem nebo druhem databáze (relační), nad kterou je nástroj postaven.Většinou jde o úpravy na úrovni řazení, omezujících podmínek pro obsah zobrazených dat, zvolení vstupních parametrů omezujících množství zobrazení dat, u pokročilejších systémů vytvoření mezisoučtů. Úpravy nad rámec těchto mezí se provádí programátorskými zásahy dodavatele a je tedy nutno je zaplatit nebo nést interní náklady v podobě odborně vyškoleného IT pracovníka. Nadstavby emulující funkcionalitu OLAP jsou opět založeny na relačních systémech a je nutno je nějakými prostředky nadefinovat tj. naprogramovat.

Ve prospěch reportingu v prostředí OLAP se dá říci, že standardní (ne-OLAP) nástroje postrádají možnosti nativní OLAP databáze s vlastním uživatelským rozhraním. Komplexnost a flexibilita OLAP reportingu spočívá v neomezenosti co do různých pohledů, úrovně detailu, kombinací dimenzí atp. de facto existuje nekonečně mnoho možností, jak nahlížet a analyzovat podniková data. Konkrétně databáze MIK-OLAP dále zbavuje uživatele nutnosti cokoliv programovat. Model, jeho plnění daty a výstupní tabulky/reporty či grafy se definují, nikoliv programují. MIK-OLAP je koncipován tak, aby jej mohl plně ovládnout manažer s přiměřeně dobrými počítačovými dovednostmi.

Případová studie: pokročilý reporting v MIK-OLAP

Česká filiálka nadnárodní společnosti působící v oblasti hromadného stravování byla v situaci, kdy s růstem objemu aktivit rostl rozsah reportingu do neúnosných mezí. V tomto oboru se navíc podniká s maržemi okolo 5 % [1], což vyvíjí zvýšený tlak na kvalitu controllingu. Mateřskou firmou žádaná sada výkazů v asi desetidenním rytmu neúnosně zatěžovala pracovníky příslušných oddělení a brzy by vedla k nutnosti zaměstnat další pracovní sílu. Vedení firmy se rozhodlo pořídit řešení MIK-OLAP s primárním cílem automatizovat celý reporting.

V následujícím textu jsou uvedeny požadavky a specifika vykazování u této společnosti a způsob jejich řešení v modelu založeném na technologii MIK-OLAP.

Požadavek 1:

Společnost má hospodářský rok odlišný od kalendářního. Přelom září/říjen je jeho přelomem. Měsíce hospodářského roku se s kalendářními neshodují, vyjma přelomů čtvrtletí, které se s kalendářním rokem překrývají. Reporty pro mateřskou společnost se vyhotovují za hospodářský rok.

Řešení požadavku 1:

Byly vytvořeny dvě dimenze období: jedna strukturovaná podle běžného kalendářního roku, druhá podle hospodářského roku začínajícího 1. října a končícího 30. září. Společnost má rovněž vlastní měsíce s počtem dnů až 40 a svá čtvrtletí. Z toho vyplynula nutnost vytvořit dvě účetní kostky. Do obou se načítají stejná data. Importy týchž dat tedy probíhají automaticky dvakrát - jednou do kostky dimenzované podle kalendářního roku a jednou do kostky se zapracovaným hospodářským rokem.

Obě kostky mají stejnou strukturu s výjimkou zmíněné dimenze Období a dimenze proměnných. Obě obsahují účtový rozvrh společnosti. V účetní kostce však následují struktury pro běžné účetní reporty (m.j. české statutární výkazy) a v "hospodářské" kostce struktury pro reporty určené mateřské společnosti (viz obrázek 6, pravá část).

Požadavek 2:

Zápis účetních transakcí probíhá do více databázových souborů (.dbf), jejichž název a umístění se k různým rozhodným účetním okamžikům (otevření nového období, uzavření předchozího) v průběhu roku mění.

Řešení požadavku 2:

Tato situace vyvolává nutnost konsolidace dat z několika zdrojů. Jak bylo řečeno v kapitole 1, toto patří mezi základní vlastnost nástrojů OLAP, tedy i MIK-OLAP. Typ zdroje dat, jejich formát a podoba má vliv pouze na nastavení importních definic. V samotné databázi potom "jsou si všechna data rovna".

Požadavek 3:

  1. Společnost účtuje ve starším účetním systému, který neposkytuje možnost vyexportovat data v potřebné podobě (textový soubor ve struktuře zpracovatelné systémem MIK).
  2. Kódy zapisované v rámci procesu účtování do jediného databázového pole účetního systému obsahují čísla analytických účtů, kódy nákladových středisek a provozů, kódy dodavatelů a odběratelů. Tyto údaje je třeba v importním souboru umístit do samostatných polí, neboť budou načítány do samostatných dimenzí (dimenze proměnných, dimenze struktury firmy a dimenze dodavatelů/odběratelů).
  3. Zákazník požaduje implementaci mechanismu tzv. "datových konzerv". Jde o to, aby odreportovaná období již nebylo možno ovlivnit dodatečným účtováním. Je nutno je zafixovat tak, aby kdykoliv bylo možno odpovědět na dodatečné dotazy mateřské společnosti a vycházet přitom z neovlivněných podkladů.

Řešení požadavku 3:

Vzhledem k vlastnostem účetního systému zákazníka a k požadavku na fixaci dat byla implementována jednoduchá pomocná databáze (datový buffer) jako součást celkového řešení MIS. Jde o datové úložiště zařazené mezi primární zdroj dat (účetnictví) a vlastní databázi MIK-OLAP. Za normálních okolností technologie MIKsolution+ tuto doplňkovou komponentu ke své funkci nepotřebuje a nejedná se o součást standardních řešení MIK-OLAP.

Obecné důvody pro implementaci pomocné databáze:

  • zdrojová data jsou v takové podobě, že k nim nelze přistoupit přímo prostředky MIK resp. primární systém není schopen data do takového formátu připravit (chybí možnost definice a exportu textových souborů, chybí automatické spouštění těchto procesů)
  • potřeba transformace (úprav) dat před načtením do MIK.

Ad 1. Nástroje technologie MIKSolution+ pro parsování textových řetězců nebyly z důvodu komplexnosti požadavku využity a transformace vstupu do podoby importovatelné do MIK-OLAP je prováděna v pomocné databázi. Tento stav technologicky kopíruje model implementace MIS - za přípravu dat v požadované struktuře je zodpovědný zákazník.

Ad 2. Navazuje na bod 1. Je nutno provést transformaci dat - dekompozici kódů užívaných v účetním systému do kódů použitelných pro adresaci elementů v různých dimenzích.

Ad 3. V obou kostkách byly založeny dvě datové vrstvy (elementy v dimenzi Typy dat) pro skutečné hodnoty - vrstva Actual a Actual_fixed. První jmenovaná obsahuje účetní data dle skutečného datumu uskutečnění zdanitelného plnění, druhá podle datumu modifikovaného v pomocné databázi tak, aby dodatečně účtované transakce neovlivnily odreportovaný měsíc.

Alternativní řešení fixace dat: vždy existuje možnost vytvořit si zálohu databáze MIK-OLAP a v případě potřeby se připojit na ni. Jelikož databáze MIK-OLAP je implementována ve formě souborů organizovaných v adresářovém stromě na disku, nepředstavuje operace zálohování nic jiného než zkopírování a přejmenování jednoho adresáře o velikosti řádově desítek MB.

Tok a zpracování dat je následující: data z primárního zdroje (účetnictví) jsou inkrementálně načtena do pomocné databáze. Zde jsou upravena a poté dle potřeby importována do MIK-OLAP. Pomocná databáze stojí na osvědčené open source platformě a architektuře klient-server.

Požadavek 4:

Ruční zadávání plánovacích dat, plánování na úrovni středisek (nikoliv podřízených jednotek - provozů).

Řešení požadavku 4:

Ve struktuře modelu byla umožněna funkcionalita plánování. Zákazník neplánuje na nejnižší úrovni (provozy) ale na nadřazené úrovni hospodářských středisek. Toto je ostatně obecný přístup k plánování - plány se sestavují za vyšší organizační celky a málokdy se jde na detail. Zápis dat je však v databázi OLAP možný pouze na bázové elementy. Na agregované úrovni tedy byly vytvořeny zvláštní bázové elementy pro zápis plánu. Na ně se odkazují zadávací formuláře v MIK-XLREPORT, kudy uživatel data do databáze zapisuje. Výsledkem je, že skutečná i plánovací data se dají analyzovat v rámci jednoho pohledu pouhou záměnou elementů v dimenzi Typ dat (plán za skutečnost) nebo aktivací funkce Porovnání plán-skutečnost.

Požadavek 5:

Používání více měn; pro přepočet majetku a závazků do cizí měny - měna mateřské společnosti - používá účetní jednotka měsíční pevný kurs. V této měně se reportuje.

Řešení požadavku 5:

V MIK-XLREPORT byly založeny přehledy měsíčních kursů pro všechny dostupné roky. Tyto tabulky jsou zadávací, takže jejich prostřednictvím lze ručně zapisovat do databáze. Jelikož však jde o zadání stejného čísla do více elementů (dnů) v jednom měsíci, je výhodnější použít funkci Plánování/Plnit. Tato funkce umožňuje vyplnit vybraný segment datového prostoru zadanou hodnotou. V modelu jsou předpřipraveny definice plnění pro předmětné kostky.

Požadavek 6:

Zobrazení počátečních zůstatků (PZ) na rozvahových účtech.

Řešení požadavku 6:

Rozlišení účtů na výsledkové a rozvahové má význam pro způsob zobrazení zůstatků. V případě výsledkových účtů, kde není třeba zohledňovat PZ na začátku sledovaného období, nám postačí prostá kumulace za vybraný časový úsek, případně kumulace období (kumulace od počátku roku do libovolného vybraného dne; ve vzorcích v MIK-XLREPORT parametr "C").

Pro rozvahové účty byl zvolen následující postup:

  1. K počátku datového stavu v MIK (1. 1. 2003) byly nahrány PZ obsažené v transakcích otevírání účetních knih pro daný rok.
  2. V dalších letech se importují pouze pohyby na jednotlivých účtech s vyloučením otevírání účetních knih.
  3. PZ získáme pomocí funkce kumulace období za všechny roky (kumulace od počátku dat v MIK - tj. od 1. 1. 2003; v MIK-XLREPORT parametr "Y").

Tento koncept by měl v každém okamžiku zajistit zobrazení správného zůstatku rozvahového účtu.

Požadavek 7:

Společnost využívá v reportech strukturu ukazatelů vytvořenou mateřskou firmou, kdy každý řádek reportu představuje tzv. SRPL položku opatřenou identifikačním číslem (SRPL = Standard Reporting Package Line).

Řešení požadavku 7:

Položky SRPL jsou velmi praktickým nástrojem modulárnosti reportingu. Představují dodatečnou vrstvu mezi účty finančního účetnictví, u nichž dochází k častým změnám co do výčtu, a stabilizovanými položkami modulárně stavěných reportů, odesílaných mateřské společnosti. Změnu v definici určité položky tak postačí provést na jednom místě a tato změna se projeví ve všech výskytech dané SRPL položky v reportech.

Dodané řešení tento koncept ve struktuře modelu a v reportech plně zohlednilo a využilo. Jedna SRPL položka je tvořena nasčítáním několika analytických účtů finančního účetnictví a každý řádek reportu představuje jednu SRPL položku.

Celou strukturu ilustruje obrázek 6, který znázorňuje dimenzi proměnných kostky Finance. V jeho levé části je hierarchická struktura elementů zobrazující účtový rozvrh. Uprostřed je z analytických účtů odkázaných referencí nasčítána položka SRPL 1101, která je v pravé části (opět formou reference) užita jako jeden ze zdrojů řádku Total Cash v definici aktivní strany rozvahy.

Obrázek 6 - Dimenze proměnných kostky Finance
(Klikněte na obrázek pro zvětšení)

Společnost tak s vynaložením přiměřených nákladů vyřešila ožehavý problém a v podobě MIK-OLAP získala kvalitní technologickou základnu pro řešení dalších témat podnikového řízení.

Závěr

Od nasazení technologie OLAP do řídících a rozhodovacíh procesů podniku se očekávají tyto efekty:

  • konsolidace dat z různých zdrojů,
  • pokročilá analýza dat z různých pohledů,
  • zrychlení, zkvalitnění a zautomatizování reportingu,
  • podpora a automatizace plánovacích procesů,
  • zefektivnění a zrychlení rutinních činností controllingu,
  • uvolnění lidských zdrojů pro významější úkoly,
  • položení základu pro realizaci metodik řízení (např. Balanced Scorecard).

Vlastní nasazení této technoogie pro řízení podniku se týká menší skupiny uživatelů z řad manažerů a neznamená tudíž zásadní zásah do informační struktury podniku a do vlastního fungování podniku. Naopak se dá říci, že je vhodným a citlivým doplněním vrcholu ledovce stávající infromační strukturuy. Při implementaci může dojít k odhalení chyb v datech provozních informačních systémů a můžou se objevit nedostatky v půběhu procesů.

Manažer ví, že údaje o jeho podniku je třeba sledovat z různých úhlů pohledu. Běžné je, že stejné výsledky posuzuje jednou přes složení zákazníků, jindy z pohledu skladby produktů, geografického rozdělení trhů, nebo podle časového průběhu. Dá se tedy řící, že uvažuje vícerozměrně. Tento jeho pohled na podnikání je mu přiorzený a vlastní. Závěrem tedy můžeme říci, že technologie OLAP je v rukou schopného uživatele mocným nástrojem, který výrazně zkvalitní a zefektivní řízení podniku.

Literatura

[1] VINCENT, L. Místo strávníků hosté. Euro, 26. 3. 2003, č. 12, s. 52.


18.10.2005 - Tomáš Vykoukal - četlo 23318 čtenářů.

[ Zpět ]


Tento článek ješte není ohodnocen.Hodnocení článku:
nejlepší [ 1 | 2 | 3 | 4 | 5 ] nejhorší
Verze pro tisk

Jméno
E-mail
Opište kód :    
Text
*)
   
Odkazy - pravý sloupec


  • Odběr novinek
  • Partneři webu:




  •  
  • Aktuální akce CVIS:


  •  
    Informační systémy
    v podnikové praxi
    (2. aktualizované a rozšířené vydání)
     

  • Nejčtenější články:
    1. SystemOnLine.cz:

    2. Přehledy informačních systémů 

      ERP systémy
       

      Plánování a řízení výroby
       

    3. ČSSI
    4. SSSI
    5. VUT v Brně
    6. Systemonline.cz
    7. Výzkum a vývoj v ČR
    8. ICT unie
    9. Cacio
    10. Živě
    11. Lupa
    12. AKA-MONITOR
    13. Jiko Blog
    14. Databázový svět
    15. destinationCRM.com
    16. MyCustomer.com
    17. ZDNet
    18. Nucleus Research
    19. ComputerWeekly.com
    20. IDC
    21. Gartner
    22. Deloitte
    23. Accenture
    24. Capgemini
    25. CIO
    26. Forrester Research
    27. Aberdeen Group
    28. Archiv: