BI-Migration

Ein Wechsel des BI-Tools hat meist einen äußeren Anlass: Lizenzkosten, ein Wartungsende, zu viele parallele Systeme oder der Wunsch nach einer Lösung, die besser zur übrigen IT passt. Die Umstellung betrifft dann Berichte, Datenmodelle und Gewohnheiten gleichzeitig.

Wir begleiten solche Wechsel, am häufigsten von Qlik, Tableau oder SAP BusinessObjects zu Power BI und von Power BI Premium zu Fabric-Kapazitäten. Andere Richtungen kommen vor, etwa zu Tableau, Looker oder den BI-Funktionen einer Datenplattform. Die Beispiele auf dieser Seite haben Power BI als Ziel, weil das der Normalfall ist. Ein vollständiger Nachbau ist dabei nicht das Ziel. Das neue System soll die Fragen der Fachbereiche besser beantworten als das alte.

Nicht jeder Bericht zieht um

Am Anfang steht ein Inventar: Berichte, Datenquellen, Berechnungen, Berechtigungen und die Frage, wer sie baut und wer sie nutzt. Viele Systeme protokollieren Zugriffe, daraus lässt sich eine Nutzungsanalyse machen. Sie trennt die Berichte, die jede Woche geöffnet werden, von denen, die seit Jahren niemand ansieht.

Jeder Bericht bekommt dann eine von vier Entscheidungen. Er zieht unverändert um, er wird neu gebaut, weil Datenmodell oder Darstellung besser werden sollen, er geht mit ähnlichen Berichten in einem auf, oder er wird abgeschaltet. Wer stattdessen jeden alten Bericht kopiert, nimmt auch dessen Schwächen mit. Maßgeblich ist, welche Entscheidung ein Bericht unterstützen soll, nicht wie er bisher aussah.

Die Logik muss übersetzt werden

Berechnungen sind der aufwendigste Teil, weil die Tools unterschiedlich arbeiten. Qlik Sense lädt per Skript und verknüpft Tabellen assoziativ über gleichnamige Felder, Power BI arbeitet am besten mit einem Sternschema. Eine reine Kopie fällt deshalb meist schlechter aus als ein Neuaufbau mit gleicher Aussage.

Aus Qlik kommend gehören Ladeskripte in die Datenaufbereitung, in Power Query oder besser in eine Datenpipeline, und Set Analysis lässt sich oft mit CALCULATE und Filtern in DAX ausdrücken. Berechnete Felder und LOD-Ausdrücke aus Tableau werden zu Kennzahlen im semantischen Modell. Ein Universe aus SAP BusinessObjects entspricht im Kern einem semantischen Modell, die Web-Intelligence-Dokumente werden zu Berichten.

Tabellen eins zu eins zu übernehmen, bringt wenig. Wir bauen das Datenmodell neu auf und definieren die Kennzahlen zentral. Das dauert länger als eine Kopie, macht aber jeden späteren Bericht einfacher. Versteckte Berechnungen in Skripten und Berichten tauchen oft erst beim Abgleich auf, dafür planen wir Zeit ein.

KI-Assistenten schreiben brauchbare Entwürfe für DAX und erklären bestehende Formeln. Die Ergebnisse sehen oft richtig aus und liefern trotzdem andere Zahlen, etwa weil der Filterkontext ein anderer ist. Wir nehmen sie deshalb nur als Vorlage und testen jede Formel gegen die Werte des Altsystems.

Wenn ein Wartungsende den Takt vorgibt

Bei SAP BusinessObjects läuft für ältere Releases die Standardwartung aus. SAP führt die Plattform mit neueren Releases fort, eine Ablösung ist also eine Option und kein Zwang. Einzelne ältere Komponenten sind in den neuen Releases nicht mehr enthalten, was auch bei einem Upgrade Aufwand verursachen kann. Für SAP BW 7.5 endet ebenfalls die Standardwartung, eine erweiterte Wartung ist gegen Aufpreis möglich. Die Wege führen unter anderem zu BW/4HANA, zur SAP Business Data Cloud oder zu einem Data Warehouse außerhalb von SAP.

Bei Power BI Premium stellt Microsoft die Kapazitäten mit P-SKUs ein und sieht Fabric-Kapazitäten (F-SKUs) als Nachfolger vor. Bestehende Verträge laufen bis zum Ende ihrer Laufzeit, Lizenzen pro Nutzer wie Pro oder Premium Per User sind nicht betroffen. Die Umstellung ist vergleichsweise klein: Man kauft die neue Kapazität zuerst, ordnet die Arbeitsbereiche zu und prüft Aktualisierungen, Berichte und Gateways. Wartungsfristen und Vertragsbedingungen klärt man besser direkt mit dem Hersteller. Wechsel zwischen Cloud-Plattformen für Daten behandeln wir hier nur am Rand.

Parallelbetrieb, Schulung und Abschalten

Altes und neues System laufen eine Zeit lang nebeneinander. Wir gleichen die wichtigen Kennzahlen ab, und zwar über mehrere Monats- und Quartalsabschlüsse hinweg, denn manche Fehler zeigen sich erst beim Jahresabschluss. Jede Abweichung wird geklärt: Fehler im neuen Modell, Fehler im alten oder eine bewusst geänderte Definition. Dokumentiert wird, welche Zahl gilt.

Parallel werden die Teams geschult, am besten mit Beispielen aus ihren eigenen Berichten, und Ansprechpersonen in den Fachbereichen helfen beim Umstieg. Ohne Einführung kehren viele zu ihren alten Tabellen zurück. Für das Abschalten gibt es einen festen Stichtag, sonst zahlt man für beide Systeme und niemand weiß, welches gilt. Danach wird das Altsystem nur noch lesend und archiviert betrieben und schließlich abgeschaltet, einschließlich Lizenzen und Zugriffen.