Looker vs Power BI – En struktureret sammenligning

Looker vs Power BI

Power BI og Looker er to stærke BI-platforme, men de er bygget ud fra forskellige grundidéer.

Power BI er Microsofts BI-platform og er tæt integreret med Microsoft 365, Excel, Teams, Power Platform, Azure og Microsoft Fabric. Platformen er kendt for sin lave brugerbarriere, stærke visualiseringer og evne til hurtigt at få dashboards og rapportering ud i organisationen. Microsoft beskriver Power BI som en samlet, skalerbar platform til både self-service BI og enterprise BI.

Looker er Googles enterprise BI-platform og er bygget omkring et centralt semantisk lag, LookML, cloud data warehouses og governance-styret analyse. Google beskriver Looker som en BI-platform med fokus på governed intelligence, Gemini, cloud-first infrastruktur, API’er og et fleksibelt semantisk lag.

Derfor handler valget mellem Power BI og Looker sjældent om, hvilken platform der “kan mest” i absolut forstand. Begge platforme kan bruges til dashboards, KPI’er, datavisualisering, rapportering, self-service og embedded analytics. Den reelle forskel ligger i, hvordan platformene er bygget, og hvilken type dataorganisation de passer bedst til.

Power BI passer ofte godt til organisationer, der ønsker bred adoption, hurtig rapportering, Microsoft-integration og en relativt intuitiv brugeroplevelse.

Looker passer ofte godt til organisationer, der ønsker en stærk central datamodel, cloud-native BI, ensartede metrics, Git-baseret udvikling og høj governance på tværs af organisationen.

I denne Power BI vs Looker-artikel sammenligner vi platformene på tværs af de vigtigste områder: arkitektur, datamodel, performance, dataforberedelse, visualisering, self-service, governance, integration, AI, embedded analytics og totaløkonomi. Målet er ikke at kåre én vinder, men at give jer et klart beslutningsgrundlag.

1. Arkitektur og datamodel

Her sammenligner vi selve fundamentet i platformene.

Datamodellen er den struktur, der bestemmer, hvordan data organiseres, hvordan forretningslogik defineres, og hvordan brugerne kan analysere data.

Datamodellen afgør:

• Hvordan data forbindes

• Hvor beregninger og definitioner placeres

• Hvordan metrics styres og genbruges

• Hvor meget frihed brugerne har i analysen

• Hvor stærk governance organisationen kan opnå

• Hvor afhængig platformen er af et underliggende datavarehus

Datamodellen er ikke bare teknik. Den er afgørende for, om organisationen får én fælles forståelse af data, eller om der opstår mange lokale versioner af sandheden.

Power BI teknisk gennemgang: semantisk model, DAX og import engine

Power BI er bygget omkring en semantisk model, hvor tabeller, relationer, measures og beregninger defineres i Power BI-datasættet. Datamodellen er ofte relationsbaseret og designes typisk efter principper som star schema, dimensionstabeller og faktatabeller.

Power BI bruger blandt andet:

• Semantiske modeller

• Relationer mellem tabeller

• DAX til measures og beregninger

• Power Query til datatransformation

• VertiPaq engine ved import mode

• DirectQuery eller live connections ved behov for direkte forespørgsler mod datakilden

• Workspaces og certificerede datasæt til governance

Power BI er stærk, når organisationen ønsker at bygge et kontrolleret datalag, som rapportforfattere og forretningsbrugere kan bygge dashboards ovenpå.

Modellen er dog ofte tæt koblet til Power BI-universet. Det betyder, at meget forretningslogik kan ende med at ligge inde i Power BI-datasæt, DAX-measures og rapportstrukturer. Det kan fungere rigtig godt, men kræver disciplin, hvis flere teams bygger egne modeller parallelt.

Analyse inden for en Microsoft-orienteret model

I praksis betyder Power BI’s arkitektur, at organisationer kan komme hurtigt i gang med at bygge rapporter og dashboards.

Hvis en virksomhed allerede bruger Excel, Microsoft 365, Teams, SharePoint, Azure eller Dynamics 365, opleves Power BI ofte som en naturlig forlængelse af det eksisterende IT-landskab. Microsoft fremhæver selv integrationen med blandt andet Teams, PowerPoint, Excel og Power Platform.

Det gør Power BI særligt stærkt til organisationer, hvor dataarbejdet skal bredt ud til mange brugere. En controller, analytiker eller BI-medarbejder kan bygge datamodeller, oprette measures og publicere dashboards, som ledelse og forretning hurtigt kan bruge.

Power BI understøtter derfor en analyse-kultur, hvor rapportering, KPI’er, dashboards og løbende performance-opfølgning er centrale.

Styrken er hastighed, tilgængelighed og bred adoption.

Risikoen er, at governance kan blive udfordret, hvis mange brugere opretter egne datasæt, egne DAX-definitioner og egne rapportversioner uden en tydelig styringsmodel.

Looker teknisk gennemgang: LookML og semantisk lag

Looker er bygget omkring et centralt semantisk lag, hvor forretningslogik defineres i LookML. I stedet for at hver rapport eller hvert dashboard definerer sine egne beregninger, samles definitionerne i et fælles modelleringslag.

Looker bruger blandt andet:

• LookML som modelleringssprog

• Et centralt semantic layer

• Direkte SQL-forespørgsler mod cloud data warehouse

• Git-baseret versionering og udviklingsflow

• Explores som analyseindgange for brugere

• API’er og embedded capabilities

• Central governance af metrics og definitioner

Google beskriver Lookers semantiske lag som et lag direkte oven på cloud warehouse, hvor kompleks SQL oversættes til forretningssprog, og hvor forretningslogik defineres én gang i LookML.

Det betyder, at Looker i højere grad fungerer som et styret lag oven på organisationens datavarehus. Data bliver typisk ikke importeret ind i Looker på samme måde som i Power BI import mode. Looker sender i stedet forespørgsler videre til datavarehuset, hvor beregningerne udføres.

Analyse gennem en central semantic layer

I praksis betyder Lookers arkitektur, at organisationen kan definere centrale begreber som omsætning, dækningsgrad, churn, pipeline, kundeaktivitet eller lagerbinding ét sted.

Når en bruger efterfølgende bygger dashboards, udforsker data eller anvender embedded analytics, bygger analysen oven på de samme definitioner.

Det giver stærk konsistens.

