Power BI + Dynamics 365 Sales: Dashboardene som faktisk blir brukt

Power BI + Dynamics 365 Sales: Dashboardene som faktisk blir brukt

De fleste Power BI-dashboards bygd for D365 Sales blir aldri åpnet etter de første to ukene.

Det er ikke fordi de er stygge, eller fordi tallene er feil. Det er fordi de svarer på spørsmål ingen stilte — eller fordi de svarer på riktige spørsmål, men i et format som ikke passer inn i mottakerens hverdag.

Denne artikkelen handler om hvordan du bygger Power BI-rapporter mot D365 Sales som faktisk blir brukt — og hvordan du gjenkjenner et dashboard som ikke vil bli det.

Power BI Dynamics 365 Sales vs innebygde D365-dashboards: når er hva nok?

D365 Sales har innebygde dashboards. De er gratis, krever ingen ekstra lisens, og kan settes opp uten Power BI.

Når er de nok?

• For operasjonelle visninger brukerne ser daglig — "mine åpne opportunities", "denne ukens aktiviteter", "leads tildelt meg" — er D365 sine egne dashboards mer enn nok. Power BI er overkill her.
• For cross-entity analyse ("hva slags kunder konverterer best fra hvilke kampanjer?") og forecast og trend ("hvor godt forhold mellom pipeline-vekt og faktisk lukket revenue?") — der har Power BI tydelig fortrinn.
• For CFO- og styre-nivå — der lederen vil se finansielle aggregater på tvers av salg, marketing, og kanskje ERP — er Power BI nesten alltid det riktige valget.

Den vanlige feilen er å bruke Power BI til alt. Eller å bruke ingenting til noe. Mellomgrunnen — D365-dashboards for daglig drift, Power BI for analyse — fungerer bedre.

D365 sales dashboard: hvem leser hva

Det første spørsmålet å stille før du designer er ikke "hvilke data har vi?" — det er "hvem leser dette, og når?"

Vi har sett fire mottakergrupper med radikalt ulike behov:

Selgeren vil se:

• Sine egne åpne opportunities sortert etter vekt og forventet close
• Sine planlagte aktiviteter denne uken
• Sin pipeline mot kvote

Dette er ikke et "dashboard" i klassisk forstand — det er en arbeidsflate. Den åpnes flere ganger per dag, helst på mobil. Power BI er ofte for tungt her; D365 sine egne visninger er som regel bedre.

Best verktøy: D365 personlige visninger eller standard salgsdashboard.

Salgssjefen vil se:

• Pipeline-helse på tvers av teamet (mengde, alder, vekt)
• Forecast-treffsikkerhet over tid
• Aktivitetsnivå per selger
• Konvertering per stadium

Dette er klassisk Power BI-terreng. Det åpnes ukentlig, eller før salgsmøter. Det driver samtaler ("hvorfor har Per ingen aktiviteter denne uken?", "hvorfor har vi 12 deals i forhandlingsfasen siste 60 dager?").

Best verktøy: Power BI med scheduled refresh.

CFOen vil se:

• Forventet revenue per måned/kvartal
• Forecast vs. actual over tid
• Pipeline-konvertering i kroner
• Customer Acquisition Cost vs. Customer Lifetime Value, hvis dataene er der

Dette er finansielt aggregert. Det krever ofte krysskobling mot ERP — som er den klassiske bro-saken for Power BI.

Best verktøy: Power BI mot Microsoft Fabric eller datawarehouse.

CEO/styret vil se:

• Et håndfull KPI-er, ikke en analyse
• Trend over kvartal og år
• Avvik fra plan

Dette er det enkleste, ikke det mest komplekse, dashboardet. Det er én side. Ti tall. En graf. Ingen filtre.

Best verktøy: Én sertifisert Power BI-rapport, distribuert på e-post eller Teams-tile.

En enkelt-Power-BI-rapport som skal dekke alle fire grupper, blir sjelden brukt av noen av dem.

Oppsummering: D365 sales dashboard per rolle

Datamodellen under Power BI + Dynamics 365

Power BI er bare så god som datamodellen den leser fra.

Tre tilkoblings-tilnærminger til D365:

1. Direct Query mot Dataverse. Sanntid, men ytelsen avhenger av spørringskompleksitet. Bra for små datasett og når sanntid betyr noe. Mindre bra for komplekse aggregater.

2. Import-modus med scheduled refresh. Power BI henter en kopi av dataene typisk hver natt. Best ytelse, men data er aldri 100 % live.

3. Dataverse → Microsoft Fabric. Den moderne tilnærmingen for organisasjoner som vil ha både D365-data og data fra andre systemer (ERP, marketing) i samme lakehouse. Mer arbeid å sette opp, men gir mest fleksibilitet langsiktig.

For SMB-er er Import-modus med daglig refresh nesten alltid riktig. For større organisasjoner med flere datakilder, Fabric-arkitekturen vinner over tid. (Datafundament-tematikken dekkes også i CRM er ikke et masterregister.)

Hva som gjør et D365 sales dashboard faktisk brukt

Tre prinsipper vi har sett fungere:

1. Det svarer på et spesifikt spørsmål mottakeren faktisk stiller seg.

