DATOVÁ INTEGRACE A JEJÍ VZTAH K MDM


Voda základ života

70% lidského organizmu tvoří voda.  Měsíčně vypije dospělý člověk řádově tolik vody, kolik sám váží.
 Asi nebudeme daleko od pravdy, když odhadneme, že 70% bankovních obchodních procesů probíhá formou zpracování různých dat.  Zatímco některá data mají lokální použití a jsou potřebná jen pro daný jednotlivý proces, jiná data tvoří páteř, která podepírá celek a zajišťuje jej proti zhroucení.

Klient je tím, kdo přináší bance zisk ať již formou poplatků, úroků nebo formou peněz, které pak banka zhodnocuje jiným způsobem. Přestože klienti nejsou jediným zdrojem příjmu, pro retailové banky jsou zdrojem nejdůležitějším. Nepochybně tak klientská data patří mezi nejdůležitější.
 Nicméně klient není ochoten věnovat bance peníze jen tak z dobrého srdce. Za své peníze vyžaduje nějakou protislužbu. Protislužby banky se obvykle nazývají „produkty“ a data týkající se produktů tvoří další podstatnou část bankovní páteře.

Bez vody člověk záhy zemře žízní. A to i v případě, kdy je obklopen vodou. Nestačí být obklopen vodou, žízeň lze uhasit, až když se člověk napije. Ani data nebudou sloužit, nedostanou-li se tam, kde jich je potřeba. A stejně jako znečištěná voda může člověku přivodit nemoc, ba i smrt, také znečištěná data mohou být pro obchodní organizmus nebezpečná.

Voda není jediné, co člověk potřebuje k životu. Stejně tak data nejsou vším.  Tak jako v životě snadno podlehneme iluzi, že voda je cosi samozřejmého a věnujeme se jiným věcem, také v bankovních institucích jsou často data považována za cosi automatického někde uvnitř informačních systémů, bez vlastního, samostatného života. Jenže podcenění se nevyplácí. O vlivu nedostatečného příjmu tekutin na lidské zdraví nechť hovoří lékaři, na vliv nedostatečné péče o přísun dat se podíváme trochu blíže nyní.

Nelekejte se zkratek

V následujícím textu občas narazíme na zkratky. Pravděpodobně jste je již někdy zaslechli. Není důvod panikařit, že si nejste jisti, co daná zkratka znamená. Pocítíte-li potřebu osvěžit si paměť, můžete nahlédnout do následujícího stručného seznamu.

Kudy teče voda do obchodních mlýnů

Běžný člověk neřeší otázku, jak voda vznikla. Ze školy si asi pamatujeme cosi o koloběhu vody v přírodě a víme, že voda není „vyráběna“ pod pramenem, že pramen je jen jednou fází v životním cyklu vody.
 S daty je to přece jen trochu jinak. Data jsou jakýmsi odrazem v zrcadle. Vypovídají o věcech kolem nás. Klient jako subjekt existoval dříve, než přišel poprvé do banky a nezmizí ze světa v okamžiku, kdy data o něm někdo záměrně, či neúmyslně zničí.  Data vznikají v určitém čase a jednou nastane doba, kdy také zaniknou, protože již nebudou potřebná.

V běžné praxi ale rozdíl mezi koloběhem vody a koloběhem dat nehraje velkou roli. Není pro nás rozhodující, že voda není dostupná, protože ještě nedoputovala podzemím ke svému prameni, zatímco data nejsou dostupná, protože ještě nevznikla. Díky tomu můžeme směle rozvíjet analogii a představovat si životní cyklus dat jako distribuci a využití vody.

Prameny dat bývají různé. Nejčastěji vznikají data v průběhu obchodních procesů zásluhou pracovníků, kteří obchodní procesy realizují. Setkáváme se ale také s daty, která přitékají zvenčí různými vstupními kanály a s daty, která vznikají následným zpracováním.

