Pomalu končí vánoční nakupovací horečka a sčítají se příjmy. V lednu začnou všichni nahánět lidi na slevách (takže si doma budeme zase říkat, proč ty vánoce neslavíme o 3 týdny později :)

Já se dneska trochu zanořím do nejlacinější metody používané v marketingu - RFM segmentace - která se používá pro cílení při oslovování zákazníků. Vnímám to jako vhodné téma na leden, kdy bude každá objednávka drahá. Pokud RFM segmentaci neznáte nebo neděláte, čtěte dál. 

RFM segmentace není nic jiného než rozčlenění zákazníků do tří kategorií, podle:

• doby od posledního nákupu (Recency)
• počtu nákupů (Frequency) 
• celkového objemu utracených peněz (Monetary)

Představte si, že máte 3 prádelní šňůry, jednu pro každou kategorii. Na Monetary šňůru pověsíte jména zákazníků vzestupně, podle útraty, na Frequency šňůru vzestupně podle počtu objednávek a na Recency šňůru dáte na jednu stranu ty zákazníky, co už dlouho nenakoupili a na druhou stranu naopaky ty, co nakoupili před chvilkou.

Pak si každou šňůru rozdělíte na dílky (segmenty), které očíslujete od jedničky směrem nahoru. Jednička znamená nejméně význaný segment (nízký obrat, málo nákupů nebo dlouhá doba od poslední objednávky - mrtvý zákazník). Jakmile to máte, začnete se na svoje zákazníky dívat optikou segmentů a jejich významů. Odteď zahodíme šňůry a všechno si vyneseme na kostku, která má na každé hraně vždy jednu kategorii:

Když se pak podíváte na jednu stěnu kostky, budete mít skupiny zákazníků, kteří vyhovují dvěma segmentům. Například zákazníky, co nakupují hodně často (Frequency), ale realizují nevýznamné objemy peněz (Monetary). Nebo zákazníky, kteří se významnou měrou podílejí na vašem obratu (Monetary), ale je to docela dlouho, kdy naposledy nakoupili (Recency).

Pohled na Recency/Frequency kategorii pak dělá takovou “heatmapu”:

Frequency 5 znamená “nakupuje hodně často” a Recency 5 znamená “nakoupil nedávno”. Cílem je mít k dispozici konkrétní seznam zákazníků, kteří jsou uvnitř každého čtverečku heatmapy + samozřejmě dobře rozumět specifiku daného segmentu. Existuje spousta pouček, jak se na jednotlivé segmenty koukat. Podobně jako u bostonské matice existují označení jako “Dojná kráva”, “Bídný pes”, apod. má RFM segmentace svoje klasifikační pojmy (loajální zákazníci, velký spendři, nový dojný krávy, …). Pro každý z těchto pojmů pak existuje přehršel rad, jak se chovat (těmhle popřej k narozeninám, na tyhle prď úplně, tyhle pozvem na golf, aj.). 

V RFM segmentaci je ohromné kouzlo - hlavně proto, jak je to celé (v dobrém slova smyslu) primitivní věc. Seřadit zákazníky na “šňůru” dovede každý, jedinou otázkou zůstane, jak se definují jednotlivé hranice mezi segmenty. 

Můžete na to použít věci jako je IBM® SPSS® Modeler, který vám vysype "machrovací" grafy, podobné tomuhle:

a nebo si to uděláte na koleně doma. Je pár věcí, které je dobré vzít v potaz, jinak budou výsledky RFM segmentace tristní, resp. nebude snadné vydělat jejím použitím peníze.

Významy R/F/M kategorií

Největší význam přikládejte zákazníkům podle doby od posledního nákupu (Recency), pak četnosti nákupů (Frequency) a teprve nakonec podle celkového obratu (Monetary). Je dobré přiřadit každému zákazníkovi zároveň nějaké jednoduché skóre, díky kterému budeme schopni plošně určit, který zákazník je nejhodnotnější, aniž se díváme na dimenze RFM. Jestliže máme v každé kategorii například 5 skupin, pak každému zákazníkovi můžeme přiřadit skóre od 1,1,1 do 5,5,5. Zákazník, který bude v kategorii Recency v segmentu 4, u Frequency v segmentu 2 a v Monetary 3, dostane skóre 4+2+3 = 9. Abysme neměli tisíce zákazníků oskórovaných pouze 125 hodnotama (počty kombinací při 5ti segmentech na každou kategorii), použijeme pro skórování ještě “váhy”. Váha bude jiná podle toho, zda je zákazník na spodní nebo horní hranici segmentu. Pokud bych měl Frequency segment pro zákazníky co nakoupili 5x až 8x, bude váha zvýhodňovat ty co nakoupili víckrát a diskriminovat ty co nakoupili méněkrát. Je vhodné, aby váha byla u Recency obecně větší než u Frequency a u Frequecy větší než u Monetary - tím se zároveň zvýhodňuje důležitější kategorie.  Vzoreček by mohl být takovýhle:

RFM Skóre Klienta = (Recency segment x Recency váha) + (Frequency segment x Frequency váha) + (Monetary segment x Monetary váha)

Seřazení všech klientů podle RFM Skóre nám pak umožní (obecně) ukázat na 20% nejhodnotnějších zákazníků.

Hranice segmentů 

Velkou otázkou tvorby RFM segmentace je jak definovat hranice jednotlivých segmentů (kdy je Recency 2 a kdy už 3). Konstatovat, že ten kdo nakoupil 6x je v jiném (méně hodnotném) segmentu než ten, kdo nakoupil 7x, není vždy úplně snadné. Můžete za sebe nechat rozhodnout robota, ale mozkové cvičení na tohle téma vám jedině prospěje a s RFM segmentací pak budete lépe pracovat. Navíc platí, že na to neexistuje správná odpověď (=automat to neudělá lépe než vy) a tak jediné co vám zbyde, je si to nakonec stejně otestovat. Nuže, více variant pro různé situace a následně praktické použití (direct mail, etc.) je jediná - i když trochu trnitá - cesta.

Správné segmenty by měly mít jisté charakteristiky:

1. podobnost v rámci segmentu - neměli byste si později klást otázky, jestli daný typ mailu pošlete všem v rámci jednoho segmentu nebo jen části zákazníků.
2. rozdílnost mezi segmenty - pokud se zákazníci v jednom segmentu podobají zákazníkům v jiném segmentu, je jeden ze segmentů zbytečný. Může se nám stát, že časem někde vypozorujeme velkou podobnost a segmenty se rozhodneme sloučit, nicméně by mezi nimi měl být od začátku jasný rozdíl.
3. ověřitelnost v čase - segmenty budeme používat pro plánování kampaní a srovnávání výsledků v čase. Chceme být schopni srovnat výsledky jednoho segmentu mezi dvěma kampaněmi a/nebo v časovém odstupu. K tomu potřebujeme stabilní RFM strukturu - časté měnění hranic mezi segmentama je problém.
4. dostatečná velikost - segment, ve kterém máme jednoho zákazníka je k ničemu. V každém segmentu by měl být vyvážený počet zákazníků, přičemž problém “3 extrémě silných (monetary) klientů” vyřešíme tím, že je prohlásíme za “příliš odlehlé” a vřadíme je do největšího segmentu (M5), ale hranice toho segmentu podle nich nekalibrujeme. Přesto se snažíme mít segmenty vzájemně co nejvíc shodné - toho docílíme laděním hranic.

