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:

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:

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:

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

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

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ů:

Ř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:

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:

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:

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