Firmy nasbíraly data. Teď zjišťují, že to byla ta snadnější část. Pokud se každé důležité rozhodnutí i nadále opírá o data, u nichž si nikdo v místnosti není stoprocentně jistý jejich původem a čistotou, stává se z drahých datových platforem pouze luxusní generátor chyb.
Paradox datové zralosti
V cloudu i lokálně vám běží datové sklady, orchestraci zajišťují propracované ETL pipeline, byznys jede v moderních BI nástrojích a nad tím vším se začíná experimentovat s prediktivními modely a generativní AI. No není to nádhera?
V praxi to ale často vypadá úplně jinak. Realita pondělního ranního reportingu je ale mnohem prozaičtější: manažeři tráví první polovinu porady hádkou o to, čí tabulka ukazuje správné číslo a proč se liší reporty ze dvou různých oddělení.
Podle analýzy společnosti Gartner stojí organizace špatná kvalita dat v průměru 12,9 milionu dolarů ročně. Tyto ztráty nevznikají jen přímými náklady na opravy pipeline, ale především chybnými rozhodnutími, založenými na zkreslených vstupech.
Zatímco v minulosti se špatná data projevila jako prázdná buňka v Excelu nebo očividně nesmyslný propad v grafu, v době AI je všechno jinak. Špatná data se dnes projevují jako sebevědomá, dokonalá, ale naprosto nesmyslná odpověď. AI halucinuje. A to tak sebejistě, že mu to na první dobrou spolknete i s navijákem.
AI halucinuje, protože ji krmíme digitálním odpadem. A odhalit takovou chybu dříve, než ovlivní byznys, je lidskými silami téměř nemožné.
Proč klasické hlídání kvality dat nestačí
V zásadě se trh dosud dělil na dva hlavní tábory.
Prvním přístupem jsou rule-based validace (reprezentované nástroji typu Great Expectations). Pokud máte v organizaci tisíce tabulek, musíte napsat a ručně udržovat tisíce pravidel. Jakmile se změní byznys logika nebo zdrojový systém, pravidla začnou generovat falešné poplachy, nebo naopak selžou. Výsledkem je unavený datový tým, který alarmy po čase začne ignorovat.
Druhým směrem je metadata observability (nástroje jako Monte Carlo, Sifflet nebo Metaplane). Tyto platformy monitorují metadata: hlídají, zda pipeline doběhla včas, zda sedí objem řádků a zda nedošlo ke změně schématu tabulky. To je užitečné pro IT provoz, ale má to obrovskou slepou skvrnu. Tyhle nástroje vidí, že potrubím protekl správný objem dat, ale už nepoznají, že v nich tečou nesmysly.
Oba tyto historické přístupy vám nahlásí, že „systém je v pořádku“. Ani jeden z nich vám však neodpoví na otázku, jestli je v pořádku samotný byznys.
Business observability jako nová kategorie
Hranice mezi „IT problémem“ a „byznysovým problémem“ v moderní organizaci mizí. Vzniká kategorie označovaná jako Business Observability.
Představenstvo nebo ředitelé divizí chtějí odpovědi na jiné otázky:
- Proč náhle klesly objemy karetních transakcí v konkrétním regionu?
- Mění se chování zákazníků u nového tarifu?
- Chová se vývoj tržeb v posledních třech dnech normálně vzhledem k historické sezónnosti.
To nejsou technické dotazy na databázi, a přesto na ně musí odpovědět (nebo neodpovědět) datová platforma.
Ukazuje se, že firmy již nechtějí platit miliony za nástroje, které jim pouze řeknou, že servery běží, ale ignorují fakt, že v datech vznikají logické anomálie.
Proto se prosazují modernější platformy, jako je například rakouská digna. Ve srovnávacích přehledech a architektonických studiích vyniká jako jedno z mála řešení, které dokáže překlenout propast mezi technickou vrstvou (monitoringem pipeline a schémat) a vrstvou byznysovou (monitoringem anomálií v samotném obsahu dat).
Pod kapotou moderní observability
Moderní platforma pro sledování kvality dat se nesmí spoléhat na statické dashboardy. Musí fungovat jako autonomní vrstva rozdělená do pěti klíčových modulů, které pokrývají celý životní cyklus dat:
- Data Anomalies: AI nečeká na to, až člověk ručně napíše pravidlo. Pokud se v tabulce transakcí náhle objeví atypické rozložení hodnot, systém okamžitě upozorní na anomálii.
- Timeliness: Nehlídá jen to, zda data chybí, ale také zda nedorazila příliš brzy (což často značí nedokončený proces na straně zdroje) nebo s neočekávaným zpožděním.
- Data Validation: Tam, kde to compliance a legislativa (např. v bankovnictví či pojišťovnictví) vyžadují, uplatňuje platforma tvrdá, pravidla na úrovni jednotlivých záznamů (např. formáty rodných čísel, IBANů nebo validitu číselníků).
- Schema Tracker: Detekuje jakékoli neohlášené změny v datové struktuře. Přidané či odebrané sloupce nebo neočekávané změny datových typů, které by mohly shodit BI reporty nebo AI modely.
- Data Analytics: Provádí pokročilé analýzy časových řad, zohledňuje sezónnost (např. víkendy vs. pracovní dny, svátky) a sleduje dlouhodobé trendy.
Pro organizace v regulovaných odvětvích v ČR a CEE regionu (bankovnictví, pojišťovnictví, telekomunikace či státní správa) jsou však klíčové dva parametry, které často rozhodují o úspěchu či selhání celého projektu:
- In-database execution: Výpočty a analýzy kvality dat běží přímo v databázi (např. ve vašem Snowflake, Databricks či lokálním PostgreSQL). Data se nikam nekopírují, neodtékají do cizího cloudu a nezatěžují síťovou infrastrukturu.
- On-premise / Private Cloud deployment: Možnost provozovat celou platformu plně ve vlastní infrastruktuře. Pro instituce podléhající regulaci ČNB, GDPR nebo přísným interním bezpečnostním pravidlům to není bonus, ale základ pro schválení bezpečností.
Programovatelnost: Data quality jako kód
Moderní platformy přestávají být jen „dashboardy s grafy“ a stávají se nedílnou součástí ekosystému.
V praxi to znamená posun k data quality as code. Například integrace Python SDK umožňuje datovým inženýrům zakládat projekty, konfigurovat datasety, spouštět inspekce a číst výsledky programově přímo z kódu.
Kontrola kvality dat se dá snadno zapojit přímo do CI/CD pipeline. Pokud datový inženýr mění transformační logiku v dbt, testy kvality dat proběhnou automaticky ještě před nasazením kódu do produkce.
Stejně tak může datový vědec (data scientist) volat inspekci kvality dat přímo ve svém Jupyter notebooku předtím, než začne trénovat nový prediktivní model nad datasetem.
Praktický filtr: Čtyři otázky pro vašeho CDO
Při výběru jakéhokoli nového nástroje nebo při auditu stávajícího stavu si položte tyto čtyři klíčové otázky:
- Odpoví nám nástroj pouze na technickou otázku, nebo i na byznysovou? Stačí nám vědět, že pipeline doběhla, nebo potřebujeme vědět, že v ní netečou nesmysly?
- Kolik lidské práce spotřebuje údržba systému za rok? Budeme muset najmout lidi na ruční psaní a neustálou aktualizaci tisíců pravidel, nebo systém dokáže anomálie detekovat sám pomocí strojového učení?
- Kam odtékají naše data, když je nástroj analyzuje? Vyžaduje řešení kopírování našich citlivých klientských dat do SaaS cloudu třetí strany, nebo umí běžet plně pod naší kontrolou (in-database / on-prem)?
- Umí se nástroj zapojit do našich stávajících procesů, nebo je to jen další samostatná obrazovka? Máme k dispozici robustní API a Python SDK pro integraci do CI/CD, nebo budou inženýři nuceni kontrolovat kvalitu ručně v dalším rozhraní?
Éra, kdy konkurenční výhodu definoval objem nasbíraných dat, skončila. Vítězi na trhu nebudou ty firmy, které zaplní své datové sklady petabajty informací, ani ty, které vygenerují nejvíce dashboardů.
Vyhrají ti, kteří dokážou zajistit, aby každé jedno číslo v reportu bylo nezpochybnitelné a každé rozhodnutí postavené na datech bylo podložené stoprocentní důvěrou v jejich spolehlivost.
Prvním krokem k této výhodě není nákup další technologie. Je to rozhodnutí, že se na příští poradě vedení přestanete přít o to, čí data jsou vlastně správná.
Chcete k tomu něco dodat? Napište krátce proč.