Data jsou všude kolem nás, a pokud je umíme využít, mohou zásadně zlepšit například řízení firem. Čím větší firmy jsou, tím více toho měří – a tím pádem mají i více dat. Ty je potřeba někde skladovat, aby nad nimi mohly probíhat různé analýzy, z nich vznikat reporty a na základě těch se pak rozhodovali jednotliví manažeři. Jednou z důležitých součástí společností řízených daty může být i datový sklad, kde se všechna data sbíhají.

Jak takový datový sklad postavit a na co si při tom dát pozor? O tom ve svém komentáři pro CzechCrunch píše Tomáš Novotný, který má jako Data Architect na starosti právě datové sklady v tuzemské technologické společnosti Trask. Jedna věc je totiž data mít, ale ještě důležitější je pak s nimi správně nakládat a pracovat.

***

Budování datového skladu se vždy týká celé firmy. Na začátku proto musí vrcholový management učinit důležité rozhodnutí, zda je pro firmu strategické datovým skladem disponovat. Funkcí datového skladu je podpora strategického i operativního rozhodování na základě dashboardů, reportů, datových analýz a naplňování reportingových požadavků regulátorů. Kdy se tedy pro sklad rozhodnout a jak dál postupovat?

1. Definujte si klíčové metriky

Nejprve si musí každé oddělení ve firmě definovat klíčové metriky, které potřebuje k posuzování vlastní výkonnosti – ať už v oblasti financí a produktivity zaměstnanců, z hlediska provizí a efektivity výrobních i obchodních procesů nebo z pohledu naplňování regulatorních požadavků. Cílem je, aby si organizace udělala rámcovou představu o tom, na jaké byznysové otázky by měl datový sklad znát odpovědi, které reporty a datové soubory by se měly automatizovat a která data by se měla historizovat.

V každé firmě totiž existuje sada datových výstupů či reportů, jejichž tvorba je nezbytná pro chod celé organizace. Mnohdy se však tyto výstupy zpracovávají částečnou nebo zcela manuální cestou. Automatizace tvorby výstupů a požadavek na historizování zdrojových dat proto může být prvním motivem pro definici a formalizaci požadavků na datový sklad. Příkladem může být vytváření účetních výkazů do výroční zprávy označených značkami podle standardu XBRL.

2. Určete si klíčové obchodní požadavky a dejte jim jasnou strukturu

Formalizace požadavků bývá momentem, kdy by měl do přípravy vývoje datového skladu vstoupit externí dodavatel. Ten organizaci pomůže vytvořit strukturovanou dokumentaci uživatelských požadavků s mapováním na obchodní procesy a stávající zdroje dat. Výsledný dokument by měl být natolik strukturovaný, aby ho bylo možné napojit na další části strukturované dokumentace celého díla – tedy na ostatní metadata datového skladu.

Dobrý dodavatel by měl disponovat referenčními modely a best-practices pro danou oblast byznysu. Jedině tak si firma může být jistá tím, že se při návrhu datového skladu nezapomene na žádnou oblast jejího podnikání a že navrhovaný datový model bude funkční a bude jej možné spravovat a snadno rozšiřovat.

Formalizace požadavků na datový sklad je zároveň krokem, který může rozkrýt neefektivnost některých obchodních procesů či jejich částí a může se tak stát impulsem k jejich úpravě. Strukturovaná definice požadavků na datový sklad tak vytváří synergický efekt s vysokou přidanou hodnotou pro celou organizaci.

3. Zvolte správný přístup k vývoji a dalšímu rozvoji datového skladu

Datový sklad není podnikovou aplikací, jejíž vývoj se definitivně ukončí po vyřešení všech požadavků. Organizace by si už v tuto chvíli měla s pomocí dodavatele určit, jaký přístup zaujmout, aby bylo možné datový sklad rozvíjet v souladu s růstem jejích aktivit.

Foto: Depositphotos

Kvalitní analýza dat je základem v chytrém řízení firem

