Von der Idee zum Dashboard – In 7 Schritten passgenaue Reporting-Lösungen entwickeln

Das Projekt ist beauftragt, alle Daten-Themen sind geklärt – dann bist du als Kundin oder Kunde erstmal raus, denn für die Umsetzung des Reportings sind jetzt wir von SKOPOS ELEMENTS zuständig. Stimmt fast, aber nicht ganz – denn wir benötigen dafür deinen Input. Wenn wir davon sprechen, Reporting-Lösungen „für“ dich zu entwickeln, dann meinen wir „mit“ dir. Du bist regelmäßig involviert, denn nur mit deinem Input können wir den für dich optimal passenden Output kreieren.

Zusammenfassung:

Grundidee
Skizze „Wireframe“
Erst-Entwurf „Mock-up“
Vervollständigung
Feinschliff
Qualitätssicherung
Onboarding

1. Grundidee

Wenn wir an die Planung und Umsetzung des Reportings gehen, haben wir bereits eine Grundidee von der Reporting-Lösung. Denn in der Regel gab es irgendeine Form von Vorgespräch zum Projekt, aus dem auch die Kostenschätzung und der zeitliche Rahmen hervorgehen, in dem wir uns bewegen. Schließlich ist das Spektrum an Aufwand und Komplexität sehr groß zwischen zum Beispiel einem einzelnen interaktiven Tabellen-Tool und einer vielschichtigen Dashboard-Infrastruktur. Eine solche grobe Einordnung ist also wichtig vor Projektbeginn. Allerdings ist sie nicht ausreichend, wenn es an die tatsächliche Entwicklung geht. Hier benötigen wir weitere Informationen, um ein stabiles Fundament zu bauen. Dabei gehen wir eine Art Fragenkatalog durch. Hier ein paar Beispiele:

Welches Problem wird das neue Reporting lösen und für wen? Zu welchen Handlungen/Entscheidungen wird das Reporting befähigen? Unter welchen Umständen/aus welcher Motivation heraus wird auf das Reporting zugegriffen?
Wie genau definieren sich die Zielgruppen? Wie/womit arbeiten sie derzeit, noch bevor es das neue Reporting gibt? Umfasst auch: Bekanntheit von Analysen und Inhalten, bisherige technische Infrastruktur, gelernte Muster etc.

Eine stichpunktartige Beschreibung ist hier ausreichend – je einfacher verständlich, desto besser. Hauptsache alle Beteiligten (Kunden- und Agentur-Seite) haben ein klares, gemeinsames Verständnis, bevor wir im zweiten Schritt mit der konzeptionellen Arbeit loslegen. Tipp am Rande: Meistens gab es schon in der Vergangenheit irgendeine Art von Reporting und Datenvisualisierung – und somit schon bestehende Ideen. Daran kann man sich auch gut entlanghangeln: Was daran ist gut (muss bleiben), was nicht?

2. Skizze/Wireframe

Erst nachdem die Grundidee umrissen ist – also Zielbild und Kernfragen stehen – beginnt der kreative Part: Wir skizzieren die Bestandteile des Reportings. Das machen wir bewusst reduziert und stilistisch. Hier geht es noch nicht um Design-Fragen. Im Gegenteil, sie würden von den wesentlichen drei Aspekten ablenken: die Anordnung der Inhalte, die User-Journey und die Funktionen.

Der Wireframe beantwortet dabei u. a. folgende Fragen: Welche Inhalte ordnen wir in einem gemeinsamen visuellen Kontext an? Wie viel Platz können/dürfen/sollen einzelne Analysen einnehmen? Wie kommen zukünftige User von einem Chart oder Dashboard zum nächsten? Wie und wo kann mit den Visualisierungen interagiert werden? Wie und wo können Filter gesetzt werden und wo greifen sie?

