Med over seks år som konsulent og involvering på projekter for mere end 50 kunder har jeg – på både godt og ondt – set forskellige tilgange til hvordan man som organisation arbejder med data.
Og uden at fornærme nogen, kan jeg vel godt sige at det roder lidt hist og her. Rodet er ikke nødvendigvis grundet manglende kompetencer eller dårlige beslutninger fra virksomhedens data & analytics team. Det er ofte bare en afledt effekt af en organisation med fart på, der prioriterer nye initiativer og leverancer over oprydning og nedbrydning af bl.a. teknisk gæld.
Vi kender det vist også godt selv. Derhjemme er jeg i gang med lidt smårenovering. Ikke noget voldsomt, men lidt silikonefuge det ene sted og lidt mørtel det andet. Og her står jeg i mit evige dilemma. Skal jeg bruge tid på at dække af eller i stedet bruge længere tid på at rydde op bagefter? Ofte ender jeg med at vælge det sidste.
Hvorfor? Jo, fordi det er sgu sjovere at komme i gang og se resultaterne. Udfordringen er så selvfølgelig at byggerod ikke kan gemmes væk lige så nemt som teknisk gæld 😬
Men det der følger med datarodet, er desværre også en gang i mellem ambitiøse folk der “skammer sig” over deres data-rod og beklager at de f.eks. ikke har styr på deres masterdata, har gang i lidt for mange Excel-ark eller ikke er nået længere med deres brug af data.
Og det er lige præcis omdrejningspunktet for dette indlæg.
Ikke med det formål at hænge virksomheder ud, men med formålet at vise at naboen roder sgu lige så meget, og at det derfor ikke er nogen skam at alt ikke står snorlige hos jer.
Det er lidt som at komme hjem til en børnefamilie (os f.eks.) og blive mødt af et “ja, undskyld at det roder lidt…”. Ved du hvad? Det er sgu helt ok, det havde jeg også forventet. I har 10.000 ting om ørene. Det skal nok gå.
I et forsøg på at nedbryde “skammen” har jeg derfor hivet fem “situationer” frem som jeg har oplevet flere steder. Forhåbenligt kan de være med til at vise dig at I ikke er alene om rodet.
Og hvis du sidder nu og tænker “hvorfor skriver han om min virksomhed”, så tag det helt roligt. Risikoen for at I er casen er forholdsvis lille, mens sandsynligheden for at andre har præcis samme udfordring som jer er væsentlig større.
Så her kommer de…
Excel som kilden til alt (ondt)
Den første situation er nok velkendt for langt de fleste. Excel som kilde.
Det her kan få det til at løbe koldt ned af ryggen hos en hver data engineer. Hvorfor f!?k vil nogen nogensinde bruge Excel som kilde? Jo fordi det er nemt og lige til og fordi folk kan forholde sig til et regneark.
Udfordringen her var dog at alle Power BI rapporter hentede data direkte fra Excel-ark flere gange dagligt. Og dette skabte lidt af et problem, da flere medarbejdere også samtidig arbejde i Excel-arkene eller glemte at lukke dem ned.
Konsekvensen? Fejl på fejl i data-load, og en lang række opkald til konsulenter for at fikse det.
Lederen og alle hans rapporter
Hvis du har læst lidt med i nogle af mine opslag, så har du forhåbenligt lagt mærke til at jeg har ret stor fokus på vigtigheden af uddannelse og opkvalificering af slutbrugere. Og dette eksempel belyser hvorfor.
I en virksomhed der egentlig havde ret godt styr på deres datasetup sad der en leder der gemte en ny rapport, hver gang han skulle gemme en specifik visning. For at gøre det værre, så blev rapporterne publiceret i et delt workspace i Power BI.
Resultatet? En ny rapport hver måned der f.eks. Kunne hedde salg_marts2023, og en lang række andre dubletter såsom _bestyrelsesmødesapril, _navnfebruar2022 etc.
Jeg tror du er med på problemet og hvilket rod det gav.
Spaghetti-arkitekturen
Denne situation er af lidt mere teknisk karakter, så hvis nogle af begreberne ikke giver mening, så frygt ej. Dem tager vi på et andet tidspunkt. Og sidder du i stedet som data engineer, så er du advaret. Det kan godt komme til at løbe lidt koldt ned ad ryggen.
Når man bygger et setup hvor data flyttes fra forskellige kildesystemer til en samlet database, og ligeledes laver en række transformationer, så kan man hurtigt få lave nogle “spændende” løsninger hvis man ikke har tungen lige i munden.
Løsningen her havde det hele. SSIS-pakker der trak data fra samme kilde som den skrev til, facts der blev brugt som kilde til dimensioner, en milliard tabeller der unødvendigt blev brugt til at persistere data under load, transformationsview der trak direkte på datamart views osv. osv.
Den bedste måde at beskrive det på, er at forstille sig en tallerken spaghetti og så prøve at identificere hvilke to ender der hørte sammen.
De mange dubletter
Hvis vi for alvor skal rykke organisationen i brug af data, så skal vi sikre at data er intuitivt og let at forstå. Og her kan struktur og gennemsigtighed være en vigtig faktor.
Desværre er det ikke altid sådan. En udfordring jeg har oplevet flere steder er at samme datapunkt eller attribut eksisterer flere steder i samme datamodel. Et eksempel et sted var at kundenavn eksisterede utrolig mange gange i datamodellen. Det eksisterede selvfølgelig i kundedimensionen, men havde ligeledes sneget sig ind i en lang række andre dimensioner og facts.
Udfordringen var at det ikke var tydeligt for brugeren hvilken af kunde-attributterne de skulle bruge når de lavede analyse. Og dette var ofte til frustration for brugeren, da de kunne risikere at få manglende eller forkerte tal hvis de valgte en forkert attribut.
Power Bi som kilde til Power BI
Det sidste eksempel er et eksempel på hvad der kan ske hvis vi er en data-ambitiøs virksomhed, men ikke får skabt den rigtige data literacy hos medarbejderne.
En virksomhed havde et ganske fint Power BI setup, og en række medarbejdere med et stort drive til at arbejde mere med data og en masse ideer til nye løsninger. Dette er selvfølgelig super fedt! Udfordringen var bare at mange af de nye løsninger blev lavet på en uhensigtsmæssig måde.
Data blev nemlig filtreret og eksporteret fra en Power BI rapport til Excel og efterfølgende gemt lokalt på en medarbejders computer.
Derefter blev Excel-filen brugt som kilde til en ny Power BI rapport som blev delt med andre i virksomheden.
Hurtigt og effektivt, men også årsag til mange fejl og problemer.
Kan du genkende nogen?
Her fik du serveret 5 situationer som jeg har oplever flere steder. Kan du genkende nogen af dem eller er der andre du selv oplever?
Og husk på, det er ingen skam at rode, fejle eller lave nogle lidt hurtige løsninger en gang i mellem. Vi skal bare være bevidste over hvilke potentielle konsekvenser det kan give på både den korte og lange bane.
Ja, og så lige huske at rydde lidt op en gang i mellem.