Projekte zur Migration von Informationssystemen (Wechsel des ERP-Systems, des CRM-Systems oder einer geschäftskritischen Anwendung bzw. Modernisierung des Data Warehouse) zählen zu den risikoreichsten Initiativen in einer ausgereiften Power BI-Umgebung. Eine geänderte, umbenannte oder gelöschte Datenquelle kann unbemerkt Dutzende von Berichten unbrauchbar machen, die mitunter von der Geschäftsleitung für wöchentliche strategische Entscheidungen herangezogen werden.
Das klassische Problem: Die Auswirkungen werden zu spät erkannt
Bei vielen Migrationsprojekten wird das BI-Team erst am Ende des Projekts einbezogen, wenn die neue Datenquelle bereits bereitsteht und das Altsystem bereits im Prozess der Stilllegung ist. Erst dann stellt es – oft unter Zeitdruck und mit engen Terminvorgaben – fest, wie umfangreich die neu zu erstellenden Berichte tatsächlich sind: Eine Aufgabe, die bereits mehrere Monate früher hätte geplant werden können, wenn die Abhängigkeitsübersicht bereits zu Beginn des Migrationsprojekts vorgelegen hätte.
Warum die native Abstammungslinie von Power BI hier nicht ausreicht
Wie in unserem Artikel zum Thema Data Lineage ausführlich beschrieben, konzentriert sich die native Data Lineage von Power BI weiterhin jeweils auf einen einzelnen Workspace: Die Datenquellen sind dort nur auf der Ebene des Berichts und des Workspaces sichtbar, ohne dass eine Gesamtübersicht auf Tenant-Ebene vorliegt. Die Migration eines ERP-Systems, eines CRM-Systems oder einer geschäftskritischen Anwendung betrifft jedoch in der Regel Datenquellen, die von Dutzenden verschiedener Arbeitsbereiche genutzt werden, die von unterschiedlichen Fachteams (Finanzen, Vertrieb, Lieferkette, Personalwesen) verwaltet werden, welche oft keinerlei Einblick in die Arbeit der anderen Teams haben. Ohne einen übergreifenden Überblick über den gesamten Mandanten ist es unmöglich, eine verlässliche Antwort auf die doch so zentrale Frage zu erhalten: „Sind wir sicher, dass wir alle Berichte erfasst haben, die diese Quelle nutzen?“
Die umfassende Vorgehensweise: Vor der Migration eine Bestandsaufnahme erstellen
Schritt 1: Die betroffenen Quellen genau identifizieren
Erstellen Sie eine vollständige Liste der Tabellen, Datenbanken, APIs oder Dateien, die vom aktuellen System bereitgestellt werden und die im Zuge der Migration geändert, umbenannt oder entfernt werden.
Schritt 2: Die Liste der verbundenen semantischen Modelle abrufen
Identifizieren Sie mithilfe der transversalen Abstammungsanalyse alle Power BI-Semantikmodelle in allen Arbeitsbereichen, die direkt oder indirekt mit diesen Quellen verbunden sind, einschließlich über zusammengesetzte Modelle oder gemeinsam genutzte Datensätze in der Live-Komposition.
Schritt 3: Zurück zu den endgültigen Berichten und Dashboards
Für jedes identifizierte semantische Modell sollten Sie die Kette bis zu den Berichten und Dashboards zurückverfolgen, die darauf zugreifen, um eine vollständige und umfassende Liste der betroffenen Endartefakte mit den jeweiligen Verantwortlichen zu erhalten.
Schritt 4: Priorisierung der Abhilfemaßnahmen
Ordnen Sie die betroffenen Berichte nach ihrer geschäftlichen Kritikalität (im Vorstand verwendet, von einer einzigen Person verwendet, aufgegebener Testbericht) und der Anzahl ihrer aktiven Nutzer ein, um die Bemühungen zur Wiederherstellung auf das zu konzentrieren, was wirklich zählt, anstatt alle Berichte mit derselben Priorität zu behandeln.
| Prioritätsstufe | Kriterium | Empfohlene Maßnahme |
|---|---|---|
| Kritik | Wird in der Geschäftsleitung eingesetzt, große Reichweite | Vorzeitiger Wiederaufbau, Parallelbetrieb vor der Umstellung |
| Wichtig | Wird regelmäßig von einem Fachteam genutzt | Planung im Zeitplan des Migrationsprojekts |
| Sekundarstufe | Geringe Nutzung, jedoch aktiver Eigentümer identifiziert | Aufgeschobener Wiederaufbau, Mitteilung an den Eigentümer |
| Zur Archivierung | Keine Nutzung in jüngerer Zeit, kein aktiver Eigentümer | Nicht neu erstellen, archivieren |
Ein Nutzen, der über das reine Migrationsprojekt hinausgeht
Sobald diese Kartierung für ein bestimmtes Migrationsprojekt erstellt wurde, darf sie nicht als einmaliges Ergebnis betrachtet werden. Sie bildet die Grundlage für eine dynamische Datenherkunftsverfolgung, die für alle zukünftigen Änderungen wiederverwendbar ist: die spätere Weiterentwicklung eines Datenschemas, die Stilllegung einer weiteren Legacy-Anwendung oder die Zusammenlegung zweier Teams oder zweier Systeme im Zuge einer Umstrukturierung.
Vorbeugen statt reparieren
Der Unterschied zwischen einem gut kontrollierten Migrationsprojekt und einem chaotischen Projekt hängt oft von einem einzigen entscheidenden Faktor ab: die Fähigkeit, die Auswirkungen vorauszusehen, bevor die Änderung in der Produktionsumgebung bereitgestellt wird, anstatt sie erst im Nachhinein durch Rückmeldungen unzufriedener Nutzer und Berichte zu entdecken, die plötzlich Fehler oder inkonsistente Daten aufzeigen.
Häufig gestellte Fragen
Zu welchem Zeitpunkt des Migrationsprojekts sollte das BI-Team einbezogen werden?
Idealerweise bereits bei der ersten Projektdefinition, noch vor der endgültigen Auswahl des neuen Systems, damit die Wirkungsanalyse den Gesamtzeitplan beeinflussen kann und kostspielige späte Erkenntnisse am Ende des Projekts vermieden werden.
Müssen alle betroffenen Berichte vor der Umstellung neu erstellt werden?
Nicht unbedingt alle gleichzeitig: Eine Priorisierung nach geschäftlicher Relevanz ermöglicht es oft, zunächst die wichtigsten Berichte bereitzustellen und die weniger wichtigen Berichte in den Wochen nach der Inbetriebnahme des neuen Systems zu bearbeiten.
Lässt sich die „Transverse Lineage“-Methode auch anwenden, um geringfügigere Änderungen als eine vollständige Migration zu antizipieren?
Ja, dieselbe Vorgehensweise gilt für jede Änderung an der Datenquelle, auch wenn diese nur geringfügig ist (Hinzufügen oder Löschen einer Spalte, Änderung des Datentyps, Umbenennung einer Tabelle), die sich unverhältnismäßig stark auf nachgelagerte Berichte auswirken kann.
Dieser Artikel stützt sich direkt auf die in „Data Lineage in Power BI“ beschriebene Methode. Siehe auch „Power BI-Bestandsaufnahme“, um über die für jede Auswirkungsanalyse erforderliche Datenbank zu verfügen.