Primární procesy, které pořídily data, mohou tato data také využívat, ale využití dat zde teprve začíná. Další putování dat v mnohém závisí na architektuře soustavy informačních systémů. Dříve, či později pak data doputují také do sekundárních systémů, tedy takových, které samy o sobě data nepořizují, ale zpracovávají je, nejčastěji pro potřeby reportingu ale také k uspokojení řady dalších potřeb.
 V sekundárních systémech typu ODS, DWH, Analytická CRM, DM a dalších se data kompletují, sbírají se informace z mnoha míst a vypočítávají se nejrůznější sumární charakteristiky. Jednou z užitečných charakteristik může být například bonita klienta nebo budoucí hodnota klienta. Informace tohoto typu se pak zpravidla nějakým způsobem promítají zpět do primárních systémů.

Tak jako po Labi můžete doplout až do Hamburku, také datová koryta bank leckdy vedou i vně organizace. V zásadě existuje několik typů komunikace s vnějším světem. Nejznámějším je pravděpodobně elektronické bankovnictví, ve kterém mohou některá data opustit prostředí banky a dostat se až ke klientovi (např. výpisy z účtů), nebo opačně může informační systém banky přijmout data od klienta (např. příkazy k úhradě). Důležité jsou vazby na externí registry ať již úvěrové registry nebo třeba katastrální registry, či nověji RUIAN (Registr Územní Identifikace Adres a Nemovitostí). Za datové toky vně organizace musíme považovat také předávání dat mezi organizacemi jedné skupiny popřípadě komunikaci mezi matkou a dceřinou společností. Všechny velké bankovní instituce v ČR mají dnes zahraniční vlastníky a pravděpodobně všechny si v nějaké podobě se svými mateřskými zahraničními centrálami předávají nějaká data.  Také některé regulatorní reporty můžeme považovat za data opouštějící prostředí organizace.

Architektura distribučních sítí

Naznačili jsme si, že data tečou mnoha směry a po mnoha vodovodních potrubích. Někdy se může zdát, že pro jejich zdárný průchod je nejdůležitější správná technologie. Ale to je jako kdybychom si mysleli, že pro zásobování domácnosti vodou je nejdůležitější, zda jsou domovní rozvody vody ve starých olověných trubkách, novějších pozinkovaných nebo v moderním plastu. Jistě, z pohledu životnosti a nákladů na údržbu má technologie vliv. Také má vliv světlost potrubí, tlak vody a a další parametry. Ale to podstatné, co dělá vodovod užitečným, není zdaleka jen materiál potrubí či technologie.

K čemu by nám bylo vodovodní potrubí, které nepřivede vodu do kuchyně či do koupelny? Sebekvalitnější vodovodní potrubí nám nebude k ničemu, najdeme-li jedinou vodovodní baterii v domě v ložnici pod postelí. Už jsme zapomněli, že bývaly doby, kdy přívod vody končící kohoutkem s výlevkou na chodbě byl velkým luxusem a voda se běžně nosila ve džberu ze studny.

Vodovodní pravěk v datových rozvodech kupodivu tak docela neskončil. Rozvody dat jsou totiž mnohem složitější a není až takovou výjimkou narazit na případy, kdy stále ještě končí na půl cesty.
 Zatímco voda je stále vodou a není podstatné, zda pochází z té, či oné přehrady nebo z podzemního zdroje, u dat je tomu jinak. Původ dat může být důležitý pro jejich obsah i další zpracování, a proto datová architektura nevystačí s prostým rozvodem z jednoho přívodního místa  do kuchyně, koupelny a na toaletu.

Způsob jak a kudy data potečou , má podstatný vliv jednak na kvalitu dat, rychlost s jakou jsou data dostupná, tak i na náklady spojené s provozem a rozvojem informační infrastruktury. Podívejme se na několik příkladů demonstrujících vybrané architektonické principy. Možná někoho překvapí, že ideální architektura neexistuje a každá architektura má své přednosti a své nedostatky.