Vybraná procesní, datová a technická architektura datového skladu i zvolené návrhové vzory pak musí reflektovat požadavky na dostupnost a rychlost zpracování výstupů, schopnost rychle implementovat změnu, potřebu provázanosti byznysové a technické dokumentace a bezpečnosti. Špatně navržená architektura datového skladu po procesní, technické i datové stránce zvyšuje celkovou cenu celého projektu.

4. Nastavte infrastrukturu tak, aby reflektovala technickou architekturu

Technologie datového skladu reflektují požadavky na dostupnost výstupů, jednoduchost správy datového skladu a rychlost změny. V rámci vývoje je však také nutné dobře nastavit vývojové, testovací a produkční prostředí.

V této fázi se osvědčil koncept oddělených prostředí datového skladu, který napodobuje ověřené postupy při vývoji softwaru. Zabezpečuje kvalitu datového skladu a odstiňuje vývoj od produkčního prostředí. Oddělení jednotlivých prostředí je navíc vhodné jak z hlediska bezpečnosti, tak i kvůli zajištění stability produkčního prostředí.

Testovací prostředí je živé a do jisté míry replikuje zpracování produkce. Když na něm prochází nově vyvinutý inkrement simulací produkčního běhu, snižuje se tím riziko výskytu chyb v „ostrém“, produkčním zpracování.

5. V procesu vývoje etablujte základní uživatelské požadavky

V procesu vývoje se zpravidla uplatňuje přístup, který reflektuje strategii odbavování uživatelských požadavků s přihlédnutím k jejich prioritám. Konkrétně uživatelské požadavky reflektuje datový model, který ruku v ruce s mapováním datových transformací představuje hlavní zdroj pro vývojáře. A na základě těchto definic vytváří transformační procedury ve vývojovém prostředí.

Před odevzdáním hotového inkrementu je nezbytně nutné zajistit provázanost dokumentace uživatelských požadavků s konkrétními obchodními procesy, datovým modelem, mapováním datových transformací a s technickou implementací požadavku. Při vývoji datových skladů je klíčová také proveditelnost dopadové analýzy napříč celým řešením – od byznysových definic až po technickou realizaci. Jinak vyvstává riziko, že byznysový uživatel nebude výstupu důvěřovat, a svět byznysu a IT vývoje si tak nebudou rozumět.

6. Otestujte výstupy datového skladu

Jestliže byznys nemá důvěru ve výstupy datového skladu, vyjde celá investice vniveč. Důvěra zadavatele se často vytrácí v okamžiku, kdy prezentované hodnoty klíčových metrik v nově nasazeném řešení nesouhlasí s očekávanými hodnotami. Aby k této krizi důvěry nedocházelo, je nutné před nasazením do produkčního prostředí celé řešení kvalitně otestovat na vhodně nastaveném testovacím prostředí. To by mělo být v jistém smyslu obrazem produkčního prostředí.

Testovací scénáře by se ale neměly omezovat na výběr několika příkladů. Ideálně by se měly testovat hodnoty metrik na celém sledovaném portfoliu faktů, přičemž rozdíly se musí vždy zdůvodnit. Nesmíme zapomínat, že je nutné testovat nejen prezentovaná data, ale i zabezpečení přístupu k nim. Proto je vhodné otestovat korektní nastavení přístupových oprávnění na nasazované výstupy.

7. Uvažujte o dalším rozvoji a řízení změn

Datový sklad zastává ve světě IT trochu zvláštní místo. Na rozdíl od jiných aplikací musí mít dlouhou životnost, neboť návrhové vzory na konsolidaci a zejména historizaci dat nelze snadno změnit. Proto se architektonická rozhodnutí přijatá v úvodních fázích vývoje datového skladu uplatňují po celou dobu jeho životnosti.

Z datového skladu se žádná data nemažou, ledaže by šlo o striktní požadavek regulátora, třeba v souvislosti s nařízením GDPR. Základní premisy proto předurčují i to, jakým způsobem se realizuje rozvoj a řízení změn v rámci datového skladu. Platí zde zlaté pravidlo: každý dodatečný požadavek a jeho řešení musí být zdokumentované, nový inkrement datového skladu musí vždy následovat nastavený návrhový vzor a datový model skladu rozšiřujte nejlépe podle referenčního datového modelu s dodržením definovaných konvencí.