Princip definice segmentů

• Recency - vezmeme jednoduše datum poslední objednávky. Říká se, že “Recency” je nejsilnější určení toho, kdo nejspíše nakoupí. U toho kdo nakoupil tento týden, máme větší šanci na prodej, než u toho, kdo nakoupil před 1/2 rokem. Tenhle fakt je základním dogmatem direct marketingu a tady ho budu považovat za axiom a nebudu to obhajovat.
• Frequency - stejně jako u doby od posledního nákupu, máme s frekvencí jistotu, že toho kdo nakoupil 3x zlomíme ke čtvrtému nákupu spíš, než prvokupce ke druhé objednávce. Pokud máte dost dat, nedává asi smysl použít celoživotní historii objednávek, protože to dává zbytečně velkou váhu aktivitě v dávné minulosti. Velmi staré objednávky nejsou dobrý indikátor budoucí aktivity. Doporučuju použít fixní okno směrem dozadu od poslední objednávky - třeba 3 roky transakcí. Pokud někdo naposledy objednal před rokem, podíváme se na jeho objednávky od teď 4 roky dozadu. Objednal-li někdo naposledy před 5 lety, podíváme se na 8 let dozadu.
• Monetary - objem peněz je nejslabší ukazatel budoucí ochoty znovu objednat. Nepoužíváme celkovou hodnotu objednávek (CLV) - to příliš koreluje s jejich počtem. Lepší je použít průměrnou velikost objednávky ze všech objednávek, použitých ke spočítání Fequency kategorie. To nám z peněz udělá víc nezávislou proměnnou. Monetary ve svém malém dopadu na uskutečnění další objednávky mohou skvěle sloužit ke dvoum věcem:
• zákazníky, kteří mají shodné Recency nebo Frequency rozdělíme tak, že ti s větším Monetary budou mít větší hodnotu
• izolujeme zákazníky s příliš malou hodnotou - pokud by měl někdo “Monetary” ve výši ceny direct mailu, nebudeme ho asi chtít kontaktovat

Praktické nastavení

Není nezbytné mít ve všech dimenzích stejný počet segmentů. Naše segmentační “kostka” může být klidně kvádr o hranách Recency 5x, Frequency 5x a Monetary 3x. Pokud vám to nedává smysl, netlačte se do symetrických kategorií!

Pro Recency kategorii je dobré mít jemnější dělení pro čerstvé nákupy, zatímco zákazníci aktivní naposledy před 2 až 2.5 lety mohou být klidně v jednom společném segmentu. Sami si na začátku vymyslete hranice, přičemž zkuste vnímat, že Recency 1 a Frequency 1 je nový zákazník (koupil “nedávno” a celoživotně jen jednou). Kolik chcete, aby uběhlo času od prvonákupu, když takový segmentu budete oslovovat? 2 dny? Týden? Měsíc?

U Frequence je to podobné jako u Recency - nejnovější zákazníci vyžadují speciální zacházení, aby znovu nakoupili. Pokud přesvědčíte zákazníka s frekvencí 2, aby nakoupil znovu, máte ho nejspíš na doživotí. Zákazníci s frekvencí 3+ jsou vaše tvrdé jádro. Frekvence by tohle měla precizně rozlišovat.

Přesné nastavení Monetary je u každého úplně jiné - je třeba správné hranice hodně hledat. Pokud nemáte žádné lepší podněty, začněte s průměrnou objednávkou (Average Order Size  - AOS) a udělejte si 3 monetary segmenty: méně než polovina AOS, více než polovina a méně než 1.5 AOS a více než 1.5 AOS. Pokud je průměrná objednávka 450,- Kč, budete mít hranice (M1) 0,- Kč až 225,- Kč, (M2) 225,- Kč až 675,- Kč a (M3) 675,- Kč a více. Můžete si udělat ještě skupinu “pod 50,- Kč”, kam dáte extrémně nízké nákupy.

Vylepšování

• “Co prodávám” - zákazníci kupující rozdílné druhy produktů (produktových linií) se chovají rozdílně. Je dobré udělat RFM segmentaci zvlášť pro každou produktovou linií vašeho katalogu a odděleně ji vyhodnocovat.
• Druh zákazníka - zákazníci jsou z různých prostředí, firmy mají v ČR NACE kódy, v americe jsou na to SIC kódy. 
• Velikost zákazníka - zákazníci různých velikostí se budou malinko jinak chovat - firma s 10 lidma nejspíš nemá oddělení procurmentu, takže se jí prodává snáze než firmě o 500+ zaměstnancích. Je dobré si s tím hrát. Můžete si na začátku rozdělit zákazníky do 2 skupin. Třeba 0 až 4 zaměstnanci a 5+ zaměstnanců - a sledovat pro tyhle dvě kategorie RFM segmentaci zvlášť. 

Pro zanořování se do dat je vhodné mít flexibilní systém, který umí data míchat a transformovat (Keboola Connection) a BI nástroj, díky kterému budete schopni segmenty kroutit, prohlížet, filtrovat a těžit - pro zjištění, zda se reakviziční kampaň na "chovatele zvířat za účelem výroby kožešin” (NACE kód 014920, 479 ekonomických subjektů v ČR) v segmentu (R2, F5, M3) vyplatila, už Excel nestačí a přichází GoodData. Doplňkový pohled přes vaší penetraci trhu a sledování toho, jak se chová saturovaný tržní segment, je už třešnička na dortu :)

Závěr

Statická RFM segmentace vám bude (skoro) k ničemu, desktopové programy typu SPSS vám sice udělají "kvalitní" segmentaci, na kterou ale nenapojíte dodatečné informace. Pokud navíc nerozumíte pravidlům, podle jakých byly jednotlivé segmenty definovány, nebudete nejspíš schopni výstupy správně zapojit do vaší marketingové strategie. Navíc věřím, že je třeba s nastavením experimentovat a nenechat si “to nastřelit automaticky” = pusťte se do toho s vervou a na vlastní triko, mozkové cvičení kolem definice segmentace byste neměli outsourcovat na dodavatele.

Pokud uděláte úkrok stranou a podíváte se na RFM segmentaci trochu z nadhledu, dá se to celé obalit spoustou buzzwordů typu "Predictive customer scoring", "Anti-churn detection", "Advanced segmentation", atd… 