Decentralizace

Bankovní instituce s dlouhou historií typicky trpí roztříštěnou a velmi početnou skupinou původně zcela nezávislých systémů. Integrace, tedy komunikace mezi systémy navzájem, vznikala postupně a to nejdříve na dávkovém principu výměny dat a později také jako on-line komunikace. Největší starosti budeme mít s daty sdílenými mnoha útvary. Můžeme si to demonstrovat na klientských datech. Klient o sobě může sdělovat bance své údaje v mnoha různých souvislostech. Například může žádat o úvěr a žádost bude zpracovávána nějakou schvalovací aplikací. Nebo může otevřít účet a s jeho údaji se setká bankovní core systém. Může také žádat o dodatkovou debetní kartu a data držitele karty bude jako první potřebovat karetní informační systém.  Tak bychom mohli pokračovat přes systémy investiční, bezpečnostní schránky, elektronické kanály dále a dále. Leckdy pak také narazíme na skutečnost, že pro zdánlivě jednu oblast, existují v bance různé informační systémy například podle segmentu klienta (jiný systém zpracovává žádosti retailové klientely a jiný žádosti korporátní klientely).

Sekundární centralizace

Budeme-li uvažovat o jednotlivých informačních systémech jako samostatných aplikacích, uvidíme data jednoho klienta na mnoha místech. První, kdo pak musí nezbytně takovou roztříštěnost řešit, jsou datové sklady a obecněji sekundární systémy. Je zřejmé, že při budování datového skladu nezbude, než realizovat nějakou konsolidaci klientských dat – rozeznat, které všechny záznamy vypovídají o totožném klientovi a které z mnohdy rozporuplných informací o tomto klientovi budeme považovat za pravdivé. Jakkoli konsolidace klientských dat tohoto typu existuje ve všech bankách v ČR a mohlo by se zdát, že se jedná o problematiku perfektně zvládnutou, není radno konsolidaci klientů podceňovat. Není to jednoduchá problematika a dokonalé řešení konsolidace neexistuje. Je nutné vždy znovu a znovu hledat přijatelný kompromis. 

 

Sekundární centralizace typicky pracuje formou dávkových úloh, zpravidla v noci, aby ráno byla k dispozici data konsolidovaná. Někdy se setkáváme s požadavky na vyšší rychlost a se snahou přejít na on-line zpracování v reálném čase. Takové požadavky ale naznačují, že jsme dosáhli místa, kdy se musíme zamyslet hlouběji nad potřebami a vhodnými způsoby jejich uspokojení.

Operativní centralizace

Konsolidovaný klient je velmi užitečný nejen v datovém skladu, ale také pro obchodní místa bank. Bankéř obsluhující klienta potřebuje ke své práci koncentrovanou a úplnou informaci o klientovi. Konsolidovaný klient se tak může promítat dále, do operativního CRM nebo ODS, podporujícího obchodní procesy. Budeme tady narážet na rychlost, s jakou bude konsolidace prováděna, setkáme se s potřebou on-line konsolidace proti které bude stát složitost takového řešení a náklady na jeho vybudování.

Největší nevýhody konsolidace klienta jsou způsobeny zastaráváním dat. V různých zdrojových systémech budeme mít různá data o stejném klientovi a budeme stát před úkolem, vybrat, co vlastně platí. Zdánlivě jednoduchá úloha typu „platí to nejnovější“ narazí na fakt, že leckdy není možné poznat, co je nejnovější. Ani v případě, že víme, kdy byla příslušná data aktualizována, nic to nevypovídá o jejich aktuálnosti, protože v různých systémech existuje celá řada procesů aktualizujících data a leckdy není snadné rozeznat, zda se jednalo o aktualizaci proto, že se banka dozvěděla novější (a tedy správnější) údaje, nebo z jakéhokoli jiného důvodu.