Hvis “omsætning” er defineret i LookML, kan den samme definition bruges på tværs af dashboards, teams, API’er og embedded løsninger. Det reducerer risikoen for, at salg, økonomi og ledelse arbejder med forskellige tal for samme KPI.

Looker understøtter derfor en analyse-kultur, hvor datateams ejer den centrale model, mens forretningen kan udforske data gennem styrede rammer.

Styrken er governance, genbrug og konsistens.

Ulempen er, at platformen kræver mere teknisk modenhed. LookML, SQL, Git og cloud data warehouse-arkitektur stiller større krav til data teamet end klassisk drag-and-drop rapportering.

Den opsummerede forskel

Power BI bygger typisk analysen op omkring semantiske modeller, DAX, Power Query og et stærkt Microsoft-integreret rapporteringslag. Det giver hurtig adgang til dashboards, bred adoption og stærk integration i Microsoft-miljøer.

Looker bygger analysen op omkring LookML, et centralt semantic layer og direkte forespørgsler mod et cloud data warehouse. Det giver stærk governance, ensartede metrics og en mere udviklerstyret tilgang til BI.

Konklusion: Arkitektur og datamodel

Valget mellem Power BI og Looker på arkitektur-niveau handler om, hvor forretningslogikken skal bo.

Hvis I ønsker en BI-platform, hvor rapportering, datamodellering og visualisering kan bygges hurtigt i et Microsoft-miljø, er Power BI ofte det mest naturlige valg.

Hvis I ønsker en centraliseret datamodel, hvor metrics defineres én gang og genbruges på tværs af organisationen, kan Looker være stærkere.

Den grundlæggende forskel er derfor:

Power BI gør det let at bygge og distribuere BI bredt.

Looker gør det lettere at styre, standardisere og genbruge forretningslogik centralt.

2. Performance og skalerbarhed

Her sammenligner vi, hvordan platformene håndterer datamængder, kompleksitet og vækst.

Performance handler om:

• Hvor hurtigt rapporter loader

• Hvor effektivt beregninger udføres

• Hvordan platformen håndterer store datasæt

• Hvordan svartider påvirkes af mange brugere

• Hvor meget performance afhænger af datamodellen

• Hvor meget performance afhænger af underliggende infrastruktur
  

Skalerbarhed handler om:

• Hvor let løsningen kan vokse med organisationen

• Hvordan platformen håndterer flere datakilder

• Hvordan den håndterer flere brugere

• Hvordan kapacitet og compute styres

• Hvordan løsningen fungerer fra pilotprojekt til enterprise-platform

Når BI bliver forretningskritisk, er performance ikke et spørgsmål om pæne dashboards. Det er et spørgsmål om tillid, adoption og driftssikkerhed.

Power BI teknisk gennemgang: VertiPaq, DirectQuery og Fabric

Power BI kan arbejde på flere måder.

I import mode indlæses data i Power BI’s in-memory engine, VertiPaq. Det giver ofte høj performance, fordi data komprimeres og beregninger kan udføres hurtigt i hukommelsen.

Power BI kan også arbejde med DirectQuery, hvor forespørgsler sendes direkte til datakilden. Det kan være relevant ved store datamængder eller behov for næsten realtidsdata, men performance bliver i højere grad afhængig af datakildens hastighed, netværk, SQL-optimering og rapportdesign.

Power BI skaleres i dag tæt sammen med Microsoft Fabric. Microsoft beskriver Fabric som en samlet analyseløsning med funktioner til dataflytning, datasøer, dataudvikling, dataintegration, realtidsanalyse, overvågning og business intelligence.

Power BI’s performance afhænger derfor typisk af:

• Datamodellens kvalitet

• DAX-kompleksitet

• Import mode vs DirectQuery

• Antal samtidige brugere

• Premium- eller Fabric-kapacitet

• Datakildens performance

• Governance omkring datasæt og refresh

Power BI kan skaleres meget langt, men performance skal designes.

Hvad betyder det i praksis?

I mindre og mellemstore datamiljøer performer Power BI ofte rigtig stærkt. Særligt når datamodellen er korrekt designet, og rapporterne bygger på velstrukturerede importmodeller.

For ledelsesrapportering, KPI-dashboards, økonomirapportering, salgsopfølgning og operationelle rapporter vil Power BI ofte levere hurtig og stabil performance.

Når datamængderne vokser, og mange brugere arbejder samtidigt, bliver arkitekturvalgene vigtigere. Så kan der være behov for:

• Premium capacity

• Fabric capacity

• Aggregationslag

• Optimerede semantiske modeller

• Reduceret DAX-kompleksitet

• Klare refresh-strategier

• Bedre dataplatform under Power BI

Power BI er altså ikke kun et rapporteringsværktøj. I større organisationer bliver det en del af en samlet dataarkitektur.

Looker teknisk gennemgang: live queries mod cloud data warehouse

Looker fungerer anderledes.

Looker er typisk ikke bygget omkring, at data importeres ind i platformen og behandles internt. I stedet fungerer Looker som et modellerings- og analyseinterface oven på et cloud data warehouse.

Når en bruger åbner et dashboard eller stiller et spørgsmål, genererer Looker SQL baseret på LookML-modellen og sender forespørgslen til datavarehuset.

Det betyder, at performance i Looker i høj grad afhænger af:

• Datavarehusets performance

• SQL-optimering

• Datamodellens struktur

• BigQuery, Snowflake, Redshift eller anden warehouse-kapacitet

• Caching-strategi

• LookML-modellens kvalitet

• Query-kompleksitet

Google fremhæver særligt Looker sammen med BigQuery og beskriver kombinationen som en stærk dataplatform, hvor Lookers semantic layer kan forenkle komplekse datarelationer og skabe en fælles sandhedskilde.

Looker skalerer derfor ikke isoleret. Det skalerer sammen med det underliggende cloud data warehouse.

Hvad betyder det i praksis?

I praksis betyder det, at Looker er stærk i organisationer, der allerede har en moderne cloud data platform.

Hvis data ligger struktureret i BigQuery, Snowflake, Redshift eller lignende, kan Looker fungere som et stærkt analyse- og governance-lag ovenpå.

Fordelen er, at store datamængder ikke nødvendigvis skal flyttes ind i BI-værktøjet. Datavarehuset håndterer beregningerne, og Looker styrer logikken, definitionerne og brugeradgangen.

