Rozhodování „vcukuletu" aneb Jak se začít rozhodovat v reálném čase

Nové generace našich procesů už nevystačí s technologiemi a daty, jež bohatě dostačovaly předchozím generacím. Proto je potřeba v maximální možné míře používat moderní technologie, které pracují se správnými daty, jež jsou navíc dostupná včas, tedy ne zítra nebo za týden nebo vůbec nikdy.

Využijte nové technologie a vysoký výpočetní výkon

Rozhodování v reálném čase je postavené na technické formalizaci a automatizaci řešení konkrétního problému. Toto řešení se musí chovat deterministicky, být výkonné, spolehlivé, škálovatelné, prostě mít všechny silné stránky a žádné slabiny. Jen takové řešení lze využít v celé řadě úloh – od drobných zlepšení na úrovni dílčí interakce se zákazníkem v rámci digitálních kanálů přes různé typy kontrolních mechanismů zajišťujících bezpečnost až po komplexní řízení kritických obchodních procesů bez nutnosti doteku lidské ruky.

Ještě před pár lety to nebylo technicky možné, ale nové technologie a rostou­cí výpočetní výkon to dnes již umožňují. Někteří vizionáři mluví dokonce o plně digitálních členech v představenstvech a středním managementu společností plně nahrazujících sofistikovanou práci živých lidí. Fantazii a inovacím se meze nekladou. Na druhou stranu lidská mysl obecně přeceňuje potenciál technologií v krátkodobém horizontu, a naopak ho podceňuje v dlouhodobém horizontu.

Logická architektura platformy pro rozhodování v reálném čase
(klikněte na obrázek pro zvětšení)

Rychlost jen pro rychlost nestačí, nastavte KPIs

Pokud budeme uvažovat o vytvoření řešení pro rozhodování v reálném čase, co k tomu budeme potřebovat? Primárně nějakou praktickou úlohu, u které znamená rychlé rozhodování zásadní konkurenční výhodu, nebo ještě lépe přímo zisk. Rychlé rozhodování pro rychlé rozhodování není samo o sobě úplně nejlepší nápad, protože s ohledem na poměrně vysoké náklady řešení se nikdy nezaplatí. Na finanční aspekty v tomto typu úloh nesmíme nikdy zapomínat. Zvolené použití by vždy mělo mít stanovená jasně měřitelná finanční a nefinanční KPIs (Key Performance Indicators – klíčové ukazatele výkonnosti).

Začněte byznysem, pak přejděte k technologiím

Co bychom rozhodně neměli nikdy dělat, je začít stavět rozhodovací řešení od technologií a pak teprve dohledávat vhodnou úlohu. Bohužel s tímto postupem se poměrně často setkáváme v praxi. Technologie vhodné pro rozhodování v reálném čase jsou skvělé a úžasné. Jsou snem každého technického fanouška, který se aspoň trochu zabývá daty. Ale přístup snažící se na prvním místě o technologickou dokonalost vede ve většině případů paradoxně ke vzniku problematických řešení z pohledu byznysu, u kterých náklady převyšují jakékoliv tržby.

Po nadefinování řešené úlohy nebo úloh můžeme začít řešit samotnou architekturu. V architektuře bychom neměli podcenit žádnou z jejích složek. Rozhodování v reálném čase musí být založené na datech a příslušných rozhodovacích algoritmech. Data a práce s nimi se v případě rozhodování v reálném čase podobají řece: data někde vznikají (pramení), někudy musejí protékat, někde se hromadí, někde se používají (pijí, zalévají, roztáčejí turbíny), data někde zanikají. A hlavně: tento typ datového toku nelze – stejně jako řeku – zastavit a počkat na jindy, až budou lepší nebo jiné podmínky. Rozhodovací algoritmy fungují u těchto datových toků analogicky jako stavidla, která umožňují nejen optimalizovat tok, ale také přeměňovat sílu vodního toku v něco přínosného.

Čtyři vrstvy pro rozhodování v reálném čase

Z technologické perspektivy je rozhodování v reálném čase rozděleno do několika vrstev.

1. Získávání dat

První oblastí je získávání a příjem dat z datových zdrojů. Jako zdroje dat mohou sloužit relační databáze, datové strea­my, soubory, datové replikace, různé typy signálů z IoT zařízení atd. V případě použití nestrukturovaných dat je nutné v maximální možné míře využít edge computing, který zredukuje a připraví data pro využití v rámci rozhodovacího řešení. Technicky se v této rovině bavíme o technologiích pro Change Data Capture, ETL pro přenos dat, streaming, messaging, distribuované file systémy, API atd. Největším rizikem této vrstvy jsou legacy systémy, které lze mnohdy jen velmi obtížně integrovat a kontinuálně z nich získávat data.