Jednorázovou RFM segmentaci si snadno uděláte "doma na koleně", pokud ji ale chcete zapojit do všedního rozhodování, potřebujete ji mít součástí vašeho BI řešení. Kvalitní ukázka toho, jak jde obyčejné RFM nafouknout na "maximum", je Futurelytics.com - startup, který z mého pohledu utáhl pár lidí na vařenou nudli, nicméně jejich marketingová exekuce RFM segmentace je brilantní a za to jim určitě patří poklona. Jsem zvědavý, kolik startupů v “datovém” kole StartupYardu přijde s něčím podobným - je to za málo peněz hodně muziky :-)

Hezký povánoční segmentování!

Kvůli datům jsme ještě nikoho nevyhodili, odhaluje Michal Buzek zákulisí Business Intelligence v Seznamu

Minule jsme se v rozhovoru s hlavním analytikem Seznamu Michalem Buzkem dozvěděli, že se investice do datové analytiky mnohonásobně vrátila za pouhé tři měsíce.

Tentokrát se podíváme na to, jak GoodData mění fungování obchodních týmů, jak ovlivňuje chod firmy, a jak se bude rozvíjet práce s daty v Seznamu v nejbližší budoucnosti.

Dostáváte z GoodData odpovědi i nad rámec běžných reportů?

Co je běžné? To, že mají obchodníci mnohem lépe přečtené své klienty, je podle mě k nezaplacení. Dnes víme, že klient u nás sice investuje desetitisíce, ale za billboardy v tom samém období utrácí miliony. Kromě toho pracujeme se sezónností i s oslovováním podle oborů činnosti. Umíme také rozebrat portfolia obchodníků i obchodních týmů, a nacházet v nich klienty, kteří si zaslouží větší péči. To jsme mohli dělat (a občas dělali) i dříve, ale dnes je to nepoměrně rychlejší a snazší.

Myslím si, že klíčem není jeden všespasitelný report, který nám otevře oči, ale sada praktických reportů, které jsou vždy při ruce, a které pomáhají v každodenní práci.  

Jak se s tím obchodníci sžívají?

Párkrát jsem v Seznamu slyšel, že obchodník má obchodovat, ne se hrabat v tabulkách. Proto jsme reporty a grafy vyladili tak, aby byly pro obchodníky jasné a čitelné na první pohled. GoodData se díky tomu stala téměř každodenním nástrojem obchodníka před schůzkou s klientem. Zjistí v něm jeho mediální strategii, inzertní vývoj, zvyklosti a spoustu dalších dat.

Pomohla analytika i těm, u kterých bys to nečekal?

Někdo se v datech našel, jiný si k nim zatím hledá cestu. Ale letos jsem mezi obchodníky zaznamenal velký hlad po informacích. U některých jsem to opravdu nečekal. Těší mě, že GoodData není nástrojem jen pro vedení a vyšší management, ale že z něj dokáže čerpat užitečné informace i řadový zaměstnanec.  

Propustili jste už někoho na základě zjištěných dat?

Zatím ne, nebo o tom nevím :-) Musím ale říct, že obchodní projekt v GoodData umožňuje manažerům mnohem lépe kontrolovat své lidi.

Jak konkrétně?

Manažer například u každého klienta vidí objem nasmlouvané inzerce a počet návštěv obchodníka. Pokud klient uzavřel za poslední rok objednávky za 50 tisíc a obchodník u něj byl 15x, tak je asi něco špatně. Naopak je chyba, když u klienta s inzercí nad dva miliony vidíme v historii komunikace pouze jeden záznam. Buď je obchodník megaborec, nebo kašle na doplňování záznamů ze schůzky.

A využívají to manažeři, nebo o té možnosti jen ví?

Využívají. Pomocí podobných přehledů mohou se svými lidmi mluvit mnohem konkrétněji. Hned je vidět, kam chodí obchodník zbytečně a na co by se měl naopak soustředit. Nesmí se to samozřejmě přehánět, ale od manažerů na to slyším docela chválu.

Změnila datová analytika chod Seznamu?

Většina lidí z firmy dnes ví, že jediná správná a důležitá čísla jsou v GoodData. Top management tam má potřebné informace k řízení firmy, produktoví manažeři zde sledují KPI a plnění svých služeb, controlling zase náklady a výnosy, obchodní manažeři výkon svých týmů a klientů, PR oddělení statistiky ze sociálních sítí…

Obrací se na vás s požadavky na reporty i lidé z dalších oddělení?

Ano. Je skvělé, že v Seznamu funguje šeptanda – v posledním měsíci za mnou přišli třeba kluci z Skliku, manažer mobilní reklamy nebo plánovačka mediálního prostoru, kteří viděli u někoho jiného užitečné reporty v GoodData, a chtějí teď připravit své vlastní. Vidí, že jim to může v práci skutečně pomoci.

Kolik lidí u vás dnes používá GoodData?

Okolo 75, z toho něco málo přes 50 dělá obchod. Někteří manažeři ale připravují z GoodData podklady pro své lidi v XLS nebo PDF, takže s reporty ve finále pracuje ještě mnohem vice lidí.

Našly si výstupy z GoodData cestu i na porady?

Na poradách nejvyššího managementu jsou reporty z GoodData standardem už několik let. Sledují zde vývoj tržeb, nákladů, zisku, plnění ukazatelů vůči plánu a podobně. Na poradách obchodních týmů se zase řeší hlavně reporty s monitoringem inzerce, historií komunikace nebo inzertní výkony na konkrétních reklamních produktech. Pak se v Seznamu pravidelně setkávají i zástupci služeb, obchodu a marketingu, a sledují vlastní KPI.

Co pokládáš za největší přínos řešení GoodData/Keboola?

Přínosů jsem už zmínil spoustu, radši řeknu, co těší mě osobně. Největší radost mám, když vidím, že to lidé ve firmě skutečně používají, a že jsou doslova hotoví z dashboardů, které jsme jim připravili. Přitom jsou to často data, která v Seznamu byla i dříve, jen ne jednoduše zobrazená na jednom místě a s možností detailního zkoumání.

Máš nějaký oblíbený report?

V jednoduchosti je síla. U obchodníků nejvíc boduje tabulka nabitá užitečnými informacemi – v řádcích jsou klienti, ve sloupcích jejich ceníkové útraty na Seznamu a mimo Seznam. Jsou nadšení, když si jednoduchým klikem na částku ve sloupci zobrazí, kde přesně klient inzeroval, a co propagoval.

Já osobně mám rád záložku se dvěma vývojovými grafy. Levý ukazuje objem klientových investic do reklamy v ceníkových cenách z databáze monitoringu inzerce, pravý objem ve skutečných cenách z obchodního systému Seznamu.

V ukázce vidíte, že klient v roce 2013 čile inzeroval – ale ne na Seznamu. Díky datům jsme to odhalili a obchodníkovi se v říjnu podařilo vrátit Seznam do hry.  

