Power BI + SAP Business One: So bekommst du aus ERP-Daten endlich nutzbare Dashboards

Definition

Power BI für SAP Business One bedeutet, Daten aus SAP Business One in Power BI zu laden, zu modellieren und als Berichte/Dashboards bereitzustellen. Es ist kein Ersatz für SAP Business One und auch keine Transaktionsoberfläche, sondern ein Analyse- und Reporting-Layer.

Einleitung

Wenn SAP Business One bei euch das ERP ist, steckt dort alles drin, was ihr fürs Controlling wirklich braucht. Power BI macht daraus Dashboards, die nicht nur hübsch aussehen, sondern tägliche Fragen beantworten: Was läuft gut, wo brennt es, und warum?

Warum „Power BI SAP Business One“ in der Praxis oft scheitert

Die Technik ist selten das Hauptproblem. Die typischen Bremsen sind Prozess und Datenlogik: Die gleiche Kennzahl wird unterschiedlich berechnet, Exporte werden manuell nachbearbeitet, und am Ende vertraut niemand den Zahlen.

• Unklare Datenquelle: „Welche Tabelle ist die Wahrheit?“ (z. B. Rechnung vs. Gutschrift vs. Storno)
• Falscher Verbindungsmodus: Livezugriff erzeugt langsame Reports und Stress auf der ERP-Datenbank
• Kein wartbares Modell: viele Einzelabfragen statt ein semantisches Modell, das mehrere Berichte trägt

Voraussetzungen & Kompatibilität (kurz und entscheidend)

Für Power BI mit SAP Business One brauchst du vor allem eine verlässliche, lesende Datenanbindung. SAP Business One läuft je nach Setup typischerweise auf SQL Server oder SAP HANA; beides ist grundsätzlich nutzbar, entscheidend ist der saubere Zugriff und ein stabiler Refresh.

• Technischer Zugriff: read-only User auf die SAP-B1-Datenbank, idealerweise nicht direkt auf der Produktiv-DB arbeiten
• Power BI Service Refresh: bei On-Premises-Quellen meist mit On-Premises Data Gateway und Service-Account
• Klare Datenverantwortung: Wer definiert KPIs (Fachbereich) und wer betreibt Datenzugriffe (IT)?

Schritt-für-Schritt: Verbindung und erstes Dataset aufsetzen

Der pragmatische Start ist ein kleines, eindeutiges Ziel: ein erstes Dataset für 1–2 Kernreports. So bekommst du schnell messbaren Nutzen, ohne gleich eine „BI-Großbaustelle“ zu eröffnen.

1) Datenzugriff klären

Lege einen dedizierten Datenbank-User mit rein lesenden Rechten an. Wichtig: keine persönlichen Accounts, sonst wird der Betrieb später unnötig fragil.

2) In Power BI Desktop anbinden

Verbinde dich mit SQL Server bzw. SAP HANA (je nach SAP-B1-Setup) und starte mit Import. Import ist für die meisten SAP-B1-Reporting-Szenarien die stabilere Basis, weil Berichte schnell reagieren und die ERP-Datenbank nicht bei jedem Klick belastet wird.

3) Erstes Dataset bauen (nur was du brauchst)

Wähle wenige Tabellen, die direkt Nutzen stiften, zum Beispiel für Sales/Finance. Typische SAP-B1-Tabellen sind OINV (Rechnungen), OITM (Artikel) und OCRD (Kunden). Danach: Datentypen bereinigen, Schlüssel prüfen, Dubletten vermeiden.

4) Refresh im Power BI Service einrichten

Veröffentliche das Dataset und richte den geplanten Refresh ein. Wenn die Quelle On-Premises ist, installiere das Gateway auf einer stabilen VM und betreibe es mit Service-Account. Ziel ist ein Refresh, der ohne „Desktop muss offen sein“ läuft.

Datenmodellierung: so werden SAP-B1-Daten reportfähig

Das Ziel ist ein Modell, das du wiederverwenden kannst: ein Dataset, viele Berichte. Dafür lohnt sich ein klares Star-Schema: Fakten (z. B. Umsatz) plus Dimensionen (Kunde, Artikel, Zeit). Der Nutzen für Anwender ist direkt spürbar: Filter funktionieren konsistent, Drilldowns sind nachvollziehbar, und KPIs sind überall gleich.

• Fakten schlank halten: Belegzeilen, Mengen, Werte, Datum, Schlüssel
• Dimensionen stabil bauen: Kunden, Artikel, Kalender als eigene Tabellen
• KPIs zentral definieren: lieber wenige, richtig definierte Measures als viele Spaltenlogiken

Performance, Sicherheit, Wartung: Best Practices die wirklich zählen

Für Akzeptanz ist Geschwindigkeit wichtiger als Feature-Tiefe. Und für die IT ist Betriebssicherheit wichtiger als der „perfekte“ Bericht.

• Performance: Import + sinnvolle Aggregation; vermeide „jede Visual fragt die DB“
• Sicherheit: Row-Level-Security dort, wo Rollen relevant sind (z. B. Vertrieb sieht nur eigene Kunden)
• Wartung: Dokumentiere Datenlogik, halte Abfragen modular, nutze einen Service-Account und klare Verantwortlichkeiten

Mini-Praxisfall: Umsatz- und Deckungsbeitragscockpit

Ein typischer Start ist ein One-Pager für Geschäftsführung und Controlling: Umsatz, Marge, Top-Artikel, Top-Kunden, Abweichung zum Vormonat. Der Drilldown führt von der KPI-Kachel bis zur Belegliste, damit Diskussionen nicht bei „Zahl stimmt nicht“ enden, sondern bei „welcher Beleg erklärt die Abweichung?“

Checkliste: schneller Selbsttest vor dem Start

• Ist geklärt, ob SAP Business One auf SQL Server oder HANA läuft und wie read-only Zugriff aussieht?
• Gibt es einen Service-Account + Gateway-Plan für automatischen Refresh?
• Sind 5–10 KPIs definiert, die wirklich genutzt werden (statt „wir laden erstmal alles“)?

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn ihr schnelle Ergebnisse wollt, aber gleichzeitig kein Risiko im Betrieb eingehen dürft. Typische Trigger: instabile Refreshes, Performance-Probleme, widersprüchliche KPI-Logik oder der Wunsch, aus einem ersten Report ein skalierbares Reporting-Setup zu machen.

Fazit

Power BI und SAP Business One passen gut zusammen, wenn Datenzugriff, Refresh und Datenmodell sauber aufgesetzt sind. Der größte Hebel ist nicht „mehr Daten“, sondern ein wartbares Dataset mit klaren KPIs, das Anwendern sofort Arbeit spart und Entscheidungen beschleunigt.

FAQs

Direkt aus SAP Business One oder über Data Warehouse?

Für den Start reicht oft die direkte Anbindung (meist Import). Wenn viele Quellen, viele Firmen/Mandanten oder komplexe Historisierung nötig sind, ist ein Data Warehouse/Lakehouse dazwischen oft die stabilere Option.

Wie messe ich den Erfolg?

An harten Effekten: weniger Excel-Aufwand, schnellerer Monatsabschluss, weniger Rückfragen zu Zahlen und mehr Self-Service-Nutzung statt Ticket-Pingpong.

Warum klappt der Refresh nicht zuverlässig?

Häufige Ursachen sind persönliche Gateways, wechselnde Credentials, instabile Netzwege oder zu große/ineffiziente Abfragen. Ein dedizierter Gateway-Betrieb mit Service-Account und schlankem Modell ist meist der Wendepunkt.