Stavební systém pro BI

Úvod

Také Vás občas napadá při rutinní rozšiřování BI řešení o nové datové zdroje, že tuto víceméně rutinní práci by šlo dělat jednodušeji a rychleji, nejlépe z velké části zautomatizovat?

Také jste si už po několikáté vyrobili “proprietární” generátory, které jsou super, protože umí přesně to, co potřebujete, ale nechce se Vám je dlouhodobě udržovat a tím ztrácí na hodnotě, nemluvě o potřebě uchovat know-how v dalších hlavách nástupců?

Také dost často pátráte po poznámkách, protože do modelu se občas některé věci píší neobratně?

Nebaví Vás udržovat dokumentaci transformačního modelu, protože je to “pakárna” a vy potřebujete jen rychle opravit chybu a spustit load dál? 

Pak Vás možná bude zajímat další text….

Stavební systém

Při delším přemýšlení mi IT obor (nejen programování, BI, reporting) připadá jako jeden z mála, kde si každý na další stavbu vyrábí nové a jiné cihly, překlady, základy. Osobně by mě zajímalo, kde se toto historicky zrodilo.

Protože už delší dobu nosím v hlavě návrh na níže popsané, hledal jsem “end to end” aplikační Framework, který by mě nezatěžoval technologií, ale umožňoval by mi rychle tvořit přidanou hodnotu a ne se patlat s objekty, mapováním, ORMem a tisíci a jednou knihovnou, technologií a závislostí…

Zatím “vyhrává” Oracle APEX, i když je to trošku k nevíře :o), ale pořád mi i přes jeho “mírnou těžkopádnost” vychází, jako jeden z těch lepších End to End řešení….Občas trošku se slzou v oku vzpomínám na ve své době proklínané Oracle Forms…(kompilace do runtime a časový overhead pro odladění byl strašný, ale když se podívám na dnešní nabídku, tak je …prázdno…a to svědomitě hledám a zkouším…a pro rýpaly bych uvedl, že v této technologii fungují systémy pro stovky concurentů (např. jeden velký primár ve velké české pojišťovně)

Nehledám slepence, ale hotový produkt, který je rychle a komfortně použitelný, obhospodařuje kvalitně celý životní cyklus a má rozumný licenční model. Budu rád za tipy od Vás…více hlav a monitorů více vidí. Prostě hledám takovou stavebnici ala stavební systémy. V prográmku si nakreslíte, co potřebujete, udělá Vám to kusovník a vytvoří objednávku, doplní potřebný režijní materiál a nemusíte řešit, jestli delší cihly, takové či makové překlady atd….). 

Jenže zde asi narážíme na ego spousty programátorů, že jen ten jejich framework je ten správný, ostatní to mají blbě…a každý si chce hrát se spodními vrstvami, ale už neřeší, že je třeba mít k tomu i rozumný prostup až do GUI a nedej bože podporu migrace, update, upgrade a srozumitelnou dokumentaci.

Situace v BI

Protože se dlouhá léta pohybuji na tomto trhu, a prošel jsem kolem většiny velkých datových skladů v ČR, situace ala aplikační framework je hodně podobná…

Technologická různorodost a “specializace nástrojů” z Vás dělá jejich otroka a žrouta času. A když už je něco zajímavého, tak to koupí někdo velký a zapouzdří a uzavře do jeho ekosystému a s produktem to jde do …háje, a to bez ohledu na onoho velkého hráče. Jeden příklad za všechny….(kdo mě zná, ví, že se nejvíce pohybuji v Oracle světě, ale nejen tam  ). Akvizice se samozřejmě musí vyplatit, pokud nejde čistě o eliminaci konkurence v zárodku, takže následuje zdražení, pardon, změna obchodního modelu či licenční politiky a nastává interní “cross sell” - další verze předěláme do našich “produktů”, aby byl vendor lock pevnější…a zákazník si mimochodem musel koupit i další naše produkty….(u Oracle typické, ale není tím výjimečný, je to standard)

Jeden příklad za všechny - hurá do historie…

Nikdo mi nemůže vyčítat neobjektivnost, s Oracle OWB jsme zde v ČR začínali, to byla ještě verze 2.0. Následovala 3.x a další verze. S verzí 3x jsme u telco operátora plnili zákaznický web tak, že po ukončení hovoru musela být informace o warm ratingu v zákaznické zóně na webu. …Za nějaký rok a pak se u nás ve firmě (Adastra) objevili pánové ze společnosti Sunopsis a nám spadla čelist…., bylo to jako potkat zhmotněný sen…každý z architektů už jsme za sebou měli pár domácích frameworků, ale typicky to bylo per projekt, proprietární, nebo na pár projektech konkrétního architekta. A teď nástroj, který měl obrovský potenciál…ani ne tak v tom, co právě uměl (metadata driven, možnost psaní vlastních generátorů, ELT koncept), ale co umožňoval. Byl technologicky nezávislý, takže ho s velkým přínosem nasazovala NCR nad Teradatu. Nástroj jako takový umožňoval i přidávat technologie, z čehož čerpá doposud…Přišel Oracle, položil na stůl asi dost velký peníz a pánové prodali. A tak vznikl Oracle Data Integrator a odstartoval interní souboj, který nástroj bude hrát v Oracle prim…OWB nebo ODI. Nějakou dobu to vypadalo na vítězství konceptu ODI, bohužel ale verze ODI 12 dle mého odhadu znamená, že interně vyhrál tým OWB, který “pašuje” do ODI filosofii OWB resp. obecně ETL…kostičky na joiny, AGG a podobně. Samozřejmě s argumentací po big data a potřebu paralelního zpracování. A také dle mého začala silná degradace produktu….verze 11 a GUI přehodili na JDeveloper či jaký a tím vznikl vítěz v kategorii jak znechutit práci…při sebevětším rozlišení monitoru Vám zbývá na efektivní práci maličké místo a pořád jen posunujete myší jednotlivé části GUI….Samozřejmě postupem času i další nástroje typu Informacica přišli s konceptem pushdown transformace, protože by se zákazník nedoplatil za trasformační servery a vedle tiše vrkal nezatížený DB server (či rack v případě Teradaty).

Dosud nástroj ODI používám na projektech, kde to jde, protože produktivita proti klasickému ETL několikanásobná, a člověk nemusí být ETL guru…(knowhow schováno v knowledge modulech). Když s ODI pracuji, často se u něj vztekám a pořád si říkám, že sednu a napíšu něco “svého”, zveřejním to jako open source a bude…že to jde dělat jednodušeji.

Projekt v BI

Na toto téma byly popsány stovky screenů, tak jen vypíchnu to relevantní:

• CASE nástroj - dobré pro datové modelování, na velkých projektech noční můra datového architekta….po dlouhé době různých kompromisů jsem zakotvil u Oracle Data SQL Modellru….hlavní důvody….podpora verzování do SVN, díky tomu podpora concurrent práce, umožňuje nastavit všechny vychytávky Oraclu (lokální partitioned indexy atd), a hlavně podporuje export dat do tzv. reporting schématu…(DB schéma, kde je model překlopen do relačních tabulek…bohužel jen relační model, fyzický ne…PROČ!!!! :(). V neposlední řadě, pokud máte koupenou Oracle DB, tak je plně zdarma….(mimochodem, také akvizice Oracle :o)). Podpora scriptů nad modelem, to už je ale spíš perlička…
• ETL/ELT nástroj - zde je možností přehršel, ale připadá mi, že to je jednostranná bitva…spousta ETL a proti tomu jen pád ELT či automated řešení (WhereScape atd)… ETL z principu nemám rád…protože projekty jsou živé, a takové přidání 2 atributů a jejich protažení 5ti ETLky a jejich krabičkami je krásně vypatlaný čas…nemluvě o uzavřenosti meta modelu u některých produktů a nemožnosti přistupovat k těmto metadatům…jiné nástroje si za přístup k metadatům nechají rády zaplatit další options…ale pro hodně různorodé datové zdroje to má svoji krásu….na pár kliknutí a krabiček se Excel/JSON/XML přestěhuje do DB tabulky….
• Řízeni loadu/procesů - tady vnímám u většiny produktů velkou slabinu, třeba jen taková jednoduchá podpora, že když mám v procesu 10 transformací v řadě a spadne mi to u deváté, tak aby se při opravě spustil od toho devátého kroku ve většině produktů představuje operaci oka přes druhou stranu těla…včetně ODI mimochodem…další slabinou jsou migrace mezi prostředími (typicky dev-test-produkce…změny konfigurací připojení, datových zdrojů atd…i když v tomto ODI ještě relativně exceluje svým konceptem)
• Reporting - toto je kapitola sama o sobě. Vyzkoušel jsme na projektech všechny možné reportingy (OBI, SAP BO, Jasper atd…)….a vždy to skončí v Excelu :)…tedy alespoň ze strany businessu je první otázka, zda to umí export do Excelu….v dnešní době se dobře prodávají různé selfBI nástroje, kde prodejci vesele tvrdí, že jen vezmete data a reportujete…nějak zapomněli, že musíte těm datům rozumět a vědět, co znamenají, aby jste neházeli do jednoho reportu hrušky a švestky…a jsme u jádra pudla….jak dodat businessu rozumně informace, jak data vznikají, na čem jsou závislá, a co vůbec znamenají….drtivá většina reportingových nástrojů podporuje vytvoření tzv. logické vrstvy, kde názvy tabulek a sloupců pojmenujete “businessově” a doplníte hodnotné komentáře typu tabulka obchodních vztahů, sloupeček identifikace zákazníka….a protože by se v těch tisíci atributech ztratila i Godzilla, tak se to celé rozseká na menší oblasti, které se pak musí vesele dál udržovat….a opět skřípete zuby…..místo efektivní práce děláte Ctrl C a V, protože holt páni vývojáři nepodporují strojový import ani export dat (vendor lock - model - ETL - reporting).
• Samozřejmě, můžete si koupit nástroje, které jsou teď v kurzu (line age nástroje, enterprise metadata repository a různé další vyšší formy vědění), které Vám za nemalé peníze a ohromnou spoustu času umožní přes různé můstky dostat k sobě metadata a informace, které vy máte běžně v hlavě…který report čerpá z kterých tabulek, a jak jsou ty plněny….(zdroje, transformace). JE to teď strašně in, ale mají jednu velkou vadu…nekdo musí vyexportovat data z nástrojů, další je musí naimportovat do “enterprise repository” nástrojů…a to vše přes různé verze jednotlivých použitých nástrojů…nu což, za 3 měsíce máte “hotovo” pro aktuální verzi řešení, a druhý den Vám přijde mail o novém release a můžete začít nanovo. Fakt smysluplná práce.

Můj přístup

Protože je člověk z povahy tvor líný dělat věci, které jej nebaví, tak jsem si udělal takovou linku. Je to celkem pěkné, ale není to úplně ono…

1. Export modelu do reporting schématu
2. Rozložil jsem si ODI repository na prvočinitele a vytvořil si view, kterými si dokážu na metadata sáhnout tak, jak potřebuji (verze 11)  - modely, tabulky, sloupce, interfaces, mapování, packages)
3. Nainstaloval jsem xwiki a zprovoznil rest API
4. Napsal si v PL/SQL procedury, které mi do xwiki generují informace o modelu, procesech, transformacích a to vše vzájemně provázané pomocí linků…historii mi drží xwiki sama (hash a nová verze, zobrazení změn ve verzích atd)
5. V Xwiki je publikována aktuální verze dokumentace - datový model s popisy, transformační model, procesy, které se starají o load (proces, parametry, pořadí transformační, smyčky atd) 

Samozřejmě to není žádná formule, ale pro business je to super, hlavně díky tomu, že SQL Data Modeler umožňuje komentáře do DB, ale i další, kam se dá psát businessovou řečí….
Relativně to funguje, ale je to jen berlička….

Má to ale i slabiny…