A co dál? Máš nápady, kam to celé posouvat?

Mým cílem je pomoct vybudovat v Seznamu supervýkonné obchodní oddělení. Jak řekl kdysi náš obchodní ředitel – měli bychom posílat obchodníky za správnými klienty ve správný čas a se správnou nabídkou.

Jak tomu podle tebe pomohou data?

Chci, aby obchodník v GoodData viděl sám sebe, a bez dalšího filtrování i klienty, které má přednostně oslovit, protože u nich má větší šanci na obchod. Pomohlo by taky rozšíření o další datové zdroje a ještě podrobnější segmentace klientů. A důležité je i vzdělávání – teď připravujeme workshop pro obchodní manažery, aby dokázali pro řízení z GoodData vyždímat maximum informací.

Dokázal bys ještě fungovat bez GoodData a Keboola Connection?

Pokud bys mi nabídnul minimálně stejně vybavený nástroj za poloviční cenu, tak jo :-) Ale jsem realista. Kdyby bylo na trhu něco lepšího, už bych to věděl. Do dob Excelu, Accesu a sosání dat z databází bych se už ale vracet nechtěl.

Cítíš se díky datové analytice pro firmu přínosnějším?

To je strašně těžká otázka. Snažím se, aby to tak bylo. Přínos ale nezávisí jen na mně nebo na klucích, kteří na GoodData dělají se mnou. Důležitá je i podpora práce s daty u vedení obchodního oddělení i u celé firmy - jak se získané informace využijí v praxi. Myslím, že se nám daří stále vice lidí v Seznamu přesvědčovat o hodnotě dat. A tím snad roste i význam analytického oddělení.

Počkej, tak snadno mě neodbudeš - zvedla se i tvá hodnota na trhu práce?

Do CV si to určitě přidám, až bude potřeba :-) Byl jsem u úplného začátku implementace GoodData v Seznamu, jsem schopen v Keboola Connection připravovat datasety a stavět datový model. Nejsem žádná hvězda, ale nějaké zkušenosti jsem posbíral. I kdybych to už nepotřeboval, tak mě poslední roky s GoodData a Keboolou fakt bavily.

Šel bys do toho znovu?

Každopádně. Pokud někdy skončím v Seznamu a nějaká jiná firma bude chtít, abych se jim pohrabal v datech, tak to v Praze určitě vezmu přes Karlín.

Empiricky jsem v minulém týdnu ověřil, že náhodný vzorek studentů na VŠ nezná tak super věc, jako jsou reporty s "Cohortama". Takže děcka:

Kohort Analýza není typ reportu ale spíš reportovací technika. Kohorta je skupina objektů, které sdílejí jednu společnou vlastnost. Je to velmi jednoduchá věc s velkým potenciálem, která jde dělat nad jednoduchou tabulkou. Cílem téhle analýzy je rozkrýt trendy právě přes dimenzi těch společných vlastností.

Mějme tabulku předplatného, kde je ID transakce (platba každý měsíc), ID předplatitele, Datum ve kterém předplatné vzniklo, Datum kdy jsme se se zákazníkem prvně potkali a cena kterou předplatné v daný měsíc stálo:

Je-li kohortou moment vzniku předplatného, můžeme si pak veškerý náš měsíční příjem "obarvit" měsícem vzniku předplatného. Tady je to vyjádřené v % - tedy kolik procent našeho obratu tvoří předplatitelé, které jsem získali v daném měsíci:

Vypadá to trochu jako hezká tapeta, ale když se podíváte na červen 2012, můžete vidět, kolik obratu nám dělají lidi, které jsme sehnali (zobchodovali) v březnu 2011.  

Tady je vidět jak to vypadá u služby SEOmoz (dnešní moz.com). Moz.com je služba placená měsíčně. Někdy kolem března 2009 se rozhodli dát novým lidem službu na 3 měsíce zadarmo. Reakcí na to byl ohromný zájem - a služba okamžitě zdvojnásobila svojí uživatelskou základnu. Jakmile akce skončila, polovina uživatelů zase odešla. Vypadalo to takhle:

Kohortou je tady, stejně jako v horním příkladu, měsíc registrace. Y-osa (vlevo) pak ukazuje počet uživatelů. 

Pokud se na to celé podíváme optikou peněz, dostaneme trochu jiný pohled:

Je krásně vidět, že nárůst uživatelů po dobu "akce" nevedl k žádnému zásadnímu zisku. Jakmile ale akce skončila, masivně se zvedl příjem služby - asi o $100k/měsíc. 

Rada na závěr: společný atribut může být téměř cokoliv, datum registrace, "tag" marketingové akce nebo nějaká jasně definovaná incentiva, kterou pro lidi děláme. Díky zobrazeným kohortám pak můžeme poměrně snadno získat povědomí, "co se nám vyplatí pro uživatele dělat". Pokud plocha toho modrého pruhu z posledního obrázku bude v čase větší než náklady na akviziční akci, vyhráli jsme. Známe-li navíc metriku CLV (client lifetime value), můžeme to celé zohlednit v souvislostech. Pak získáme odvahu k (drahým) akcím typu: "hej, pozveme kravaťáky na golf, oni si pak něco koupí".

Howg!

UPDATE 2013-12-10: Pavel Jašek v komentáři na facebooku doplňuje další info k CLV metrikám na své prezentaci na SlideShare

Investice do Business Intelligence se nám za tři měsíce vrátila desetinásobně, říká Michal Buzek, hlavní analytik Seznamu

Zítra mám v GoodData ekosystému 4. narozeniny. 

Za tu dobu jsem stihl odpracovat přes 12.000 hodin práce, naučil se jinak o věcech přemýšlet, probděl nespočet nocí, trpěl komunikací přes mnoho časových pásem, poslal stovky supportních ticketů do GoodData a zpracoval desítky zákaznických projektů. Ale hlavně jsem poznal spoustu skvělých lidí a naučil se obrovské množství zajímavých věcí, který mě posunuly o notný kus dopředu. 

Přeju si, aby se mi dařilo Keboolu udržet stejně svěží, svobodnou a nadšenou. Aby se dál neevidovala docházka, přestala počítat dovolená, vývojáři se nehádali s analytikama, z poza oceánu lítalo míň Zendesk ticketů a klienti stále psali jen spokojené dopisy.

Nic z toho by ale nikdy nevzniklo, nemít doma trpělivou Alenu, nebýt lidí v GoodData, kteří nám nesmírně pomáhají, nebýt našich klientů, kteří nám důvěřují a hlavně nebýt skvělých lidí v Keboole, který mi pomáhají táhnout tuhle káru dál.  

Jsem vám všem za to moc vděčnej,

Díky!

Amazon Kinesis je služba v rámci Amazon Web Services (AWS), která umožňuje zpracování jakýchkoliv dat v reálném čase. Aktuálně běží v neveřejném režimu a přístup k ní se schvaluje žádost po žádosti (moje žádost trvala asi 2 dny).

