Det er fandme dumt at blive ved med at lave dashboards, som ikke bliver brugt

BI-folk skal forstå den virkelighed, som data fungerer i, og ikke sidde på toppen af den støvede data-højborg og regere gemt væk bag firewalls og ticket-systemer, skriver Søren Christian Søndergaard Poulsen.
Brødtekst

Forestil dig, at du lige har lanceret et nyt produkt.

Lad os sige, produktet er et gulvtæppe … Ja, ja, jeg skal nok lave perspektivering til, hvorfor dette eksempel er relevant for Business Intelligence-teamet, men hæng nu på for en stund. Vi skal lige varme op.

I har måske haft nogle fokusgrupper forbi for at give deres udsagn om, hvad de synes om produktet.

Men nu skal jeres nye produkt ramme jeres testbutik for første gang. Ramme virkeligheden.

I har allokeret et mindre observationsteam af R&D-, salgs- og marketingsfolk til at følge produktets første rejse.

Dette team hjælper med at pakke lastbilen.

Nogle af kollegerne i observationsteamet tager plads ved siden af chaufføren i lastbilen, og undervejs til butikken noterer de forhold, der evt. kunne påvirke produktet (eks. fugtighed i bagkassen – kunne være via IoT-aktiverede sensorer – men vi kører lige den håndholdte version).

Når lastbilen ankommer til butikken, observerer teamet turen fra lastbilen og ind i butikkens baglokale.

De observerer udpakningen af tæppet – det, der skal udstilles i butikken, herunder merchandising.

De observerer, hvordan butikspersonalet tager imod produktet, og hvilke spørgsmål de måtte have. Observationsteamet bliver hængende og observerer første kunde, der kommer forbi butikken og spørger ind til gulvtæppet.

Observationsteamet spørger første kunde, om de må følge gulvtæppet fra butik til slut-destination. De bliver og observerer, hvordan gulvtæppet bliver ”installeret” hos kunden, hvilke spørgsmål og udfordringer, der måtte være.

Jeg blev introduceret til denne proces for snart 15 år siden, da jeg studerede på Handelshøjskolen. Det var gulvtæppefirmaet Milliken, der kørte med dette ”first-delivery team”- koncept. Om de fortsat gør det, skal jeg ikke kunne sige. Men det handlede grundlæggende om at lære, forstå og få så hurtig feedback omkring nye produkter som muligt. Ikke mindst lære i kontekst af virkeligheden, i kontekst af rigtige mennesker og ikke i opstillede test-laboratorier med brugergrupper, der får betaling for deres deltagelse.

Gulvtæpper og business intelligence

I en dialog jeg havde med en meget kompetent herre, Snurre hed han, blev jeg indirekte mindet om ovenstående case.

Vi snakkede nemlig om, hvordan vi BI- og data-folk kunne optimere effekten af data hos slutbrugerne ved at gøre op med metoder, tilgange og arbejdsformer som tilsyneladende har meget lidt gennemslagskraft.

Et opgør med blot at samle en klynge af mennesker i et mødelokale en hel dag, udfordre dem på deres ønsker og så i øvrigt kalde det en workshop.

Dette er der som udgangspunkt ikke noget galt med, og det skal vi da fortsætte med, men lærer vi reelt at forstå, hvad BI-brugerne har brug for, hvordan data skal anvende og i hvilken kontekst?

Lærer vi at forstå, hvilke reelle udfordringer og barrierer BI-brugerne rammer, når virkeligheden sætter ind, og vi ikke længere står i et mødelokale og drømmer en data-drevet fremtid op?

Nej vi gør sgu da ej!

For når virkeligheden sætter ind, er tallene i rapporterne den mindste del af problemet. Så hvad nu, hvis vi tog disse problemer i opløbet?

Hvad, hvis vi BI-folk, dette gælder både konsulenter og interne BI-teams, fik en forståelse for virkeligheden, inden data ramte virkeligheden?. Vi fik måske endda ved den lejlighed nedbragt den distance, der i dag eksisterer mange steder, hvor BI-folkene sidder i Langtbortistan på toppen af den støvede data-højborg og regere. Hvor den nærmeste bruger, i fugleflugt, føles som kilometer væk, gemt væk bag firewalls og ticket-systemer.

Hvad med i stedet at hente inspiration fra diverse antropologiske-, sociologiske- og læringsskoler.

Nu skal jeg ikke hive Snurre med ind under bussen, såfremt I synes det er en dårlig idé eller et dårligt blogindlæg, men jeg skylder Snurre en tak for at bringe mine tanker denne vej.

Tanken er helt simpelt. Jeg gør i øvrigt brug af den, når jeg gennemfører datastrategi-forløb. At komme ud i forretningen, så snart de har erkendt deres behov, og være en passiv eller aktiv flue på væggen i forbindelse med forståelsen af forretningen.