Další potíže přinese různorodá kvalita dat. Zejména u starších dat budeme narážet na případy, že kvalita dat není dostatečná pro rozhodnutí, zda se dva různé záznamy o klientovi týkají jednoho totožného klienta nebo ne. Přitom žádná technologie sama o sobě nemůže vytáhnout ze šuplíku příslušnou smlouvu a dohledat v ní informace, které by pomohly rozhodnout. Bude nezbytný vstup člověka a proces, který bude na míle daleko od požadavku na rychlou dostupnost výsledku.

Z výše uvedených důvodů je prakticky nemožné realizovat konsolidací dat k naprosté spokojenosti všech, kdo data využívají. Nicméně přínos konsolidace je nesporný a vysoké náklady na její řešení jsou opodstatněné.

Existuje ale také jiná alternativní architektura, která není postavena na konsolidaci ve svém centru. Tato architektura vychází z ideje oddělení správy klientských dat od ostatních procesů a vyčlenění této správy do samostatné CRM aplikace. V praxi to pak vypadá tak, že všechny útvary banky, které přicházejí do styku s klientem, jsou povinny data tohoto klienta nejdříve pořídit nebo aktualizovat do CRM aplikace a poté se tato data pomocí integračních mechanizmů rozešlou na všechna potřebná místa. Tím pochopitelně úloha nekončí, nadále je potřebný také opačný směr, tedy komunikace od satelitních aplikací do CRM, která umožní zobrazit na jednom místě všechny podstatné informace.

Výhodou je, že data klienta jsou pořízena jen jednou, využívána jsou opakovaně. Není nutné opakovat zakládání stejných dat jednou do bankovního core systému, podruhé do schvalovací aplikace, potřetí do aplikace investiční, počtvrté do aplikace správy elektronických kanálů… a tak dále. Protože je to konkrétní pracovník, který rozhoduje, kdo je unikátním klientem, má šanci operativně dohledat chybějící informace, leckdy má možnost přímo se zeptat klienta na aktuálnost informací, které o něm máme a může jednoduše opravit to, co není aktuální.

A nevýhody? V prvé řadě náročnost. Pokud není tato architektura budována cíleně od začátku, dostanete se do situace, kdy máte třeba padesát nebo sto aplikací, které by měly být odběrateli klientských dat.  Mezi takové odběratele mohou patřit také aplikace třetích stran, například když na pobočkách banky prodáváte také produkty třetích stran. Ještě složitější je směr opačný. Jak postupovat  v případě, kdy třetí strana prodává vaše bankovní produkty? Můžete zpřístupnit svou CRM aplikaci jiné organizaci? Jak postupovat v případě, chcete-li nové klienty získávat elektronickými kanály? Obecněji se dá říct, že se neobejdete bez datových toků, kterými získáváte data o klientech mimo standardní CRM aplikaci.

Nezapomínejme také na fakt, že přenesení odpovědnosti za rozhodnutí o konsolidovaném klientovi z technologie na člověka má vedle nesporných výhod také nevýhody. Závisí totiž na provozní disciplíně pracovníků, na přesném dodržování metodiky a schopnosti řešit výjimečné situace.
 Situaci nám bude také komplikovat existence starších dat. Může se snadno stát, že teprve po několika letech vyplave na povrch fakt, že dva klienti, o kterých jsme si až dosud mysleli, že se jedná o různé osoby, jsou ve skutečnosti jedinou osobou. Budeme proto potřebovat také procesy (technické i obchodní), jak dodatečně sloučit dva klienty do jednoho.

Pokud se zamyslíte nad výhodami a nevýhodami obou architektonických přístupů, pravděpodobně se nevyhnete pocitu, že ideální by byla kombinace obou. Taková kombinace samozřejmě spojuje  výhody obou přístupů, ale zachovává si také jejich nevýhody, byť  budou mít nevýhody při rozumném přístupu jen omezený dopad.

Nezapomínejme ale, že postupné uspokojování jednotlivých potřeb, rozvine architekturu do mnohem větší šíře, než jak by se zdálo ze základních principů, které jsme diskutovali výše.