K čemu to je?

Zatím to zkoumám, ale nevypadá to jako něco moc revolučního. V podstatě jde o to, že Kinesis pro nás provozuje frontu na data, do které může padat cokoliv odkudkoliv a jakoukoliv rychlostí. My si musíme napsat aplikaci, která si z fronty data bere, něco s nima dělá a vrací je na výstupu (třeba zase do jiné Kinesis fronty). Kinesis samotný s psaním aplikací na zpracování dat nijak moc nepomáhá. K dispozici je SDK pro Kinesis - tedy obalené funkce typu GetNextRecords. 

A konkrétní příklady?

• zpracování logů
• analýza dat v reálném čase
• odchycení a zpracování dat ze sociálních sítí
• analýza finančních transakcí
• gaming analytika
• strojové účení

Kolik to stojí?

Kinesis se, stejně jako všechno ostatní v AWS, platí po hodině provozu za provozní jednotku (shard). Jeden shard zvládne přijímat data rychlostí 1MB/sekundu a odesílat rychlostí 2MB/sekundu. Aktuálním limitem na jeden vložený datový objekt je 50kB. Text tohohle blogpostu by jeden "shard" zvládl přijmout zhruba 500x/sekundu. Cena ze tenhle nejmenší "shard" je $0.015 za hodinu. Další a poslední cena je za vkládající operace. Jeden milion vložení (přijetí) datových objektů stojí $0.028. 

Když bych zůstal u objemu tohohle blogpostu a řekl, že má 3.5kB, pak kdyby chodil do Kinesis takovýhle text 300x/sekundu celý měsíc, stálo by to:

• 1 shard = $11.16 / měsíc
• vložení textu 500x/sekundu = 803.520.000 vložení za měsíc = $37,49 / měsíc (vložení = příjem jednoho blogpostu)

Suma sumárum

Největší přidanou hodnotou je tedy hlavně držení streamu dat, o který se nemusíme starat. Bude to možná poměrně konkurence pro Pusher. Pro Keboola Connection je to hlavně příležitost - de-facto na podobném principu dávno fungujeme a Kinesis nám může pomoct "zpevnit základy". 

Znovu se tedy potvrzuje to co jsem psal na konci staršího blogpostu - nejenom díky Kinesis si můžeme troufnout na náročnější projekty a cítit se v Cloudu silnější. 

K vidění na Kinesis zatím moc není, tady je promo video a odkazy na dokumentaci. Přikládám screenshoty z aktuální Management Console.

Ať se snažím jak nejlépe dovedu, vždycky mám problém vysvětlit lidem, co neprocesujou data, co Keboola dělá. 

Potřebovali jsme vyrobit obyčejnou prezentaci, která bude poslatelná emailem a čitelná pro normální lidi. Mámo, táto, to je i pro vás! :)

Credits jdou za Pavlem a Lumírem.

Z kraje léta spustila GoodData do ostrého provozu svůj nový analytický engine AQE (Algebraic Query Engine), který má oficiální produktové jméno GoodData XAE. XAE je ale určitě čínsky “podviživený kuře”, takže já zůstanu u AQE :-) Od prvního momentu je to pro mě věc s největší přidanou hodnotou - když mi to Miki ukazoval, zamiloval jsem se na první dobrou :-)

Úvod lehce ze široka

Každý systém, který má ambice vizualizovat data, potřebuje nějaký matematický aparát. Pokud jako vstup budu mít prodané položky a jména obchodníků a budu z toho chtít zjistit medián obratu obchodníka, musí nejprve někde na pozadí proběhnout sečtení všech prodaných položek v daném měsíci pro každého obchodníka a nad tímto výsledkem pak můžeme počítat medián. Levá tabulka je surový vstup, pravá je odvozená za pochodu a většinou si ani neuvědomujeme, že takové mezi výstupy vznikají. Nad tou pravou pak můžu počítat věci jako nejlepší obchodník měsíce, průměrný/“mediánový”, aj.:

Pokud nemám robustní analytický backend, nemůžu si dovolit dělat “co mě napadne”, ale musím uživatele svázat do nějakých předpřipravených “vertikálních” analýz (churn analýza zákazníků eshopu, RFM segmentace, kohorty předplatného, aj.). Vrtat se v datech je možné mnoha způsoby. Kromě GoodData, které tady chystám vyvrcholení :), máte na trhu BI nástroje jako Birst, Domo, Klipfolio, RJMetrics, Jaspersoft, Pentaho a mrtě dalších. Vypadají super! O některých z nich jsem se otřel dříve. Osamocený datový analytik pak ještě sáhne po Rku, SPSS, RapidMineru, Weku, aj. - ale to nejsou BI nástroje. 

Většina ze zmíněných BI nástrojů nemá propracovaný matematický aparát, takže vám umožní čísla sečíst, spočítat četnost prvků, zjistit maximum, minimum a průměr. Tady je to krásně vidět na promo videu RJMetrics.

Systémy jako je Domo.com nebo KlipFolio.com pak řeší problém absence matematického aparátu trochu trikem. Lidem nabízejí spoustu matematických funkcní - jak v excelu - které jdou ale aplikovat na jednotlivé tabulky, ale ne na celý datový model. Někdo si řekne, že je to jedno, ale opak je pravdou - tohle je prubířský kámen všeho kolem datové analytiky. Zkusím vysvětlit proč.

Hranice našeho pískoviště stojí na aplikaci zákona o zachování "business energie”: 

"pokud nedokážeme našemu zákazníkovi vydělat větší peníze než ho naše služby (a licence GoodData) stojí, nebude s náma spolupracovat"

Pokud vezmeme výpis faktur ze SAPu a nakreslíme graf “jak to roste”, poženou nás zákazníci jako sedláky u Chlumce. My potřebujeme trochu víc, potřebujeme dávat za pochodu jednotlivé datové dimenze do souvislostí (dimenze = tématický soubor dat, nejčastěji reprezentovaný jako tabulka dat - dimenze mezi sebou nemusí mít žádné jasně definované vazby; tabulku v analytickém projektu nazýváme datasetem). 

V momentě, kdy dáme jednotlivým dimenzím souvislosti, vznikne logický datový model. Logický model popisuje “business” souvislosti a často není shodný s technickým modelem, ve kterém ukládá data nějaký systém. Pokud má například Mironet e-shop, je databáze za tímto eshopem optimalizovaná pro potřeby e-shopu, nikoliv finanční, obchodní a/nebo subscription analytiky. Čím složitější je prostředí, jehož data se analyzují, tím méně podobností mají technické a analytické datové modely. Nízká (strukturální) podobnost zdrojových dat a dat, které potřebujeme k analýze, vyřazuje většinu GoodData konkurence. 

