Power BI Navision: So klappt die Verbindung zu Dynamics NAV
Wir zeigen dir, wie du Power BI sauber mit Microsoft Dynamics NAV (Navision) verbindest – inklusive Voraussetzungen, Berechtigungen, Datenmodell und typischen Stolperfallen.
- OData, SQL oder Content Pack vergleichen
- Schritt-für-Schritt bis zum Dataset
- Sicherer Zugriff mit Azure AD
.png)
Wenn NAV-Zahlen in Excel stecken, kostet dich das jeden Monat Zeit
Viele NAV-Teams bauen Reports immer wieder neu: Export aus Microsoft Dynamics NAV, Excel zusammenkopieren, Filter nachziehen, Versionen verschicken.
Power BI löst das – aber nur, wenn Datenzugriff, Berechtigungen und Refresh von Anfang an sauber aufgesetzt sind. Sonst endet es in kaputten Refreshes, widersprüchlichen Reports und Frust bei Finance und Vertrieb.
Warum Power BI + NAV in der Praxis oft scheitert
Die Technik ist nicht das Problem. Die Details sind es: welcher Connect-Weg, welche Rechte, welches Datenmodell und wie du Reports wartbar hältst.
Falscher Verbindungsweg
OData connector, SQL-Datenbank oder Power BI content pack: Jeder Weg hat Grenzen bei Performance, Feldern, Filtern und Updates. Ohne Auswahlkriterien baut ihr am Bedarf vorbei.
Berechtigungen sind nicht geklärt
Wenn Rollen in NAV, Web Services und Power BI nicht zusammenpassen, funktionieren Reports nur im Desktop – oder nur für einzelne Nutzer. Sauber wird es mit Azure Active Directory und klaren Zugriffskontrollen.
Datenmodell fehlt
Viele starten mit „einfach mal connecten“ und bekommen dann unklare Kennzahlen. Ein gutes Dataset (saubere Fakten/Dimensionen, klare Measures) macht aus NAV-Data stabile Reports.
Ehrliche Partnerschaften führen zu erfolgreichen Datenprojekten.
Seit Jahren realisieren wir skalierbare Lösungen mit Microsoft Power BI, Fabric und Copilot.
Zertifizierungen
Projekte
zufriedenheit
Für wen lohnt sich Power BI mit Navision besonders?
Wenn du Microsoft Dynamics NAV als ERP nutzt und Finance/Controlling oder Vertrieb regelmäßig Reports braucht, ist Power BI der direkte Hebel: weniger Excel, mehr Transparenz.
Typische Signale: wiederkehrende Monatsreportings, manuelle Konsolidierung, viele „Kannst du mir schnell…?“-Anfragen und kein einheitliches Dashboard für Sales, Offene Posten oder Liquidität.
Was steckt im Paket?
Die wichtigsten Bausteine, damit Power BI Navision im Alltag funktioniert.
Connector-Auswahl & Setup
Wir vergleichen OData connector vs. SQL-Datenbank (inkl. Database views) vs. Power BI content pack – und wählen den Weg, der eure Reports stabil und erweiterbar macht.
Voraussetzungen & Rechte
Check von NAV-Usern, Service-Accounts, Web Services/OData, Netzwerkzugriff, Gateway (falls nötig) und Power BI Workspace-Konzept. Ziel: Zugriff für die richtigen Rollen, nicht für Zufall.
Datenmodell & Kennzahlen
Aufbau eines belastbaren Dataset: z.B. Umsatz (Sales), offene Aufträge, Debitoren/Kreditoren, Artikel, Lager, Deckungsbeitrag – mit klaren Measures und nachvollziehbaren Filtern.
Dashboards, Visualizations & Betrieb
Umsetzung von Reports und Dashboards mit Visualizations, Drilldowns und sauberem Refresh-Konzept. Optional: Contextual Power BI FactBox im ERP-Kontext (je nach Setup/Version).
Willst du einmal sauber klären, wie ihr NAV an Power BI anbinden solltet?
- Wir prüfen eure NAV-Datenzugriffe
- Ihr bekommt 2–3 Lösungsoptionen
- Klarer Pfad zu stabilen Reports
Gemeinsam erzielte Ergebnisse.
Zwei Beispiele aus der Praxis – typische NAV-Reporting-Situationen und wie der Weg zum Dashboard aussieht.
Handelsunternehmen: Sales- und Marge-Reporting aus NAV
Ausgangslage
- Sales-Reports als Excel-Export aus NAV
- Uneinheitliche Filterlogik je Abteilung
- Viele manuelle Korrekturen vor Meetings
- Unklare Definitionen für Rabatt/Marge
Ergebnis
- Ein zentrales Dataset für Sales-KPIs
- Dashboards mit Drilldown bis Beleg
- Standardisierte Visualizations und Filter
- Geplante Refreshes statt Handarbeit
Produktion: Lager, Einkauf und Cash im NAV-Reporting stabilisieren
Ausgangslage
- NAV-Daten teils nur über SQL erreichbar
- Reports brechen durch Refresh-Probleme ab
- Unklare Datenherkunft in mehreren Reports
- Keine konsistente Sicht auf Lager und OP
Ergebnis
- Data-Pipeline-Fundament in Fabric für NAV-Data
- Governance/Lineage mit Purview vorbereitet
- Einheitliche Berichte für Einkauf und Finance
- Stabilerer Betrieb durch klare Zugriffe
Unser Ansatz: In vier Phasen zum Erfolg
Unser Vorgehen als Route zum Gipfel: erst Klarheit, dann stabiler Connect, dann Reports, dann Skalierung.
Erstgespräch
Wir klären eure Ziel-Reports, Datenquellen, NAV-Version (klassisch NAV vs. Dynamics 365 Business Central), und wählen den passenden Integrationsweg (OData connector, SQL-Datenbank, Content Pack oder Zusatztools wie Jet Reports/Navida).
Setup
Wir richten die Verbindung ein (z.B. Web Services/OData oder SQL mit Database views), bauen das Dataset, testen Berechtigungen (Azure Active Directory/Power BI Rollen) und definieren den Refresh inklusive Fehlerbehandlung.
Training
Wir setzen 1–2 Kern-Reports um, erklären Modell und Measures, und zeigen euch, wie ihr Reports wartbar erweitert – statt jedes Mal neu zu basteln.
Skalierung
Danach skalieren wir: weitere Datenbereiche, zusätzliche Visualizations, Apps/Workspaces, Governance und – wenn sinnvoll – Datenmanagement über Microsoft Fabric für mehrere Quellen jenseits von NAV.
So fühlt sich Reporting mit NAV und Power BI danach an
Wenn Dataset, Rechte und Refresh stehen, werden aus NAV-Daten verlässliche BI-Berichte.
- Reports entstehen per Excel-Export aus NAV
- Unklare KPI-Definitionen je Abteilung
- Refresh klappt nur „bei manchen“
- Viele Einzellösungen, wenig Governance
- Fragen dauern, Entscheidungen warten
- Zentrales Dataset als „eine Wahrheit“
- Dashboards für Sales, Lager, Finance
- Geplanter Refresh mit nachvollziehbarer Fehleranalyse
- Rollenbasierter Zugriff, klar dokumentiert
- Schnellere, bessere Entscheidungen im Alltag
Wir lassen unsere Kunden für uns sprechen
SANHA GmbH & Co. KG
- Absatz- und Produktionsplanung auf Basis von Erfahrung statt Daten
- Unzureichende Transparenz über Nachfrageentwicklung am Markt führte zu Planungsunsicherheit
Ergebnis:
- KI-basierte Absatzprognosen als Grundlage für die Produktionssteuerung
- Effiziente Ressourcennutzung und frühzeitig erkennbare Nachfrageentwicklung
GBG Unternehmensgruppe
- Fragmentierte BI-Landschaft mit Tools wie Snowflake und Tableau
- Strategischer Wunsch nach Microsoft-Integration zur Vereinheitlichung
Ergebnis:
- Integration in das Microsoft-Ökosystem reduziert Systembrüche und vereinfacht die Datenarchitektur
- Unternehmensweite Migration von Tableau und Snowflake zu Power BI und Fabric
EW GROUP GmbH
- Daten aus zahlreichen internationalen Tochtergesellschaften waren verteilt und schwer vergleichbar
- Management hatte keinen konsolidierten Überblick über zentrale KPIs der einzelnen Gesellschaften.
Ergebnis:
- Zentrale Daten- und Reportingplattform schafft Transparenz über Kennzahlen aller Gesellschaften.
- Fundierte Managemententscheidungen auf Basis konsolidierter Daten statt isolierter Einzelreports.
Preisrahmen: vom ersten NAV-Dashboard bis zur Plattform
Der Umfang hängt vom Connect-Weg, euren Reports und dem Zielbild (nur Power BI oder plus Fabric) ab.
- Optionen-Check (OData/SQL/Pack)
- Technischer Connect & Rechte-Check
- Dataset-Grundlage für 1 Use Case
- Erster Report inkl. Best Practices
- Mehrere Reports & KPI-Set abgestimmt
- Sauberes Datenmodell mit Measures
- Refresh-Konzept inkl. Troubleshooting
- Berechtigungen & Workspace-Struktur
- Mehrere Quellen zusätzlich zu NAV
- Fabric-Setup für Datenmanagement
- Governance/Lineage mit Purview
- Rollout-Konzept für Fachbereiche
Willst du einmal sauber klären, wie ihr NAV an Power BI anbinden solltet?
- Wir prüfen eure NAV-Datenzugriffe
- Ihr bekommt 2–3 Lösungsoptionen
- Klarer Pfad zu stabilen Reports
Häufige Fragen
Wie verbinde ich Power BI mit Dynamics NAV (Navision) – OData oder SQL?
Beides ist möglich. Über den OData connector kommst du typischerweise über NAV-Web Services an Daten – oft gut für einen schnellen Start, aber je nach Datenmenge und Modell kann es bei Performance und Modellierung Grenzen geben. Über die SQL-Datenbank (z.B. über Views) hast du meist mehr Kontrolle und kannst Daten für Reports besser strukturieren. Welche Route passt, hängt von eurer NAV-Architektur, euren Reports und dem Refresh-Bedarf ab.
Welche Voraussetzungen und Berechtigungen brauche ich für NAV-Power-BI-Reports?
Du brauchst Zugriff auf die NAV-Daten (OData/Web Services oder SQL), passende NAV-Rechte für den genutzten Service-User und ein klares Power-BI-Berechtigungskonzept (Workspaces, App, Rollen). Für saubere Zugriffskontrollen empfiehlt sich die Einbindung über Azure Active Directory. Wichtig: Klärt früh, wer Daten sehen darf (z.B. nach Region/Team) und ob Row-Level-Security im Dataset nötig ist.
Wie funktioniert die Einbindung in Business Central im Vergleich zu NAV?
Dynamics 365 Business Central bietet moderne Anbindungswege und ist im Microsoft-Ökosystem stärker „cloud-ready“. Gleichzeitig ist das Ziel dasselbe: ein stabiles Dataset, saubere Reports und kontrollierter Zugriff. Wenn ihr von Microsoft Dynamics NAV Richtung Business Central geht, lohnt es sich, das Datenmodell so zu bauen, dass der Umstieg nicht zu einem kompletten Neuaufbau eurer Berichte führt.
Welche Alternativen gibt es – Content Pack, Jet Reports oder Navida?
Ein Power BI content pack kann für Standard-Reports ein schneller Start sein, stößt aber oft an Grenzen, sobald ihr eigene Logik, zusätzliche Quellen oder individuelle Visualizations braucht. Jet Reports ist eine etablierte Reporting-Option im NAV/Business-Central-Umfeld, oft stark in klassischen Reports. Navida wird ebenfalls genutzt, wenn spezielle Anforderungen oder vorhandene Setups im Haus sind. Wir empfehlen: erst Ziel-Reports festzurren, dann Tool- und Connect-Weg wählen – nicht umgekehrt.