Det gør Looker særligt relevant i datatunge organisationer, hvor BI skal understøtte mange teams, mange datakilder og mange komplekse spørgsmål.

Ulempen er, at performance ikke alene kan løses i Looker. Hvis datavarehuset er dårligt modelleret, hvis SQL-forespørgslerne er tunge, eller hvis compute ikke er dimensioneret korrekt, vil brugerne opleve det direkte i rapporterne.

Looker kræver derfor et stærkt datagrundlag under platformen.

Den opsummerede forskel

Power BI kan levere meget høj performance via import mode og VertiPaq, men kræver optimeret datamodel, kapacitetsstyring og DAX-disciplin, når løsningen skalerer.

Looker skubber i højere grad beregningerne ned i datavarehuset. Det gør platformen stærk i cloud-native datamiljøer, men performance afhænger meget af datavarehusets struktur, kapacitet og optimering.

Konklusion: Performance og skalerbarhed

Hvis I ønsker hurtige dashboards, effektiv rapportering og stærk performance i et Microsoft-miljø, er Power BI ofte et stærkt valg, særligt når datamodellen er velbygget.

Hvis I allerede har en moderne cloud data warehouse-struktur og ønsker BI direkte oven på den, kan Looker være meget skalerbar.

Den afgørende forskel er, hvor performance skal optimeres:

I Power BI optimeres meget i BI-modellen.

I Looker optimeres meget i datavarehuset og LookML-laget.

3. Dataforberedelse og transformation

Her sammenligner vi, hvordan platformene håndterer data, før de bliver til analyser.

Dataforberedelse handler om:

• At hente data fra kildesystemer

• At rense og strukturere data

• At kombinere datakilder

• At definere beregninger

• At sikre datakvalitet

• At gøre data klar til analyse
  

Dårlige data bliver ikke gode, bare fordi de vises i et flot dashboard.

BI-platformens evne til at håndtere transformation er derfor afgørende for kvaliteten af rapporteringen.

Power BI teknisk gennemgang: Power Query, M og DAX

Power BI har stærke indbyggede funktioner til dataforberedelse.

Power Query bruges til at hente, rense og transformere data. Det foregår ofte i et visuelt interface, hvor brugeren kan:

• Fjerne kolonner

• Ændre datatyper

• Splitte felter

• Merge tabeller

• Append tabeller

• Filtrere rækker

• Oprette beregnede kolonner

• Strukturere data fra Excel, SQL, API’er og andre kilder

Under overfladen bruger Power Query M-sproget.

DAX bruges derefter til measures, beregninger og analytisk logik i datamodellen.

Det gør Power BI stærkt for analytikere, controllere og BI-udviklere, der ønsker at kunne arbejde med dataforberedelse og analyse i samme miljø.

Hvad betyder det i praksis?

I praksis betyder det, at Power BI kan fungere som både rapporteringsværktøj og let transformationslag.

For mange virksomheder er det en stor fordel. Man kan hente data fra ERP, CRM, Excel, databaser eller cloud-kilder, rense dem i Power Query og bygge rapporter ovenpå.

Det giver hurtig time-to-value.

Men i større enterprise-miljøer kan der opstå udfordringer, hvis for meget transformation sker inde i individuelle Power BI-filer eller datasæt.

Risikoen er:

• Dublerede transformationer

• Flere versioner af samme KPI

• Uens datarensning på tværs af rapporter

• Sværere dokumentation

• Kompleks DAX-logik

• Afhængighed af enkelte rapportudviklere

Derfor bør Power BI i større organisationer ofte kombineres med et mere robust datalag, eksempelvis Fabric, Azure Data Factory, SQL, data warehouse eller lakehouse.

Power BI er stærk til datatransformation, men det kræver governance at skalere.

Looker teknisk gennemgang: LookML frem for klassisk ETL

Looker er ikke primært et ETL-værktøj.

Looker forventer i højere grad, at data allerede er gjort klar i et datavarehus. Transformation, datarensning og integration ligger typisk før Looker, eksempelvis i:

• BigQuery

• Snowflake

• Redshift

• dbt

• ETL/ELT-værktøjer

• Cloud data pipelines

Looker bruges derefter til at definere forretningslogik, relationer og metrics i LookML.

LookML kan blandt andet definere:

• Dimensioner

• Measures

• Joins

• Explores

• Beregninger

• Filtreringslogik

• Adgangsregler

• Genbrugelige forretningsdefinitioner

Det betyder, at Looker ikke nødvendigvis er stedet, hvor rådata renses. Det er stedet, hvor rensede og strukturerede data gøres forståelige, konsistente og anvendelige for forretningen.

Hvad betyder det i praksis?

I praksis betyder det, at Looker kræver et mere modent datagrundlag.

Hvis organisationens data ligger spredt i Excel, manuelle exports, lokale databaser og usammenhængende systemer, er Looker sjældent første skridt alene. Så skal der først etableres en dataplatform, hvor data samles, renses og struktureres.

Når det fundament er på plads, kan Looker til gengæld give meget stærk kontrol over forretningslogikken.

Det er især værdifuldt, når flere teams skal bruge de samme begreber.

Eksempel:

Hvis salgsafdelingen, økonomiafdelingen og ledelsen alle arbejder med “omsætning”, kan definitionen styres centralt i LookML. Dermed undgår man, at hver afdeling selv fortolker KPI’en forskelligt.

Looker er derfor mindre self-service-ETL og mere governance-styret semantic modeling.

Den opsummerede forskel

Power BI har stærke indbyggede transformationsmuligheder via Power Query og DAX. Det gør platformen velegnet til organisationer, der vil hurtigt fra datakilde til dashboard.

Looker fokuserer mere på semantisk modellering oven på et datavarehus. Det gør platformen stærk i organisationer, der allerede har eller ønsker en moden dataplatform.

Konklusion: Dataforberedelse og transformation

Hvis I har behov for at rense, kombinere og modellere data direkte i BI-værktøjet, vil Power BI ofte være det mest praktiske valg.

Hvis I ønsker at placere transformation i en central dataplatform og bruge BI-laget til governance, metrics og genbrugelig forretningslogik, kan Looker være stærkere.

Den afgørende forskel er, om BI-platformen også skal være jeres primære transformationsværktøj, eller om transformationen skal ligge før BI-laget.

4. Visualisering og brugeroplevelse

Her sammenligner vi, hvordan platformene præsenterer data, og hvordan brugeren arbejder med analyserne.

