thinkBI #042 – Von der Skizze zum Datenmodell: Was die Anforderung zusammenhält

In thinkBI Folge 42 blicke ich auf einen Power-BI-End-to-End-Workshop zurück, den ich gemeinsam mit Jasmin Simader im Rahmen der Daten WG gestaltet habe. Unser Ausgangspunkt war die Frage, wie wir den Weg von der Anforderung bis zur Umsetzung als zusammenhängenden Prozess vermitteln können.

Power BI zu bedienen ist ein Teil dieser Arbeit. Im Projekt müssen wir außerdem klären, welche Information gebraucht wird, wie wir sie verständlich darstellen und welche Daten sie tragen. Dafür wollten wir im Workshop bewusst am Anfang Raum schaffen.

Mit KI lassen sich heute Entwürfe aufbereiten und Teile der Umsetzung unterstützen. Dadurch wird schnell etwas sichtbar. Ein ansprechend gestalteter Prototyp kann allerdings bereits geklärt wirken, obwohl wichtige Zusammenhänge noch gar nicht ausgesprochen wurden.

Deshalb liegt für mich ein wesentlicher Teil der Arbeit darin, die Anforderung gemeinsam verständlich zu machen. Dieses Verständnis muss den Weg vom ersten Gespräch über das Datenmodell bis zur Visualisierung begleiten.

Hier klicken, um den Inhalt von Spotify anzuzeigen.
Erfahre mehr in der Datenschutzerklärung von Spotify (öffnet in neuem Tab).

Eine Skizze macht Anforderungen besprechbar

Wir haben mit einem Canvas zur Anforderungsanalyse begonnen, das Jasmin vorbereitet hatte. Danach ging es ins Prototyping, vom kleinen Whiteboard bis zu einer einfachen PowerPoint-Vorlage, in der sich vorbereitete Grafiken zu einem Dashboard-Entwurf zusammenstellen ließen.

Die niedrige Einstiegshürde ist dabei wichtig. Wer eine fachliche Vorstellung hat, soll sie zeigen und besprechen können. Dafür muss die Person noch kein BI-Werkzeug beherrschen. Eine Zeichnung oder eine zusammengeschobene PowerPoint-Folie schafft einen gemeinsamen Gegenstand für das Gespräch.

An diesem Entwurf lässt sich diskutieren, was gemeint ist. Warum soll eine Information dort stehen? Was soll eine bestimmte Darstellung verständlich machen? Brauchen wir die gezeichnete Visualisierung tatsächlich, oder wäre eine einfachere Form für die späteren Nutzer leichter zu verstehen?

Prototyping ist damit ein Werkzeug der Kommunikation. Es erlaubt uns, Gedanken sichtbar zu machen, bevor wir sie technisch umsetzen. Das kann auch Vorstellungen einschließen, deren Umsetzung später genauer geprüft werden muss.

Die Skizze allein hält allerdings nicht das gesamte Gespräch fest. Wenn ich nach Wochen meine eigene Handschrift kaum noch lesen kann, fehlen mir womöglich auch die Erläuterungen dazu. Deshalb gehört der textuelle Kontext dazu. Was haben wir mit dieser Darstellung gemeint, und welche Überlegungen standen dahinter?

Was Menschen verständlich hilft, kann auch KI helfen

Im Workshop haben wir Zeichnungen zusammen mit ergänzenden Beschreibungen an KI übergeben. Daraus konnten aufbereitete Dashboard-Prototypen entstehen. Für mich war daran besonders interessant, dass dieselben Kommunikationsmittel an mehreren Stellen des Prozesses nützlich waren.

Ein Bild kann Beziehungen oder eine gewünschte Anordnung zeigen, die sich in einem längeren Text nur umständlich beschreiben lassen. Die ergänzende Beschreibung hält fest, was aus dem Bild allein nicht hervorgeht. Zusammen machen beide die Absicht besser zugänglich.

Das ist eine Beobachtung aus unserer Arbeit mit diesen Mitteln. Wie gut ein Ergebnis ausfällt, hängt vom konkreten Werkzeug und vom übergebenen Kontext ab. Ein aufbereiteter Entwurf bleibt deshalb ein Gegenstand für die weitere fachliche Klärung.