Dám příklad na našem interním projektu. Interní projekt jsem vybral proto, že obsahuje logický model, který potřebujeme používat sami pro sebe. Není to tedy uměle nafouklé “protože to zákazník zaplatí”.

Do GoodData nahráváme různé tabulky, které jsou spojené vazbama. Vazby definují logický model; logický model pak definuje “co jde s daty dělat". Náš interní projekt slouží k měření naší vlastní aktivity a spojuje data z českého účetnictví (Pohoda), kanadského účetnictví (QuickBooks), z vykazovací cloudové aplikace Paymo.biz a několik Google Drive dokumentů. V interním projektu máme 18 datasetů a 4 datumové dimenze.

Obecnější model vypadá takto a detailní model vypadá takto. Červeně jsem označil jméno klienta, černě jméno našeho analytika a modře odpracované hodiny. Chci tím ukázat, že jsou jednotlivé související informace v projektu bohatě rozprostřeny. Díky vazbám GoodData ví, co dohromady dává smysl.

Nad tímhle modelem stavíme dashboardy, ve kterých sledujeme, jak nám jde práce od ruky, srovnáváme mezi sebou měsíce, lidi, druhy práce, koukáme na náklady a výnosy, aj.

Cokoliv v tom našem dashboardu je přesně šité na míru naší potřebě. Nikdo nám nediktoval, jak se to bude chovat. Tahle volnost je pro nás kritická a jen díky ní dokážeme stavět nad GoodData cokoliv si zamaneme = je jen na naší schopnosti, jestli uspějeme a zákazník s náma bude spokojený. 

Trochu pastička na zákazníka je v tom, že podobný dashboard je možné na první pohled sestavit v ledasčem. Mám tady příklady dashboardů z KlipFolio. Jsou super, ale mají jedno podstatné “ale” - všechny vizuální komponenty jsou objekty, které načítají informace z předem připravených dat, které někdo designoval přesně pro účely toho dashboardu. Není možné to překroutit a začít třeba 2 čísla ze dvou podkladových tabulek podělit a sledovat jejich podíl v čase. A month-to-date toho podílu už vůbec ne. O situaci, kdy máte data, ve kterých jsou vazby “many to many”, nemá smysl vůbec mluvit. Velká výhoda těhle BI produktů (řikají si BI, ale BI to není) je v tom, že jsou líbivé a podbízivé. Člověk na startu neodhadne, že si kupuje křáp, který vlastně neumí o moc víc než jeho Excel.

Proč je trh zaplavený produkty, které hrají na maličkém hřišti se stěnama vylepenýma cool vizualizacema? Nevím, ale lidi jedou na vlně “Cool, BigData analytika!” a jsou hladový po čemkoliv co má podobu reportu. Tématická analytika se udělá za pár dní - transformace transakcí a počítání "Customer lifetime value" je snadná, dokud mi každý neřiká jak to chce mít podle sebe. 

"Nikdo na světě kromě GoodData nemá schopnost provozovat analytické projekty, které jsou 100% svobodné svojí podstatou (datovým modelem) a v těchto projektech nechat lidi dělat cokoliv chtějí, aniž by museli být low-level data analytici a/nebo programátoři. Bum!”

Jak to GoodData dělá?

V Excelu je každý zvyklý sečíst sloupeček “A” tím, že dá do libovolné buňky vzoreček “=SUM(A:A)”. V GoodData sečte sloupeček A tím, že napíše vzoreček “SELECT SUM(A)”. Jazyku kterým se v GoodData tyhle vzorečky píšou se říká MAQL - mnohodimenzionální analytický dotazovací jazyk (Multi-Dimension Analytical Query Language). Zní to děsivě, ale zatím to každéj dal, i Pavel Hacker má z Keboola Academy diplom na Report Mastera :-). Pokud se podíváte zpátky na ten můj datový model z našeho interního projektu, můžete si říct, že chcete průměrný počet hodin z jedné strany datového modelu, ale filtrovaný třeba typem úkonu, seskupený podle popisu projektů a jména klienta a to celé jen pro úkony, které proběhly o víkendu odpoledne. Všechny metriky budou vypadat jako “SELECT AVG(hours_entries) WHERE name(task) = úklid”. Multidimenzionalita toho jazyka je v tom, že neřešíte, v jaké dimenzi je jméno úkolu a v jakém je vztahu k počtu vykázaných hodin a nedejbože jménu klienta. GoodData, resp. vztahy v logickém modelu, který pro klienta navrhujeme my, za vás pořeší úplně všechno.

A teď jádro pudla: pokud vám připravím (denormalizovanou) tabulku do Excelu ve které to bude pěkně na zakázku sesypané dohromady, nebude to nikomu kdo tohle čte, dávat problém spočítat. Pokud vám dám data rozdělená podle dimenzí (a dimenze bude často jiný zdroj dat - jako jsou výstupy z našeho českého a kanadského účetnictví), bude to potřeba zpracovat mnohem složitějc (nejspíš začnete v SQL joinovat jako zuřivý). Jelikož se svět nedá popsat jednou tabulkou (teda asi dá - key value pair - ale nepůjde s ní moc pracovat), je pohled přes mnoho dimenzí tím podstatným. Bez něj je všechno jen takové to domácí počítáníčko :)

Kalibrace pozornosti: teď už byste pomalu mohli říct “wow”, protože pokud se vrtáte v datech, mohli byste mít vysokou míru afinity k popsané situaci :)

Jdeme do finále

Výroba dotazovacího jazyka je nejsložitější úkol, který v BI dneska můžete řešit. Není to o uložení velkých dat, není to o jejich zpracování, ani vykreslení grafů nebo příprava API, aby se dalo s váma perfektně spolupracovat. Dotazovací jazyk si nekoupíte ani za měsíc nenaprogramujete. 

Pokud bude jazyk složitej, nebude ho umět zákazník používat. Pokud bude jazyk hloupej, nebude s ním schopný dělat co chce. GoodData má jednoduchý jazyk na vyjádření jakkoliv složitých otázek směřovaných do dat a zároveň má aparát, kterým tento jazyk napasuje na jakkoliv složitý BI projekt (logický datový model). V případě GoodData je to právě MAQL/AQE - z mého pohledu je to tou jedinou věcí, která je na GoodData neopakovatelná. Kluci z Brna a Prahy - Tomáš Janoušek, David Kubečka a Tomáš Jirotka - navíc rozšířili AQE sadou matematických důkazů (složitá algebra), díky kterým je možné rychle testovat, že nové funkce v AQE platí pro jakékoliv druhy logických modelů. GoodData tak má jistotu, že překlady mezi (MAQL) metrikama a nějakým SQL na spodních databázích jsou správně. AQE tak pro běžného člověka překlene propast, která ho dělí od low-level scriptování. 

