facebook LinkedIN LinkedIN - follow
IT SYSTEMS 4/2009 , AI a Business Intelligence

BI řešení – jediná verze pravdy?

Petr Šprungl


„Jediná verze pravdy“ je teze, která je s oblibou používána ve výčtu přínosů snad každého BI řešení. Je snadno obhajitelná, vysvětlitelná a pochopitelná. Jistě, prezentovat stejnou skutečnost vícekrát je špatné. Prezentovat ji vícekrát a pokaždé jinak, je ještě horší. Dělejme to proto jen jednou. Ale neláká nás náhodou dát slovo „pravda“ do uvozovek? Vždyť jsme jako dodavatelé řešení opatrní, hledáme alibi a milujeme zadní vrátka (to kdyby ta naše pravda skutečnou pravdou náhodou nebyla). Nechme si raději na uvozovky zajít chuť a snažme se o to, aby naše pravda tou pravdou byla…


Těžko nabýt, lehce pozbýt

Vztah uživatele k BI řešení musí být založen na absolutní důvěře. Uživatel musí být přesvědčen, že informace, které získává, jsou správné, úplné a relevantní. Pokud tomu tak není, celé BI jaksi ztrácí smysl. O co je těžší takovou důvěru získat, o to je snadnější ji ztratit. Velké objemy dat, vysoká míra agregace, složitost výpočtů – to vše jsou faktory, které způsobí problém v tu nejméně vhodnou chvíli. Nikdo není schopen vše donekonečna ověřovat a na prezentované výstupy se prostě musí všichni spolehnout. Zpravidla platí, že největší šrámy na vzájemné důvěře způsobují buď chyby na první pohled jasně viditelné, nebo chyby skryté, jejichž důsledky se projeví až po delší době. Do očí bijící chyby bývají naštěstí méně závažné a lze je odhalit velmi rychle, nicméně na dodavatele nevrhají vůbec dobré světlo. Vždyť pokud sám nedokáže odhalit ani tak evidentní záležitosti, kdo zaručí, že jsou v pořádku i ty skryté? Nebezpečí skrytých vad potom netkví pouze ve vysoké ceně jejich odhalení, ale hlavně v důsledcích, které zapříčinily.

Lze BI testovat?

Problému je jednoznačně lepší předcházet. Proto chceme testovat a věřit, že všechny potenciální chyby takto odhalíme dříve než uživatel. Testování BI řešení však není tak jednoduché. S funkčním testováním potíže mít nebudeme, funkcionalitu jednotlivých komponent včetně jejich integrace ověřit lze. Funkční chyby sice žádoucí nejsou, avšak pro uživatele budou přijatelnější než jakékoliv chyby obsahové. Základ testování proto musí být vystaven na obsahu, tedy že všechny vrstvy obsahují taková data, která mají obsahovat. Prokazujeme přitom, že fungují načítací mechanismy, že jsou načtena na správných místech všechna data, že výsledné výstupy odpovídají tomu, co uživatel požadoval atp. Testování přitom nemůže být pouze jednorázové. Opakování je nutné nejen v okamžiku redefinice požadavků a úprav řešení, ale zcela pravidelně během vlastního provozu, kdy jsou neustále načítána nová a nová data a kdy na straně jejich zdroje hrozí jakákoliv změna stávajících podmínek, struktur či obsahu.

Mnoho vrstev, zajícova smrt

Abychom zvýšili efektivitu, v organizační struktuře počet úrovní snižujeme, zatímco v BI řešení máme tendenci nové úrovně přidávat. Je to ale vždy ku prospěchu? Nestanou se přidané úrovně jen dalším zdrojem nepředvídatelných potíží? Pokud budeme střídmí, počet úrovní bude úměrný rozsahu a skutečným potřebám a dokážeme všechny tyto úrovně uřídit, bude to dobré.

Oblíbený evergreen

Při úvahách o pravdivosti prezentovaných dat nelze opomenout ani často omílané problémy s jejich čistotou. Mnoho konečných problémů a nesouladů je způsobeno právě daty, která jsou chybná už na svém vstupu (neúplná, duplicitní či pravidlům neodpovídající data). Je ale nutné si rozmyslet, zda můžeme takový problém přesunout na zdroj dat, zda součástí našeho řešení nemělo být i řešení podobných nečistot. Měli bychom zvážit, zda taková data dohodnutým způsobem opravovat, nebo je prohlásit za chybná, zda požádat jejich strůjce o zjednání nápravy, či je rovnou zahodit do koše. Toužíme-li po pravdivosti a úplnosti, zabývat se tím musíme. Postupů a prostředků existuje mnoho.

Dokumentační peklo

To, že byl výpočet výsledného ukazatele proveden přesně podle zadání, lze relativně snadno ověřit. Ale odpovídá zadání skutečně tomu, co chtěl uživatel? Zadání, návrh, specifikace (či jak tomu budeme říkat), proti kterým má být výsledek akceptován, jsou pak s oblibou používány coby alibi. Co naplat, že se požadavky mezitím změnily… Pojďme raději cestou užší spolupráce s konečným spotřebitelem, postupujme důsledně po menších přírůstcích, které mohou pružně reagovat na měnící se potřeby. A přitom se nebojme bořit dosavadní dogmata. Na druhou stranu, pokud alespoň nějaký popis existuje, je to dobré. Je mnoho případů, kdy se řešení živelně rozšiřuje, doplňují se další vrstvy, tvoří nové výstupy, a přitom nikdo na dostatečnou dokumentaci nedbá. Ano, je to efektivní, rychlé, levné, ale pouze v případě, že bude zajištěna stálá přítomnost původního tvůrce. Jinak se budeme muset vydat cestou pokusů a omylů, které korektnosti a důvěryhodnosti nijak nepřidají.
Jistě, udržet pravdu pravdou je velká dřina. Ale nerezignujme. Prostředky k tomu důvěrně známe: rozumná dokumentace, testy, zapojení uživatele, přírůstkový přístup, … Jen nebuďme líní je v pravou chvíli využít. A když se nám něco nepovede, nebojme se vlastní chybu prostě přiznat, opravit, a hlavně se z ní pro příště poučit!

Autor působí jako team leader společnosti Aquasoft.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Transformace bankovnictví a pojišťovnictví v éře umělé inteligence

Umělá inteligence se stala hy­ba­te­lem digitální revoluce ve finančním sektoru. Přináší bezprecedentní možnosti automatizace, personalizace služeb a optimalizace rizik. Přestože potenciál AI je enormní, jen malá část bank má připravenou komplexní strategii pro její implementaci.