Tilbage

7 faldgruber i Data Warehouse - del 5

Nu til de seriøse problemer. Dette er den femte af i alt 7 artikler om de 7 faldgruber, som BI Architect Brian Bønk Rueløkke gennem tiden er stødt på i sit arbejde med Data Warehouse.

Mødet med de seriøse problemer

Der er nu behov for elementer, der kan vinde tilliden tilbage. Der er behov for en leverance fra Data Warehouse der kan give indsigt i nøgle elementer som virksomheden venter på, inden projektet bliver lukket før tid.

Med hast kan der hurtigt bikses noget flot sammen ved hjælp af et open source værktøj der kan generere "eye-candy" hurtigere end vi kan stave til Ib. Teamet får sat nogen overordnede måltal op for marketing afdelingen og produktteamet og gjort det lækkert at se på. Alt sammen i håbet om at vinde i hvert fald, deres gunst tilbage.

Teamet før først en masse ros, men når behovet for yderligere data og rapportering, bliver rosen hurtigt glemt.

Data fra Data Warehouse matcher ikke med det samme data fra kildesystemet som marketing har. Problemet med at data lyver er nu endnu større - nu er der to datasæt som ikke viser de samme resultater. Ikke alene er tallene forkerte, de er ikke engang tæt på hinanden.

Teamet der arbejder på Data Warehouse er helt sikre på at alt er gjort helt korrekt. Data er sat sammen på den korrekte måde og webdata, der før var rodet og ustruktureret, er nu lagt pænt i tabeller med navngivne kolonner. Men realiteterne møder forventningerne og tallene giver ikke mening.

Der er to årsager - enten fungerer de grundlæggende ideer og funktioner i Data Warehouse ikke, eller også er tallene så langt fra forventningerne (og stadig korrekte) at modtagerne ikke kan tro på rapporterne.

Uforudsete problemer

Målsat på at finde årsagen til problemet, er der behov for at arbejde med Data Quality. Derigennem findes der pludseligt tal der, på baggrund af deres tidsstempler, viser sig at ske i fremtiden! Ikke alene lyver Data Warehouse data, nu er datakilderne også behæftet med tydelige fejl.

Hertil skal lægges at data ikke er sat til at opdatere i den næste time og der er stadig problemer med data fra i går.

I sidste øjeblik, går det op for en at der er behov for noget real-time overvågning for at finde denne slags problemer fremadrettet.

Nu taber man selv troen på data i Data Warehouse. Andre tror heller ikke på det. De udarbejdede rapporter og dashboards bliver ikke brugt fordi organisationen ikke tror på indholdet. De vil hellere have små stumper af rå-data fra kildesystemerne, end data der er fejlbehæftet og som modsiger kilderne.

Kampen for at levere resultater

Uden støtte og opbakning fra organisationen, er teamet bag Data Warehouse også begyndt at tabe modet. De reelle resultater begynder at være så meget mindre end hvad man selv forventede og omkostningerne er skyhøje og har overskredet budgettet flere gange.

Alt fokus bruges nu på at levere en eller anden form for indsigt ud fra det data der er. Hvis bare organisationen kunne se fordelene ved et Data Warehouse, så kunne det hele nok blive godt.

Endelig, efter en meget lang kamp, får man hul igennem og kan begynde at arbejde med analyser. Den del af rapporteringen som drager nytte af alle de timer der er brugt til databehandling, identity management, tilgangen til web-sessioner for marketing, dynamisk database behandling og slutteligt optimering på performance.

Tiden er nu inde for at vise resultaternes udvikling over tid.

Det er sværere end forventet at levere positive resultater

Produktteamet er formodentlig nok de første til at tage udviklingen over tid til sig. Så lad os starte med noget værdifuldt til dem. Eks. en kohorte analyse der kan vise aktiviteter der understøtter churn.

Selv om det nu er en simpel øvelse, er der ingen fra teamet der turde tænke sig denne løsning før Data Warehouse. SQL sproget er det som man selv og hele analytiker-teamet kender - så lad dem da bruge det til at skabe værdi til organisationen.

Efter de få første linjer af SQL går det hurtigt op for en hvor stor en kompleks en forespørgsel mod databasen det vil blive. Sammensætte data på tværs af mange sessioner fra websitet, utrolig mange brugere og en ikke endnu defineret periode er noget af det sværeste teamet har lavet til dato via SQL.

Men hvorfor er det så svært?

Et eller andet sted bagerst i hukommelsen er det noget der lyser op. SQL er et set-baseret sprog som gør det stærkt til at filtrere, gruppere og lave simple beregninger. Sætte data sammen på tværs af tabeller og lave store datasæt er let. Det er dog ubrugeligt i denne opgave, da det ikke fungerer til at regne på kohorter og adfærd ud fra events på en hjemmeside.

Efter mange timers arbejde med at regne, gange og dividere datasæt og undersæt. Tilføje det der lige nu ligner en uendelig række af regler og parametre, er det endeligt lykkedes at komme frem til noget brugbart.

Men hvordan i himlens navn får man så produktcheferne og andre ansvarlige til at selv at vedligeholde og supportere så fremragende SQL kode? Ender det alligevel med at Data Warehouse teamet bliver flaskehals på denne del?

Organisationens valgte værktøj til visualisering kan i hvert fald ikke håndtere denne del automatisk. Det værktøj er bygget til at visualisere data i færdig form og ikke analysere adfærd ud fra events på en hjemmeside.

Hver afdeling skal nu have samme leverance

Ens team ser nu at hver eneste afdeling gerne vil have et lige så skræddersyet dashboard som produkt-teamet har fået.

Der skal nu udarbejdes SQL og dataanalyse for dem alle, udarbejdes dashboards og udgive dem i en let tilgængelig portal som kan vedligeholdes og derfra distribueres ud til organisationen.

Løsningen performer alligevel ikke som forventet og kapaciteten er ikke som aftalt. Hvad der tidligere var en fantastisk ide er nu endt som en horn i siden på en selv og noget som man selv sidder og vedligeholder og forsøger at holde i luften i en alt for travl hverdag.

Næste gang

Det var indlægget for denne gang. Næste uge vil jeg se på de sidste krampetrækninger i løsningen inden jeg i det sidste indlæg ugen efter, vil komme med mit forslag til at komme uden om alle de problemer de 6 foregående indlæg har forsøgt at skitsere.