Ikke "Sales Overview". Det er for vagt. Heller "Hvilke deals er i fare denne måneden?" eller "Hvor mange leads konverterer fra hver kampanje, og hva er CAC?". Et dashboard som svarer på ett konkret spørsmål brukes ti ganger oftere enn ett som dekker ti vage.

2. Det levereres der mottakeren allerede er.

Salgssjefen leser ikke Power BI-portalen daglig. Hen leser Teams. Et Power BI-tile pinnet i en Teams-kanal, eller en automatisk PDF-rapport i innboks hver mandag morgen, øker faktisk bruk dramatisk.

3. Det inviterer handling, ikke bare observasjon.

"Pipeline-vekt: 14M NOK" er observasjon. "12 deals over 6 mnd gamle uten siste aktivitet" er handling. Den andre genererer en samtale, en oppfølging, en beslutning. Den første blir bekreftelse-tall.

Power BI-bygging vs. konfigurering

Power BI ut av boksen kan veldig mye uten kode. For et SMB-CRM-dashboard er det sjelden behov for DAX-magi.

Det som krever mer arbeid:

• Forecast-modeller som ikke bare summerer pipeline-vekt, men trekker inn historisk konverteringsrate per stadium og selger.
• Cohort-analyse av kunder over tid.
• Power BI Embedded i en kunde-portal eller eksternt system.
• Row-level security der ulike selgere ser ulike data.

For 80 % av organisasjoner er "ut av boksen + noen tilpassede visualer" nok. Det er sjelden Power BI-kompleksiteten som er flaskehalsen — det er data-kvaliteten under. (Se Dynamics 365 og Power Platform-oversikt for større plattform-konteksten.)

Mobil og distribusjon av Power BI Dynamics 365 Sales-rapporter

D365-mobilappen er primært for selgerens daglige bruk. Den fungerer for å logge en samtale, se en kontakt, oppdatere en deal — ikke for å lese en rapport.

Power BI-mobilappen, derimot, fungerer overraskende godt for ukentlig sjekk. En salgssjef kan se pipeline-helse på toget hjem fra et møte.

Distribusjon-tips som vi har sett virke:

• Pinn ett dashboard per rolle i Teams. Sales-leder har sitt; CFO har sitt.
• Automatiser ukentlig e-post med snapshot. Mandag 07:00, sammendrag av forrige uke.
• Hold Power BI-appen åpen på en skjerm i salgskontoret. Hvis det fysiske kontoret eksisterer.

Power BI governance: unngå rapport-jungelen

Power BI vokser. Etter 12 måneder har de fleste organisasjoner 20-50 rapporter, ulike workspaces, og uklare regler for hvem som kan endre hva.

Det betaler seg å sette opp tidlig:

• Workspace-struktur per avdeling eller funksjon. Ikke alle dashboards i samme workspace.
• Sertifiserte datasett. Når data-leader sier "dette er den offisielle revenue-modellen", er det den andre rapporter skal bygges på.
• Lifecycle-ansvar. Hvem fjerner en rapport som ingen åpner på 90 dager?

Et CRM-Power-BI-prosjekt som ikke planlegger for governance fra dag én ender ofte med en wild west av rapporter etter 18 måneder.

Realistisk Power BI Dynamics 365 Sales-leveranse

For en SMB med D365 Sales, et godt Power BI-dashboard-prosjekt:

• 4-8 uker fra start til go-live
• 2-5 dashboards som dekker de fire mottakergruppene
• Datakvalitet-vask i D365 som forutsetning (ofte 1-2 uker i seg selv)
• Følge-opp-runder 30 og 60 dager etter for å justere det som ikke ble brukt

Vellykkede prosjekter har færre dashboards som brukes mer. Lange backlog-prosjekter med 15 dashboards har ofte 2-3 som faktisk leves med.

Når Power BI Dynamics 365 Sales er feil verktøy

Det finnes situasjoner der Power BI er overdimensjonert:

• Et team på 3-5 personer der D365 sine egne dashboards og Excel-eksport er nok
• Når dataene endrer struktur ofte og rapportene må følge med
• Når det reelle problemet er datakvalitet, ikke visualisering — Power BI vil bare gjøre dårlige data raskere synlige

Og situasjoner der Power BI er underdimensjonert:

• Stort dataaggregat på tvers av D365, ERP, marketing-automation, eksterne kilder — Microsoft Fabric eller en dedikert datawarehouse-løsning passer bedre
• Komplekse statistiske modeller — Python eller R utenfor Power BI gir mer fleksibilitet
• Sanntids-ML-baserte spådommer — krever Azure ML eller lignende, ikke Power BI alene

Konklusjon

Et Power BI-dashboard er ikke verdifullt fordi det er pent. Det er verdifullt når noen faktisk åpner det, ofte, og gjør noe annerledes som følge av det de så.

Det krever at du vet hvem mottakeren er, hva de stiller seg av spørsmål, hvor de allerede leser sin info, og hva som genererer en handling fra dem. Alt det andre — connector, datamodell, DAX — er teknisk gjennomførbart for det meste.

D365 Sales gir dataene. Power BI gjør dem brukbare. Designet og kontekst-arbeidet er det som avgjør om de blir brukt.

CTA

---