Die konkrete Visualisierung als Skizze hilft dabei, dass du, als Kundin oder Kunde, ein schnelles Verständnis unserer Lösungsvorschläge erhältst. So kannst du besser mitbestimmen und hinterfragen. Hol hier gerne auch schon deine Stakeholder und einige End-User mit ins Boot. Beim gemeinsamen Blick auf den Wireframe kann diskutiert, angepasst und konkretisiert werden.

Und für uns von SKOPOS ELEMENTS ist das Ganze auch von großem Vorteil: Es ist viel dankbarer und effizienter, die Entwicklung in einer Datenvisualisierungs-Software nicht aus dem Bauch heraus auf einem weißen Blatt Papier zu starten (das klassische „Fass ohne Boden“), sondern zielgerichtet einen konkreten Plan abzuarbeiten und somit die eigenen Kapazitäten und Ressourcen auf die Optimierung und Ausgestaltung zu fokussieren.

Hier siehst du ein Beispiel aus der konzeptionellen Phase unseres Kitchen-Impossible-Dashboards.

3. Erst-Entwurf/Mock-up

Erst wenn der konzeptionelle Wireframe auf Kundenseite abgesegnet ist, geht es für uns an die technische Entwicklung. Nun sind wir dank unserer Skizzen gut gewappnet und können in der gewählten Reporting-Software die eigentliche Umsetzung starten – wir nutzen als Software meistens Tableau oder Power BI.

Der Erst-Entwurf (auch Mock-up genannt) ist dabei bewusst noch kein präsentationsreifes Reporting mit visuellen Feinheiten. Schließlich ist der Erst-Entwurf vor allen Dingen ein „Proof of Concept“ – sowohl auf Kunden- als auch auf Agentur-Seite. Wir von SKOPOS ELEMENTS können prüfen, ob unser Daten- und Software-Set-up die intendierten Funktionalitäten ermöglicht (andernfalls müssen wir hier nachbessern).

Du als Kundin oder Kunde hast darin eine Spielwiese zum Austesten und Erproben der konzipierten Lösung. Hier wäre es enorm wichtig, dass tatsächliche End-User mit hinzugenommen werden, um Feedback zu geben: Ist das, was wir theoretisch erarbeitet haben, in der praktischen Umsetzung auch gut gelungen? Wo müssen wir umdenken?

4. Vervollständigung

Der vorherige Erst-Entwurf enthält als Mock-up oft nur erste Beispiele und noch nicht alle Auswertungen und Abbildungen. Wenn das technische Set-up abgesegnet ist, können wir nun also an die Vervollständigung gehen: Dieser vierte Schritt bedeutet für uns vor allen Dingen „Strecke machen“. Am Ende dieses Prozesses sollte das Reporting komplett sein, bedeutet: alle Funktionen, alle Charts, alle Dashboards sind drin.

Parallel zu unserem Arbeitsfortschritt sammeln wir in mehreren, engmaschigen Schritten Feedback und arbeiten die Anpassungswünsche ein. So spielen wir uns mit dir mehrfach den Ball hin und her. Das ist meist ein Mix aus Schriftverkehr (z. B. Screenshots mit Kommentaren) und Jours fixes für den persönlichen Austausch. Hier gibt es aber kein festes Erfolgsrezept, denn das ist Geschmacks-Sache und eine Frage von Ressourcen, Umfang und Komplexität der Reporting-Lösung.

Hier machen wir erste Schritte in der Software (in diesem Fall Tableau).

5. Feinschliff

Wenn das Reporting in Funktion und Umfang vervollständigt und abgesegnet ist, kommt die Kür: Alles richtig schön machen! Dabei formulieren wir bei Bedarf schriftliche Elemente wie Mouseover-Texte aus und optimieren generell alle Aspekte rund um Layout und Formatierung. Am Ende soll ein optisch harmonisches, sauberes und einladendes Gesamtbild entstehen. Schließlich besteht die Realität von Reporting-Lösungen nicht nur aus Inhalt und Funktion, sondern eben auch aus einer ansprechenden Verpackung.

Je nach Feedback optimieren wir hier alle Aspekte rund um Layout und Formatierung.