Visualisering handler om:

• Dashboards

• Grafer

• KPI-kort

• Tabeller

• Drill-down

• Filtrering

• Designmuligheder

• Interaktivitet
  

Brugeroplevelse handler om:

• Hvor let platformen er at lære

• Hvor hurtigt rapporter kan bygges

• Hvor intuitiv analysen føles

• Hvor meget teknisk viden brugeren skal have

• Hvor godt platformen understøtter både ledelse, analytikere og data teams
  

Et BI-værktøj skaber først værdi, når brugerne faktisk anvender det.

Power BI teknisk gennemgang: drag-and-drop og stærkt visual layer

Power BI er kendt for sit stærke visualiseringslag.

Brugere kan relativt hurtigt bygge dashboards med:

• KPI-kort

• Søjlediagrammer

• Linjediagrammer

• Matrix-tabeller

• Kortvisualiseringer

• Slicers

• Drill-through

• Tooltips

• Bookmarks

• Custom visuals

• Rapportnavigation

Power BI føles ofte intuitivt for brugere, der allerede kender Excel og Microsofts måde at arbejde på.

Microsoft fremhæver også, at Power BI kan bruges til at oprette og dele analyserapporter, og at Power BI Desktop kan bruges til at oprette interaktive rapporter.

Hvad betyder det i praksis?

I praksis betyder det, at Power BI ofte er stærkt, når rapporter hurtigt skal ud til mange brugere.

En økonomimedarbejder kan bygge budgetopfølgning. En salgschef kan få pipeline-overblik. En driftsleder kan følge produktionstal. En direktion kan få KPI-dashboard.

Power BI egner sig særligt godt til:

• Ledelsesdashboards

• KPI-rapportering

• Økonomirapportering

• Salgsrapportering

• Operationel performance

• Self-service dashboards

• Standardiserede rapportpakker

Brugeroplevelsen er typisk mere “rapportorienteret” end Looker. Det betyder ikke, at Power BI ikke kan bruges analytisk, men platformens styrke er, at mange brugere hurtigt kan forstå og navigere i rapporterne.

Looker teknisk gennemgang: Explores, dashboards og modelstyret analyse

Looker har også dashboards og visualiseringer, men brugeroplevelsen er mere modelstyret.

Brugere arbejder ofte gennem:

• Dashboards

• Looks

• Explores

• Filtrering

• Drill-down

• Ad hoc-analyse

• Genbrugelige metrics fra LookML

• Embedded dataoplevelser

Looker er mindre orienteret omkring “træk og slip alt frit” og mere orienteret omkring styret udforskning af en central datamodel.

Det betyder, at brugeroplevelsen i høj grad afhænger af, hvor godt LookML-modellen er designet.

Hvis modellen er stærk, kan brugerne arbejde selvstændigt med data uden at skulle forstå den underliggende SQL.

Hvis modellen er svag eller ufærdig, kan Looker føles teknisk og begrænsende.

Hvad betyder det i praksis?

I praksis betyder det, at Looker er stærk, når brugerne skal udforske data inden for fælles definitioner.

En bruger kan gå ind i et Explore og undersøge salg, kunder, produkter eller aktivitet uden selv at skrive SQL. Men de felter, relationer og metrics, brugeren arbejder med, er defineret centralt.

Det giver en anden type self-service end Power BI.

Power BI giver ofte brugerne frihed til at bygge rapporter.

Looker giver ofte brugerne frihed til at udforske data inden for en styret semantisk model.

Looker er derfor stærk, når organisationen vil kombinere self-service med datakontrol.

Til gengæld kan nye brugere opleve en stejlere læringskurve, særligt hvis de kommer fra Excel, Power BI eller klassiske dashboardværktøjer.

Den opsummerede forskel

Power BI tilbyder en mere intuitiv og visuelt orienteret dashboardoplevelse, som mange forretningsbrugere hurtigt kan tage i brug.

Looker tilbyder en mere modelstyret analyseoplevelse, hvor brugerne arbejder med data gennem et centralt semantic layer.

Konklusion: Visualisering og brugeroplevelse

Hvis jeres vigtigste behov er flotte, intuitive og hurtigt anvendelige dashboards til mange brugere, vil Power BI ofte være det stærkeste valg.

Hvis jeres vigtigste behov er, at brugerne udforsker data med fælles definitioner og stærk governance i baggrunden, kan Looker være stærkere.

Den afgørende forskel er, om brugeroplevelsen primært skal være rapport- og dashboarddrevet, eller om den skal være model- og governance-drevet.

5. Self-service vs. central styring

Her sammenligner vi, hvordan platformene balancerer brugerens frihed med organisationens behov for kontrol.

Self-service handler om:

• At brugere selv kan bygge rapporter

• At brugere selv kan stille spørgsmål til data

• At brugere selv kan kombinere dimensioner

• At brugere ikke altid skal vente på IT eller BI-teamet
  

Central styring handler om:

• Ensartede KPI-definitioner

• Adgangsstyring

• Datakvalitet

• Governance

• Versionering

• Dokumentation

• Én fælles sandhed

Den svære balance i BI er ikke at vælge mellem frihed og kontrol.

Det svære er at designe en model, hvor begge dele kan eksistere samtidig.

Power BI teknisk gennemgang: governed self-service

Power BI understøtter self-service ved, at brugere kan oprette rapporter, bygge dashboards og arbejde med data i et relativt tilgængeligt interface.

Samtidig kan organisationen styre data gennem:

• Semantiske modeller

• Workspaces

• Rollebaseret adgang

• Row-Level Security

• Object-Level Security

• Certified datasets

• Deployment pipelines

• Microsoft Purview

• Fabric governance

Power BI kan derfor bruges som en governed self-service-platform.

BI-teamet kan definere centrale datasæt og datamodeller, mens forretningen bygger rapporter ovenpå.

Hvad betyder det i praksis?

I praksis betyder det, at Power BI kan skabe høj BI-adoption.

Mange brugere kan få adgang til data, bygge rapporter og arbejde selvstændigt.

Det er en stor styrke, især i organisationer hvor rapportering tidligere har været afhængig af Excel, manuelle exports eller centrale rapportbestillinger.

Men friheden kan også skabe udfordringer.

Hvis governance ikke er tydelig, kan der opstå:

• Mange datasæt med samme formål

• Flere versioner af samme KPI

• Uklare ejerskaber