• Jako reporting knowhow dobrý, ale podpora pro aktivní vývoj nulová….
• Když píši poznámky, kde se kombinují informace o více tabulkách, tak musím jen v xwiki, JIRA atd…pro popis modelu z nadhledu chybí podpora (schéma a linky umím, ale…je to humpolácké)
• Ruční maslostroj - vyexportovat model do reporting schématu, spustit procky, udržovat nadstavbové parametry packages v ODI atd…
• Namodeluji v modelu, ale implementace co DB (nové tabulky super, změny raději ručně), potom musím reverse do ODI modelu a až poté mohu použít v interfaces….ručně aktualizace reportingu (detekce změn, popsat, publikovat v potřebných “business areas”, a přidat do reportů….moc rutinní práce, náchylnost k chybám, nízká produktivita… 

Vize

A po spoustě slov se dostávám k jádru pudla….Nešlo by to udělat úplně jinak?

Mít:

• Jednu jednoduchou repository (ideál souborovou xml/git s aplikační nadstavbou) – i když DB má také svoje krásy, toto ještě není úplně domyšleno, jde to oběma způsob, ale…
• Rest API (s podporou verzování - zde výhoda gitu, ale musel by se naučit, jak zacházet se sémantikou, v některých případech základní delta nestačí)
• Importem/exportem -  přes různé agenty - možnost tvorby různých nadstaveb - model, ETL/ELT, runtime, migrátor do DB a agentů atd
• Kompilace do “předpřipravených dotazů” s podporou runtime parametrů a proměnných?
• Runtime agent …vezme předkompilovaný kód, zajistí connections, file operace, naplnění proměnných a exekuci transformace…včetně logování :)
• Podpora tvorby datových setů (v různém jazyce ala multi language v Oracle OBI. Měli jsme zavedenou businessštinu a techničtinu :) ) - taková open data, ale s možností parametrizace datových setů podle reálných hodnot…a následně export do různých datových formátů resp. prostě xlsx…a když by to umělo ještě vložit ty data do šablony a doplnit do sheetu i podmínky z filtru, tak můžete reportingové platformy zahodit
• A to vše jako open source, či co nejvíce otevřené. Zde se musím poklonit myšlence ODI….knowledge moduly a přístup k metadatům pomocí odiref je prostě super věc….dá se přízpůsobit víceméně každému přístupu při budování skladu….
• Platit by šlo za různé agenty (nahrávání Excelů, datových setů s podporou metadat, event reporting, on data reporting, data quality, report publishing atd.)
• Předpřípravené modely pro kus oblastí (např. parties, adresses, contacts…contract/service atd) - to by byla efektivita, díky společné metodice názvosloví snadno adaptovatelné. A také už mě nebaví po desáté modelovat parties, deal atd…). Nemluvě o repository těchto modelů dovnitř firmy díky verzování této repository…
• Připravené šablony do xwiki či podobného nástroje (s podporu fulltext vyhledávání a výběru požadované výstupní informace…)
• Trasovatelné přes JIRu či jiný ticketing…(linky na tasky v xwiki atd) 
• Když to zaměřím na aplikační vývoj, tak de facto vzniká end to end framework, protože i GUI se dá přes metadata generovat…když mrknete na Ataccama RDM, tak to má GUI generované přes pár metadat a spoustu xlst transformací a vypadá to skvěle, použitelné je to skvěle a generuje to kód pro GWT toolkit…takže třeba se k tomu vytvořeno v sobě samém dostaneme…

Podle mého to zase není tak složité…samozřejmě až na detaily typu já vytvořím model tabulky a kolega už jej potřebuje změnit, resp. použít…takže nějaké DB či centrální části (typicky oblast modelu) se asi nevyhneme…

Realita:

• Jsem trvale vytížen projekty, času na podobné věci málo, i když bych rád…vždycky si vzpomenu na obrázek, jak jeden chytrý nabízí kolo, ale pánové táhnou káru s hranatými s omluvou na nedostatek času…to je přesně ono, ja jsem v jednu chvíli kolař, a hned další ten s tou károu…:). Pokaždé když se vztekám při práci si říkám, že už bych do toho měl fakt šlápnout…
• Musím se poklonit pánům, co tvořili model repository v ODI. Čistá práce pánové, i když univerzální občas až moc, ale když se do něj ponoříte, tak oceníte, že někdo v pár tabulkách dokázal uložit vše potřebné…
• Jsem ochoten sdílet vše výše uvedené, jediná podmínka je pak otevřenost řešení, nebo “neomezená licence” na všechny mé současné i budoucí projekty :o)
• Stále hledám framework, který by mi umožňil efektivní vývoj výše uvedenéhoj….de facto bych mohl vývoj dělat přímo v tomto nástroji (sám sobě frameworkem), ale zde je potřeba i GUI…a to já holt neumím, jsem datař tělem i duší….i když to GUI je poměrně jednoduché, ale pár desítek obrazovek to je…+ samozřejmě dost logiky v API….
• Nejraději bych to viděl na xml soubory (datový model, transformační model, migrace/upgrade, GUI konfigurace), ale dalo by se i v Oracle DB…i proto mě to trošku táhne do Apexu…verze 5.2 už konečně umí klasický datagrid…ale zase už je to hodně uzavřené v Apexu….
• Hledám partnery do této oblasti, preferuji otevřenost….možnost obchodního modelu viz free + platby za “knowledge moduly”, agenty, kusy připraveného datového modelu (včetně jazykové parametrizace pro skalní příznivce modelu v národním jazyce) atd…
• Na straně xwiki by bylo potřeba někoho šikovného (šablony - přizpůsobení korporátním barvičkám atd, aktivní makra pro přístup do logů a metadat v repository, persistence, generování resume pages, ochrana stránek před úpravou
• Reporting nad metadaty či integrace na jiné metadata nástroje (migrace na repository, export do stávající repository atd…) - jen jiné použití tvorby datových setů

Závěr:

Naznačil jsem jeden ze směrů, který je dle mého vynucován aktuálními trendy…nedostatek kvalifikovaných lidí (knowhow v knowledge modelu), ošetření publikace knowhow směrem k businessu (selfservice), a hlavně zvýšení produktivity rámcově o 100%….(namodeluji, vzápětí použiti v transofrmaci, a implementační knowledge modul mi umožní vygenerovat change script na míru)…Jejda, to by se pracovalo….

Cílem tohoto článku je rozpoutat diskuzi na téma otevřené metadata repository, nad kterou by byli vytvořeny další aplikace, které metadata využíjí i rozšíří. V neposlední řadě pak i hledám propojení na další lidičky, které jsou myšlenkově na stejné vlně a znají lidi, co by chtěli vyhrnout rukávy. Třeba více rukou a hlav = rychlejší pokrok…protože z toho hranatého kola už mě bolí hřbet…:)

PS: Napsáno česky, kdo by chtěl, může přeložit do jiných jazyků a volně publikovat, jen prosím o uvedení originálního zdroje.

 Autor Petr Šimbera, psimbera@gmail.com

Smart Home/ IoT - aktuálně ani ne v plenkách

Úvod

Za chvíli se stanu majitelem menšího staršího rodinného domku, kde mě čeká rekonstrukce. Neb jsem IT pozitivní, a chtěl bych kombinaci starého rozumu z pohledu topení (neregulovatelné, ale velmi příjemné www.biofire.cz) a moderního přístupu (říditelné dodatkové topení a pár dalších blbinek) vrhnul jsem se na Internet v domnění, že si jen poobjednávam komponenty (snímače, spínače, kartu do počítače, a framework resp nějaké all-in-one s Linuxem a bude za chvíli hotovo…a jako obvykle jsme dost těžce narazil.

Chytrý dům/Smart Home/HomeKit, IoT ?

Protože jsem rozmlsaný komfortem produktů Apple (ale databáze mám na Linuxu :o) ), mrknul jsem i na Homekit….Možná někdy bude velmi zajímavý, ale odhaduji tak 3 roky. Z mého pohledu je to spíš idea, a hlavně potřebný HW v nedohlednu…a to nemluvím o avizovaných cenách, proti tomu je i Apple troškař...

Tudíž jsme spadl na zem a začal jsem hledat nějakou jinou univerzální platformu…Člověk by čekal, že v roce 2015, kdy už má být IoT na silně vzestupné křivce a marketingová bublina už skoro hrozí prasknout, bude spousta udělátek se standardním rozhranním (typicky silové prvky, snímače atd, vše ideálně přes wi-fi nebo rádio (868MHz) a za rozumný peníz. Skutečnost je ale daleko za očekáváním….

Prozkoumávám web a nacházím různá řešení, ale drtivá většína nesplňuje moji představu - mám iPhone/iPad tak proč bych proboha klikal v nějakém LCD based rozhranní z roku (a hlavně přoč za něj i platit, řešit update firmware atd), každá platforma má svoje termostaty, svoji centrální jednotku, takže rozvodná skříň slaboproudu by mohla směle konkurovat Temelínu :o). Možná jsem hledal špatně, ale zatím jsem nenašel nic, co by splňovalo základní požadavky z pohledu rozsahu s nadnosti zavedení. I proto vzniká tento článek, snad se ozve někdo, kdo vytáhne králíka z klobouku...tipy vítány.

Co je pro mě chytrý dům ?

Opět spousta marketingu…na rovinu…televizi mám jednu a pouštím ji 2x do týdne na déčko dceři…žádné hyper sound systémy, atd, stejně tak limatizace, rekuperace a pod…

Co podle mě potřebuje “chytrý dům” ? (některé části mohou být “optional”, ale v závěru podávám vysvětlení proč takto…):

1. Základní zabezpečení bezpečnosti - prostorová čidla, magnetická čidla na okna, alespoň jedna IP kamerka, napojení na PCO resp. na mobil uživatelů domu, automatický alert potvrzeného alarmu na Policii ČR
2. Ovládání vjezdových vrat - ideálně telefonem,resp. přes mobilní data (otevři/ zavři) - ukončí hádky kdo otevíral bránu ručně minule a kdo je na řadě teď
3. Měření spotřeby elektřiny - ideálně formou možnosti rozdělení světla, zásuvky (per okruh), topení, TUV - není nad to vědět, kde utíkají penízky (i kvůli potřebě solidní regulace chci jít do elektrického topení, protože primární topení jsou neregulovatelná akumulační kamna, které vytápí hlavní prostory) - do budoucna integrace s dodavatelem energie (samoodečet + výkonový profil - custumizace cen dodávek, ale to je za horizontem...), zde je možnost sbírat informace z jednotlivých zařízení přes API, tedy až to budou umět  a podporovat...nyní spíše na úrovni wattmetru na zájmových okruzích (vím, kolik jsem spotřeboval, znám parametry zařízení, vím z eventů, kdy byl který v provozu) 
4. Regulace topení - nakonec přímotopy (s ohledem na primární způsob vytápění a potřebu důsledné regulace, včetně pohledu na investiční náklady) - co místnost, zjednodušeně - co místnost, to přímotop + teplotní senzor + podlahové vytápění jen koupelna separé - vše chci ovládat z mobilního telefonu i s možností na dálku, včetně komfortního nastavení regulace  - toto z jednoduchého důvodu - topení představuje pro klasické domy zásadní nákladovou položku, která je navíc nejlépe ovlivnitelná bez omezení komfortu…(podotýkám, že nemám pasivní dům, ale dům z roku 1940, který připravuji k zateplení)
5. Protože jsme “digitální rodinka”, tak potřeba i solidního wi-fi router jako hlavního připojovacího uzlu - připojení na net, ideálně v kombinaci se zálohováním počítačů
6. A protože pracuji i na dálku (pevná IP), tak i solidní zabezpečení, forwarding VPN  atd - ideálně bezpečné, a bez potřeby mých updatů, když za mě někdo vyřeší i adaptivní firewall a útoky na zranitelnosti - halejujá...
7. Oddělený okruh elektřiny pro připojení kritické infrastruktury (do pracovny pro počítače a právě pro systém chytrý dům) - zalohování APS, případně malý agregát...ale to už si vymýšlím, bude stačit, když se bude umět po nové startu sám dát dohromady...

Co nepotřebuji:

• Ovládání klimatizace
• Ovládání osvětlení - připadá mi to s ohledem na cenu řešení v RD jako absolutně vyhozené peníze (protože mám doma notorické nezhasínače, tak stejně budou LED nebo úsporky), návratnost v desítkách let 
• Media centrum atd
• LAN rozvody po domě (jen kablík mezi patry, pro pobočný wi-fi), neb jsme všichni wi-fi based a 150MBit duplex postačuje :o), holt, když už budu potřebovat, tak se připojím přímo do routeru (1Gb LAN předpoklad)
• Audio rozvody 
• Vědět ze lednička právě chladí, sporák právě vaří..-změním názor, pokud budu moci vybrat z menu a automatická kuchyně sama vyrobí večeři…ale to až tak za 5-8 let…:o), hlavně mi stačí znát spotřebu (po oblastech), když máte lednici A++, tak stejně už spotřebu nemáte moc jak ovlivnit...

A hlavně nechci řešit integraci a komunikaci několika platforem mezi sebou (viz synergické efekty dole), s ohledem na roztříštěnost trhu a očekávaný rozvoj by to bylo “smart Hell at home”

Co jsem doposud zjistil ? 

Hledal jsem usilovně 2 dny po všech různých webech, skrze anglický a český web (čínštinu bohužel neovládám), narazil jsme na spoustu pojmů, ale hlavně dojmů...neuvádím jednotlivé výrobce, můžete sami pohledat...

Další poznatky:

• Za regulaci el. topení dáte  předběžně 2x více, než za samotné konvektory…(při decentralizované regulaci) - běžně stojí senzory 1800, aktory 1600, programovatelné termostaty - široké cenové rozpětí od 1500 až po desítky tisíc…
• Ceny regulovatelných LED žárovek neřeším….
• Když bych si aktuálně udelal seznam, tak bych potřeboval nejméně 3 jednotky (bezpečnost, topení, wi-fi), spousta káblíků, konfigurace atd…
• Z pohledu IoT - kde bych čekal rozumný peníz, tak jsou šílené částky ( snímač teploty s komunikací stovky Kč, nebylo vyjímkou i 1800…). když se podívám na součástky i na jednoduché kontrolery (Atmel, Rapsberry PI, Andruino), tak bych čekal teplotní senzor s komunikací v řádu do 250Kč, výkonové spínače do 500Kč, a k tomu centrální prvek (standalone, karta do počítače, která s tím umí komunikovat v řádu jednotek tisíc, ale s kompletně webovým UI dostupným přes LAN)
• Raději nezkoušejte udělat propočet návratnosti, protože o tom to opravdu není, snad kromě regulace topení, a i tam to za současných cen je na několik let...

Narazil jsem i na pár společností, které tvrdí, že nabízejí all-in-one, ale na základě informací z jejich webů (TechSpec, video návody atd) je silně převažující funkčnost, kteoru nepotřebuji a naopak výrazně chybí základní funkce zabezpečení domu a regulace otopných soustav integrované do all-in-one. Podle dostupných cen (opět zdroj web) jsou to hlavně ceny úplně mimo rámec reálné návratnosti….typicky vyšší desítky tisíc, kdy morální životnost odhaduji tak maximálně na 5 let…(s ohledem na očekávaný boom v této oblasti)

Závěr:

Ať si každý udělá svůj závěr, ale minimálně po dvou dnech pátrání mi připadá IoT v oblasti chytrých domů totálně v plenkách, a jdoucí směrem uzavřených řešení, které ve výsledku vedou k rozvodné skříni ala Temelín…

1. V rámci tohoto malého výzkumu jsme narazil na jeden velmi zajímavý počin….projekt Turris Lite (https://lite.turris.cz/en/) a spolupráci CZ.Nicu a Jablotronu (https://www.nic.cz/page/2875/jablotron-a-cz.nic-spojili-sve-sily-a-pripravuji-system-pro-chytre-a-bezpecne-ovladani-domacnosti/ ,i když záznam tiskovky na webu je hodně rozpačitý….potřeba sdělit, ale neví se co přesně…). Podle mého takto může vypadat opravdové domácí IoT Heart - centrální prvek - výkonný router s rozšiřitelnou funkčností (linux OpenWrt), kompletní “servis” - zabezpečení, automatický update, ovládání GPIO, rozšiřitelnost, sdílená storage, v budoucnu i "appstore SW a HW, zkrátka má potenciál ekosystému.
2. CZ.NIC asi nebude mít zájem pokrýt celou oblast, ale pro komerčního leadera, který tuto oblast kreativně a dlouhodobě zastřeší se otevírá možnost vytvoření velmi zajímavého i výnosného ekosystému, které bude tvořit/vymýšet dílčí prvky (levné senzory, aktivní prvky, aplikace), které spolu budou umět mluvit (GPIO, I2C atd) a budou základem pro opravdové řešení ala chytrý dům….v ČR jsou tisíce lidí zabývajíc se elektronikou, jednočipy atd….od studentů elektrotechnických fakult po fandy z praxe…Co takhle soutěže - vytvořte návrh/prototyp dle požadovaného zadání, a my Vám zaplatíme (podíl na prodejích), hromadnou výrobu pak může zaštítit nekdo typu Jablotron (či jiný výrobce s výrobní  základnou), designu se meze nekladou, protože typickou jsou tyto zařízení maličká (ať žije 3D tisk).
3. Nad tímto HW postavit aplikační framework (inspirace andruino IDE), a pak přijdou ke slovu SW aplikace…a zde jsou už principy appstores známé a odzkoušené. A stejný scénář ala apple - HW a SW na jednom místě a velmi dobře integrovaný...

SW pro řízení chytrého domu:

Představa:

• Několik komfortní GUI (ideálně nativní aplikace, nebo HTML5), přizpůsobené platformě (IOS, Android)…přeci jen klasický “technický” web stávajících řešení to koncovému zákazníkovi neprodá (alespon podle ukázek z webů různých výrobců), GUI může být z různých zdrojů (GUIčkáři jsou hračičkáři, konkurence povede k rychlejšímu rozvoji) 
• Důraz na jednoduchou konfiguraci prvků systému a jednoduchost ovládání (jak HW, tak SW)
• API - message, objekty, řízení V/V operací (jednoduché jako raspberry) - spojení tvůrců SW navzájem i SW/HW, HW/HW
• Dokumentace - HowTo, Logy atd
• Pokročilé adaptivní samořízení - nevím jak vy, ale proč pořád vymýšlet týdenní plány regulace topení, které se mění, protože život je změna …dnes, v době učících mechanismů, ať se regulace naučí, jak Vaše rodina žije a podle toho ať reguluje (selflearning se zpětnou vazbou, loguje dočasné manuální přenastavení)…k tomu je ale třeba aby systém dokázal identifikovat přítomnost lidí v místnostech, otevření oken pro větrání, atd - zkrátka práce s daty (event based systémy, data mining atd) (klidně by mi nevadilo poskytovat anonymní statistiky pro cloudové řešení pro samoučení  pro potřebu kontrolních vzorků, srovnání modelů, učení se od druhých chytrých domů formou potvrzení hypotéz už jinde atd)

Idea na konec

A tím se dostávám zpět na začátek…kombinace zabezpečení a regulace přináší základní synergický efekt…senzory zabezpečení mohou sloužít jako zdroj informací o pohybu “přátelských osob” v prostorech, takže pak systému nemusím říkat na základě sledování vzorců chování (příchod domů, příprava večeře, pobyt v obývacím pokoji, hygiena, spánek) ať se systém sám naučí hledat úsporu (otevírání vrat - blíží se člověk, podle identifikace ovladače (telefon), ví kdo to je, co typikcy dělá po příchodu domů, přepdokládaný příchod dítěte ze školy (týdenní rozvrh se opakuje) atd…tomu se dá poměrně jednoduše naučit, případně konfigurovat - příští týden tady nejsme (a co to znamená pro chytrý dům, nechť si řeší sám - minimální teploty, kontrola zajištění domu atd), včetně vychytávek typu má přijet zimomřivá tchyně, hlásím poruchu regulace :o). K tomu přidejte informace o počasí z meteo stanice (resp. cloud weather), integraci s kalendářem obyvatelů a konečně vidím neco, co mi dává smysl…základní cíle splněny - komfort, spolehlivost, adaptibilita, rozumná ekonomická náročnost, resp. rozumná návratnost investice….

Případným zájemcům o rozvinutí tohoto konceptu jsem k dispozici (plošný spoj jsem dělal 2x v životě, nechce se mi bastlit ze součástek, raději bych si koupil nakoupil krabičky, kterou zapojím do infrastruktury a “just works” , můj primární zájem je o data a řízení podle nich…resp. analýzy dat...jsme zkrátka datař s chutí kecat občas do všeho...

Sci-fi aneb Cesta k applience pro vyhodnocování událostí

Úvod:

Prosím berte s mírnou rezervou, čestně prohlašuji, že jsem před napsáním tohoto příspěvku nepožil žádný alkohol ani omamné látky, je to výsledek přemýšlení a k zamyšlení...

V jednom svém projektu na zlepšení logistiky na papíře resp. do šuplíku jsem řešil, sledování velkého množství vozidel v geografickém kontextu (silnice, oblast, zeme atd).

Jde o obecnou úlohu, objekt, jeho stav, jeho pohyb a vazba mezi objektem a geografickym kontextem (vsem vozidlum na dane silnici v useku x-y (oblast) posli zpravu).

Rád bych se s Vámi podělil, jak jsme dopadl, když jsme zkoušel na toto aplikovat hadoop…(na papíře a v pár malých testech).

O čem je Hadoop zde nebudu rozebírat, na to najdete odkazů dost.

Co zajílao mě, že data jsou v rámci zajištění dostupnosti bez HW redundance v systému celkem 3x (na 3 uzlech). Bohužel se jedná o identické kopie (což je ostatně důvodem). Jenže, když si vezmete, jak by ve výše uvedeném případu mohla vypadat vypadat vstupní datová věta:

<timestamp> <object> <action event> <GPS> <direction vector> <object instance info> <aditional structured info>

Když použiji geolokace, tak GPS mi dává k dispozici možnost přiřadit jeden nebo více GIS objektů (úsek silnice, silnice, město, region, země -zjednodušeně).

Vazba mezi objektem a GIS objektem je dynamická, resp. jak se objekt pohybuje, vznikají a zanikají vazby mezi sledovaným objektem a GIS objektem.

Zároveň je třeba zachovávat “instančnost objektu” kdyz daným místem projiždím dvěma jízdami, abych měl možnost data rozlišit.

Když budu toto ukládat do HDFS, tak super, mám tam uloženo, rozdistribuováno víceméně náhodně, resp. jaké jsou zde možné “partitioning” strategy ?

• Objekt - tento se přímo nabízí, ale objekt může jet přes půl Evropy, takže když budu dělat statistiky typu které objekty mi projeli danou oblastí v rozmezí dnů X-Y, tak prohledávám všechna data na přítomnost oblasti, k tomu je třeba určit instanční start a cíl (kontext jízdy).
• Oblast či jiný GIS objekt - podobně, jen když sleduji objekt, opět bych musel číst vše (čímž rozumíme číst na úrovni uzlů)

Když si představíte objem dat pro 100.000 vozidel, s 10ti vteřinovou periodou za 3 roky, tak máte velmi zajímavé číslo…x3 (redundance hadoop) - tak to je tak na 50ti uzlový cluster…(nemám nějak přesně vypočteno). Toto bych musel živit investičně a energeticky….

Protože potřebuji objekty sledovat near-real time, uvažoval jsme i o Sharku, resp. tupples v paměti….ale tam jsme narazil na problém sdílení tupples mezi úlohami…nějak nedomyšleno….

Jak z toho ven….potřebuji mít v paměti resp. rychle dostupné informace o aktivních objektech, statistické reporty ať jdou klidně na disk…

Připomnělo mi to boj s telco CDR záznamy a použitím MPP systémů….jedna dimenze distribuce dat je prostě málo…

Každý výrobce se s tím popral po svém (appliance systémy), které na řadu úloh představují opravdu 100 násobné zrychlení, ale v okamžiku konkurent objemných dotazů ( sada dotazů per sledovaný objekt a sada dotazů per GIS objekt by potřebovali opravdu silné trubky….). Trošku vyjímkou je Oraclovská Exadata, které to vyřešila šalamounsky tzv. inteligentní storage (Oracle Exadata Storage server), který umožňuje pushdown základních filtrů na tzv. chytrou storage (CPU, disky, a hoodně drahý Oracle software, který filtruje datové bloky, případně počítá parciální výsledky a až ty posílá ke konsolidaci do DB serveru (nepřipomíná Vám to něco ? :o)) )

Jenže jak udržet v paměti 100tisíce instancí objektů (vyřešit jejich persistenci) atd…to už by musela být pěkná farma…

Tak jsme přemýšlel, jak by se dalo vyřešit:

• Distribuce dat pro redundanci, ale současně využitelnou pro více partitioning strategy, tj. jednou záznam distribuovat v kontextu objektu, a podruhé /resp. vícekrát hiearchcky) v geo kontextu…abych neměl data 6x (3x přes objekt, 3x přes geo)
• Jak to uživit výkonově, jak umožnit distribuované výpočty, resp. udržení instancí objektů, on-event alerty pro komunikaci s objektem atd…
• Jak by to mohlo fungovat, aby to nepotřebovalo druhý Temelín…(to by se našim Rakouským sousedům nelíbilo…)

Vyšla mi z toho hypotetická architektura:

• Inteligentní distribouvaná storage s vlastní výpočetní kapacitou pro push down filtra (základní selektivita) - typická úloha, načti mi posledních 1000 událostí daného objektu, načti mi události objektů, které se v daném čase měli vazbu na daný GEO objekt….šlo by realizovat jednotlivými uzly distribuovaného výpočetního systmu na bázi PC, ale to mi připadá šíleně neefektivní…
• Využití grafických karet s rozšířenou pamětí - GPUček to má dost (s jejich běžnou rychlostí by dokázalo jedno GPU obsluhovat stovky či tisíce instancí objektů, pamět by musela být trošku větší), persistence (stav objektu v čase opět na iteligentní storage do třetí  kopie dat, organizovaná instančně)
• Alternativa ke grafickým kartám - ARM procesory ve velmi vysoké hustotě typu HP MoonLight…ale i tak by to bylo na několik racků…zase kvůli nižšímu výkonu procesorů

Technické řešení:

• Z pohledu inteligentni storage se mi jeví jako nejlepší jednoúčelové počítače (SSD disk cca 256GB, 4core CPU, RAM 16GB a centrální napájení, 10GbE, nebo PCI-e - zkrátka jednoúčelová krabička s velmi vysokou výpočetni a storage hustotou - CPU nemusí být high-tech, ale zase to nesmí být pomalá potvůrka, OS na bázi Linuxu…velmi velmi ořezaného…(ideálně ala blade šasi, kam se jen strkají další moduly….což je blízko IBM Netezee, i když ta teď integruje na jedné kartě jak storage (disk), tak výpočetní výkon (programovatelná hradla)). Volání API storage (inteligentní API - dej mi události a parametry, persistuj stav, vrať mi stav instance objektu v čase - po určitou dobu pro fail-over). SSD uvažuji kvůli trendu klesající ceny, velmi nízké spotřebě (ono už se zaplatí jen z pohledu dimenzování zdroje, úspory energie a chlazení), i když nic asi nebrání tiered storage (6TB disk jako archív pro data ageing) ušetří několik SSD, ale několikanásobně zpomalí odezvu při historických dotazech na tyto data
• Jeden výpočetní uzel obsahuje v sobě tolik storage modulů, kolik mu umožní sběrnice PCI-e, případně síťový protokol (privátní síť) a propustnost
• Stejně tak obsahuje výpočetní uzel jednu nebo více grafických karet, které umí adresovat resp. volat služby inteligentní storage - případně je zde možné uvažovat právě o specifikcýh řešeních pro distribuovaný computing…ale to už není úplně moje doména…
• A to celé může běžet na Linuxu jako black box…

Je to nejspíš hudba budoucnosti, ale narůstající exploze dat nás k něčemu takovému povede…zkrátka inteligentní applience stroj pro zpracování událostí (eventů, na instancích objektů s možností near real-time vyhodnocování). Vše s nízkou spotřebou, velkou hustotou osazení, a obrovskou datovou kapacitou…

Využití pro další úlohy:

• Pohyb lidí ve městě, optimalizace městské dopravy, dopravní proudy v rámci města, uživatelům nabízí plný komfort (ala navigace s aktuální dopravou - nasedni na tramvaj č.3, která dojede na zastávku xx za 3 minuty, poloha tramvaje,obsazenost, atd)
• Internet věcí - predikce spotřeby energií (elektrická i plyn)  v kontextu regionu GIS oblast - ulice, městská část,  ve vazbě na počasí v daném místě, a především vazba na připojenou rozvodnu - energetici omluví za zkratku)
• Logistika zboží - multimodal, sledování zásilky, od kamionových přeprav, přes kontejnerové, vagóny, až po kusové zásilky (e-shop)
• Válečná resp. vojenská logistika - kvalitní armádní logistika vyhrává války….informační podpora je jeden z nejdůležitějších faktorů - plynulé zásobování (tanky v pohybu, četa v pohybu, nahlášené požadavky na doplnění (spotřeba střeliva  a pohonných hmot od tanku), záchranné operace, po monitoring jednotek (v kontaktu, přesun na pozici, komunikace, kooperace, enemy detection s využitím UAV - pohybující se objekt, můj není, je to nepřítel :o)  atd) 

Zkrátka je hodně lidských i strojových činností, které když se překlopí na události (stavový diagram) a v kontextu Geo dávají velké využití.

Takže hurá do budoucnosti…

Reporting (a metadata) II.část

Zkusím bez obalu, tentokrát trochu techničtěji uvést návrh řešení, který má podle me zajímavou budoucnost….a velký potenciál…dodat businessu co si žádá...

Jak pracují reportingové platformy (z technického pohledu)

1. Musí být připravena (a udržována) metavrstva, která mapuje data do fyzického DB modelu (star schéma, snowflake schéma) - dimenze, fakta, ukazatele, hiearchie - a pojmenovává je z pohledu business významu. 
2. Tato metavrstva je v nějaké formě publikována (univerza v BO, prezentační oblast v Oracle OBI atd)
3. Uživatel se přihlásí do reportingové platformy a otevírá existující report, nebo zakládá nový -  nakliká, jaké informace potřebuje  a v jaké podobě, nastaví filtrační omezení
4. Při požadavku na zobrazení výsledku reportu je do datového úložiště generován dotaz (nyní nejčastěji SQL), který v rámci vytvoření dotazu :
• Načte požadované položky (sloupčky s SQL funkcionalitou)
• Generuje joiny mezi tabulkami do dotazu
• Aplikuje filtry (které jsou vstupními filtry reportů)
• Provádí agregaci dat, kde je možné agregovat už v DB  (group by, ti lepší umí i analytické funkce nebo přes klauzuli with)
5. Výstup (dataset) je načten do aplikačního serveru reportingové platformy
6. V případě tenkého klienta (zpracování využívá serverové CPU):
• Zde jsou provedeny další agregace a výpočtové operace (computed sloupce)
• Výstup je naformátován (tabulka, graf atd) a odeslán do prohlížeče 
7. V případě tlustého klienta: (probíhá na klientském CPU)
• Dataset odeslán na klientský počítač 
• Zde jsou provedeny další agregace a výpočtové operace (computed sloupce
• Výstup je naformátován (tabulka, graf atd) a klient vidí výstup (aby si jej mohl vyexportovat do Excelu :o) )
8. Při změně podmínek (změna zobrazení, změna filtrů, atd) je generován nový dotaz (často s využitím cache), který přepočte data, nebo seřadí, agreguje atd…
9. Při přechodech mezi reporty resp. drill down se spouští jiné reporty, které dostávají do vstupních parametrů hodnoty filtrů pro drilované data

a to je v kostce vše….že to není žádná raketová věda ?

Samozřejmě  i pár technických vychytávek a perliček existujících platforem:

• Předpočítané reporty - datasety pro vybrané reporty jsou vytvořeny a uloženy v dočasném úložišti nebo i paměti aplikačního serveru - pro zrychlení přístupu - de facto další stupeň datové agregace
• Aplikační servery si drží svoji “cache”, kde mají nejčastěji požadované data, různé materializace a agregace dat (ať žijí flash disky)

Aby to vše mohlo fungovat, tak jsou klíčové dvě věci:

1. Metadata - metavrstva musí být správně připravena a obsahovat, a mělo by to být i popsáno v business kontextu. Protože požadavky rostou, tak typicky pak jsou metavrtvy dost rozsáhlé (atomové elektrárny)
2. Aby ten, kdo tvoří report věděl, co vlastně tvoří, a z čeho report tvoří, musí vědět, s jakými daty pracuje, jaké jsou mezi nimi logické i technické vazby atd, a jak vlastně a odkud vznikají (zdroje) 

Metadata jsou mé oblíbené téma…z vlastní zkušenosti vím, že není snadné udržet aktuální informace a do ktrátkého komentáře v toolech popsat, jak je dané KPI počítáno, pokud to zrovna není jednoduchá SUM, MAX operace

Tyto informace musí být prostřednictvím reportingu podány business uživateli tak, aby pochopil, s čím pracuje (za mě nejtěžší fáze celého řešení). S tím se odvíjí i potřeba lineage analýzy (narazil jsme na pěkné www.sqldep.com), ale je třeba dodat další obsah a kontext (logické vazby a závislosti mezi objekty) popsané tak, aby byli pochopitelné pro business lidi.

Takže jak to vyřešit ?

Dávám Vám k úvaze, zda by to nemohlo fungovat třeba takto:

• Mít na jednom místě všechna potřebná metadata - aktuální, propojená, “čistá” - svatý grál...
• Mít Excel, odvahu a chuť dotáhnout…resp. zajímavá příležitost pro dodavatele řešení 

1. Sdílená metadata - na jednom místě

Metadata lze sdílet skrze nástroje (od CASE, přes ETL/ELT až po reporting) což není  nic moc objevného, dokonce to nabízí spousta reportingových platforem, ale mezi námi, zkuste to reálně použít ne jen pro PoC, ale v běžném provozu….i můj oblíbený nástroj ODI v tomto dost kulhá. Nezřídka je tato featurka zpoplatněná naprosto nesmyslně za enormní částky jako add-on. A co teprve v případě, kdy máte CASE napr. Sybase PowerDesigner, ETL Informaticu, a reporting SAP BO….

Druhou možností jsou enterprise metadata nástroje, které medata z jednotlivých toolu nasávají a snaží se je propojit….ale mezi námi, tyto tooly stojí víc, než celé reportingové platformy a mají jednu filosofickou botu….nikdy nejsou up-to-date a velmi často pak máte odpověd, že není publikována aktuální verze….a zde je právě to jinak a ještě se to bude měnit v nové verzi.

Pokud budou metadata sdíleny genericky (metadata driven přístup), máte vždy jistotu, že jsou aktuální, protože se podle nich generují transformační kódy datových transformací, loady ze zdrojů, nápočty kostek, i prezentované výstupy…. snímky a exportované verze….než naimportujete do nástroje a propojíte, tak už se zase něco změní a můžete opakovat znovu…takže nejlepší cesta je on-line metadata.

Na půl cesty

Protože se touto oblastní už nějakou dobu zabývám, tak jsem v praxi potkal spoustu hodně zajímavých “utilit”, které tuto oblast řešili, ale většinou je vytvořil jeden člověk pro jednu oblast….

Kupodivu nejde ani o nijak složité struktury (pokud neberu v potaz problematiku verzování, generováni change scriptů a potřebných datových transformací při migraci změny do DB). 

U některých zákazníků jsem vytvořil následující architekturu, která zdaleka není dokonalá, má overheady, ale je funkční…

• CASE: Oracle Data Modeler - verzujeme pres subversion
• ETL: Oracle Data Integrator - verzuje uvnitř sama sebe
• reporting BO: verzuje také uvnitř, ale k metadatů s enedá nijak rozumne dostat (uzavřené řešení)
• publish metadat: xwiki (www.xwiki.org)  - pomocí stránek v xwiki je generována dokumentace logického datového modelu a transformací (ODI), navzájem propojené

Co mě k tomu vedlo ?

1. Potřeba dokumentovat celé řešení (datový model, transformační model) - s cílem selfservice BI - minimalizovat potřebu businessu komunikovat  s IT, resp. aby si report byli schopní vytvořit sami, aby znali data své firmy, a když už nevědí, tak aby jsme měli jedno místo, odkud čerpáme informace…
2. Potřeba vyhledávat - full text, procházet několik PDF v různých verzích se mi fakt nechce…stejně tak učit všechny lidi z businessu, aby si uměli itevřít data modeler, a vyčíst co potřebují, mít možnost prolinku - tato tabulka je plněna tímto interface v ODI (transformační model), ze zdrojových tabulek - prolink na tabulky
3. Mít možnost komunikace s businessem v kontextu informace - ke stránce mi dají komentář (ať už ke sloupečku či transformaci)
4. Vize byla napojit to i na BO - report - položka (vazba na tabulku), transformační pravidlo v BO, a link na tabulku,z které je čerpáno - zde jsme zjistili,ze by jsme museli složitě parsovat export univerza z BO (textový soubor), další cesty jsme postupně eliminovali…na projektu s OBI jsem to zatím ještě nenasadil, ale tam by to mělo jít
5. Mít možnost sledovat verze (dokumentace) i tabulek, alespon nějak rozumně - využíváme historizaci stránek v xwiki

Řešení celkem funguje, ale má svoje overheady, které jsem zmínil i výše:

1. Potřeba sehrát medata na jedno místo - obdobné problémy s enterprise metadata repository

• Technický postup, jak vyexportovat data z OracleData Modeleru do jeho reporting schématu (featurka ODM), zkrátka z xml to uloží do DB do sady tabulek (bohužel nyní bez fyzického modelu) - pomocí GUI Datamodeleru
• Vysnímkovat data z work repository ODI - procedura v OracleDB
• BO jsme zatím odpískali
• Sustit proceduru v PL/SQL, která pomocí REST API xwiki aktualizuje stránky (spouštíme vše, sama xwiki se rozhoduje, jestli došlo ke změně stránky, tak ji zaverzuje), celké přegenerování dokumentace trvá cca 10minut (5 minut ODM generuje obsah xml do reposting repository)

A vše je v xwiki….datový model, transformační model, prolinky mezi nimi

Produkt XX

Aby to fungovalo lépe a netrpělo mouchami neakuálnosti metadata, a současně aby řešení přineslo nejvyšší přidanou hodnotu, tak by bylo vhodné mít všechna metadata on-line propojená v jedné repository, do které může přistupovat více lidí najednou a nad kterou pracuje více separátních aplikací (přes API). 

Jak:

1. Jedno úložiště metadat (CASE nástroj - uživatelsky přítulný, který bude podporovat metadata driven i ETL nástroj resp. definici transformace cíl-zdroj), a k tomu tvorba metauniverz (ala OData), která bude sebepopisná, s linky na dokuemntaci publikovanou ve fulltext systému (xwiki se celkem osvědčilo)
2. Vyřešit verzování (paralelně pracující vývojáři, ale i roll out DEV-TEST-PROD) - zde se mi pere má databázová duše s xml soubory a Gitem (Git toto se souboru umí velmi dobře, řešení v DB je peklo na zemi). Osobně lavíruji s použitím souborového formátu xml, s tím, model si aplikace načte do paměti (linq či podobné) a parciální save ukládá přímo do xml souborů, ty posléze uživatel pushne do nadřízené repository
3. Pár relativně jednoduchých GUI - tvorba DB modelu (s podporou vzorů, šablon atd), možnost definovat popisy až do úrovně prezentační vrstvy, podpora synonym (Party -> Odběratel, jedna tabulka, kda kontexty, filtr na data, ale současně i třeba jen některé stavy záznamu pro odběratele atd). Toto by se dalo udělat i jako plugin do prohlížeče, či webová aplikace (s tlustým klientem)
4. Mapper pro transformace - těchto jsem viděl už dost, protože to řešíme všichni….zde ale napojitelný na tuto metadatovou bází, a definice transoformace v univerzálním jazyku (já jsem pro SQL, kolega dělá v DSL, atd…), s podporou virtuálních tabulek (mezitransformace, které je ve výsledku subselectem a nemá persistována data). Opět samostatná appka
5. Stejně tak reporting - tvorba virtuálních oblastí (přes různé zdroje dat, s možností připojení datamartu k stage tabulce pro agilitu), vše popsáno s vazbou na zdroje prostřednictvím výše tvořených metadat…
6. Utilita, která sleduje změny v git repository a pro commitované objekty přegeneruje stránky v xwiki., tj. vše up-to-date, plně provázané, prolinkované….ve firemním face…zkrátka knowledge base, jak má být….
7. No a k tomu "už jen" generátory kódu, které na základě metadat a patternů generují transformační kód
8. To spojit do workflow (procesy a jejich závislosti, pořadí transformací, logování, repair atd) a nad tím reporting opět do wiki (denní page pro load, co se událo, kam byla která data nahrána atd)

Reporting:

Myslíte si, že jsem zapomněl na téma článku a rozepisuji svoje vize ? Jen částečně...protože nový reporting nad dat spravovanými výše uvedeným způsobem otevírá nové možnosti pro existující nástroje....

Takže ona reportingová platforma nové generace ?

Tu ale všichni znáte, existuje 20 let a jmenuje se MS Excel …od verze 2010 s pluginy typu PowerPivot, PowerQuery….a navíc s podporou napojení na datový zdroj OData.

Nejsem rozhodně M$ člověk či obchodník, ale musím říct, že tyto pluginy se mi jeví jako potenciální killery reportingových platforem….dáte businessu řešení v technologii, kterou dobře zná, je rozšiřitelná, univerzální….netrpí neduhy reportingových platforem, a nyní i výkonné  a komfortní nástroje (na rozumném notebooku není problém hrát i s  daty o velikosti několika milionů záznamů)

A co jí chybí k dokonalosti ?

1. Strana klienta: Pokud si trošku pohrajete s PowerPivot resp. s Odaty, tak zjistíte, že to tak user friendly není. Je třeba měnit zdrojový dotaz pro volání Odata (doplnění filtrů atd), na což dle mého chybí pěkný plugin do Excelu, který by prezentoval rozhranní OData (jaké jsou dostupné, s odkazy na knowledge base, a hlavně s možnost efektivního zadávání vstupních parametrů) - když se podíváte na youtube, je dost příkladů, jak napojit excel na datový zdroj Odata (velkou výhodou je, že OData poskytují k datům i metadata, ve kterých můžete mít i linky do xwiki), ale není to business komfortní…(jako reportingové platformy). Tomuto pluginu udělat pěkné gui, aby si člověk vybratl oblast, měl možnost definice filtrů, s možností rozkliku reálných hodnot do filtru atd....to by se dobře prodávalo.
2. Aplikační server: zde je více možností, mě se nejvíce líbí node.js a podobné technologie s rozšířeními pro generování OData API. Tento aplikační server působí ale výhradně jako převolávač, takže pokud Vaše DB umí OData API, tak stačí jen připojit...
3. Databáze - příprava definic dotazů, které slouží jako podklad pro volání agregátů s možností execute parametrů (propagace filtrů z OData volání až do zdrojových dotazů pro usnadnění tvorby exekučního plánu a dosažení maximálního výkonu). Buď formou view, view atd pro oblasti, aby bylo možné využít agregační sílu databáze - tj. 

připravit sady reportů v excelu (resp. z existujících udělat s mírnými úpravami šablony, které se napojí na datové zdroje pomocí pluginu).
De facto se jedná o datové rozhranní, kde OData poskytuje metadata, možnost propagace filtrů atd. Agregace jsou buď součástí definice rozhranní (podkladový dotaz), nebo se pak dělají až z výsledků naimportovaných do excelu prostředky excelu.

Co to znamená?

1. Úspora stovek tisíc Kč za nákup reportingové platformy, úspora statisíců při tvorbě reportingových oblastí a tvorby desítek reportů, aby vypadali stejně jako nynější reporty v excelu
2. Potenciální úspora za ETL (v řádech milionů CZK) - (když už máte všechny metadata i transformace, tak pak jde jen o to napsat generátory, které z těchto informací generují transformační skripty - metadata pattern driven ala ODI (mapping dává logiku, knowledge modul řeší technickou realizaci pro daou technologii) - buď můžete vzít ETL typu Clover ETL (www.cloveretl.com,  nebo jiné, kde lze transformace generovat jako xml nebo přes nějaké API), nebo jen rozumné workflow a generovat sady SQL a shell skriptů (protože pak už by bylo ETL jen jako velmi drahý scheduller). K tomu logování a máte platformu, kteoru Vám může leckdo závidět…ono to stejně někdo snad udělá jako produkt 
3. Business bude mít dál svůj excel, jek mu ho upgradujete na flexibilní tool pro analýzy datových zdrojů (dashboardy, pivot table, kontingenční tabulky) - spustí plugin, vybere si zdroje, nastaví filtry, execute…a má data…v kontingenčce či výpisu

Samozřejmě jsou i argumenty proti….pracovníci pak mají u sebe na počítačích kritická data firmy (zákaznícké báze atd…). Mezi námi, oni je tam mají vždycky, protože co jim brání si tyto data vyreportovat v reportingové platformě a vyexportovat do Excelu ?

Řešit se dá i umístěním úložiště těchto excelů, podporou šifrování (má i excel), zamykáním souborů pod heslem atd…Jsem skálopevně přesvědčena mohu i dokázat….kdo má přístup k datovému skladu, dostane data na lokální disk, pokud chce….

Budoucnost ?

A teď si tento tool představte i pro Big data, kde je situace s metadaty ještě více tristní…a máte…jednu platformu (napojit se na HCatalog, další generátory pro generování kódů v mapreduce, či sparku, pigu atd…výstup je opět soubor (typicky např. csv, který se dá načíst do excelu (samořejmě předpokládám silné filtrace a agregace na úrovni Hadoopu, výstup by měl být už jen pro prezentaci výstupů….

Nebylo by to pěkné ?

Závěr 

Takže ohledně reportingu....nevěřte nám z IT, reporting je jen dělník, který odedře část práce, ale nejvíce je jí na Vás a pak na tvůrcích metadat pro reportingové platformy a zajištění jejich provozu.

Až si toto jednou přečte někdo, kdo se naštve, a bude chtít vytvořit co popisuji, budu rád spolupracovat, strašně rád bych poté takovýto tool dodával zákazníkům, s tímto by byla radost jít do tendrů na dodávky. 

Tentokrát na téma reporting

Úvod

Předpokládám, že každý ze čtenářů přichází do styku s reportingem. Realizace reportingu:

1. MS Excel kolující po firmě mailem, či na sdíleném disku jako shared workbook

2. Reporting v rámci core systému

3. “Enterprise” reporting platformy

4. Přístup k datům s heslem, co si vyrobíš to máš

5. Nové generace reporting systémů typu Tableau (a desítky dalších)

Každé z těchto cest, kterými se může Váš reporting vydat má svá pro i proti. V tomto postu jsem se zaměřil na reporting nad BI/DWH řešeními, i když v hodně věcech lze chápat jako generalizované (operativní reporting má velmi shodné rysy).

Mám za sebou poměrně dost projektů, kde se tvořili BI/DWH řešení a vždy jedna z nejbolavějších věcí byla, jaký reporting nad řešením vytvořit, aby bylo:

1. User friendly
2. Nákladově efektivní
3. Dlouhodobě udržitelné
4. Pokrývalo potřeby businessu na formu výstupů, zajištění distribuce atd…
5. Aby se to líbilo IT či deccision makerům - ale o tomto dnes mluvit nebudeme…:o)

Bohužel najít reportingové řešení, které by splňovalo všechny 4 ukazatele je jako potkat Yetiho a naučit ho twítovat…

Kritéria

1. User friendly

Tato oblast opravdu není u klasických reportingových platforem příliš silná….především, pokud máte danou technologii naučit a motivovat k používání pracovníky, kteří “myslí v Excelu”.  Kdo má zkušenosti s těmito nástroji, měl by mi dát za pravdu…o tomto by se dali napsat tisíce blogů, ale stačí se podívat na google…

2. Nákladová efektivita

Enterprise reportingové platformy jsou investice v řádu vyšších stovek tisíc u minimálních konfigurací, u větších firem i jednotky a desítky milionů. Když zde zkusíte počítat selským rozumem business case (úspora času, dostupnost informací, zlepšení chodu firmy), tak aby Vám to vyšlo musíte být hodně kreativní, a když do nákladů započtete správně i ssuport a náklady na provoz, tak to prostě vyjít nemůže…
Zde můžete namátnout, že nové generace reportingů typu Tableau jsou přece self-service atd. Jenže jedna věc je používat v týmu 3-4 lidí, a druhá když to nasadíte o 50ti lidí (správa verzí, metadata zdrojů, connection do datových zdrojů atd). Vyzkoušel jsme si několik různých řešení této generace a výpočtem podle list price to zase tak levná řešení nejsou…počítáno na analytický tým 10ti lidí a k tomu 1-2 analytici jako provozní podpora.

3. Dlouhodobá udržitelnost

Kdo má zkušenosti s migracemi Oracle OBI 10 na 11, kdo zkoušel migrovat SAP BO z patchsetu na patchset, nebo nedejbože vyšší verzi, (před pár lety to i u dalších typu Cognos, Microstrategy atd bylo hodně podobné), ten mi dá za pravdu, že v danou chvíli by hodil na vývojové tými těchto nástrojů napalm (ať si užijí to samé peklo jako vy při migracích a upgradech).
Bohužel většina těchto enterprise nástrojů jsou slepence postupně nakoupených technologií, které firmy nakoupili postupně, původní týmy resp. autoři si užívají na Havaji (dobře prodali), a nové týmy se snaží dát dohromady kolečka a čtverečky, aby vytvořili jednu plnou plochu…čest jim za odvahu a odhodlání, ale to vám problém nevyřeší...ale když koupíte nástroj za několik milionů, tak se business vlastníkovi špatně vysvětluje, že musí dál používat MSIE 9, protože daná verze reportingu s vyššími verzemi blbne a nasadit novější verzi znamená nákladu v řádu desítek MDs.

Klasická provozní správa těchto platforem je také práce pro Sysifose, od uživatelských práv, přes publikace reportů, dokumentaci reportů, sdílení dat, omezení přístupu k datům atd…

Nové generace reporting toolů jsou na tom velmi podobně, i když zde spíše vlivem překotného vývoje, je otázkou, kterým směrem se budou dále vyvíjet.

Samozřejmě existují i cloud řešení, kde provoz řeší poskytovatel řešení, ale i tak potřebujete na své straně člověka, který jim bude umět vysvětlit, co vlastně chcete a stejně tak bude evangelizátorem zpátky do firmy.

4. Potřeby businessu

Veličina stálá asi jako kapka rtuti na špičce jehly...mění se ze dne na den, často se otočí kormidlem o 180 stupňů. Ale to je zkrátka business, protože musí umět reagovat nejen na změny na trhu, ale i na změny nejvyššího managementu :o). Controlling oddělení, finanční analytici, scoring oddělení, zákaznická péče jsou tímto téměř pověstní, ale beru to tak, že na nich většinou leží velká odpovědnost, tak chtějí adekvátní informační podporu.
Mezi nejčastější požadavky patří - přidejte mi tam ještě tuto dimenzi, přes kterou chci data vidět, chtěl bych si data měnit (what-if - požadavek na writeback), chci si nad nimi počítat…..zkrátka vše, co poskytuje nástroj, který se jmenuje excel…a na kterém tito lidé vyrostli a dost těžko jim budete vysvětlovat, že to co už mají ve firmě koupené je přeci jenom Excel, ale vy jim dodáte potvůrku za několik milionů a ona nebude zdaleka umět ani polovinu toho, co umí excel…takže ve finále jim uděláte tabulkové reporty, které si oni vyexportují do excelu a nad nimi tvoří své modely a kalkulačky…tímto výsledkem končí dle mé zkušenosti 4/5 projektů. Sice jsou dashboardy, s prokliky až na úplný detail, ale xls datasheet je prostě datasheet. A ať chcete nebo ne, reporting platformy jsou v ČR už 2 desetiletí, ale na tomto se pořád nic nezměnilo…a dle mého ani nezmění…

Výsledek nasazení 

Z počátku nadšení (pěkné barvičky, pekné grafy, a umí to i export do excelu...), přes mírnou rozpačitost...tohle musím udělat pokaždé, a toto to fakt neumí, vždyť v excelu je to trivka, vždyť já si chci jen uložit poznámku k tomuto řádku...až po mírný odpor, resp. hledání oklik a dalších cest.
Opět nelze všechny projekty poaušalizovat, ale dost často po několika letech sleduji, jak se řešení provozuje, ale kdysi slibovaný přínos pro business se nějak nekonal (ať již z důvodu změny priorit business, nebo se tam ještě nestihlo dodělat to a to a bude to za půl roku...)

Důvody:

1. Nastavení očekávání zákazníků spojených s implementací reporting platformy (obchodník slíbí standardně zázrak do dvou dnů)
2. Dodavatelé reportingových nástrojů - drží zažitý koncept uby nehty, protože vytvořit opravdu novou generaci, který by toto řešila a někdo ji koupil jsou investice v řádu desítek či spíše stovek milionů a oni utratili z anákup existujících i několikanásobně vyšší částky.
3. Implementátoři - snaha prosadit používání platformy na vše je ve výsledku kontraproduktivní. Na druhou stranu, řešení  pro 3 datové analytiky za někollik milionů se také špatně vysvětluje (i když v důsledku může firmě zefektivněním jejich činnosti ušetřit miliony)
4. Vývojový proces - zde je třeba rozdělit kategorie, které se především odlišují dobou dodání výstupu a kvalitou výstupu (od nejrychlejšího po nejpomalejší):

• Selfservice - aneb “urob si sám” - pro fázi discovery super, ale zkuste to pak rutinně udržovat pro desítky uživatelů, to se Vám pak na poradě sejdou reporty, které budou jako z jiné galaxie
• Vývoj na straně businessu  - toto funguje, ale znamená to mít člověka, který překlene technickou část reportingu (umí s ním dělat včetně kliček) a má business znalost (ví, co jsou hrušky a jablka a nemíchá je). Bohužel tito lidé se hledají velmi špatně, ale může to takto fungovat i dlouhodobě (zkušenost z mnoha projektů, kde se kolikrát genericky z businessu překlopil člověk, který si vzal řšení za své a udělal na něm kariéru)
• Vývoj reportů IT lidmi - bohužel se stále tento přístup v mnoha firmách drží, nepochopitelně, ale ono to v podstatě vyhovuje oběma stranám - business e může vymluvit, že to IT nepochopilo, a stejně tak IT má alespon trvalý přísun práce (a dobře se obhajuje budget)

Závěr této části:

Rozhodně neříkám, že je vše špatně, daří se i dobré projekty, zde paušalizuji, ale shrnuto a podtrženo:

1. Spousta práce na obou stranách dost často s diskutabilním přínosem (protože pod reportingem je potřeba typicky vytvořit i datový sklad)
2. Když už se řešení podaří vytvořit, business naučit používat, tak se neustále potýkáte s chováním, kdy daný postup v jednom reportu jde, ale v druhé z nějakého záhadného dlvodu ne…(a není to mezi monitorem a židlí)
3. A ve finále platforma slouží jako portál pro exporty do excelu....

A výsledek z pohledu investice ? (resp. business ownera) 

• Utratili jsme budget (často zvýšen v průběhu boje, neb se zapomnělo na pár desítek reportů),  řešení jakžtakž funguje, i když má pár masařek, pokrývá část potřeb (typicky ty nejjednodušší ). Ale zkuste si udělat usage statistiky (a vyčlenit z nich exporty do excelu). Dost možná se budete divit, tlouct hlavou do zdi…
• Náklady na provoz jsou z pohledu poměru srování k přínosu enormní (u větší firmy 2+ lidé fulltime, aby se to udrželo v provozu, a jako support lidem, co vyvíjejí reporty - ať již business jako self, nebo IT). Zkuste si to zjistit u Vás ve firmě ? (v menších firmách je to jeden člověk, ale představte si, že třeba odejde...)
• A klíčoví lidé z businessu (marketing, controlling, atd) dál hledá okliky, jak rychle dostat výstupy, které včera nikdo nechtěl a pozítří je má prezentovat představenstvu… (vyexportuj report do excelu, k tomu připojí další excel, lookup, pivot table, pár výpočtu a bulharských konstant a je  doma….za pár večerů, ale splní úkol pro představenstvo…)

Trošku smutné....

A je jiná cesta ? Je možné změnit myšlení na obou stranách a najít společnou cestu, která bude efektivní, udržitelná a user friendly ? (to si nechávám jako téma na příště)

Aféra Big Data - odhalení (finance )

Tak jsem zase zpět...

Úvod

Dneska si vezmeme na paškál finanční sektor. Předem podotýkám, že pokud jste citlivé povahy a zaměstnáni v IT firmy z finance segmentu, tak snad raději ani nečtěte...Dále pak uvádím, že díky zkušenostem z poměrně mnoha projektů datových skladů v těchto společnostech vycházím z praktické zkušenosti, a jsem i hodně zaujatý...takže rychle do toho, půl je hotovo...

Co je finance segment ?

Banky, splátkové společnosti a další instituce, které mají shodnou charakteristiku chování vůči zákazníkům, pojetí v chápání datového skladu (CDW/EDW/ADW), i přístupem a rychlostí k jeho budování...optika těchto skladů je zaměřena směrem klient - a kolem něj smlouvy, účty, hiearchie a balíčky produktů,  říkám tomu party-based DWH (party je fyzická i právnická osoba, s oblibou se unifikují, můžete chápat zjednodušeně jako entitu klient)
Další společnou charakteristikou je ...jak to říct...ultrakonzervatismus, rigidita, "zoufalá pomalost", a neskývané zoufalství mnoha business uživatelů....čekání, čekání, mnoho hrůzy nahání...:)
Pokud si myslíte, že je to problém jen velkých bank a nové atraktivní banky jsou na tom lépe, dalo by se vyprávět....
Subjektivně však musím uznat, že u stávající banky (kam jsem odešel po cca 12 letech u KB) jsem nadmíru spokojen, protože mi od nich nikdo nevolá, vše zařídím elektronicky, platím kosntantní poplatky a nechává mi dost volného "vzduchu". A asi ještě nemají vybudované akviziční call centrum....protože nikdo nevolá :). Protože ale znám její historii,  musím uznat velký pokrok v kvalitě IT systémů a development cyklu za poslední rok...a dost skryté reklamy...