6. Qualitätssicherung

Selbstverständlich laufen parallel zur bisherigen Entwicklung diverse Prüfungen und Maßnahmen zur Qualitätssicherung. Dennoch planen wir am Ende nochmal etwas Zeit für eine finale Abnahme ein: Wir lassen durch unterschiedliche Personen nochmal alles auf „Herz und Nieren“ prüfen – dabei geht es sowohl um Inhalte (Daten, Analysen) als auch um Funktionen (Filter, Export und andere Spielereien).

Bei der Qualitätssicherung nehmen wir bewusst die Perspektive der End-User ein. Konkret prüfen wir ausgehend von der Software und Hardware, die in deinem Unternehmen im Einsatz sein werden, verschiedene Dinge: Desktop-Anwendung oder Server-Lösung? Dein Server oder unser Server? Großer Bildschirm? Kleiner Laptop? Oder gar auf dem Smartphone? Welches Modell? Zudem gehen wir nochmal gezielt auf deine Use-Cases ein – wenn z. B. der Export von Grafiken ein wichtiges Element ist, schenken wir dessen Prüfung besonderes viel Aufmerksamkeit.

7. Onboarding

Onboarding bedeutet, dass die End-User an die neue Lösung herangeführt werden. Das kann „unpersönlich“ via E-Mail mit Login-Informationen und Handout zur Bedienung erfolgen – oder Zielgruppen-individuelle Schulungen umfassen. Dabei kann der Prozess über uns laufen oder du nimmst das Thema konzernintern selbst in die Hand. Umfang und Komplexität der Reporting-Lösung sind dabei maßgeblich für die Form des Onboardings. Auch die Anzahl an End-Usern kann die Onboarding-Lösung beeinflussen.

Möglicherweise ist keine weitere Erläuterung zur Bedienung nötig und eine Information, wie und wo auf das neue Reporting zugegriffen wird und wann es sich aktualisiert, reicht völlig. Diese Feinheiten sind sehr projektindividuell zu bestimmen. Wichtig ist, dass das Thema überhaupt besprochen und geplant wird. Wir unterstützen dich dabei und bringen gerne unsere Erfahrungen ein.

Sieben Schritte, hunderte Erfahrungen: Was zählt wirklich bei der Entwicklung einer Reporting-Lösung?

Der Weg ist das Ziel: Die Schritte vor Fertigstellung des Reportings sind maßgeblich für dessen Erfolg. Ein Reporting, das über Nacht aus dem Boden gestampft wird, ist selten erfolgreich. Hinter jedem guten Reporting steckt ein Plan und an manchen Stellen lohnt es sich, sich zu Beginn Zeit zu nehmen.

Wenig Mehrarbeit für enormen Mehrwert: Die Entwicklungsstrecke klingt für dich vermutlich erstmal aufwendig – warum kann SKOPOS ELEMENTS die Arbeit nicht einfach allein machen? Die Erfahrung zeigt, dass wir am Ende sehr viele Überarbeitungsschleifen drehen, wenn wir im Alleingang starten. Das kostet beide Seiten viel Zeit und Ressourcen. Unterm Strich ist das Projekt sehr viel effizienter, wenn man bei der Entwicklung gemeinsam arbeitet.

End-User an den Anfang: Wenn wir von gemeinsamer Reporting-Entwicklung sprechen, meinen wir uns (SKOPOS ELEMENTS) und dich als Kundin oder Kunde. Ganz konkret meinen wir aber jene Personen, die am Ende wirklich mit dem Reporting arbeiten. Vielleicht nicht alle von ihnen, aber ein paar Menschen, die Interesse und Erfahrung mitbringen. Denn ihr Feedback ist entscheidend. Wenn das Reporting der Projektleitung gefällt, freuen wir uns – aber wenn es den Menschen gefällt, die damit arbeiten und damit jetzt noch besser arbeiten können, dann haben wiederum wir alle gute Arbeit geleistet. Und darauf kommt es an!