• Rapportspredning

• Manglende dokumentation

• Forvirring om, hvilke tal der er officielle

Power BI er derfor stærkt til self-service, men kræver klare spilleregler.

Looker teknisk gennemgang: central model først

Looker starter et andet sted.

I Looker er den centrale model ikke noget, man eventuelt bygger senere. Den er selve fundamentet.

Forretningen arbejder oven på LookML-modellen, hvor datateamet har defineret relationer, metrics og forretningslogik.

Det betyder, at Looker i højere grad prioriterer central styring fra starten.

Self-service sker gennem:

• Explores

• Dashboards

• Looks

• Filtrering

• Drill-down

• Governed metrics

• Genbrugelige definitioner

Men brugerne arbejder ikke frit direkte med rådata på samme måde.

Det gør Looker stærkt, når organisationen ønsker self-service uden at give slip på datadefinitionerne.

Hvad betyder det i praksis?

I praksis betyder det, at Looker ofte passer godt til data-mature organisationer.

Det er organisationer, hvor man allerede har eller ønsker:

• Et stærkt data team

• En central dataplatform

• Fælles KPI-definitioner

• Versionering af datamodeller

• Git-baseret udviklingsproces

• Klar governance

• Dokumenteret forretningslogik

Looker kan være mindre spontant for en almindelig forretningsbruger at komme i gang med end Power BI, men til gengæld kan det give stærkere kontrol på tværs af organisationen.

Looker er derfor ikke nødvendigvis mindre self-service. Det er en anden type self-service.

Power BI giver mere rapport-self-service.

Looker giver mere governed data exploration.

Den opsummerede forskel

Power BI gør det let at brede BI ud til mange brugere og understøtter central styring gennem semantiske modeller, workspaces og governance-funktioner.

Looker bygger self-service oven på en central LookML-model og prioriterer konsistens, genbrug og datastyring fra starten.

Konklusion: Self-service vs. central styring

Hvis I ønsker bred adoption, hurtig rapportbygning og self-service for mange typer brugere, er Power BI ofte et stærkt valg.

Hvis I ønsker stærk central styring af metrics og forretningslogik, og hvis jeres datateam skal eje modellen centralt, kan Looker være stærkere.

Den afgørende forskel er, hvor meget frihed brugerne skal have i rapportlaget, og hvor meget der skal styres i datamodellen.

6. Governance, sikkerhed og compliance

Her sammenligner vi, hvordan platformene understøtter adgangsstyring, datakontrol, compliance og tillid til tallene.

Governance handler om:

• Hvem der må se hvilke data

• Hvordan KPI’er defineres

• Hvordan datamodeller ændres

• Hvordan rapporter godkendes

• Hvordan adgang dokumenteres

• Hvordan data lineage og audit håndteres

• Hvordan organisationen sikrer én fælles sandhed

Når BI bliver brugt til ledelsesbeslutninger, budgetter, drift, kunder og compliance, er governance ikke en teknisk detalje.

Det er fundamentet for tillid.

Power BI teknisk gennemgang: Microsoft governance og sikkerhed

Power BI er tæt koblet til Microsofts sikkerheds- og compliance-økosystem.

Platformen kan blandt andet bruge:

• Microsoft Entra ID

• Row-Level Security

• Object-Level Security

• Workspaces

• Sensitivity labels

• Microsoft Purview

• Audit logs

• Deployment pipelines

• Fabric governance

• Conditional Access

• Microsoft 365-politikker

Microsoft beskriver Fabric som en samlet platform med robust databeskyttelse, styring og overholdelse, og Power BI er en central BI-del af dette økosystem.

Det betyder, at Power BI ofte er særligt stærkt i organisationer, hvor IT allerede styrer brugere, adgang og compliance gennem Microsoft.

Hvad betyder det i praksis?

I praksis betyder det, at Power BI kan passe direkte ind i en eksisterende Microsoft-governance.

Hvis virksomheden allerede bruger Microsoft 365, Azure, Entra ID og Purview, kan Power BI-adgang og sikkerhed styres i en kendt struktur.

Det gør Power BI stærkt til:

• Enterprise governance

• Interne rapporteringsmiljøer

• Rollebaseret adgang

• Ledelsesrapportering

• Compliance-orienterede organisationer

• Microsoft-centrisk IT-drift

Udfordringen ligger typisk ikke i, om Power BI har governance-funktioner. Det har platformen.

Udfordringen er, om organisationen bruger dem konsekvent.

Looker teknisk gennemgang: governance gennem LookML og central model

Lookers governance ligger i høj grad i det centrale semantiske lag.

LookML gør det muligt at definere forretningslogik, relationer, metrics og adgangsregler centralt. Google fremhæver, at Lookers semantic layer kan skabe en fælles kilde til sandhed for metrics på tværs af enterprise-stakken.

Looker kan blandt andet understøtte:

• Central metric governance

• LookML-baserede definitioner

• Git-versionering

• Model reviews

• Adgangsstyring

• User attributes

• Row-level-lignende filtrering

• Audit og aktivitetslogning

• Centraliserede Explores

• Genbrug af forretningslogik
  

Looker er derfor stærk, når governance ikke kun handler om adgang, men også om semantisk konsistens.

Hvad betyder det i praksis?

I praksis betyder det, at Looker kan give stærk kontrol over, hvordan data forstås.

Det er ikke kun et spørgsmål om, hvem der må se hvilke rækker. Det er også et spørgsmål om, hvordan organisationen definerer sine nøgletal.

Hvis alle dashboards, analyser og embedded løsninger bygger på samme LookML-model, bliver det lettere at sikre, at KPI’er er konsistente.

Det er særligt værdifuldt i organisationer, hvor mange teams arbejder med samme data, men fra forskellige perspektiver.

Eksempel:

Marketing arbejder med kampagneperformance.

Salg arbejder med pipeline og omsætning.

Ledelsen arbejder med vækst og margin.

Finance arbejder med budget og forecast.

Hvis definitionerne styres centralt, reduceres risikoen for, at hvert team opfinder sine egne beregninger.

Den opsummerede forskel

Power BI er stærk på governance gennem Microsofts sikkerheds-, adgangs- og compliance-økosystem.

Looker er stærk på governance gennem et centralt semantic layer, LookML og modelstyret datadefinition.

Konklusion: Governance, sikkerhed og compliance