Činnosti v segmentu

Tady Vám sice google také pomůže, ale jistě máte své zkušenosti - trendem v těchto segmentech je akvizice klientů, akvizice klientů a posléze akvizice bývalých klientů....

1. Akvize klientů - člověk by od solidní konzervativní banky čekal, že jej bude znát, bude chápat jeho potřeby (analýza plateb v bance, uzavřené smlouvy na pojištění), ale asi je někde chyba...Jak si jinak vysvětlit ty úžasné telefonáty, za které by se nemusel stydět telemarketing WS kráječů....heslo dne je uzavírej s námi další smlouvy, refinancuj půjčky a hypotéky...kupuj si další balíčky, pojistky, atd, protože my musíme plnit akviziční plány....jen škoda, že spousta těch úžasných nástrojů na kampaně nerozumí požadavku zákona, že když explicitně při telefonickém rozhovoru neochotu přijímat další takové rozhovory, tak Vám zavolají přístě stejně znovu...asi v call centru chybí tlačítko vyřadit z akvizic...spousta stávajích řešení DWH v těchto institucích je zaměřena na KPI, což rovná se akvizice...zvláštní je, že když jsem v několika případech rozporoval hodnotu akvizic formou suma počtu, že pro banku či pojišťovnu by měl být hlavním ukazatelem spokojenost klienta a jeho výtěžnost (něco jako ARPU v telcu), tak na mě většinou všichni nesouhlasně koukali. A hovorů na téma, jak jsem s danou společností spokojen jako klient bych napočítal za poslední dekádu na jedné ruce.

2. Reporting - operativní/analytický/regulatorní - velmi silná doména činnosti těchto společností, z mého kritického pohledu výrazně souvisí s přezaměstnaností v daním segmentu. Oddělení, které nemá "svoje" reporty je žhavým kandidátem na reorg, proto není nad to vymýšlet reporty, zadat jejich realizaci a tu projektově řídit (cca 12 měsíců intenzivní práce...dodavatelů či interního IT a mnoha členů oddělení) ...a pak další dva roky hledat, komu ten report vnutit... já varoval, že jsem zaujatý :o). Když se někdo najde, je potřeba zajistit distribuci reportů do mailu (spamming mailboxu), security v reportu (rozřezání dat v reportu tak, aby pokud možno nikdo neviděl nic v celkovém kontextu a aby si to každý pak musel stejně vyjíždět z provozního systému). To, že každý report ukazuje trošku jinak stejná data, ale jiná celková čísla ponechme stranou, nebudeme malicherní...protože to voda na mlýn reps. námět projektů typu revize reportingu, sjednocení reportingu, konsolidovaný reporting atd...Nad BI řešeními v těchto institucích vznikají stovky reportů (opět bych zmínil, že jsem přesvědčený a naučený, že pro běžnou firmu stačí 15 reportů, každý s pár záložkami). I proto má typicky oddělení BI v těchto bankých 60+ pracovníků...Velmi mocným generátorem práce je i povinný regulatorní reporting typu Solvency/Solvency 2, Basel x, kde se také mění postupně pravidla a rozšiřuje se záběr a způsob hodnocení rizik, hotovosti, investic atd...kde jde také o trvalou práci desítek lidí v BI týmu i na straně businessu.

3. Kontinuální "Reorg" - aneb trvalá kontinuální reorganizace, kdy jedna se fáze reorganizace prolínají mezi sebou a výsledkem jsou další reorganizace - od cost cuttingu až po snahu vytvořit více manažerských pozic, to je každodenní chleba pracovníků v těchto společnostech...samozřejmě při záměru reorgu se mění i reporty, oprávnění k reportům atd, takže BI oddělení má o zábavu postaráno. S ohledem na rychlost implementace změn v BI řešeních v tomto segmentu občas nastává vtipná situace, kdy po půlročním vývoji BI team zjistí, že oddělení, které požadovalo novou sadu reportů či atributů  již zaniklo a vzniklo jiné, které se na informace chce dívat z jiného pohledu...

4. Fraud detection - zcela logicky je toto při prvním pohledu jedna z mála oblastí, kde se celkem daří dynamice a práci s daty...protože tady jde o prachy...a ne malé....při druhém pohledu zjistíte, že pod stoly kolegů  fraudu běží druhý datový sklad, protože oni nemohou čekat, až oddělení BI dodá nové atributy za půl roku v dalším release (půlrok v tom lepčím případě). Ať již se jedná o operace s bankovními kartami, či pojistné podvody...Pro objektivnost je třeba uvést, že co jde, tak rádi načtou z DWH, k tomu doplní excely a accessy a jedeeem...V těchto odděleních lze potkat opravdové nadšence a profíky, protože BI sami dělají, propojují data, analyzují...radost s nimi spolupracovat

5. Risk/Scoring - klient čerpající aktiva společnosti (půjčky, hypotéky, úvěry) musí být "oskórován", nejlépe objektivně (silná rigidita vůči jakémukoliv objektivního zhodnocení). Výsledkem pak je, že i firma, která roste, má kvalitní čísla, nedostane díky zamítavému postoji risku úvěr, protože přece patří do rizikového segmentu. V lepších případech Vás podpoří board, ale i ten je silně zdrženlivý, protože by pak risc mohl říct...my to říkali...risk oddělení mají časo své datové sklady (ale ne pod stolem, ale někde natajno, protože tyto jejich datové sklady obsahují velká tajemství...podle vyjádření risku...co kdyby tyto data náhodou dostal do rukou někdo nepovolaný...data jsou načítána z firemního DWH, a obohacována o unikátní know-how správců tohoto risk data skladu). I v těchto odděleních najdete technologické fandy, ale kupodivu spolupráce s nimi je subjektivně hodně o sebeovládání, protože kdo není z risku, ten jako by nebyl...

