Tradiční přístup k aplikacím typu BI a datových skladů založený na vybudování robustní datové vrstvy konsolidující a napravující data z mnoha různých datových zdrojů a následné přikládání dalších vrstev sloužících pro různorodou práci s připravenými daty (reporting, ad-hoc analýza, predikce apod.) je samozřejmě teoreticky správný a schopný řešit vše myslitelné i nemyslitelné. Ale už prvotní vybudování takového řešení levné není. Natož pak jeho následné úpravy a rozšiřování, které nezřídka vyžadují zásah do velkého množství datových i aplikačních vrstev celého řešení. Což vedle dalších nákladů přináší i vyšší riziko chybovosti a ve většině případů je závislé na konkrétním dodavateli řešení. Nemluvě pak o rychlosti implementace takového projektu a pochopitelné nemožnosti okamžité reakce na aktuální potřeby koncových uživatelů vyvolané neustálými změnami v oblastech jejich činnosti. Přes všechny nevýhody a možná rizika však taková řešení existují a dobře fungují. Zčásti proto, že si to žádá složitost prostředí a požadavků, zčásti proto, že se jedná o řešení, na kterých jsou společnosti při rozhodování v klíčových procesech životně závislé a jsou schopné a ochotné je i patřičně zaplatit.

Nářky firem, především menších a středních, nad neutěšeným stavem jejich stávajícího reportingu, který je založen především na soustavě méně či více propracovaných excelových tabulek, a nad vysokou cenou komplexních BI řešení, nutí k uplatnění poněkud odlehčenějšího či zjednodušujícího přístupu. V takovém případě bychom měli uvažovat především o dále uvedených rysech celého řešení či projektu. Nejde jen o vlastnosti konkrétní použité technologie nebo nástroje. Dlužno však dodat, že současný trh BI platforem a technologií už naštěstí dokáže nabídnout vhodné nástroje, které takový přístup podporují.

Minimální počet datových vrstev

Klidně můžeme zapomenout na klasický datový sklad a vytvořit pouze logické reportovací rozhraní nad stávajícími daty. Bude-li to nutné (především v případě více různorodých datových zdrojů či složitějších transformací), pak jich budovat jen nejnutnější minimum. Vzhledem k rostoucí výkonnosti technické infrastruktury jsou naštěstí na ústupu argumenty pro budování vrstev za účelem optimalizace odezvy dotazů zahrnujících především agregace velkého množství dat.

Jednoduchá struktura datových vrstev

Datové vrstvy nesmí být příliš složité, měly by se skládat jen z malého množství objektů, vazby mezi objekty musí být jednoduché a snadno udržovatelné. Vrstva použitá jako podklad pro prezentaci dat by měla být totožná s vrstvou pro uložení dat. Zvolená struktura musí umožňovat snadnou budoucí úpravu a rozšiřování bez nutnosti radikálních změn v doposud vybudovaných částech. Veškeré technické detaily fyzického uložení dat by měly být v ideálním případě záležitostí vlastní technologie a implementátor by se jimi měl zabývat jen ve specifických případech.

Minimální počet prezentačních nástrojů

Uživatelé by měli v ideálním případě používat jen jediný prezentační nástroj využívající společnou datovou vrstvu, který bude plnit všechny požadavky v oblasti reportingu, ad-hoc analýz, případně i predikcí a simulací. Takový nástroj musí v dnešní době obsáhnout jak požadavky na klasický přístup k reportům a ukazatelům pomocí webového rozhraní, tak přístup ke stejným informacím a objektům pomocí mobilních zařízení. Že by mělo být takové prostředí pro koncové uživatele dostatečně jednoduché, srozumitelné a atraktivní, se rozumí samo sebou.

Samoobslužnost na straně prezentace dat

Koncoví uživatelé musí být schopni vytvářet své pohledy a analýzy nad připravenou reportovací vrstvou sami a seskupovat je do přehledných reportů či dashboardů bez nutnosti asistence správců či dodavatelů.

Samoobslužnost na straně datových zdrojů

Kromě přípravy vlastních reportů musí být uživatelé schopni stávající předpřipravená data kombinovat s daty vlastními (např. plány pro srovnání, historie dat, data sociálních sítí apod.) či si vytvářet na základě vlastních dat úplně nové datové oblasti. Řešení tak může být plně samoobslužné, koncový uživatel zvládá nejen tvorbu vlastních specifických reportů, ale i přípravu jejich dat.

Rychlá implementace

Implementace řešení nesmí trvat řádově měsíce a roky, ale jen dny a týdny. Uživateli musí přinést konkrétní přínosy velmi rychle a implementace musí být schopna okamžitě reagovat na jakékoliv změny a nové požadavky, nutné je budování po malých, ihned použitelných přírůstcích. Vlastní technologie pak musí být velmi rychle nasaditelná a zprovoznitelná.

Možnost prototypování

Ještě před rozhodnutím o implementaci musí být možné ověřit jak konkrétní technologii, tak hypotetické přínosy. Je proto vhodné, aby byl ověřovaný nástroj nějakým způsobem dostupný pro realizaci prototypového či pilotního řešení, bez nutnosti složité instalace a zprovozňování. Implementace prototypu pak musí být možná ve velmi krátkém čase, neboť demonstrace na vlastních datech a na vlastních požadavcích je vždy výrazně účinnější než jakékoliv obecné obchodní prezentace.

Nízká cena licencí

Jedná se o velmi relativní tezi, zjednodušeně musíme mluvit o cenách v řádu jednotek, nikoliv desítek tisíc (jednorázová cena vlastní licence v korunách na jednoho uživatele). Jednotková cena na uživatele bude samozřejmě klesat v případě licencí pro větší počet uživatelů, dostupná musí být i licence pro neomezený počet uživatelů. Předpokládáme, že bude řešení rozšířeno mezi větší množství pracovníků jako jediné používané, případně též mezi pracovníky partnerů či zákazníků.

Nezávislost na konkrétním dodavateli

Jednoduchá, standardní a doporučovaná implementace technologií bez použití proprietálních postupů a frameworků konkrétního implementačního partnera umožní snadnější budoucí rozvoj a údržbu řešení. Je vhodné předpokládat, že další vývoj řešení bude prováděn přímo vyškolenými pracovníky uživatele, nikoliv původním dodavatelem. V extrémním případě pak musí být schopen další vývoj a údržbu převzít jiný nezávislý dodavatel.

Neřešit vše

Desátá, poslední teze je možná nejdůležitější a vrací se k myšlence zmíněné výše. Tedy s minimem námahy lze vyřešit většinu potřebného. Nesnažit se nutně o speciální funkce a požadavky, které lze obejít alternativním způsobem či pro ně lze využít jiné běžně používané aplikace i za cenu určité ruční práce. Soustředit bychom se měli především na realizaci požadavků, které budou přinášet nejvyšší efekty.

Takto bychom mohli pokračovat dále, samozřejmě nic není černobílé a realita bývá někde uprostřed mezi oběma přístupy. Uvedené teze berme především jako body k zamyšlení, zda je námi zvolená cesta opravdu ta jediná správná. A to bez ohledu na stranu, na které momentálně stojíme. Jasné ale je, že čím víc psů za námi poběží, tím víc sil budeme potřebovat, abychom jim utekli. Máme na to těch sil opravdu dost? A máme vůbec ten věčný útěk zapotřebí?

Petr Šprungl
Autor působí jako senior business consultant společnosti Aquasoft.