Pexon Consulting | 8 Min. Lesezeit | 01.06.2026
TL;DR
Power BI Copilot ist für die Standard-Vertriebs-Auswertung okay — in der Fertigung scheitert er an drei strukturellen Limits: Schema-Komplexität, fehlende Cross-System-Integration, kein Mid-Management-Use-Case. Die produktive Alternative für Mittelstand-Industriebetriebe heißt Claude Code mit MCP-Servern für SAP. Konkrete Pain-Points und Pattern aus drei Pilotprojekten.
Nachtrag, Stand 18.09.2026: Dieser Beitrag ist im Juni 2026 erschienen. Im April 2026 hat SAP die SAP API Policy in der Fassung 4.2026a veröffentlicht (abgerufen am 18.09.2026). Ziffer 2.2.2 untersagt die Nutzung von SAP-APIs für die Anbindung generativer oder (teil-)autonomer KI-Systeme, die Abfolgen von API-Aufrufen planen, auswählen oder ausführen, außer über von SAP vorgesehene Architekturen, Datendienste oder dienstspezifische Wege. Das gilt auch für lesende Zugriffe.
Für den Vergleich unten ändert das nichts an den vier Pain-Points von Power BI Copilot, wohl aber an der Bauweise der Alternative: Welche SAP-Aufrufe in welcher Reihenfolge passieren, gehört in den Flow, nicht in die freie Entscheidung des Modells. Soll das Modell selbst wählen, nennt SAP dafür eigene Wege, das MCP Gateway der SAP Integration Suite, SAP-eigene MCP-Server über Joule Studio und A2A. Was für Ihre Landschaft gilt, klärt verbindlich nur Ihr SAP-Vertrag oder Ihr SAP-Account-Team.
Was Microsoft auf der Industrie-Messe behauptet — und wo der Reality-Check ansetzt
Wer in den letzten 12 Monaten auf der Hannover-Messe oder der SPS-Nürnberg war, hat den Pitch gehört: „Mit Power BI Copilot fragt der Werkleiter einfach ‚wo verlieren wir Output?‘ und bekommt die Antwort.“ Auf der Demo-Bühne mit aufbereiteten Sample-Daten funktioniert das. Im echten Industriebetrieb mit Standard-SAP, einem MES-System, drei Excel-Insellösungen und der gewachsenen Datenmodell-Komplexität von 20 Jahren — nicht.
Wir haben das in drei konkreten Pilotprojekten 2025/2026 messen können. In allen drei Fällen war die Empfehlung am Ende dieselbe: Power BI Copilot als nettes Add-on für die Controlling-Abteilung, aber kein produktiver Hebel für die Fertigung. Stattdessen ein Custom-Agent mit MCP-Servern für die echten Quellsysteme.
Das ist kein Microsoft-Bashing. Power BI ist nach wie vor das beste BI-Tool im Mittelstand, der semantische Layer ist erstklassig. Der Copilot oben drauf ist das Problem — und in diesem Artikel geht es um die vier Gründe, warum.
Pain 1 — Schema-Komplexität in Fertigungs-Daten
Power BI Copilot funktioniert nur, solange das zugrunde liegende semantische Modell überschaubar bleibt. Microsoft selbst nennt 25-30 Tabellen als praktische Obergrenze, ab der die Antwortqualität abrutscht. In einem typischen SAP-Mittelständler reden wir aber über deutlich mehr: Materialstamm (MARA, MARC, MARD), Bewegungsdaten (MSEG, MKPF), Aufträge (AUFK, AFKO, AFVC, AFRU), Stücklisten (STKO, STPO, STAS), Arbeitspläne (PLKO, PLPO), Werke und Lager (T001W, T001L), Kalkulationen (KEKO, KEPH), und das ist nur die Spitze.
Wer das in ein Power-BI-Modell schiebt, landet bei 80-150 Tabellen. Der Copilot kann dann nicht mehr zuverlässig die richtigen Joins finden. Aus drei Pilots: ungefähr 35-50 % der Antworten waren faktisch falsch — der Copilot hat z.B. Material-Bewegungen mit Auftrags-Rückmeldungen verwechselt, weil beide Tabellen ein MENGE-Feld haben.
Wer das nicht selbst gemessen hat, hält die Demo-Beispiele für repräsentativ. Die Demo nutzt ein DAX-optimiertes Star-Schema mit 8-12 Tabellen — also genau das, was niemand in einer echten Fertigung hat.
Pain 2 — Power BI Copilot kann nicht Cross-System
Die zweite Wand kommt bei Cross-System-Fragen. Beispiel: „Warum hat Lieferant ACME die letzten drei Lieferungen verspätet?“ Das braucht: Bestellungen (SAP MM), Wareneingänge (SAP MM), E-Mail-Korrespondenz (Outlook / SharePoint), Lieferanten-Bewertung (oft Excel im SharePoint), Reklamations-Tickets (Jira oder ServiceNow).
Power BI Copilot lebt im Power-BI-Dataset. Cross-System-Joins funktionieren technisch über Composite Models, aber der Copilot versteht die Composite-Grenzen nicht. In allen unseren Tests hat er entweder nur das angeguckt, was in einem Modell lag, oder Halluzinationen über Datenquellen produziert, die er nicht wirklich gesehen hat.
Das ist nicht reparierbar mit besseren Prompts. Das ist eine architektonische Limitation, die Microsoft erst in der nächsten Major-Version adressieren will — und auch dort nur über M365-Copilot-Studio mit eigener Lizenz pro User.
Pain 3 — Power BI Copilot ist Controller-Tool, nicht Operations-Tool
Der dritte Pain ist der unterschätzte: Power BI Copilot ist von der DNA ein Reporting-Tool. Antworten kommen als Visual oder als textuelle Zahleninterpretation. Was die Fertigung aber wirklich braucht, sind Aktionen: einen Lieferanten anmailen, einen Auftrag verschieben, einen Wartungsplan generieren, einen FMEA-Draft erzeugen.
Diese Manager-Aktionen sind die echten Stundenhebel, wie wir im Beitrag zu den 7 Use-Cases für Manager in der Fertigung gezeigt haben. Keine davon ist mit Power BI Copilot umsetzbar — der Copilot kann eine Zahl interpretieren, aber kein PDF generieren, keine Mail entwerfen, kein Excel mit Vorschlägen befüllen.
Wer das ignoriert und Power BI Copilot trotzdem in die Fertigung schiebt, optimiert das, was sowieso schon halbwegs funktioniert (Controlling-Reports), und lässt die echten Hebel liegen.
Pain 4 — Lizenzkosten und Datenschutz-Boundary
Power BI Copilot kostet in der M365-Variante 30 USD pro User und Monat extra, in der Standalone-Premium-Variante deutlich mehr. Bei 50 Power-Usern in einer Mittelstands-Fertigung sind das schnell 18.000 USD pro Jahr, ohne dass ein einziger der Fertigungs-Use-Cases damit abgedeckt wäre.
Der zweite Punkt ist Datenschutz. Power BI Copilot läuft in der Microsoft-365-Service-Boundary. Für die meisten DSGVO-Use-Cases ist das okay, für KRITIS-Stadtwerke und für Fertigung mit Exportkontrolle (z.B. Rüstung, Dual-Use) ist die fehlende Region-Kontrolle ein Showstopper. Wir hatten zwei Pilots, die genau daran final gescheitert sind — der CISO hat die Freigabe verweigert.
Mit Claude Code über AWS Bedrock in eu-central-1 oder Azure OpenAI in einer EU-Region ist die Region-Kontrolle vertraglich und technisch sauber. Bei einer typischen Token-Last (3-8 EUR pro User und Monat) sind die laufenden Kosten zudem deutlich niedriger als die Power-BI-Copilot-Lizenz.
Warum Claude Code mit MCP+SAP funktioniert
Die produktive Alternative ist ein Custom-Agent-Setup mit drei Komponenten: Claude Code als Coding- und Workflow-Assistant, ein MCP-Server für SAP als Datenquelle und ein dünner Tool-Layer für die weiteren Systeme (MES, SharePoint, Outlook).
Drei strukturelle Vorteile gegenüber Power BI Copilot:
- Beliebige Schema-Komplexität. Das LLM sieht nicht das gesamte SAP-Schema, sondern nur die Tool-Beschreibungen des MCP-Servers. Pro Use-Case 8-12 Tools, sauber dokumentiert. Damit ist die Schema-Komplexität für das LLM konstant, egal wie groß das SAP-Backend wird. Der Werkzeugkatalog sagt dabei, wie ein Aufruf aussieht, nicht, dass das Modell ihn frei wählen darf: Bei SAP legt der Flow die Aufruffolge fest, das ist der Punkt aus Ziffer 2.2.2 der SAP API Policy.
- Native Cross-System-Joins. Der Flow ruft je nach Fragetyp SAP, Outlook und SharePoint nacheinander auf. Kein Composite-Model nötig. Bei Outlook und SharePoint kann die Auswahl beim Modell liegen; für die SAP-Seite ist sie im Flow festgelegt, weil die SAP API Policy 4.2026a genau diese Auswahl regelt. Antworten kommen aus drei oder vier Datenquellen, ohne dass jemand vorher ein Datenmodell baut.
- Aktionen statt Reports. Der Agent kann nicht nur lesen, sondern auch Dokumente generieren, Mails entwerfen, Excel-Tabellen ergänzen. Genau die Operations-Use-Cases, an denen Power BI Copilot scheitert.
Das ist kein Hex und kein Magic. Es ist Standard-Engineering — wir setzen das aktuell für Mittelstands-Fertiger ab 300 Mitarbeitern auf, typischerweise in 8-12 Wochen für den ersten produktiven Use-Case.
Concrete Migration Pattern — so läuft der Wechsel
Wer aktuell Power BI Copilot evaluiert oder einen gescheiterten Pilot hinter sich hat, muss nicht alles wegwerfen. Das pragmatische Migrationsmuster, das wir in zwei Pilots gefahren haben:
Power BI bleibt im Stack — als Visualisierungs-Backend für klassisches Controlling-Reporting. Power BI Copilot wird deaktiviert oder auf Sales-/Vertriebs-Use-Cases beschränkt, wo er tatsächlich Wert bringt. Für die Fertigung kommt der Custom-Agent dazu.
Konfidenz: hoch. Aus den drei Pilots ist das die Architektur, die in allen drei Fällen funktioniert hat — bei unterschiedlichen ERP-Versionen (S/4HANA, ECC 6.0) und unterschiedlichen Reifegraden.
Wann Power BI Copilot trotzdem die richtige Wahl ist
Fair-Play: Es gibt drei Szenarien, in denen Power BI Copilot die bessere Antwort ist als ein Custom-Agent.
- Reines Controlling-Reporting mit sauberem Star-Schema und 8-15 Tabellen. Hier funktioniert der Copilot überraschend gut, und die Lizenzkosten sind im Verhältnis zum Engineering-Aufwand eines Custom-Agents günstiger.
- Sales- und Marketing-Daten mit CRM-Anbindung (Dynamics), weil Microsoft die Datenmodelle hier nativ verstanden hat und die Cross-System-Limitation kein Problem ist.
- Power-BI-zentrische Organisationen mit M365 E5 und einem Reifegrad, der weitere Engineering-Investitionen kurzfristig nicht erlaubt. Power BI Copilot als „ist-eh-schon-da“-Hebel funktioniert für die nächsten 6-12 Monate, bis der nächste Investitionszyklus kommt.
Für die typische Mittelstands-Fertigung mit Pain in Produktion, QS und Einkauf — also genau dort, wo der größte Hebel sitzt — empfehlen wir den Custom-Agent. Power BI Copilot deckt das nicht ab und wird es in den nächsten 18 Monaten laut Microsoft-Roadmap auch nicht abdecken.
Häufig gestellte Fragen
Ist Power BI Copilot in der Fertigung grundsätzlich unbrauchbar?
Nein, nicht grundsätzlich. Für klassische Controlling-Auswertungen mit einem überschaubaren Datenmodell ist er okay. Für Operations-Use-Cases (Produktion, QS, Instandhaltung, Einkauf) scheitert er aktuell strukturell. Die richtige Aufteilung: Power BI Copilot für Controlling, Custom-Agent für Operations.
Was kostet ein Custom-Agent mit MCP-SAP-Server gegenüber Power BI Copilot?
Einmalig 60.000-85.000 EUR für Setup und ersten Use-Case, danach 8.000-15.000 EUR pro weiterem Use-Case. Laufende LLM-Kosten ca. 200-600 EUR pro Power-User und Jahr. Power BI Copilot kostet bei 50 Usern ca. 18.000 USD pro Jahr ohne Setup. Ab 3-4 produktiven Custom-Use-Cases (typisch nach 8-12 Monaten) ist der Custom-Agent günstiger UND leistungsfähiger.
Brauche ich für den Custom-Agent eigene Entwickler im Haus?
Nein. Wir setzen den Agent typischerweise gemeinsam mit dem Kunden-Team auf — Pexon übernimmt MCP-Server und Tooling, die Fachabteilung definiert Use-Cases und Pflicht-Felder. Nach Go-Live reicht ein dedizierter „Agent Owner“ mit 0,3-0,5 FTE für Monitoring und neue Use-Cases.
Kann ich Power BI Datasets gleichzeitig mit dem Custom-Agent nutzen?
Ja. Der Custom-Agent kann sehr gut auf Power-BI-Datasets als Tool zugreifen (über die Power BI REST API). Wir nutzen das in einem aktuellen Pilot, wo Controlling-Modelle in Power BI bleiben und der Agent diese als eine von vielen Datenquellen einbindet. Beste-aus-zwei-Welten-Pattern.
Was passiert mit M365 Copilot Studio? Ist das die Lösung für Cross-System?
Teils, und die Antwort hat sich im Juni 2026 geändert. SAP beschreibt seitdem selbst einen Weg dorthin: Copilot Studio als MCP-Client über das MCP Gateway der SAP Integration Suite, dokumentiert in einer eigenen Referenzarchitektur (abgerufen am 18.09.2026). Unter Ziffer 2.2.2 der SAP API Policy 4.2026a ist das zugleich der von SAP vorgesehene Weg, wenn ein Modell selbst entscheiden soll, welchen SAP-Dienst es aufruft. Voraussetzung ist die SAP Integration Suite. Ohne sie bleiben die alten Grenzen: keinen nativen RFC-Connector ohne Custom-Code, und Lizenzkosten, die stark mit der Nutzung skalieren. Unsere Einschätzung zum 18.09.2026: Wer die Integration Suite hat und einen frei wählenden Agenten will, nimmt das MCP Gateway. Wer einen festen Ablauf gegen SAP braucht, fährt mit dem Custom-Agent günstiger und flexibler.
Nächster Schritt
Wenn Sie aktuell Power BI Copilot in der Fertigung evaluieren oder einen gescheiterten Pilot hinter sich haben und die Alternative bewerten wollen: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — mit Use-Case-Schnitt in Woche 1 und produktivem Custom-Agent-Prototyp bis Woche 6.
Verwandte Themen
→MCP Server SAP: LangGraph Multi-Tool-Agent für Manufacturing
→Claude Code Fertigung: 7 Use-Cases jenseits des Werker-Hypes
→Microsoft Fabric — wenn Power BI doch das richtige Backend ist
