Eine These, die in der SAP-Beraterszene noch niemand laut ausspricht: Wenn KI-Agenten heute schon MSPs ihre eigene PSA-Software bauen lassen – warum sollte im BI-Umfeld etwas anderes gelten? Ein Gedankenexperiment zu SAP Analytics, Qlik, Crystal Reports und Power BI.
Der Auslöser: Was gerade bei den MSPs passiert
In der Managed-Services-Branche vollzieht sich derzeit ein bemerkenswerter Wandel. MSPs wie MIPGlobal oder ITPartners+ ersetzen reihenweise SaaS-Tools durch selbst gebaute KI-Agenten – vom CRM bis zum Reporting. Die Begründung ist immer dieselbe: Warum sechs Monate auf die Roadmap eines Anbieters warten, wenn der eigene KI-Agent das Problem in zwei Wochen löst?
Genau diese Logik lässt sich eins zu eins auf das SAP-Reporting-Umfeld übertragen. Und dort steht mit SAP Analytics (Cloud), Crystal Reports und Wettbewerbern wie Qlik oder Power BI ein ganzes Marktsegment, das strukturell erstaunlich ähnlich funktioniert: Der Fachanwender hat einen Informationsbedarf, kann ihn aber nicht selbst umsetzen, und beauftragt einen Berater oder Key User, der das Reporting-Tool bedient. Genau dieser Vermittlungsschritt gerät durch generative KI unter Druck.
Die Hypothese
These: Sobald Fachanwender in der Lage sind, ihre Analyse- und Reporting-Anforderungen in natürlicher Sprache zu formulieren und eine KI daraus direkt eine SQL- oder HANA-Abfrage sowie eine passende Visualisierung generiert, verliert die klassische BI-Werkzeugkette, insbesondere im Beratungsgeschäft, einen Teil ihrer Existenzberechtigung. Nicht weil die Tools schlecht wären, sondern weil der teuerste Teil der Wertschöpfungskette, nämlich die Übersetzung von Fachfrage in technische Abfrage, zunehmend von der KI übernommen wird statt vom Berater oder vom lizenzierten Self-Service-Layer.
Konkret: Wer heute für eine Ad-hoc-Auswertung einen Crystal-Report bauen lässt oder eine SAP Analytics-Story pflegt, könnte morgen einfach fragen:"Zeig mir den Wareneingang der letzten 90 Tage nach Lieferant, gruppiert nach Verzögerung in Tagen."
Ein KI-Agent mit Zugriff auf das HANA-Schema übersetzt das in eine korrekte SQL-Abfrage, liefert Tabelle und Diagramm, ganz ohne SAP Analytics-Lizenz, ohne Story-Design, ohne Crystal-Reports-Layout.
Was dafür spricht
- Self-Service ist bereits die erklärte Zielrichtung von SAP Analytics selbst. Die Marketingaussage lautet seit Jahren, Fachanwendern Analysen zu ermöglichen, ohne die IT einzubinden. KI-gestützte Text-zu-SQL-Funktionalität erfüllt dieses Versprechen konsequenter, als es die bisherige Klick-Oberfläche je konnte.
- Der Lizenzdruck ist real. SAP Analytics-Einzellizenzen bewegen sich je nach Ausbaustufe zwischen rund 50 EUR und mehreren Hundert EUR pro Nutzer und Monat. Bei Qlik Sense Enterprise SaaS kalkulieren Vergleichsportale mit rund 3.600 EUR pro Nutzer und Jahr, während sich die geschätzten Gesamtkosten für 100 Nutzer je nach Tool zwischen 150.000 und 400.000 EUR pro Jahr bewegen können. Crystal Reports kommt zwar günstiger, bindet aber erhebliche Beraterstunden für Layout- und Formelpflege.
- Der eigentliche Engpass war nie das Werkzeug, sondern das Wissen, wie man die richtige Frage stellt. Genau das kann eine KI mit gutem Datenmodell-Kontext heute leisten.
Was dagegenspricht – und warum die Analogie zur MSP-Branche hier hinkt
Genau an diesem Punkt lohnt sich der Blick auf die Gegenstimmen aus dem MSP-Artikel. ScalePad-CEO Chris Day beschreibt es mit dem Eisberg-Bild: Der Prototyp ist der sichtbare, glänzende Teil über der Wasseroberfläche. Darunter liegt alles, was Software tatsächlich betriebssicher macht – Berechtigungen, Audit-Logs, Integrationen, Skalierbarkeit. Im SAP-Umfeld ist dieser unsichtbare Teil sogar noch größer, aus vier Gründen:
- Berechtigungskonzept und Datenschutz. SAP Analytics und Qlik bilden komplexe, oft feldwertabhängige Berechtigungsstrukturen ab (z. B. Umsatzdaten nur je Vertriebsregion sichtbar). Ein selbst gebauter KI-Agent, der direkt SQL gegen die HANA-Datenbank fährt, muss dieses Berechtigungsmodell erst nachbauen – sonst entsteht ein handfestes Datenschutz- und Compliance-Risiko. Das ist kein Detail, sondern der Kern jeder professionellen Reporting-Architektur.
- GoBD-Konformität und Revisionssicherheit. Wer Auswertungen erzeugt, die in steuerlich relevante Prozesse einfließen, bewegt sich im Geltungsbereich der GoBD. Nachvollziehbarkeit, Nachprüfbarkeit und Unveränderbarkeit (§§ 140–148 AO, § 238 ff. HGB) sind keine Nice-to-haves, sondern Pflicht. Eine Ad-hoc-KI-Abfrage, die bei jeder Formulierungsänderung ein leicht anderes Ergebnis liefern kann, ist für Managementinformationen unproblematisch, aber für prüfungsrelevantes Reporting jedoch grundsätzlich ungeeignet, solange Versionierung, Logging und Reproduzierbarkeit fehlen.
- Semantische Korrektheit ist kein Selbstläufer. Ein KI-Agent generiert syntaktisch valides SQL zuverlässig. Ob die Abfrage aber betriebswirtschaftlich korrekt ist, z.B. ob etwa "Umsatz" Netto oder Brutto meint, ob stornierte Belege korrekt ausgeschlossen werden, ob Perioden nach Buchungs- oder Lieferdatum abgegrenzt werden, all das erfordert tiefes Verständnis des zugrunde liegenden Datenmodells. Genau hier passieren die teuersten Fehler, weil sie unauffällig aussehen und trotzdem falsch sind.
- Skalierung und Verbreitung. Eine SAP Analytics-Story oder ein Crystal Report lässt sich zentral pflegen, terminieren, an 200 Empfänger verteilen und mit definierten Rollen versehen. Ein Chat-Interface pro Einzelfrage skaliert dafür schlecht; und wer dieselbe Auswertung jeden Montag will, braucht am Ende doch wieder ein festes, versioniertes Artefakt.
Die Kostenrechnung: Lizenz vs. Token
Ein nüchterner Blick auf die reinen Rechenkosten zeigt, warum das Argument "KI ist billiger" zu kurz greift. Aktuelle API-Preise für ein leistungsfähiges Sprachmodell wie Claude Sonnet liegen bei etwa 3 EUR pro Million Input-Token und 15 EUR pro Million Output-Token, wobei Input- und Output-Token getrennt abgerechnet werden. Eine einzelne Ad-hoc-Abfrage samt Kontext (Datenmodell-Schema, Berechtigungsregeln, Vorjahresvergleich) verbraucht selten mehr als ein paar Tausend bis niedrige Zehntausend Token, das liegt im Centbereich, nicht im Euro-Bereich.
Auf den ersten Blick schlägt das jede SAP Analytics- oder Qlik-Lizenz um Längen. Die eigentlichen Kosten entstehen aber nicht bei der einzelnen Abfrage, sondern bei:
- dem Aufbau und der Pflege des Datenmodell-Kontexts, den die KI braucht, um korrekte Abfragen zu generieren (Tabellenbeziehungen, Geschäftslogik, Berechtigungsregeln als Kontext-Dokumentation),
- der Qualitätssicherung, also einer fachlichen Prüfinstanz, die verhindert, dass halluzinierte oder semantisch falsche Abfragen ungeprüft in Managemententscheidungen einfließen,
- und dem Betrieb der Infrastruktur (Datenbankzugriff, Logging, Berechtigungsprüfung), die im Lizenzmodell von SAP Analytics oder Qlik bereits enthalten ist, beim Eigenbau aber komplett neu entstehen muss.
Genau das ist Chris Days Punkt: Der Prototyp kostet Cent, die produktionsreife, revisionssichere, berechtigungskonforme Lösung kostet Berater- und Wartungsstunden – und die verschwinden nicht, sie verschieben sich nur.
Fazit: Kein Ersatz, aber eine Verschiebung der Wertschöpfung
Die Hypothese in ihrer radikalen Form, dass SAP Analytics, Qlik und Crystal Reports überflüssig werden, hält der Prüfung nicht stand, zumindest nicht für unternehmenskritisches, prüfungsrelevantes oder breit verteiltes Reporting. Dafür sind Governance, GoBD-Konformität und Berechtigungskonzepte zu zentral, um sie nebenbei neu zu erfinden.
Realistischer ist eine zweigeteilte Zukunft, wie sie sich auch im MSP-Artikel abzeichnet: Standardisierte, wiederkehrende, verteilte Auswertungen bleiben in SAP Analytics, Qlik oder als gepflegter Crystal Report bestehen.
Der explorative, spontane Analysebedarf, also die Frage, die heute noch eine Ticket-Warteschlange beim Berater durchläuft, wandert zunehmend zur KI-gestützten Selbstbedienung ab, vorausgesetzt, jemand hat vorher ein sauberes, dokumentiertes und berechtigungskonformes Datenmodell dafür geschaffen.
Für die Beratungsbranche bedeutet das eine Verschiebung, kein Verschwinden:
Weniger Wertschöpfung im Bauen einzelner Reports, mehr Wertschöpfung im Aufbau des semantischen und Governance-Fundaments, auf dem KI-Agenten überhaupt sicher arbeiten können. Wer als SAP-Berater heute noch Story-Layouts pixelt, sollte sich morgen eher als Architekt für KI-taugliche, GoBD-konforme Datenmodelle positionieren – nicht als deren Ersatz, sondern als deren Voraussetzung.
*Ausgangspunkt und Analogie dieses Artikels: CRN-Bericht "KI-Coding stellt das MSP-Softwaremodell auf den Kopf" (crn.de, 22.07.2026).*