Hvis jeres governance primært skal forankres i Microsofts identitets-, sikkerheds- og compliance-struktur, vil Power BI ofte være det mest naturlige valg.

Hvis jeres governance primært handler om at styre metrics, forretningslogik og semantiske definitioner centralt, kan Looker være stærkere.

Den afgørende forskel er, om governance primært skal styres gennem IT-økosystemet eller gennem BI-platformens semantiske model.

7. Integration og økosystem

Her sammenligner vi, hvordan platformene passer ind i det øvrige IT-landskab.

Integration handler om:

• Datakilder

• Cloud-platforme

• Office-værktøjer

• Data warehouses

• API’er

• Automatisering

• Embedded analytics

• Samarbejdsværktøjer

• Strategisk IT-retning

Valget af BI-platform er sjældent isoleret. Det hænger næsten altid sammen med organisationens øvrige teknologivalg.

Power BI teknisk gennemgang: Microsoft-first økosystem

Power BI er dybt integreret med Microsofts økosystem.

Det gælder blandt andet:

• Excel

• Teams

• PowerPoint

• SharePoint

• Power Platform

• Azure

• Microsoft Fabric

• OneLake

• Dynamics 365

• Microsoft 365

Microsoft fremhæver direkte, at Power BI-rapporter kan integreres og deles i Microsoft-tjenester som Teams, PowerPoint, Excel og Power Platform.

Det gør Power BI til et meget naturligt valg i virksomheder, hvor Microsoft allerede er den primære digitale arbejdsflade.

Hvad betyder det i praksis?

I praksis betyder det, at Power BI ofte har lav integrationsbarriere.

Brugere kan arbejde med data i Excel, dele indsigter i Teams, præsentere rapporter i PowerPoint og bygge automatiseringer med Power Automate.

For mange organisationer er dette en stor fordel, fordi BI bliver en del af de værktøjer, medarbejderne allerede bruger.

Power BI passer derfor godt til organisationer, der ønsker:

• Tæt integration med Microsoft 365

• Rapportering i Teams og SharePoint

• Excel-nær BI

• Azure-baseret dataarkitektur

• Fabric som samlet dataplatform

• Power Platform-integration

Power BI’s styrke er ikke platform-neutralitet. Styrken er dyb integration i Microsofts økosystem.

Looker teknisk gennemgang: Google Cloud og cloud data warehouse

Looker er tæt knyttet til Google Cloud, men er også designet til at arbejde oven på moderne cloud data warehouses.

Looker kan blandt andet bruges sammen med:

• BigQuery

• Snowflake

• Redshift

• Google Cloud

• Google Workspace

• Google Sheets

• API’er

• Embedded applikationer

• SaaS-produkter

• Moderne dataplatforme

Google fremhæver Looker on Google Cloud med funktioner som Google Cloud IAM, private networking og integration med BigQuery.

Det betyder, at Looker passer særligt godt til organisationer, der har valgt Google Cloud eller en cloud-native data warehouse-strategi.

Hvad betyder det i praksis?

I praksis betyder det, at Looker er stærk, når BI skal fungere som et lag oven på en moderne dataplatform.

Hvis organisationen allerede har investeret i BigQuery, Snowflake eller en tilsvarende warehouse-struktur, kan Looker skabe et governance- og analyseinterface ovenpå.

Looker passer derfor godt til organisationer, der ønsker:

• Cloud-native BI

• BigQuery-integration

• Semantic layer oven på warehouse

• API-baseret integration

• Embedded analytics

• Data apps

• Genbrug af metrics på tværs af løsninger

Lookers styrke er ikke nødvendigvis, at alle medarbejdere allerede kender brugerfladen. Styrken er, at platformen kan blive et centralt, genbrugeligt datalag for mange forskellige analyseoplevelser.

Den opsummerede forskel

Power BI er stærkest i Microsoft-økosystemer, hvor BI skal integreres med Teams, Excel, PowerPoint, Azure, Fabric og Microsoft 365.

Looker er stærkest i cloud-native datamiljøer, hvor BI skal bygges oven på et cloud data warehouse og et centralt semantic layer.

Konklusion: Integration og økosystem

Hvis jeres organisation allerede er Microsoft-baseret, vil Power BI ofte være det mest oplagte valg.

Hvis jeres organisation arbejder cloud-native, særligt med Google Cloud eller moderne data warehouses, kan Looker være et stærkt valg.

Den afgørende forskel er ikke kun antal connectors. Det handler om, hvilket økosystem BI-platformen skal være en naturlig del af.

8. AI og avanceret analyse

Her sammenligner vi, hvordan platformene passer ind i det øvrige IT-landskab.

Integration handler om:

• Datakilder

• Cloud-platforme

• Office-værktøjer

• Data warehouses

• API’er

• Automatisering

• Embedded analytics

• Samarbejdsværktøjer

• Strategisk IT-retning

Valget af BI-platform er sjældent isoleret. Det hænger næsten altid sammen med organisationens øvrige teknologivalg.

Power BI teknisk gennemgang: Copilot og Microsoft Fabric

Power BI’s AI-strategi er tæt forbundet med Copilot og Microsoft Fabric.

Microsoft fremhæver, at brugere med Copilot kan oprette rapporter, oprette DAX-beregninger, lave oversigter og få svar på samtalesprog.

Power BI kan blandt andet understøtte:

• Copilot i rapportopbygning

• DAX-generering og forklaring

• Tekstlige opsummeringer

• Q&A på data

• AI visuals

• Forecasting

• Integration med Azure AI

• Fabric som samlet data- og analyseplatform

Det gør Power BI stærkt for organisationer, der allerede arbejder med Microsofts AI-strategi.

Hvad betyder det i praksis?

I praksis betyder det, at Power BI gør AI mere tilgængeligt for forretningsbrugere.

Brugere kan få hjælp til at bygge rapporter, forstå dashboards og skrive DAX. Det kan sænke barrieren for at arbejde med data.

Power BI’s AI-styrke ligger især i:

• Rapportgenerering

• Analyseassistance

• DAX-hjælp

• Dashboard-opsummeringer

• Microsoft 365- og Fabric-integration

AI bliver dermed en del af den eksisterende Microsoft-arbejdsflade.

Looker teknisk gennemgang: Gemini og agentic BI

Lookers AI-strategi er tæt knyttet til Gemini og Google Cloud.

Google beskriver Looker som en agentic BI-platform, hvor Gemini, cloud-first infrastruktur, API’er og semantic layer arbejder sammen.