Jasmin zeigte im weiteren Workshop unterschiedliche Möglichkeiten der KI-Unterstützung. Das Spektrum reichte von Chat-Anwendungen bis zu Coding-Agenten, die Dateien in einem Projekt bearbeiten können. Diese Unterschiede sind im Alltag relevant. Die Teilnehmer können auf unterschiedliche Software zugreifen und bringen verschiedene Voraussetzungen mit.

Der gemeinsame Ansatz bleibt trotzdem verwendbar. Wer seine Anforderungen verständlich festhält, kann diesen Kontext im verfügbaren Werkzeug weiterverwenden. Auch eine Chat-Anwendung braucht die Informationen, anhand derer sie den übergebenen Code oder eine gewünschte Änderung einordnen soll.

Die Anforderung bestimmt den Umfang des Modells

Nach dem Prototyping haben wir Grundlagen der Modellierung aufgegriffen. Sternschema, Namenskonventionen, Granularität und explizite Measures. Diese Punkte gehören in denselben Zusammenhang wie die Anforderung am Anfang.

Wenn wir wissen, welche Information gebraucht wird, können wir gezielt auswählen, welche Tabellen und Spalten ins Modell gehören. Einfach alles zu laden, was im Quellsystem verfügbar ist, verschiebt diese Auswahl in die spätere Arbeit. Die Anforderung gibt uns dagegen einen begründeten Anfang. Weitere Daten lassen sich bei zusätzlichem Bedarf ergänzen.

Auch die Granularität muss zu den benötigten Aussagen passen. Auf welcher Detailebene sollen Daten vorliegen, damit die gewünschte Betrachtung möglich wird? Eine Skizze kann einen Informationsbedarf sichtbar machen. In der Modellierung müssen wir prüfen, welche Struktur ihn tatsächlich trägt.

Daraus entsteht zugleich ein Ansatzpunkt für Datenqualität. Sobald feststeht, welche Daten wir wofür benötigen, können wir die entsprechenden Qualitätsanforderungen benennen und überprüfen. Die Frage nach Qualität erhält damit einen konkreten Bezug zur vorgesehenen Nutzung.

Metadaten helfen, diese Grundlage nachvollziehbar zu machen. Jasmin zeigte dazu den Entwurf eines Quality-Dashboards, das Metadaten abfragt und die verfügbare Datengrundlage sichtbar macht. KI kann auch beim Ergänzen solcher Beschreibungen unterstützen. Welche fachliche Bedeutung festgehalten werden soll, muss dafür verständlich vorliegen.

Ein Zusammenhang bis zur Visualisierung

Zum Ende haben wir den Bogen zurück zur Darstellung gespannt. Wer am Whiteboard frei entwerfen darf, wird möglicherweise Ideen entwickeln, die über die vertrauten Standardvisualisierungen hinausgehen. Dann lohnt sich die gemeinsame Prüfung. Welchen Zweck erfüllt die gewünschte Form, wie verständlich ist sie und wie lässt sie sich umsetzen?

Dabei kann der Weg über vorhandene Visualisierungen, deklarative Beschreibungen oder eine eigene Entwicklung führen. Skizzen und dokumentierter Kontext bleiben auch hier hilfreich, gerade wenn KI an der Umsetzung beteiligt ist.

Für mich liegt darin der Wert des End-to-End-Blicks. Anforderung, Prototyp, Modell und Visualisierung hängen fachlich zusammen. Die Auswahl der Daten und die Anforderungen an ihre Qualität entstehen aus demselben Informationsbedarf, den wir am Anfang besprechen.

Business Intelligence ist die Fähigkeit einer Organisation, Entscheidungen systematisch mit Informationen zu verbinden. Im konkreten Projekt beginnt diese Verbindung damit, dass Menschen gemeinsam verständlich machen, welche Information sie benötigen. Wie viel davon bleibt bei uns erhalten, wenn aus dem ersten Gespräch ein Datenmodell und schließlich ein Dashboard wird?

🎧 Die komplette Folge findest du im thinkBI Podcast.

Eine Skizze macht Anforderungen besprechbar

Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/

Veröffentlicht von

Marcus Wegener

Marcus Wegener

Marcus Wegener ist Full Stack Power BI & Fabric Engineer und schreibt auf thinkBI über Datenmodellierung, Power BI, Fabric und Business Intelligence als Grundlage besserer Entscheidungen. Im Zentrum steht nicht das Dashboard, sondern die Frage, wie aus fachlichen Anforderungen tragfähige Informationsstrukturen entstehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.