6. Marketing a Campaign systémy - aby s emohlo akvizovat jako na běžícím pásu, je samozřejmě třeba generovat kampaně, cílové skupiny, multichanel komunikaci, komunikaci brandu a spousta dalšího žargonu...Faktem je, že se jedná o systémy, které asi nejvíce po regulatorním reportingu požadují data po datovém skladu. A faktem také je, že je nedostávají, a když, tak za velmi dlouho....a výsledek ? Třetí datový sklad, tentokrát opět pod stolem či u někoho v kanceláři za květináči (podvědomá snaha chránit hodnotné informace tím, že počítač nebude vystaven na očích), někteří si postupně z budgetu zaplatí i dost výkonné stroje, což poznáte podle silného hukotu ventilátorů zpoza vzdálených stolů, to Vám klasické nabušené PCčko neudělá...V tomto případě se ale musím těchto ddělení zastat...jsou mnohdy vedeni upřímnou snahou co nejlepšího zacílení kampaní, mají snahu opravdu poznat zákazníky (aby jim mohl ilépe prodat co dostali za úkol). Tyto oddělení jsou ozvláště neoblíbené u BI oddělení, protože když něco potřebují, potřebují to rychle a odpověd přijdte za 3/4 roku, dáme to do dalšího releasu, snad se to tam vleze dost často vyvolává berserk mód předkladatelů požadavku. Výsledkem jsou pak právě ty hučící stroje v jejich kancelářích. Zároveň jsou to vděční tvorové, jakmile jim jednou vyjdete vstříc, nespokojí se s prstem...a vznikají profesní přátelství...  ¨

7. Samozřejmě core business - core systémy bank jsou podobně rigidní jako banky, což je ale v hodně případech pochopitelné, příkladem mohou být pokusy nahradit 2 core systémy jiným systémem, výsledkem jsou 4 systémy - původní zůstávají běžet, protože migrace existujících smluv a produktového portfolia se ukáže jako nepřekonatelná překážka, pro nový systém se udělá redesign produktů a dalších 10 let se pomalu přesjednává či migruje...a ten čtvrtý vzadu je část businessu, která řeší specifické úlohy, jako třeba pdopora produktů, které nový systém přes věškerou snahu nepodporuje...Release cyklus core systémů v bance je cca 9-12 měsíců, což je současně argument mnoha BI týmů, na otázku, kde že to vázne...

8. UFO/CRM integrační aktivity - různé UFO systémy (Unified front end) nebo CRM systémy s unifikační funkcí (typu Siebel atd) - protože v běžné finančí společnosti najde i několik desítek systémů (bod 7 protažený v čase) , tak aby se z toho uživatelé na přepážkách úplně nezbláznili, nasazují se řešení, které mají za úkol poskytnou "jednotný front end", konsolidovaný pohled na klienta,  zajistit IN/OUT API do backend systémů, což už je o integraci a nehynoucím businessu velkých integrátorů a konzultačních firem zvučných jmen...byl jsme svědkem a bohužel i realizotorem změnového požadavku na přidání 3 atributů, a odhad pracnosti včetně testu byl 60MDs, a nejhorší na tom bylo, že to byl hodně reálný odhad...n-vrstvá aplikace, 6 integračních API do backend systému, integrační testy...a toto člověku z businessu vysvětlíte hodně těžko....

9. Vymáhání - týká se především splátkových společností, kde jde o nezbytnost, s ohledem na množství aktivit. U ostatních spíše okrajová aktivita, vymáhání nesplaceného pojistného, atd. Ve splátkových společnostech se jedná o telefonáty, e-maily, procesy odprodání balíků pohledávek atd

Data v segmentu

Zdroje dat (se zaměřením na objemné data):

1. Tvrdé core systémy - nejčastěji poměrně monilitické systémy
• u všech společností pak i vedení finančího účetnictví (SAP, mainframe based atd)
• banky - správa produktů, účtů, systémy pro platby kartami, bezhotovostní převody z/na účet, úročení, správa aktiv, deposit, zajištění
• splátkové společnosti - rozpis splátek, platby a jejich párování, přegenerování předpisů splátek, úročení
• pojišťovny - předpisy a platby - smlouvy a jejich rizika, alokace pojistného, správa pojistných rezerv
2. Systémy pro správu a obsluhu kampaní - jak bylo zmíněno, jedná se o velmi aktivní oblast, kampaň střídá kampaň, informace pro vyhodnocení, call listy, sběr výsledků
3. CRM/UFO integrační systémy - sice jsou prostředníky mezi přepážkou a backend systémy, ale současně jsou často i zdrojem klientských požadavků na změny produktů atd - klientské data, požadavky, záznamy o voláních, systému unifikace klientů (kandidátské a unifikované skupiny atd)
4. Karetní systémy - mnoho společností provozuje či využívá systémy pro kreditní a debetní karty - tyto představují neustále narůstající a trvale rostoucí data
5. Provizní systémy, systémy hodnocení partnerské sítě - pro člověka z jiného oboru možná okrajová data, ale pro ty
6. Vymáhání - u splátkových společností i u bank  jde o nedílnou součást primárního businessu, a jako taková generuje objemné data, od vyzívacích dopisů, telefonátů az po odprodej či přímé vymáhání pohledávek

Co s těmito daty ?

Nevybavuje se mi banka, pojišťovna či větší splátková společnost, který by neměla datový sklad s velmi širokým rozsahem. Právě finanční společnosti byli historicky první v ČR, které začali tvořit rozsáhlé BI řešení. V každé společnosti je nad DWH nasazen silný reporting, kvalita reportů a jejich nadpočet je věc druhá. Datové sklady nabývají na objemu, s ohledem na výrazný pokles ceny storage se neřeší data ageing,ale dokoupí se další rack se storage, takže běžný objěm je od jednotek TB po desítky TB u velkých bank. Dalo by se tedy říci, že je vše v pořádku. Poradím Vám, neříkejte to před zázstupci businessu v těchto společnostech. Samozřejmě výjímky existují a není jich úplně málo, je zde ale jedno velké ALE. 

Stávající datové sklady jsou používány a využívány, ale spíše tou "konzervativní" částí bankovního businessu (reporting, regulatorní reporting). Projektový management BI řešení je hodně rigidní a pro hodně lidí z businessu velkou zkouškou trpělivosti. Nebylo by ale fér shodit vinu jen na IT oddělení, zkrátka v těchto společnostech vše trvá dlouho (za výjímku z tohoto pravidla můžeme brát splátkové společnosti, ty trh nutí k vyšší rychlosti). 

Nejmenší spokojenost je na straně marketingu a produkt managementu, protože tyto útvary potřebují mnohem rychlejší reakci na jeich požadavky, i proto jsou tyto velmi často provozovateli partyzánských daatabází, kam jsou nahrávány informace ze standardního BI a obohacovány o potřebné informace, ať již pomocí klasických BI technologií, nebo formou skriptů pod gescí pracovníků těchto útvarů s technickými znalostmi.

Big data potenciál:

1. U existujících DWH vidím spíše potenciál využití big data jako podpůrnou agilní technologii, která je schopna v kooperaci se standardním BI saturovat akutní informační potřeby. Umožní pokrýt ať již formou sandboxingu, nebo formou poskytnutí báze dat v hadoopu pro data scientisty v útvarech marketingu, analýz, zákaznické podpory. Technologie dnes dostupné (zdarma) umožňují velmi rychlé a praktické propojení dalších ad-hoc zdrojů dat s těmito archivovanými datya provádění opravdových ad-hoc analýz (PIG, splunk, a další technologie)
2. Využití big data platformy jako on-line archivu detailních dat:

• Relační databáze BI je třeba zálohovat. Odhadem 60-80% dat v existujících BI řešeních jsou detailní data, která svojí povahou časově expirovala, ale drží se s heslem když je odarchivujeme, už nebudou dostupná a zítra pro ně někdo přijde
• Archivní data v hadoop zůstávají on-line dostupné pro expertní analýzy dlouhých časových řad i analýzy s potřebou procházet plný detail, hadoop poskytuje i silný výpočetní framework, který není tak těžké se naučit
• Zmenšení velikosti relační databáze o 60% představuje z pohledu nároků na čas zálohování, počet pásek, velikost zálohovacího okna velmi významnou úsporu - jak časovou, tak i přímou finanční (počet pásek na zálohu, počet mechanik s ohledem na velikost zálohovacího okna atd)
• Poměr ceny za GB na enterprise diskovém poli a na JBODu složeném ze  SATA III disků představuje potenciál úspory v desítkách milionů (v případě potřeby obnovy HW) + úspory lidské práce. Takže pokud má IT banky napjatý rozpočet, zde je možná cesta pro odložení velkých investic do dašího rozšíření enterprise diskových kapacit pro nenasytné BI. 
• Stejně tak porovnání ceny enterprise class serverů a komoditních serverů pro hadoop generuje úsporu, obzvlášt, když pro hadoop je možné použít vyřazené servery či low-end servery bez rizika ztráty dat díky vysoké redundanci dat v HDFS (posbírejte ty v marketingu, tak se jich typicky najde, a když budete hledat, najdete i další "kopie" datového skladu :) )

Kombinací výše uvedeného může firma dosáhnout stavu, kdy bude mít v big data technologiích umístěny nejen archivní, ale i aktivní data(D-1), a může jej pak použít pro agilní podporu oddělením, které nejsou spokojeny se standardními BI především z důvodu pomalého zavádění změn do BI. 

Tím lze v podstatě dosáhnout vyrovnané či spíše pozitivní nákladové bilance, protože lze použít HW poschovávaný v kancelářích nespokojených oddělení, kde běží pirátské datové sklady,  a který je možné po dohodě využít jako základ infrastruktury big data technologií a oddělení v podstatě. Uvolněné lidské zdroje  s technickými znalostmi v business odděleních je pak potenciálně možné transformovat na datové analytiky nad big daty. Oni se zbaví vysilující rutiny udržet multiTB databáze a současně jim dáte novou hračku, která jim umožní další profesionální růst...na jejich ochotu k této změně bcyh si klidně vsadil.

Je zde samozřejmě i scénář, že marketing a další oddělení, kde žijí tyto paralelní datové sklady, nebudou čekat na rozhoupání IT, ale překlopí tyto svoje "sklady" na Hadoop.  S ohledem na dostupnost technologií a počáteční nízkou nvestiční náročnost bych se vsadil, že už takhle pár Hadoopů někde v kancelářích esele hučí ventilátory :).

Závěr

Nezmiňuji zde jednu velkou oblast sběru informací ze sociálních médií, kde jsou big data používány ve světě, mám velkou obavu, že pokud bych měl jako vysoký šéf ve finanční společnosti posuzovat svoji firmu podle reakcí na sociálních médiích, tak bych ji rovnou zavřel. Osobně tomuto segmentu nedávám velkou váhu v kontextu české republiky, ať již kvůli penetraci sociálních médií mezi zákazníky těchto společností, tak i z dlvodu, že se občas diskuzí účastním a po 10 minutách znechucene vypínám, protože se diskuze zvrhávají do ideologických přestřelek a osobních invektiv.

V případě, že zástupci tohoto sektoru nevzali v potaz upozornění v úvodu a dočetli až sem, tak se:

- omlouvám těmto lidem za určitou paušalizaci, vím o mnoha zajímavých aktivitách, které zde ale nemohu uvést z důvodu existujících NDA, ale ruku na srdce, myslím, že jsem to popsal to, jak tyto firmy fungují z pohledu BI hodně realisticky

- pokud Vás výše uvedené myšlenky zaujali, budu rád, když mě kontaktujete, rád Vám pomohu utříbit si myšlenky a případně pomohu s přípravou podkladů atd pro Vaši prezentaci dovnitř firmy

Budu rád za Vaši reakci, přeji příjemný večer

Petr Šimbera

PS: Příští díl bude na téma big data v telco segmentu...

PPS: Odpověď na připomínky typu - proč to píšete v čestině - dva důvody - uvedené informace jsou nejvíce pravdivé a ověřitelné v kontextu ČR (je relativně málo BI řešení, které jsou velké a kolem kterých jsem v ČR přinejmenším neprošel, nebo o nich alespoň od kolegů neslyšel). Jistě, hodně těchto informací je univerzálních, ale upřímně, moje aktuální znalost angličtiny neobsahuje schopnost jemné i tvrdší ironie...pokud se někdo chcete ujmout překladu, klidně překládejte a publikujte, jen prosím nezapoměňte uvést originální zdroj (alespoň odkaz na můj linkedin :o) )

Aféra Big Data - odhalení (retail)

Potenciální využití big data v retail segmentu

Úvod

V retailu jsem již před nějakým časem tvořil datový sklad pro jeden velký řetězec. Protože už to je hodně let zpět, oživil jsme trošku své paměťové buňky a zkusil dát dohromady, a pobavil se i s pár zajímavými lidmi a níže uvádím oblasti, kde vidím potenciál využití big data pro retailové řetězce. V dalším textu se snažím o srozumitelnost i pro čtenáře, kteří jsou spíše kupujícími. Předem upozorňuji, že nejsem expert na procesy retailu, resp. je to už delší dobu.

Co je retail ?