Det handler delvist om at komme behovene nærmere, men lige såvel at forstå jargonen, kommunikationen, biases blandt medarbejderne, processerne, adfærd, magtfordelingen, attituderne, problemer, analytiske kompetencer, diskussionerne og ikke mindst den måde, som de i dag analyserer og anvender data på (hav fokus på kritisk tænkning eks.). Forstå, hvilken virkelighed, jeres fremtidige rapportpakke, dashboard, data-cuber, data-sø, data-you-name-it skal passe ind i.

Det bør både inspirere jer til de fremtidige brugsscenarier og påvirke den måde, I designer løsningerne på, men ligeledes give jer en indikation af, hvilke udfordringer der venter og hvorfor.

Er det det dashboard, I planlægger at udvikle til dem, der bliver udfordringen?

Er det kommunikationen omkring tallene, der kan blive udfordringen?

Er det medarbejdernes tid, der kan blive udfordringen?

Er det medarbejdernes manglende kritisk-tænkning-kompetencer, som vil give jer problemer med at få den fulde effekt?

Læg dertil den viden I får om forretningen, som fremover vil blive yderst værdifuld, når I skal sparre og udfordre den enkelte forretningsenhed i mulighederne med data. Selv hvis I allerede kører en hybrid-model med decentrale BI-udviklere, vil jeg anbefale, at disse bliver en flue på væggen.

Hvilken flue vil du være, når du bliver stor?

Hvilken flue skal man så vælge?

Den passive flue er en flue, man ikke bemærker - tavs og ikke-påtrængende. Der er ingen interaktion med forretningen, og hele formålet er at beskrive de forskellige forhold så objektivt som muligt. Fordelen ved denne tilgang er, at man forstyrrer den eksisterende forretning til et minimum, og I får det helt rette billede af jeres brugeres virkelighed. Åbenlyst er ulempen, at såfremt et spørgsmål melder sig, må man samle til bunke og stille disse på et senere tidspunkt og derved minimere sandsynligheden for, at man får det korrekte svar i forlængelse af den pågældende kontekst, hvori spørgsmålet opstod.

Den aktive flue derimod summer rundt og er lidt pågående og irriterende, næsten på samme vis, som når sidder du en varm sommerdag i dit sommerhus og nyder en frankfurter med et koldt glas rosé (jeg ved ikke lige, om det er en menu i øvrigt). Begge fluer har på forkant en lang række spørgsmål, de gerne vil have svar på, men i modsætningen til den passive flue, så stiller den aktive flue spørgsmålene 'on-the-spot' for at få så præcis en forståelse af den specifikke situation og kontekst som muligt, men stadig under nogle forhold, som gør forretningen i stand til at arbejde videre uden de store forstyrrelser. Hvad laver du lige nu? Hvorfor gør du det? Er outputtet som forventet? Fortæl mig lidt om denne problemstilling/situation/proces ... Hvilke data, og hvorfor kan data gøre en forskel lige her? Hvordan kan data gøre dig/jer mere effektive i fremtiden? Hvordan forbereder de sig til møder, hvor data skal præsenteres? Snakker de forbi hinanden på møderne og hvorfor (hvad er den reelle årsag hertil)? 

Observér, hvor data kunne gøre en forskel, herunder pre- og post-proces. Observér processer, og ikke mindst hvilke kan forbedres. Observér, hvilke typer af beslutninger der træffes.

Lav en liste med forskellige mål, I søger afdækket gennem jeres observationer.

Den valgte flue kombineres med forskellige tilgange, som sikrer, at du/I får dækket forretningen på bedste vis, herunder 'shadowing' af artefakten (følg en specifik artefakt eks. udarbejdelsen af en data-baseret anbefaling til lederen), lytteposter (placér dig der, hvor der er meget snak - møder, kantinen, kaffemaskinen), 'piggybacking' (ligesom jeres ledere laver 'piggybacking' på jeres organisatoriske data, kan du/I gøre det samme ved at vælge specifikke situationer, som giver et ekstra godt billede af forretningsenheden). Derudover er det vigtigt at have in mente, at der vil være en form for 'observations-effekt', da nogle medarbejdere kan tænkes at opføre sig en smule anderledes, end de normalt ville.

En variant kan ligeledes være at udstyre udvalgte BI-brugere med "data-dagbøger".

Ovenstående tager afsæt i, hvad I kunne gøre, før I udvikler diverse data-leverancer, men det kunne lige såvel være på bagkant - lige præcis som "first-delivery team" hos Milliken. Det skylder I jer selv.

Ovenstående gennemgået tilgang bliver endnu mere vigtig, når vi snakker AI- og ML-projekter.

Det er tid til forandring.

Det tager helt sikkert mere tid end at afholde en workshop eller gennemgå en kravspecifikation, men det er fandme også dumt at blive ved med at udvikle rapporter, dashboards m.m., som aldrig rigtig har en effekt i forretningen. Så måske det var på tide at prøve noget nyt, som tilmed har en masse positive sideeffekter.

Vi slipper processen for tidligt og kommer ind i den for sent - derfor får jeres BI-brugere ikke den fulde effekt!