Konzeptkarte

SAP BusinessObjects BI Platform

Stand 2026-08-29

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP BusinessObjects BI Platform?

Worum es geht

SAP BusinessObjects BI Platform ist der On-Premise-Serverbestand, der die klassischen SAP-Reporting-Werkzeuge beherbergt: Web Intelligence, Crystal Reports und — zu ihrer Zeit — Design Studio, Lumira Designer, Analysis, Dashboards und Explorer. Über „BusinessObjects“ zu sprechen, als wäre es ein Report-Designer, übersieht, was den Ausstieg tatsächlich erschwert. Die Plattform ist ein Central Management Server mit einem Rechtemodell, einer Ordnerstruktur, einer Scheduling-Engine, die Tausende Instanzen an Postfächer und Dateiablagen ausliefert, einem Publikationsmechanismus mit Bursting und einer semantischen Schicht aus Universes, von der jeder Bericht abhängt.

Deshalb ist die Migration keine Report-Konversionsübung. Ein Kunde mit viertausend Berichten hat meist eine viel kleinere Zahl wirklich unterschiedlicher Berichte und eine viel größere Menge umgebender Maschinerie: Empfängerlisten, zeilenbasierte Sicherheit über Universe-Restriction-Sets, geplante Verteilungen mit Geschäftsverantwortlichen, mit denen seit Jahren niemand mehr gesprochen hat, und Integrationen, die exportierte Dateien konsumieren. Die Berichte zu ersetzen ist die sichtbare Hälfte; die Plattformverhalten zu ersetzen ist die Hälfte, die entscheidet, ob die Migration gelingt.

Die semantische Schicht verdient eigene Aufmerksamkeit. Universes — UNV im klassischen Designer, UNX im Information Design Tool — kodieren Joins, Kontexte, Aggregate Awareness und Sicherheit. Sie sind ein echter Vermögenswert, und sie haben auf der anderen Seite kein originalgetreues Äquivalent: SAP Analytics Cloud konsumiert Live-Verbindungen und Datasphere-Modelle, was ein anderes Modellierungsparadigma ist, kein anderes Dateiformat. Ein Universe wird neu ausgedrückt, nicht konvertiert.

Einen BusinessObjects-Bestand ehrlich lesen. Statt einer Berichtszahl das CMS-Inventar anfordern: Objekte nach Typ, geplante Instanzen pro Monat, unterschiedliche Universes und die Zahl der Berichte, die im letzten Quartal tatsächlich geöffnet wurden. Diese letzte Zahl ist meist ein Bruchteil der Gesamtzahl, und sie ist es, die die Arbeit dimensioniert. Dann fragen, wem die Zeitpläne gehören.

Wartungshorizonte der Plattform wurden mehr als einmal veröffentlicht, verlängert und neu veröffentlicht. Die aktuelle Product Availability Matrix lesen, keine Folie — auch nicht diese.

Der auslösende Faktor für die meisten BusinessObjects-Bestände ist überhaupt kein BusinessObjects-Datum — es ist das, worüber der Bestand berichtet. Ein großer Teil der BusinessObjects-Universes und Crystal-Verbindungen zeigt auf klassisches SAP BW, und die Mainstream-Wartung von BW 7.5 endet am 31. Dezember 2027, mit optionaler kostenpflichtiger erweiterter Wartung bis 2030 (SAP-Wartungsankündigung, 23. April 2020). Wenn die Quelle ausläuft oder zu Datasphere migriert, muss jedes darauf aufgebaute Universe neu ausgedrückt werden, unabhängig davon, was BusinessObjects selbst gerade auf seiner eigenen PAM-Uhr tut. Die beiden Zeitachsen als gekoppelt behandeln, nicht als identisch: Ein Kunde kann BusinessObjects Jahre vor der BW-Frist außer Betrieb nehmen — oder gezwungen sein, jedes Universe anzufassen, sobald sich die BW-Quelle darunter ändert, weit bevor die Plattform selbst ausläuft.

Bei der Dauer geht die Schätzung gleich zweimal daneben. Ein CMS-Nutzungsextrakt dauert typischerweise ein bis zwei Wochen, um korrekt gezogen und interpretiert zu werden — die meisten Verzögerungen entstehen, weil niemandem das Scheduling-Postfach gehört, nicht durch das Werkzeug. Einmal nach Nutzung statt nach Inventar dimensioniert, läuft ein mittelgroßer Bestand (einige hundert wirklich aktive Berichte, einige Dutzend Universes) sechs bis zwölf Monate bis zur Ablösung; ein Bestand mit starkem Bursting an externe Empfänger oder regulatorischen Verteilungen läuft regelmäßig länger, weil diese Verteilungen als gleichwertig nachgewiesen werden müssen, bevor jemand den Cutover freigibt — nicht bloß nachgebaut.

Die Entscheidung, die das erzwingt, und der Kompromiss darin. Sobald das nutzungsbasierte Inventar existiert, organisiert eine Entscheidung das gesamte Programm: die überlebenden Berichte auf dem Ziel neu bauen oder ablösen. Ein Bericht, der im letzten Quartal zweimal geöffnet wurde, ist ein Kandidat für die Ablösung, nicht für die Konversion, und der Kompromiss ist politisch, nicht technisch — die Ablösung eines Berichts kostet ein Gespräch mit seinem Eigentümer, während die Konversion eine Budgetposition plus eine Wartungspflicht kostet, die das Projekt überlebt. Eine zweite Entscheidung folgt aus der ersten, und sie ist die, die Schätzungen vergessen: Jedes Plattformverhalten — Bursting, Publikationssicherheit, geplante Verteilung an externe Empfänger — wird reimplementiert, durch einen anderen Mechanismus ersetzt oder fallengelassen. Das muss pro Verteilung entschieden werden, mit benanntem Geschäftsverantwortlichen, statt einmal für den gesamten Bestand auf einer Folie festgelegt zu werden.

Warum es zählt

Die meisten SAP-Kunden berichten immer noch aus BusinessObjects, und die Plattformverhalten — Scheduling, Bursting, Universe-Sicherheit — sind das, was eine Migration unterschätzt. Die Berichtszahl ist die falsche Kennzahl.

Kernpunkte

Ein Serverbestand, kein Report-Designer: CMS-Rechtemodell, Ordner, Scheduling, Publikationen und Bursting, plus die semantische Universe-Schicht.
🔴 Die Berichtszahl ist die falsche Scoping-Kennzahl. Objekte nach Typ, monatlich geplante Instanzen, unterschiedliche Universes und im letzten Quartal tatsächlich geöffnete Berichte sind die richtigen.
Universes (UNV/UNX) kodieren Joins, Kontexte, Aggregate Awareness und zeilenbasierte Sicherheit — im Ziel neu ausgedrückt, niemals konvertiert.
SAC konsumiert Live-Verbindungen und Datasphere-Modelle: ein anderes Modellierungsparadigma, kein anderes Dateiformat.
Wartungshorizonte wurden mehr als einmal verlängert — die aktuelle Product Availability Matrix lesen, keine Folie.
Die Entscheidung, die das Programm organisiert, ist Neubau-oder-Ablösung, getroffen pro Bericht anhand der Nutzung im letzten Quartal — nicht pro existierendem Bericht.
Plattformverhalten (Bursting, Publikationssicherheit, externe Verteilung) werden pro Verteilung mit benanntem Geschäftsverantwortlichen entschieden, nie einmal für den gesamten Bestand.

Quellen

In der App öffnen →