Náhled za horizont

IT je obvykle vnímáno jako služba byznysu. Obchodní část banky je ta, která přináší peníze a vytváří zisky, IT je pak službou, bez které se obchodní procesy neobejdou, nicméně službou, která tvoří jen náklady, ale nic nepřináší.

Takové vnímání má svá úskalí. Obchodní procesy prodávají služby zákazníkům, tyto služby se nazývají „produkty“. Služby samotné ale de fakto realizuje v bance (až na výjimky) IT infrastruktura. Informační systém, ve kterém banka vede běžné účty, není službou dodávanou byznysu, která umožňuje byznysu prodávat své služby vedení běžných účtů ale je spíše službou zákazníkovi, kterou obchod (byznys) prodává.

Zkusme si to připodobnit k automobilce. Paralela je to vzdálená, nicméně právě pro svou vzdálenost nám může něco zajímavého napovědět. Obchodní procesy banky se budou podobat obchodním procesům v automobilce. Najdeme zde (aspoň vzdáleně) podobné aktivity jako získávání zákazníků, propagaci, marketingové kampaně, služby zákazníkům, zajišťování dodávek, hodnocení rizik a podobně. IT oddělení banky se ale nebude podobat IT oddělení automobilky. Svým charakterem bude mnohem blíže výrobní lince. Zatímco v automobilce se na výrobní lince vyrábějí automobily, které pak obchodní procesy prodávají, produkty banky se „vyrábějí“ v IT a obchod je pak prodává koncovým zákazníkům, klientům.
 Je taková paralela užitečná? Odpověď na takovou otázku můžeme najít v paralele samotné. V automobilce nepochybně bude obchod úkolovat výrobu ve smyslu „vyrobte tolik a tolik aut“ nebo „připravte do výroby takové a takové auto, protože po takovém je poptávka“. Stěží ale může někdo z obchodního oddělení diktovat výrobě, jak konkrétně má auta vyrábět. Musí to být výroba, kdo má za úkol najít nejefektivnější způsob, jak výrobky produkovat.

Možná to zní překvapivě, ale v bankách to bývá občas jinak a obchod diktuje IT nejen jaké produkty má realizovat, ale do jisté míry také, jakým způsobem to má dělat. Důvodem pro takové chování je fakt, že obchod je vnímán jako ten jediný, kdo přináší peníze a tudíž jako jediný může rozhodovat, jak s nimi naložit. A pokud IT přijde s názorem, že z pohledu banky jako celku by byla lepší varianta A, která bude dražší, ale přinese efekt na více místech, pak byznys, který daný projekt platí, bude trvat na variantě B, která je levnější, protože celkem správně nevidí důvod, proč by měl z peněz svého oddělení platit něco, co přinese prospěch oddělení jinému. Nechejme čtenáři na samostatné úvaze, co by se stalo, kdyby vlastníkem produktů bylo IT a obchod by dostával provize za jejich prodej.

Zdánlivě jsme se hodně vzdálili tématu datových toků. Jenže kdo ví, možná jsme naopak zahlédli v mlžném oparu jádro pudla. Dotkli jsme se totiž otázky, jak vlastně hodnotit efektivitu architektury. Několikrát jsme zmínili, že neexistuje dokonalá architektura a že každá z různých variant má své výhody, nevýhody a své náklady. Chceme-li se správně rozhodnout o kompromisu architektonických přístupů mezi přínosy, nevýhodami a náklady, můžeme to udělat jedině z pohledu celku a nikoli z pohledu nějakého konkrétního oddělení, které daný projekt platí.

A tak až otočíte ráno kohoutkem v koupelně, vzpomeňte si, že by možná váš bratr raději vynechal vodovodní baterii v koupelně a ušetřené peníze by využil jinak. Projektant, který navrhoval váš dům, se ale bratra neptal. Rozhodoval se na základě obecnějších principů a zkušeností.