Doporučuji projít si trošku Google, ale v principu - chodíme tam všichni, někteří z donucení, někteří za zábavou a "lákavými" slevami. Dost lidí v oboru i pracuje. Retail je v podstatě rychloobrátkový prodej ve velkém množství, s nízkými maržemi, ale velkým objemem prodejů, i proto se o něm mluví jako o rychloobrátkovém businessu - FMCG (fast moving cunsumer goods) - zkrátka potraviny, drogérie, část spotřební elektronicky (nosiče), ale z našeho pohledu můžeme do tohoto segmentu zahrnout i prodejce elektronicky, ať v kamenné podobě, ale i internetové.

Činnosti v retailu

Základní činnosti v retailu:

1. Obchod by měl vědět, co chce/bude prodávat - v běžném supermarketu najdete v databázi i desítky tisíc produktů (artiklů) - je poměrně těžké namíchat mix nákupů, který bude zajímavý a prodejný. znamená to průzkumy u lidí, tak konkurence, tak i výrobců.  

2. Obchod resp. jeho majitel musí dobře nakoupit - centralizované nákupy, jak říkal hlavní hrdina básníku - levně nakoupit, draze prodat. A nejlepší je, když mu ještě výrobce přispěje na to, aby byly jeho produkty ve velkých obchodech. Dříve listovné, zalistovací poplatek per artikl, dnes příspěvny na společnou propagaci produktů.

3. Dobrý obchod má snahu poznat své zákazníky - čím víc o zákazníkovi vím, tím lépe dokážu ovlivňovat jeho nákupní potřeby a chování

4. Samotný nákup  - stovky metrů a hledání oblíbených nebo akčních výrobků - ideálně pro prodejce, co nejdelší nákup, zoufalství, nakonec nakoupíte mnohem víc, než jste pvodně chtěli, a ideálně i pár prémiových produktů - váš prodejce Vás budemilovat

5. Pokladna - fronta - poslední příležitost Vám něco vnutit...pak nekonečné pípání a na závěr platba. Ideální zákazník je takový, který má zákaznickou kartu, proč vysvětlíme za chvilku

6. Správa zásob - ležáky a zboží, které se blíží spotřebě je nutné identifikovat, kvantifikovat, oblepit slevovými psákami a rychle prodat. Po překročení data spotřeby hrozí ztráta  a náklady na kafilerii 

7. Marketing - spousta analýz, co dát za zboží do reklamních letáků, a za jakou cenu, aby to přitáhlo lidičky, samozřejmě v kombinaci s potenciálmě splnění bodu 2 - jendím slovem je to alchymie na základě dat, průzkumů, sezóny atd

8. Logistika - zákazník musí najít svůj jogurt s danou příchutí, či oblíbené ovoce, protože jinak hrozí, že přístě půjde ke konkurenci. Cesta od výrobce na pult obchodu je poměrně dlouhá, trvá několik dní, při zahrnutí objednávky a času výroby jsme v rozmezí od několika dnů po několik týdnů. Na transportu a meziskladech se u nadnárodních řetězců podílí spousta poslečností = v kombinaci s počasím a odbory ideální kombinace sloužící jako generátor problémů  

9. Problematika householdu - opět poznání zákazníka resp. skupiny zákazníků  - stejné jméno a stejná adresa při registraci zákaznické karty Vás předurčuje k zařazení do householdu (skupina osob, které obývají stejný prostor, resp. vyjídají stejnou lednici a ideálně nakupují společně) 

10. Clustering produktů - statistické vyhodnocení nákupních košů a nákupního chování - asi nejzprofanovanější případ společného nákupu dětsých plenek a piva - opravdu to funguje za přepdokladu dostatečných vstupních dat

11. Rozmístění zboží na prodejně - čerpá informace z přechozích činností - primárním cílem je udržet zákazníka na "prodejním parketu" co nejdéle---jeho odhodlání neutrácet se postupně snižuje pod záplavou akcí...narůstá únava...už nebudu hledat mé oblíbené špagety, ale koupím ty, co jsou vystavené z čela regálů, což je typicky nejvýnosnější pro obchodníka...až se najde řetězec, kde bude zboží logicky uspořádáno s cílem minimalizovat čas potřebný k nákupu, budu jeho věrným zákazníkem...na druhou stranu asi dlouho nevydrží...

Data v retailu

Zdroje dat:

1.  Zákaznické karty = opakovatelná identifikace nakupujícího - relativně  maličko dat, ale obrovský význam pro výše uvedené činnosti - pověstná třešnička na dort

2. Záznamy o prodeji - konečně kandidát pro big data -  účtenky - představují obrovský objem dat, v současnosti společnosti moc nevyhodnocují, prodeje jsou typicky agregovány na úroveň den, prodejna, artikl, kusy. Přitom clustering produktů (nákupní košík) resp. vyhodncení korelac mezi produkty může být velmi cenný z pohledu, s rozšíření o segment zákazníka (household x příjmová skupina) v kombinaci s posledním střípkem - zákaznická karta...a máme Vás :). Záznamy o prodejích resp. účtenkách jsou doufejme někde archivovány, přeci jen, když už se dělá agregace, tak musí být z čeho. Předpokládejme, že data nejsou v centrále, ale lokalizovány na prodejnách

3. Zásoby - naskladňování - objednávka - naskladnění na prodejnu - zboží "na place" - relativně málo dat, protiváha k účtenkám - ale protože se naskladňuje po velkých baleních, tak přeci jen mnohem menší, než účtenky. Člověk by řekl že naskladnění - účtenky musí dát nulu...v E15 jsem si přečetl, že se ročně v ČR ukradne z obchodů zboží za 2 miliardy...tak to je ten rozdíl :)

4. Kampaně - letáky - hodně práce, a nakonec je z toho pár dvojlistů...nejdůležitější je časová platnost akce, lokalizace, a zpětná kontrola zásahu (zvýšení obratu na požadovaných skupinách sortimentu)

5. Logistika - intra i extra logistika - pracoval jsme pro jednu dopravní firmu, která zajišťovala mimo jiné zásobování supermarketů - naplánovat návozy na centrální sklady (několik v ČR) se závozy na prodejny (desítky až stovky v ČR) - zaměstnává to spoustu CPU a mnohem více lidí. Jeden příklad za všechny...možná nevíte, ale pivovary a výrobci nealko začínají už od cca února vyrábět na sklady, aby v létě zvládly nápory žíznivých krků...podobně vánoční sortiment...viz poslední čtvrtletí roku 2013 a mnoho diskutovaná intervance...obchodníci vykoupili velkoobchodní sklady během několika dní z obavy před pohybem koruny...

Co s těmito daty daty ?

Když už data potenciálně máme, resp. měli by jsme na diskutovaném hadoopu, jak by se daly využít ? 

Dost z níže popsaných věcí se dnes již realizuje, ale přesnost je ekvivalentní agregované statistice prodeje a tím snížení adresnosti a přesnosti akční nabídky.

Použijeme data pro standardní úlohy s rozšířením možností a přesnosti

1. Optimalizace zásobování resp. eliminace ležáků - téma i u firem z jiných segmentů trhu - optimalizace zásob a tím snížení rizika expirace zboží - korelace v rámci nákupního košíku (co se s čím kupuje v rámci jednotlivých nákupů v kombinaci s prodejním dnem a  dobou) a dlouhou časovou řadou - umožní firmě získat podklady pro optimalizaci naskladnění, takže ležák se ležákem nestane, protože ho na sklad nedovezeme :). Pro snížení objemu disponibilních zásob a minimalizaci převozů mezi prodejnami. Dnes je k dispozici pouze denní objem prodejů, což je suma za den a prodejní místo. Může to stačit, ale nemusí...

2. Vyhodnocení akční kampaně - když použiji na nákupní košík seznam produktů v akci, získávám informaci, jak moc je daný člověk zvyklý nakupovat věci v akci

3. Opět na bázi nákupního košíku - produkty v nákupním košíku rozdělené do skupin (food, nod food, fresh) mi opět dává korelaci, jaké kombinace produktů u mě zákazníci nakupují v rámci jednoho nákupu umožní mi to lépe strukturovat akční nabídku (kde slevit více, kde méně, kde naopak), abych docílil nákupo zboží, které chci výhodně prodat - znáte to - sleva není zadarmo :).

4. Korelace produktů v nákupním koši - pokud identifikuji produkty, které jsou klíčové pro prodej jiného výrobku, mohu akcí podpořit produkt, který zákazníka podnítí k nákupu dalších produktů - napadá mě příklad - nabídnu dobré víno, a k tomu prodám zákazníkovi sýry a lupínky, protože každý ví, že dobré víno je potřeba zajíst něčím dobrým...dodavatelů vína je přebytek, s dobrými sýry a šunkou je to horší, takže "skřípnu" dodavatele vína, nabídnu jej v akci, a zvýším cenu sýrů. Podobě těstoviny a omáčky na ně (i kečup se hodí). Podobně letní grilovací akce typu 3kg krkovice, k tomu basu piv, dřevěné uhlí do grilu a navrh pěknou zástěru, aby jsme se neumazali :). Můžete si říst, že na toho nepotřebuji znát strukturu jednotlivých nákupů, ale pak je to vyšší riziko a dojem může převládnout nad realitou...koupí 5 PET lahví levného piva a 2kg párků za 45Kč/kg...ale i to je korelace...pak jen musím znát strukturu mých zákazníků, abych neobjednal hodně krkovice, ale měl dostatek párků a plastáků na skladě.

5. Optimalizace nákup u dodavatelů - větší objem nákupu = lepší cena, ale musím mít jistotu, že prodám za zajímavou cenu, případně, pokud vím, že o daný produkt mají zákazníci zájem bez velké citlivosti za cenu, mohu v případě klíčové dodávky přeplatit jiného zájemce a ještě na tom v součtu vydělám.

6. Optimalizace akcí a slev  - řetězce se dostali do spirály, kdy zboží bez nápisu sleva = vysoké riziko neprodeje, enormní tlak na prodejní ceny...lepší segmentací nabídky slev (rozumněj postupné omezování rozahu a výše slev) bez vlivu na dosažený profit znamená potenciální cestu ven z této spirály...při znalosti korelace produktů mohu do slevy zařadit jen jeden výrobek, který je hojně nakupovaný a  který zajistí prodej i navázaných produktů (s lepším profitem). A nebo obráceně - hodně produktů se slevou, kde mě ale sleva nebolí a vím, že se těch produktů v daných dnech neprodá tolik...ale na letáku to vypadá zajímavě (někde jsem viděl nabídku na slevu na letní gumy na auto v polovině prosince - buď omyl, něbo někdo uvažoval stejně :)

7. Plán prodejů - podrobné časové řady prodejů produktů s vazbou na prodej další produktů umožňuje zpřesnit odhad a zvýšit pravděpodobnost úspěšného splnění plánu prodejů , resp. i vytvořit pravděpodobnější plán. Díky výpočetní síle a rozsahu dat lze přepočívávat každý den a případně korigovat navázané operace (pokud produkt nejde, tak snížit jeho zásobu i třeba odvolat objednávku, nebo přesměrovat na jiný obchod, kde scénář připravili lépe) 

8. Household - přepočet košů domácnosti (přes zákaznické karty) , řazení do zákaznických segmentů je výpočetně náročná úloha, a pokud by jsme používali účtenky v  dělší časové řadě,  budeme mít segmentaci i cistlivost householdu na změny cen jako na dlani...druhá věc je indikace členů domácnosti podle nakupovaných produktů (kojenecká výživa - malé dítě = pleny, olejíček, jídlo pro kočky nebo psy - super, mají zvířecího miláčka, pro obojí se peníze vždycky najdou. Vysoké procento zásahu do sorty akčního zboží za nejlevnější ceny, žádný jiný "normální" produkt  = důchodce s časem objet postupně více obchodů a koupit vše za slevy...?)

8. Nové cesty - úvaha, někde ve světě už realizují - když dáme na vozík senzor polohy a její uchování v hadoopu, propojíme s účtenkou (u pokladny) - v kombinaci s plánem prodejny a osazením produktů, získáme  mapu, kudy zákazník projížděl, přes jaké zóny, a co reálně nakoupil...při použití na masu dat umožní výhodněji rozmístit produkty s cílem dát zákazníkovi "pod nos" to, co víme, že bude chtít při daném scénáři průjezdu nakoupit, případně co chceme, aby koupil ...ze mě by moc moudří nebyli, vždycky "náhodně bloudím", odložím košík a chodím bez něj a jedu podle seznamu...:)

Samozřejmě dat je v retailu více, zmínil jsem ty dle mého nejdůležitější z pohledu objemu a významu. Stejně tak použití dat, zde ale předpokládám realističnost scénáře, ať již z minulé praxe, nebo z možnosti technologií a hledání souvislostní ve velkých objemech dat. 

Nejhorší pak je když po dlouhých analýzách přijdete s hypotézou za matadory businessu a oni Vám to rozstřelí jako broky holuba...ale to už je o konkrétních případech...

Budu rád za Vaši reakci...