BI-val: Looker vs Power BI vs Metabase vs Lightdash

BI-val väcker ovanligt starka känslor. Folk har sina favoriter och sina trauman. Jag försöker hålla mig nykter och titta på vad som faktiskt passar ett givet team, för det finns inget verktyg som är bäst för alla. Här jämför jag Looker, Power BI, Metabase och Lightdash utifrån hur svenska bolag jag jobbar med faktiskt använder dem och vad de orkar förvalta.

Looker: modellering i centrum

Looker bygger på LookML, ett lager där du definierar mått och dimensioner som kod. Styrkan är att alla rapporter använder samma definitioner, så att intäkt betyder samma sak överallt. Priset är att du behöver folk som kan och vill underhålla LookML. För organisationer med starkt datateam är det ofta värt det.

Power BI: brett och Microsoft-nära

Power BI är svårt att slå om resten av huset redan kör Microsoft. Det är kraftfullt, har stor träffyta och de flesta controllers har sett det förut. Baksidan är att modellering i DAX kan bli en egen liten konst, och att styrning över definitioner kräver disciplin eftersom det är lätt att alla bygger sina egna mått.

• Lågt motstånd i Microsoft-tunga organisationer.
• Stark Excel-känsla som gör tröskeln låg för ekonomifunktioner.
• Kräver tydliga regler för att inte definitionerna ska spreta.

Metabase: enklast att komma igång

Metabase är det jag oftast föreslår när ett team vill se värde snabbt utan stor investering. Det är lätt att installera, lätt att lära ut och tillräckligt för de flesta vanliga frågor. När behoven växer kan det kännas begränsat, men för många bolag når de aldrig den gränsen.

Vilket verktyg som passar er beror på er datamognad och era resurser. Det är en av de saker vi reder ut tidigt i vårt arbete med dataplattform, eftersom valet påverkar hela kedjan bakom.

Lightdash: BI ovanpå dbt

Lightdash är intressant just för team som redan lever i dbt. Det läser dina dbt-metrics direkt, så att definitionen finns på ett ställe i koden i stället för att dubbleras i BI-verktyget. För ett team med moget dbt-arbete är det en elegant lösning som håller sanningen samlad.

Self-service mot styrd rapportering

En av de svåraste avvägningarna i BI är hur mycket frihet slutanvändarna ska ha. Self-service, där vem som helst kan bygga sina egna rapporter, känns demokratiskt och avlastar datateamet. Men utan styrning leder det ofta till att samma mått räknas på tio olika sätt och att ingen längre vet vilken rapport som stämmer. Den andra ytterligheten, där bara datateamet får bygga, ger kontroll men skapar en flaskhals och frustrerade verksamhetsmänniskor som väntar i veckor på en enkel ändring. Jag försöker hitta en mellanväg där de centrala måtten är låsta och granskade, men där användarna fritt får kombinera och filtrera ovanpå den trygga grunden. Vilket verktyg ni väljer påverkar hur lätt den balansen är att uppnå, eftersom vissa verktyg är byggda för styrning och andra för frihet.

Prestanda och hur verktyget frågar

Ett ofta förbisett perspektiv är hur BI-verktyget faktiskt frågar mot ert lager, för det påverkar både svarstider och kostnad. Vissa verktyg drar hem stora mängder data och bearbetar dem lokalt, vilket blir trögt och dyrt på stora tabeller. Andra skickar smarta frågor direkt till lagret och låter det göra jobbet, vilket nästan alltid är att föredra när datan är stor. Jag tittar därför inte bara på hur snygga diagrammen är utan på hur verktyget beter sig mot datakällan under huven. En dashboard som tar trettio sekunder att ladda kommer ingen att använda, hur fin den än är. Caching kan hjälpa, men cache som inte uppdateras i tid skapar i stället förvirring när siffrorna verkar gamla.

Vanliga fallgropar

Den dyraste fällan är att välja efter demo i stället för efter förvaltning. Ett verktyg som ser imponerande ut i en säljdemo kan vara tungt att driva i vardagen. Jag tittar alltid på vem som ska äga rapporterna om ett år och om de orkar med det verktyget då.

Adoption är halva striden

Ett BI-verktyg som ingen använder är bortkastade pengar, oavsett hur kraftfullt det är. Jag har sett organisationer köpa det mest avancerade alternativet och sedan upptäcka att affärsfolket fortsätter exportera till Excel ändå, för att tröskeln var för hög. Därför väger jag in hur sannolikt det är att de tänkta användarna faktiskt tar till sig verktyget. Ibland är ett enklare verktyg som folk vågar öppna värt mer än ett mäktigt som bara datateamet behärskar. Jag brukar testa det tidigt genom att låta några riktiga slutanvändare bygga en egen rapport under en kort workshop. Klarar de det utan att fastna är det ett gott tecken.

Relaterat

• dbt-projektstruktur: Mappar, modeller och tests som skalar
• ETL vs ELT vs Reverse ETL: Modern data stack för svenska bolag
• Data quality-ramverk: Great Expectations + dbt tests i CI/CD

Vill du ta det vidare?

Vill du ha ett oberoende råd kring vilket BI-verktyg som passar er, utan att jag har en licens att sälja, hör av dig via kontaktsidan. Vi går igenom era behov och jag ger en rak rekommendation. Fler exempel på hur andra valt finns i vår casebook.