Looker fokuserer blandt andet på:

• Conversational analytics

• Dashboard agents

• Gemini-understøttet analyse

• Natural language querying

• AI-first data apps

• Semantic layer som grundlag for troværdige AI-svar

• API’er til conversational analytics

• Embedded AI-dataoplevelse

En vigtig pointe er, at Lookers semantic layer giver AI’en et styret datagrundlag. Hvis AI skal svare på forretningsspørgsmål, er det afgørende, at den bygger på korrekte og konsistente definitioner.

Hvad betyder det i praksis?

I praksis betyder det, at Lookers AI-styrke ligger i kombinationen af conversational analytics og et centralt semantic layer.

AI bliver ikke bare en assistent oven på dashboards. Den bliver knyttet til de forretningsdefinitioner, der allerede er styret i LookML.

Det kan være stærkt i organisationer, hvor AI skal bruges til mere end at opsummere rapporter.

Eksempel:

En bruger spørger: “Hvorfor faldt dækningsgraden i sidste måned?”

Hvis Looker-modellen indeholder styrede definitioner for omsætning, vareforbrug, dækningsgrad, kundegrupper og produktkategorier, kan AI’en arbejde med et mere kontrolleret datagrundlag.

Looker passer derfor godt til organisationer, der ser AI som en del af en bredere governed data strategy.

Den opsummerede forskel

Power BI’s AI-styrke ligger i Copilot, Fabric og Microsoft-integreret analyseassistance.

Lookers AI-styrke ligger i Gemini, conversational analytics, AI-agenter og et semantic layer, der kan give AI et styret datagrundlag.

Konklusion: AI og avanceret analyse

Hvis I allerede arbejder i Microsofts AI- og Fabric-økosystem, vil Power BI være et naturligt valg.

Hvis I ønsker AI-understøttet BI baseret på en central semantisk model og Google Cloud, kan Looker være stærkere.

Den afgørende forskel er, om AI primært skal hjælpe med rapportering og analyse i Microsoft-økosystemet, eller om AI skal bygges oven på et cloud-native semantic layer.

9. Embedded analytics og API

Her sammenligner vi, hvordan platformene kan integreres i egne applikationer, kundeportaler og digitale produkter.

Embedded analytics handler om:

• At indlejre dashboards i egne systemer

• At bygge kundeportaler med data

• At tilbyde analytics i SaaS-produkter

• At styre adgang og sikkerhed programmatisk

• At bruge API’er og SDK’er

• At bygge skræddersyede dataoplevelser

Når BI ikke kun er intern rapportering, men en del af et produkt, bliver embedded analytics afgørende.

Power BI teknisk gennemgang: Power BI Embedded

Power BI tilbyder embedded analytics gennem Power BI Embedded.

Microsoft beskriver Power BI Embedded som et Azure PaaS-tilbud, hvor appudviklere kan integrere interaktive rapporter i deres apps uden selv at bygge datavisualiseringer og kontrolelementer fra bunden.

Power BI Embedded bygger typisk på:

• Azure-kapacitet

• Embed tokens

• Service principals

• JavaScript SDK

• REST API

• Row-Level Security

• Integration med Azure AD/Entra ID

• Kapacitetsbaseret betaling

Power BI Embedded er særligt oplagt i Microsoft- og Azure-baserede applikationsmiljøer.

Hvad betyder det i praksis?

I praksis betyder det, at Power BI kan bruges til at integrere rapporter i interne portaler, kundeportaler eller applikationer.

Det er især relevant for organisationer, der allerede har Azure-kompetencer og Microsoft-identitetsstyring.

Power BI Embedded er stærkt til:

• Interne portaler

• Kundeportaler

• Microsoft-baserede SaaS-løsninger

• Standardiserede dashboards i apps

• Hurtig embedded BI uden at bygge alt selv

Til gengæld er det typisk mest naturligt, når resten af arkitekturen også ligger tæt på Microsoft.

Looker teknisk gennemgang: API-first og embedded analytics

Looker har en stærk embedded- og API-orienteret position.

Google fremhæver Lookers embedded capabilities og Looker APIs som centrale funktioner til at bygge custom data experiences, AI-first data apps og embedded data products.

Looker kan blandt andet bruges til:

• Embedded dashboards

• Custom analytics interfaces

• API-baserede dataoplevelser

• SaaS analytics

• Kundeportaler

• Data monetization

• Conversational analytics i egne applikationer

• Genbrug af LookML-logik i eksterne løsninger

Looker er derfor stærk, når BI skal være en integreret del af et digitalt produkt.

Hvad betyder det i praksis?

I praksis betyder det, at Looker ofte er relevant for virksomheder, der ønsker at bygge analytics ind i egne platforme.

Det kan være:

• SaaS-virksomheder

• Platform businesses

• Kundeportaler

• Dataprodukter

• Interne specialapplikationer

• AI-baserede dataoplevelser

Lookers styrke er, at embedded analytics kan bygge oven på den samme LookML-model som den interne BI.

Det betyder, at interne dashboards, kundeportaler og API-baserede løsninger kan bruge samme metric-definitioner.

Det giver en stærk kobling mellem governance og produktudvikling.

Den opsummerede forskel

Power BI Embedded er stærkt i Azure- og Microsoft-baserede embedded scenarier.

Looker er stærkt i API-first, cloud-native og produktorienterede embedded scenarier, hvor semantic layer og genbrug af forretningslogik er centralt.

Konklusion: Embedded analytics og API

Hvis I vil indlejre rapporter i Microsoft- eller Azure-baserede applikationer, er Power BI Embedded ofte et stærkt valg.

Hvis I vil bygge skræddersyede dataoplevelser, SaaS analytics eller kundeportaler oven på et centralt semantic layer, kan Looker være stærkere.

Den afgørende forskel er, om embedded analytics primært skal være indlejrede rapporter, eller om det skal være en integreret del af et datadrevet produkt.

10. Total Cost of Ownership

Her sammenligner vi den samlede økonomi ved at eje og drive platformen.

TCO handler ikke kun om licenspris.

TCO handler om:

• Licenser

• Platformskapacitet

• Cloud-forbrug

• Datavarehus

• Implementering

• Udvikling

• Vedligehold

• Governance

• Uddannelse

• Kompetencekrav

• Support

• Skalering

• Embedded analytics

• Drift over tid

