Posledních pár let jsem měl možnost být u několika projektů na vybudování datového skladu nebo jeho kompletní přestavbu. Jednalo se zpravidla o společnosti ve finančním sektoru. Týkalo se to jak vcelku malých společností, pro které bylo tohle téma zcela nové, tak i velkých mezinárodních organizací, které řešily vybudování řešení datových skladů na úrovni celé skupiny podniků.
Jak už to u projektů bývá, očekávání – a s tím spojené ambice byly veliké a zpravidla přesahující oblast datových skladů (tou oblastí mám na mysli zejména podporu rozhodování na manažerských úrovních, nejrůznější reporting a analýzy dat). Společným znakem těchto očekávání bylo, že vybudováním datových skladů budou vyřešeny problémy v datové kvalitě, budou vyloučeny vzájemné nekonzistence mezi reporty a dalšími výstupy, zabrání se nejednoznačné interpretaci firemních dat a zpravidla se také vyřeší nejrůznější provozní nedostatky a „gapy“ ve funkcionalitách primárních informačních systémů a na ně navázaných vnitropodnikových procesů. Požadovaná data a výstupy pak budou samozřejmě k dispozici včas, ideálně online, potřebné změny nebude potřeba řešit s „IT“ ve zdlouhavém změnovém řízení, ale nejlépe formou „samoobsluhy“. A jako třešnička na dortu – vše bude barevné, v moderním designu a v mobilní aplikaci.
Nic proti samotným potřebám a očekáváním. Situace se komplikuje ve chvíli, kdy uvěříme, že výlučným řešením je datový sklad (DWH). Datový sklad je dost často chápán (typicky sponzory projektů) jako místo, kam se pořizují kopie veškerých firemních dat. Díky této fyzické koncentraci dat a za pomoci velmi výkonných informačních technologií (a možná ještě nějakých sofistikovaných modelů a metodik) pak dochází k zázračné integraci a transformaci těchto různě strukturovaných, různě detailních a různě kvalitních dat do přehledných, snadno srozumitelných a jednoznačných informací. Bohužel zázrak se nekoná, voda na víno ani data na informace se jen zásluhou DWH nepromění.
Navíc si dovolím k takovému chápání DWH jednu zásadní poznámku – datový sklad podle mne nemá být úložištěm veškerých možných dat, ale jen takových, které potřebujeme pro zodpovězení našich otázek a podporu našeho rozhodování. Je to podobné jako byste se vydali na dovolenou a pro jistotu si s sebou chtěli vzít všechny věci, které máte doma – co kdybyste je náhodou mohli potřebovat? Výsledkem bude, že se nevejdete do auta nebo překročíte limit zavazadel do letadla anebo také vůbec nikam nepojedete, protože všechno skončí velkou hádkou ještě na začátku.
Jak ale rozhodnu, která data budu potřebovat? Toto rozhodování se nejlépe provádí, pokud použijeme nějaký univerzální datový model, pomocí kterého si určíme a pojmenujeme nejdůležitější „entity“. V bankovním prostředí je nejčastější entitou tzv. „protistrana“ (tedy nejčastěji zákazník-bankovní klient). Model nám pak pomáhá dále určit, jaké údaje o „entitě“ potřebujeme sbírat. To zpravidla bývá snadné, protože jsou k dispozici ustálené modely pro jednotlivá odvětví. Na určený model potom takzvaně „mapujeme“ zdrojová data z primárních systémů. Výsledkem takového mapování je, že mimo jiné zjistíme, která zdrojová data potřebujeme a která ne. V naší analogii s cestou na dovolenou to dost často to znamená, že místo pěti lodních kufrů cestujeme s několika málo elegantními zavazadly.
Problém pro datový sklad a jeho model ale nastává ve dvou bodech. Prvním je kategorizace hodnot a jejich sémantika. Jinými slovy sjednocení číselníků. Datový model nám třeba říká, že bude potřeba sledovat typy bankovních účtů a pomáhá nám ve svých datových strukturách takové kategorické hodnoty ukládat. Jenže některým uživatelům stačí informace, zda je účet považován za aktivní nebo pasivní, zatímco jiní potřebují členit vybrané aktivní účty podle typů úvěrů, někomu pak stačí dělit úvěry na zajištěné a nezajištěné, to ale zase nevyhovuje kolegům z marketingu, kteří potřebují znát konkrétní typ produktu. Technicky je toto snadno řešitelné, existuje mnoho nástrojů v této oblasti, které se říká „reference data management“ (RDM). Potíže nastávají spíš ve věcné oblasti – napříč celou firmou je potřeba dosáhnout dohody na jednotné podobě číselníků, jejich unifikovaných hodnotách a jejich společné interpretaci. To je proces, který i ve středně velké organizaci může trvat přes dva roky a je to spíš téma pro management consulting než pro vlastní data management. Pro moji úvahu je ale podstatné, že díky uvedení RDM „na scénu“ se již dostáváme mimo hranice, které vytyčují pojmenované a bezpečně zmapované území datového skladu. Reference data management je považován za jednu z důležitých komponent Master Data Managementu (MDM).
Druhým bodem, který komplikuje naplnění datového modelu datového skladu je skutečnost, že dost často existuje více datových zdrojů pro stejnou entitu. Tyto datové zdroje mají většinou různou kvalitu, stáří (a s tím spojenou validitu) – a ne vždy jsou úplné a mohou obsahovat navzájem rozporuplné informace. Opět nejlepším příkladem jsou data o klientech – typicky jsou k dispozici údaje ze systému řízení vztahů se zákzníkem (CRM), ale zároveň každý další dílčí primární systém udržuje vlastní klientská data. Klientská data jsou tedy téměř vždy „roztroušena“ napříč celou firmou. V rámci jednotlivých systémů se pak navíc mohou ještě vyskytovat duplicity (jeden klient je veden vícekrát pod jiným klientským účtem) – a to buď díky nějaké chybě, nebo z nějakého zvláštního důvodu.
V ideálním případě existuje jeden zvolený informační systém, který funguje jako „master“ pro danou datovou entitu. Může to být například zmíněný CRM systém. V našem případě by tak v CRM měl každý klient přiřazený svůj vlastní jednoznačný konsolidovaný identifikátor a ten by pak byl propisován ke všem ostatním „instancím“ dat o tomto klientovi ve všech ostatních systémech. V master systému by také byly vybrány ty nejsprávnější (nejkvalitnější) dílčí údaje (například ověřená aktuální e-mailová adresa klienta, jeho poštovní adresa ověřená proti nějakému externímu registru adresních bodů). To, co zde velmi zjednodušeně popisujeme je ale základní podstatou MDM. Master data management se tak netýká pouze klientských dat, ale také třeba dat o kontraktech (ty se mohou v průběhu životního cyklu objevovat v různých systémech a vzniká podobný problém jako u klientských dat), různých událostech např. servisních úkonech, stížnostech atd.
Bohužel ze zkušenosti víme, že ve velkém množství organizací master data management zavedený není – anebo jen částečně a s mnoha omezeními. Právě v takových společnostech se setkáváme s požadavkem nebo spíše očekáváním, že funkci chybějícího MDM nějak automaticky převezme datový sklad. A dost často tomu tak opravdu je. Má to ale několik nevýhod – takto jsou „masterovaná“ až „sekundární“ data a zpravidla se nepropisují konsolidované identity zpět do primárních systémů. Většina běžných provozních procesů tak probíhá nad původními „nemasterovanými“ daty. Logika datové konsolidace je pak také většinou podřízena potřebám reportingu, které se nemusí shodovat s potřebami klíčových provozních procesů. Navíc se zařazením funkcí MDM pod DWH výrazně navyšuje rozsah projektu datového skladu včetně projektových rizik. V podstatě se nedostatek v oblasti masterování dat skrývá pod projekt datového skladu a zastírá se pravá podstata problému.
Dovolím si tvrdit, že většina společností, která cítí potřebu (nového) datového skladu, ve skutečnosti urgentně potřebuje zaměřit pozornost na oblast Master Data Managementu. Teprve potom může vybudovat datový sklad, což při současné míře zkušeností s budováním DWH a s využitím v dostupných robustních informačních technologií může být projekt relativně snadný, dobře plánovatelný a dodaný bez navyšování rozpočtu a v očekávaném čase. Prostředky, které jsou připraveny na nový datový sklad, je efektivnější vynaložit v první fázi na MDM. To, proč se tak neděje, je dle mého názoru způsobeno především tím, že možnost, že problém neexistujícího masteringu dat zapouzdříme do projektu DWH, je velmi lákavá. Projekt MDM je daleko více celofiremní záležitostí, který se může vyžadovat i velké změny výrazně přesahující oblast dat a informačních technologií.