Konzeptkarte

SAP Lumira (Discovery & Designer)

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 Lumira (Discovery & Designer)?

SAP Lumira ist eine Marke, die zwei Produkte mit unterschiedlicher Herkunft, unterschiedlichen Nutzern und unterschiedlichen Migrationspfaden abdeckte — und sie zu vermischen ist der verlässlichste Weg, ein Lumira-Engagement falsch zu bepreisen.

Worum es geht

Lumira Discovery ist die Self-Service-Linie: ein Desktop-Werkzeug, mit dem ein Analyst einen Datensatz beschafft, aufbereitet und Visualisierungen baut, ohne serverseitiges semantisches Modell. Es entstand aus SAPs Antwort auf die Self-Service-Welle, und seine Nutzer sind Analysten, die an eigenen Daten arbeiten, häufig vollständig außerhalb der IT-Governance.

Lumira Designer ist Design Studio unter späterem Namen: der skriptbasierte BI-Anwendungsdesigner mit Erweiterungs-SDK, genutzt von Entwicklern, um verwaltete, ereignisgesteuerte Analyseanwendungen auf BW und HANA zu bauen. Seine Nutzer sind Entwickler, seine Artefakte sind Anwendungen, und sein Rest ist Code.

Die beiden landen an unterschiedlichen Orten. Discovery-Inhalte laufen auf SACs Story- und Explorationsoberflächen zu, und die Migrationsschwierigkeit wird von einer Frage ungovernanter Daten dominiert — woher kam der Datensatz des Analysten, und lässt das Ziel ihn auf demselben Weg genauso leicht darauf zugreifen. Designer-Inhalte laufen auf SAC Analytic Applications zu, und ihre Schwierigkeit wird von kundeneigenen SDK-Komponenten dominiert, die als Custom Widgets neu gebaut werden müssen. Ein einziger Plan, der „Lumira migrieren“ sagt, ohne diese beiden zu trennen, liegt bei beiden falsch.

Was zuerst zu klären ist. Fragen, welches Lumira installiert ist und wer es nutzt. Lautet die Antwort „Analysten mit Desktop-Dateien“, hat man ein Governance- und Datenzugriffsproblem im Migrationskostüm. Lautet die Antwort „ein Entwicklungsteam mit Anwendungskatalog“, hat man ein Code-Neubau-Problem. Viele Bestände haben beides, in unterschiedlichen Abteilungen, ohne gemeinsamen Eigentümer.

Für einen Berater ist die Markenkollision selbst der verkaufbare Einblick: Sie erklärt, warum frühere Lumira-Schätzungen beim selben Kunden widersprüchlich ausfielen, und sie macht das erste Meeting produktiv statt erkundend.

Die beiden Produkte tragen unterschiedliche Kopplung, was selbst Teil des Markenkollisionsproblems ist. Lumira Designer erbt Design Studios Abhängigkeit von seiner BW- oder HANA-Quelle und damit dieselbe Mainstream-Wartungsklippe von BW 7.5 am 31. Dezember 2027 (kostenpflichtige Verlängerung bis 2030; SAP, 23. April 2020) oder das identische 2027-bis-2030-ECC-Fenster, je nachdem, was zutrifft. Lumira Discovery ist anders: Seine Datensätze sind häufig lokale Dateien oder Ad-hoc-Extrakte, die ein Analyst außerhalb jeder verwalteten Quelle beschaffte, sodass möglicherweise gar keine BW- oder ECC-Uhr koppelt — der auslösende Faktor ist eher eine Laptop-Erneuerung, ein Betriebssystem-Upgrade, das die Desktop-Installation zerbricht, oder eine Sicherheitsrichtlinie, die die ungovernante Datenbeschaffung endlich bemerkt.

Die Aufwandsschätzung muss sich genauso teilen. Ein Discovery-Inventar ist eine Data-Governance-Übung, bevor es eine Migrationsübung ist: herausfinden, woher die Datensätze tatsächlich kamen, und ob das Ziel demselben Analysten den Zugriff auf dieselbe Quelle mit derselben Leichtigkeit erlaubt — wenn nicht, ist die „Migration“ eigentlich eine Änderung, wie diese Person an Daten kommt, und sie wird als solche abgelehnt werden. Ein Designer-Inventar folgt exakt dem Design-Studio-Muster: kundeneigene SDK-Komponenten zählen, bevor Anwendungen gezählt werden, weil die Komponente, nicht die Anwendung, die Einheit des Neuaufbaus ist. Eine einzige kombinierte Schätzung über beide Produkte hinweg, zu einem Aufwandssatz, ist der Weg, wie ein Lumira-Engagement in beide Richtungen zugleich falsch bepreist wird.

Die Entscheidung, die das erzwingt, zweimal. Discovery und Designer stellen nicht dieselbe Entscheidung, und genau deshalb kann ein Plan nicht beide abdecken. Für Discovery ist die Entscheidung eine Governance-Entscheidung: Bekommt der Analyst einen verwalteten Pfad zu denselben Daten, oder akzeptiert die Organisation, dass die Desktop-Gewohnheit sich einfach verlagert? Sich zu weigern, das zu entscheiden, erzeugt sechs Monate nach Projektabschluss einen Schattenbestand auf irgendjemandes Laptop. Für Designer ist die Entscheidung pro kundeneigener Komponente: neu bauen, durch eine Standardfunktion des Ziels ersetzen, oder fallenlassen. Der Kompromiss zwischen den beiden Hälften ist einer der Art, nicht der Größe: Die Discovery-Antwort ist kulturell und langsam, die Designer-Antwort ist technisch und schätzbar, und beide unter ein einziges Datum zu stellen, ist der Weg, wie ein Lumira-Programm bei der Hälfte scheitert, die niemand verfolgt hat.

Warum es zählt

Zwei Produkte unter einer Marke, mit unterschiedlichen Nutzern, unterschiedlichen Nachfolgern und unterschiedlichen Kostentreibern. Ein Plan, der sie nicht trennt, liegt bei beiden Hälften falsch.

Kernpunkte

🔴 Eine Marke, zwei Produkte: Lumira Discovery (Self-Service-Desktop) und Lumira Designer (umbenanntes Design Studio).
Discovery-Nutzer sind Analysten mit eigenen Datensätzen, häufig außerhalb der IT-Governance.
Designer-Nutzer sind Entwickler; seine Artefakte sind skriptbasierte Anwendungen und sein Rest ist SDK-Code.
Discovery landet auf SAC-Stories und -Exploration; Designer landet auf SAC Analytic Applications.
Vor jeder Schätzung klären, welches Lumira und wer es nutzt — viele Bestände betreiben beides ohne gemeinsamen Eigentümer.
Zwei Entscheidungen, nicht eine: eine Governance-Entscheidung für Discovery (verwalteter Pfad oder akzeptierter Schattenbestand) und eine Pro-Komponente-Neubau-Entscheidung für Designer.
Die beiden Hälften unterscheiden sich in der ART, nicht in der Größe — die eine ist kulturell und langsam, die andere technisch und schätzbar; ein einziges Datum verbirgt die langsame.

Quellen

In der App öffnen →