Den største fejl er at sammenligne Power BI og Looker udelukkende på pris pr. bruger.

Den reelle økonomi ligger i, hvordan platformen implementeres og skaleres.

Power BI økonomisk gennemgang

Power BI har typisk en mere tilgængelig og gennemsigtig indgang end Looker.

Microsoft beskriver, at Power BI-licenser kan kombineres på flere måder, eksempelvis med Premium-kapacitet, Fabric-kapacitet og Power BI Pro-licenser til brugere, der skal oprette og publicere rapporter.

TCO i Power BI påvirkes især af:

• Antal brugere

• Pro-licenser

• Premium/Fabric-kapacitet

• Behov for Report Server

• Embedded analytics

• Datamodellering

• DAX-udvikling

• Governance

• Azure/Fabric-infrastruktur

• Support og vedligehold

Power BI kan være meget omkostningseffektivt i små og mellemstore scenarier, især hvis virksomheden allerede har Microsoft-licenser og Microsoft-kompetencer.

Hvad betyder det i praksis?

I praksis betyder det, at Power BI ofte har lavere startbarriere.

Det gør platformen attraktiv for virksomheder, der vil hurtigt i gang med BI uden en stor enterprise-aftale fra dag ét.

Men TCO kan stige, når:

• Antallet af brugere vokser

• Rapporter bliver forretningskritiske

• Premium eller Fabric bliver nødvendigt

• Der kommer mange datasæt

• Governance skal professionaliseres

• Embedded analytics skal implementeres

• Dataplatformen skal udbygges

Power BI er ofte billigt at starte med, men ikke nødvendigvis simpelt at skalere uden styring.

Looker økonomisk gennemgang

Looker har typisk en mere enterprise-orienteret prismodel.

Google beskriver Looker pricing som en kombination af platform pricing og user pricing, og at man skal kontakte salg for at finde den rigtige løsning. Google beskriver også forskellige editions som Standard, Enterprise og Embed med årlig forpligtelse.

TCO i Looker påvirkes især af:

• Platform pricing

• User pricing

• Edition

• Cloud data warehouse-forbrug

• BigQuery/Snowflake/Redshift compute

• LookML-udvikling

• Data engineering

• Git- og deployment-processer

• Governance-setup

• Embedded analytics

• API-brug

• Dataplatformens modenhed

Looker er derfor sjældent det billigste valg for en mindre virksomhed, der blot ønsker simple dashboards.

Til gengæld kan Looker give en mere robust økonomi i organisationer, hvor mange teams skal bruge samme semantiske model, og hvor BI skal indgå i en større dataplatform.

Hvad betyder det i praksis?

I praksis betyder det, at Looker ofte kræver større investering upfront.

Man skal typisk have:

• Et stærkt datateam

• Et moderne datavarehus

• LookML-kompetencer

• Governance-processer

• Klar dataarkitektur

Men hvis organisationen allerede har dette, kan Looker reducere skjulte omkostninger ved inkonsistente KPI’er, dublerede rapporter og parallelle datamodeller.

Lookers økonomiske styrke ligger derfor ikke nødvendigvis i lav licenspris. Den ligger i genbrug, styring og skalerbarhed i komplekse datamiljøer.

Den opsummerede forskel

Power BI har typisk lavere indgangsbarriere og er ofte økonomisk attraktivt i Microsoft-miljøer og klassiske rapporteringsscenarier.

Looker har typisk højere enterprise-barriere, men kan give stærk værdi i organisationer med moderne dataplatform, central governance og behov for semantic layer på tværs af BI, API’er og embedded løsninger.

Konklusion: Total Cost of Ownership

Hvis I ønsker en omkostningseffektiv vej ind i BI og allerede arbejder i Microsoft-økosystemet, vil Power BI ofte være det mest tilgængelige valg.

Hvis I arbejder med komplekse datamiljøer, cloud data warehouse, embedded analytics og central metric governance, kan Looker være en mere strategisk investering.

Den afgørende forskel er ikke, hvilken platform der er billigst pr. bruger.

Det er, hvilken platform der giver den mest bæredygtige dataarkitektur over tid.

Overordnet konklusion

Power BI og Looker kan begge være det rigtige valg.

Men de passer typisk til forskellige typer organisationer, forskellige teknologiske miljøer og forskellige måder at arbejde med data på.

Power BI er stærk, når organisationen ønsker bred BI-adoption, hurtig rapportering, stærke dashboards og tæt integration med Microsofts økosystem.

Power BI giver typisk mest mening, hvis I:

• Allerede arbejder i Microsoft 365, Teams, Excel, Azure eller Fabric

• Ønsker hurtig time-to-value

• Har mange forretningsbrugere, der skal bruge dashboards

• Vil bygge ledelsesrapportering og KPI-overblik

• Har behov for en intuitiv brugeroplevelse

• Ønsker self-service BI med mulighed for central governance

• Vil integrere BI i Microsofts sikkerheds- og compliance-struktur
  

Looker er stærk, når organisationen ønsker central styring af metrics, cloud-native BI, semantisk modellering, Git-baseret udvikling og stærk governance på tværs af mange teams.

Looker giver typisk mest mening, hvis I:

• Har en moderne cloud data warehouse-struktur

• Arbejder med BigQuery, Snowflake, Redshift eller lignende

• Ønsker ét centralt semantic layer

• Vil definere KPI’er og metrics én gang

• Har et stærkt data team

• Ønsker governance-styret self-service

• Skal bygge embedded analytics eller data products

• Vil bruge BI som en del af en bredere cloud-native datastrategi
  

Den vigtigste beslutning er derfor ikke:

“Hvilken platform er bedst?”

Men snarere:

“Hvilken platform passer bedst til vores dataarkitektur, vores kompetencer og den måde, vi ønsker at styre og bruge data på?”

Hvis BI primært skal være et bredt rapporteringsværktøj i Microsoft-økosystemet, vil Power BI ofte være det mest naturlige valg.

Hvis BI skal være et centralt, semantisk og governance-styret datalag oven på et cloud data warehouse, kan Looker være det stærkere valg.

---

Er I i tvivl om, hvilken platform der passer bedst til jeres behov?

Kontakt Capana – så hjælper vi jer med at afklare krav, datagrundlag og ambitionsniveau, og vi anbefaler den løsning, der passer til jeres organisation.

Tag fat i os for en uforpligtende sparring – og få et konkret bud på næste skridt.