2. Transformace dat

Druhá vrstva by měla zajistit transformaci dat. Podporovat různé frekvence jejich zpracování od real-time v podobě Data Pipeline přes microbatch až po klasické dávkové zpracování, aby proces byl efektivní, rychlý a spolehlivý. Datové transformace by měly obsluhovat a plnit všechna datová úložiště bez ohledu na to, zda jde o databáze, nebo datové streamy. Rozhodně by ale datové transformace neměly násilně přerušovat spojitost datového toku.

Příkladem nežádoucího přerušení je příchod zprávy z datového streamu, její transformování do databázových struktur a následné generování prakticky totožné nové zprávy na základě změny databázové struktury. Jak to tedy dělat lépe? Zprávy by měly být uložené v co nejsurovější podobě, obohacené statickými daty (lze tak učinit dynamicky) a následně přímo zpracované. V případě komplexnější logiky s více zprávami je možné využít starší a ověřené technologie pro complex event processing nebo odpovídající funkčnosti novějšího stream processingu.

Největším rizikem této oblasti je zahlcení transformační vrstvy velkými objemy dat, jež vznikají nárazově, např. při denní účetní závěrce. Z důvodu těchto špiček je nutné implementovat pro stejnou transformační logiku více optimalizovaných technických transformací a dynamicky je podle potřeby přepínat. Pro zajištění konzistence technických transformací je vhodné použít řešení typu Metadata Drive Development, s nímž lze – pomocí metadat logické transformace a soustavy optimalizovaných šablon technických transformací snadno a rychle dosáhnout požadovaného výsledku.

3. Datové úložiště

Předposlední vrstvou je datové úložiště. Historicky se datová úložiště označovala jako ODS (Operational Data Store). Současná generace ODS prošla velmi dlouhou evolucí včetně určitého posunu role v architektuře, takže se dnes často označují novějšími názvy jako data hub nebo digital integration hub. Datové úložiště by mělo mít charakter databáze, a to jak pro statická data v podobě relačních struktur primárně obsahující master data, případně dokumenty, tak pro dynamická data v podobě front zpráv. Optimální kombinací je hybridní úložiště RDBMS se strea­mingovou platformou. RDBMS spravuje sdílená master data, případně jiné statické datasety. Streamingová platforma obsluhuje samotný datový tok i jeho integraci.

4. Distribuční vrstva

Poslední je distribuční vrstva, která se primárně řeší pomocí API. API se dělí do dvou skupin: datová API a API pro rozhodování. Datová API umožňuje využívat jednotná integrovaná data i mimo kontext rozhodování. API pro rozhodování tvoří obálky pro modely vytvořené pomocí strojového učení (machine learningu) a umělé inteligence (artificial intelligence). Učení těchto modelů se opírá o datové úložiště a vývoj modelů zcela přesahuje rozsah tohoto článku.

Je možná trochu překvapivým zjištěním, že i v případě rozhodování v reál­ném čase platí univerzální Paretovo pravidlo, kdy 80 % úsilí musí být věnováno přípravě dat a pouze 20 % je o samotném rozhodování v reálném čase. Do distribuční vrstvy spadá také operativní reporting zaměřený na rozhodování.

I rozhodování v reálném čase vyžaduje integrace a governance

Samozřejmě nesmíme zapomenout, že každé řešení pro rozhodování v reálném čase je nutné integrovat pro procesní a technické roviny firmy. Data musejí do řešení vstupovat, řešení musejí poskytovat datové a rozhodovací služby a hlavně musejí dělat správná rozhodnutí. Zapomenout nesmíme ani definování odpovídající governance celého řešení.

Dva pilíře zajistí úspěch projektů

Rozhodování v reálném čase je v informačním managementu výzvou. Budování tohoto typu řešení má podle našich zkušeností dva základní pilíře: datovou platformu s podporou pro datové strea­my a distribuční vrstvu podporující rozhodování. Pouze při úspěšné implementaci obou lze dosáhnout požadovaných výsledků a opravdu se kvalifikovaně a automatizovaně rozhodovat v reálném čase. 

Autor je senior data architect ve společnosti Adastra.