UPDATE 17.11.2013: MAQL je dotazovací jazyk, který je na základě logického modelu (LDM) překládaný pomocí MAQL interpretru (dříve QT - "Query Tree" engine) do stromu dotazů. Tyhle dotazy jsou vlastně definice "star joinů", ze kterých "Star Join Generator" (SJG) vyrábí podle fyzického datového modelu (PDM - leží pod LDM) vlastní SQL dotazy na DB backend. Celé to na začátku dal dohromady Michal Dovrtěl a Hynek Vychodil. Nová implementace AQE tohle všechno navíc položila na solidní matematický základ ROLAP algebry (podobá se relační algebře).

Pro srovnání jsem vzal datový model z Report Master kurzu v Keboola Academy a nad ním udělal report:

Graf mi na pravé Y ose ukazuje, kolik jsem udělal v Afgánistánu, Albánii, Alžíru a Americké Samoe kontraktů za posledních 13 měsíců. Na levé Y ose mi ukazuje modrou čárou, kolik mi přinesl průměrný obchodník a zelenou čárou mi ukazuje kolik byl medián obratu na obchodníka v daném měsíci (vstupy jsou de-facto shodné s ukázkovou tabulkou úplně na začátku).

Graf tedy obsahuje tři metriky (viz legenda pod grafem):

• "# IDs” = SELECT COUNT(ID (Orders)) - spočítá počet prvků
• “prumer na obchodnika” = SELECT AVG(obrat na obchodníka) - spočítá průměr z (pomocné) metriky počítající sumu obratu na obchodníka
• “median na obchodnika” = SELECT MEDIAN(obrat na obchodníka) - spočítá medián z (pomocné) metriky počítající sumu obratu na obchodníka

a pomocná metrika

• "obrat na obchodníka” = SELECT SUM(totalPrice (Orders)) BY employeeName (Employees) - spočítá hodnoty položek (nějaké prodeje) na úrovni obchodníka

Všechno je samovysvětlující, snad jedině “BY”, což mi definuje, že se mi peníze “totalPrice (Orders)” spočítají podle obchodníků a ne chaoticky mezi sebou. Troufám si tvrdit, že každý kdo je ochotný a bude se maličko snažit, se to naučí (ostatně to v Keboola Academy učíme jak na běžícím pásu). 

A teď to hlavní. AQE to přeloží na následující SQL:

S trochou nadsázky lze říct, že sestavení mého reportu je vlastně poměrně dost složité, ale mě to díky AQE vůbec netrápí. Platí-li hypotéza, že:

1. pokud mi GoodData nevydělá balík peněz, tak ji nebudu používat
2. balík peněz vydělám jen přesným používáním BI projektu, šitým na tělo
3. BI šité na tělo je komplexní záležitost, kterou je možné obsloužit jen díky AQE

… pak je AQE základem úspěchu GoodData.

UPDATE 17.11.2013: jak to léta používám, vůbec mi nedošlo to zásadní - kontextovost MAQL metrik - úplně se mi to vrylo pod kůži a jinak si to neumím představit. Perfektně to pospal Hynek Vychodil v komentáři dole (nejde tu konkrétní komentář linkovat, tak tady je pro jistotu screenshot) 

Poznámka pod čarou: výše uvedené MAQL metriky jsou jednoduché příklady. Někdy je potřeba metriku postavit tak složitě, že je až nepředstavitelné, co se s daty musí na pozadí stát. Tady je příklad metriky z jednoho projektu, kde je analytika nad nestrukturovanými texty. Metrika počítá konverzační témata v aktuálním (zvoleném) období podle moderátorů:

Lukáš Křečan před časem blognul, že lidi jsou největší konkurenční výhoda GoodData. 

Lidi jsou základ, bez nich to určitě nejde a jsou to oni, kdo tvoří neopakovatelnou atmosféru ve které vznikají unikátní věci. Jeden za druhým jsou ale nahraditelní. Největší konkurenční výhoda GoodData (a zároveň zásadní duševní vlastnictví) je AQE. Pokud by ho neměla, musel by uživatel reporty klikat v sevřeném UI, které mu vezme tolik potřebnou flexibilitu. Bez AQE bude GoodData někde v partě mezi Tableau, Bime, Birst, aj. Stane se v zásadě nezajímavou a bude zhusta soupeřit s firmama, co si nad “Redshiftama" budou stavět vlastní UI.

AQE je pro GoodData neopakovatelná příležitost jak utéct konkurenci, která bude už jen ztrácet. Nikdo jiný dneska nedokáže implementovat novou funkci do produktu, kde mohou být libovolná data v libovolně rozměrech (dimenzích) a přitom si analyticky dokázat a otestovat správnost implementace. 

Hranice mezi falešnou představou že “ten cool dashboard je pro mě přínosný” a "opravdovým potenciálem vytěžitelným z dat", je velmi tenká... a jmenuje se customizace. Libovolný model pro libovolná data a nad ním libovolné výpočty. Může to kdokoliv nazvat jako extrém, ale bez schopnosti spočítat přes mnoho dimenzí přirozený logaritmus z podílu hodnot dvou období, do světa finanční analytiky díru neuděláte. AQE je gamechanger na poli BI a díky němu GoodData redefinuje pravidla hry. Dneska obecná odmocnina, zítra K-means... :)

Howg!

Kouk jsem se dneska na to, kolik dat držíme a zpracováváme v Keboola Connection. Nejsou to žádný ultra objemy, ale když si uvědomíme, že jsou to primárně čistý obchodní informace našich klientů (transakce a číselníky), je to docela dost. Nepočítám do toho náma vygenerovaný logy a eventy, popisující provozní parametry, ani zálohy a podobné věci. 

Vzal jsem v úvahu období od začátku minulého měsíce do včerejška, čísla jsou vždy agregovaná za jeden konkrétní nejaktivnější den:

• Počet operací proti Storage API: 37.689
• Objem přijatých dat: 26.5 GB
• Objem odeslaných dat: 33.5 GB
• Čas strávený obohacováním dat: 1.992.890 sec (23 dní!)

A ještě 3 celkové statistiky k dnešnímu dni:

• Celkový objem držených (živých) dat: 1.3TB 
  
• Počet všech řádků : 6 miliard
• 5 nejčastějších chyb v API: 
• nesedící struktura dat při importu od klienta
• validace obsahu tabulky
• nepovolený přístup
• překročený počet povolených indexů
• cílová tabulka nenalezena

A stupínek vítězů pro technologie, které se na tom podílí?

1. místo určitě stále zastávají Amazon RDS (MySQL) servery
2. místo nově zabral Amazon Redshift
3. místo zabírají (měřeno přes palec) Google BigQuery, HP Vertica + R a Amazon CloudSeach

Minulý týden jsme ale měli "IT party" s Karlem Minaříkem a myslím, že Amazon CloudSearch brzo vystřídá ElasticSearch. V kostech cítím, že v tom leží budoucnost. Tlak na co největší rychlost a JSON všude kam se podíváš - trend je jasnej :-)

HR okénko:

Sháním někoho se zkušeností s AWS Data Pipeline a/nebo AWS SWF. Pokud nikdo takový neexistuje :), hledám nadšence, co si s tím pro Keboolu zaexperimentuje. Kontakt nejlépe v komentářích nebo emailem na petr@keboola.com.

Problém?

Cloud - nejvíc nebezpečná věc, zvlášť  tady v čechách!

Tohle téma si schovávám od půlky května. Bacha, TL;DR :) 

Na Facebooku proběhl post Radka Hulána:

"O data v cloudu se typicky starají lidé s mnohem lepšími znalostmi než váš lokální admin (včetně důrazu na zabezpečení) a jsou k dispozici 24/7. Pro menší firmy nedává dle mého vůbec smysl mít vlastní servery, licence, administrace, pokud daná věc existuje jako cloudová služba…"

(pro datové archeology přidám ještě link na zálohu)

Pod postem se rozhořela klasická česká diskuse. Pár výcuců:

• až vypadne cloud, přijde firma o tisíce
• citlivá data nesmí pryč
• proti výpadku lokálního serveru se dá aktivně něco dělat
• Hlavně si sám sobě můžu dělat zálohy jak chci a kdy chci
• A pak jsem zažil chybu, při které zmizel důležitý soubor z placeného "Google Docs pro firmy", na kterém aktivně pracovalo 100+ lidí…
• kdyz si poridim hostovany exchange u MS, jak sezenu admina?
• SSL samotné není zárukou zcela bezpečné komunikace
• Nic není zárukou bezpečné komunikace v okamžiku, kdy svá data pustíte ven.
• …

Základní doporučení je samozřejmě nevlastnit žádný počítače, protože pak se nemusím trápit myšlenkou, jestli není v řadiči sběrnice nějakej odposlechovej software. Taky je dobrý nemít umělý koleno, protože to má určitě výrobní číslo, který je v cloudu na nebezpečným úložišti - což radikálně ohrožuje moji svobodu a tím pádem i bezpečí… :)

"Cloud" je skloňované slovo ve všech médiích. Podobně jako BigData. Evidentně polarizuje společnost na 2 skupiny. Češi si myslí, že v Cloudu o svoje data během mžiku přijdou. Řiká se, že každej čech je odborníkem na fotbal a marketing, podle projevů na internetu jsme všichni experti na cloud a IT bezpečnost. Když se to zkombinuje s tím, že si všechno uděláme nejlíp sami, nastane pekelná kombinace. 

O čem je vlastně řeč?

• strach o práci - všichni ti chytráci v diskusích zmiňují nízkou bezpečnost cloudu a svorně tvrdí, že jima postavená infrastruktura je bezpečnější, nikdy nemá výpadek konektivity, nikdy v ní nehoří, nikdo do ní nikdy nepronikne, atd… Nevidím za tím nic než strach, že jejich dominantní postavení v dané práci vezme vniveč, protože non-IT oddělení získají kontrolu nad svými daty a pana "Administratora" se nikdo nebude potřebovat na nic ptát.
• provize od stávajícího vendora - není nic hošího než nemuset koupit další chassi k diskovému poli. EMC² pláče, obchody nejdou a CTO nemá kick-backy od firem typu TechData.com (kick-back má tady nejčastěji podobu zájezdu do Alp pro zákazníka měsíce). Pokud náklady na provoz informačního portálu pražanům vyjdou dneska na ~100 mio Kč / rok (vůbec neověřuju, je to plácnutí do vody - čistě příklad), nebude asi jakákoliv optimalizace zdrojů průchozí přes konzumenty kick-backů. 1/2 z těhle věcí nemá v Cloudu vůbec místo

• neznalost - resp. povědomí nabyté čtením diskusí v českých e-zinech. Hlášky typu "Webový Office NE! Spadnou internety a celá firma stojí." má logiku stejnou jako "Barák bez vlastní vodárny NE! Nepoteče voda a nespláchneme záchody."
• EU vs USA - to se 99% SMB segmentů netýká, nicméně Cloud provider není jen Amazon/Google/Rackspace
• interní směrnice - je často důsledkem IT důvodů nebo politického lobby, které nemá nic společného s tím, kdo může poskytnout dané firmě nejlepší možné řešení. Takové směrnice buď bezmyšlenkovitě stojí na obecném "EU" doporučení, které firemní právník s CTO za zády alibisticky interpretuje jako veto a de-facto nařídí, aby vše bylo on-premise (lokální instalace na vlastním HW). 
• "něco se na mě zjistí" - přestanu kontrolovat část procesu (tím trpí Keboola nejvíc - GoodData syndrom). Pokud se nebavíme přímo s majitelem firmy, je všechno co zákazníkovi nabízíme potenciálním ohrožením existujícího managementu, protože dělá data transparentní. "Slice&Dice" je pro takové lidi nůž do zad :)

• odpovědnost za rozhodnutí (alibismus) - cokoliv nového je pro některé lidi složité prosadit. Je prostě lepší tlačit káru dál ve vyjetých kolejích, než časem obhajovat, proč jsem se pod něco podepsal.
• absence příkladů od velkých lokáních hráčů - tady asi nejvíc mohou zamakat firmy typu netmail.cz, které, pokud mám správné informace, mají v portfoliu top-notch hráče, ale né úplně dobře to mohou publikovat, takže je tady nenajdeme

Český paradox - obava z dostupnosti

Český paradox - obava z bezpečí dat

Co cizina?

NASA říká, že by bez Identity Managementu (AWS IAM) v Cloudu neuřídila přístup k datům, který generují roboti na Marsu, Pfizer do Cloudu přenáší výzkum léků, NASDAQ tam analyzuje burzovní data, Obama na něm postavil svoji první prezidentskou kampaň a letiště v Norimbergu v Cloudu provozuje portál obsahující osobní data svých zákazníků. Seznam pár "AWS" případových studií je tady (důležité je říct, že Amazon AWS není jediný Cloud provider, vybral jsem si ho jen jako osobně nejbližšího zástupce) 

Long story short…

Problém bude vždycky v lidech. Pokud provozujete problematickou webovou aplikaci, ke které se má někdo připojit online, budou vaše data stejně špatně chráněná v interní serverovně jako v Cloudu. Pokud s tím budete ale něco chtít dělat, bude v Cloudu mnohem rychlejší postavit kaskádu firewallů, demilitarizovanou zónu a zapojit systém aktivní kontroly průniku. Všechno tohle dává práci šikovným lidem a bere ji lemplům. Nevím, jestli to je nebo není tím pravým důvodem, proč v čechách lidi tolik křičí, když na Cloud přijde řeč…

Kdo dočetl až sem, může hodit oko na stručný seznam služeb, které používáme v Keboole: http://padak.keboola.com/cloud-vyhazujeme-penize-oknem

UPDATE 22.10.2013: Americká armáda přechází na Google Apps s 50 000 lidmi - link.