Bevor der erste Bericht existiert: wie wir das Reporting einer großen Einführung aufbauen

4 min reading
Aus dem Maschinenraum

Bevor der erste Bericht existiert: wie wir das Reporting einer großen Einführung aufbauen

Das Reporting umfasst alle Berichte, die ein Kunde aus dem System erhält. Es für eine große Retail-Execution-Einführung aufzubauen, also für die tägliche Arbeit des Außendiensts in den Geschäften, ist keine Frage von ein paar Diagrammen.

5
geplante Reporting-Bereiche
3
Ansichten je Bereich im Schnitt
2
bereits beim Kunden im Test

Drei Dinge müssen zusammenkommen, bevor der erste Bericht entsteht

Was der Kunde will, welche Daten sich mit der App überhaupt erheben lassen und ob das System sie rechtzeitig berechnen und ausliefern kann. Wie das bei uns aussieht, zeigen wir am Beispiel eines Projekts für einen globalen Getränkehersteller im US-Markt, in dem Daniel Janik aus unserem Team das Reporting verantwortet.

Die Methode

Fünf Etappen, zwei davon sind ein Abgleich mit der Realität

Eine Wunschliste geht nie direkt in den Bau. Sie passiert zuerst zwei Kontrollpunkte: ob die Anwendung diese Daten überhaupt erheben kann und ob der Kunde die fertigen Ansichten bestätigt.

Fünf Etappen des Reporting-Aufbaus, mit zwei Kontrollpunkten: ob die Anwendung die Daten erheben kann und ob der Kunde die Berichte auf Testdaten durchgeht
Tippen Sie auf das Diagramm, um es in voller Größe zu öffnen.

1. Der Umfang beginnt beim Kunden, aber eine Wunschliste ist erst der Anfang

Zuerst legen das Analyse- und das Technikteam gemeinsam mit den Fachbereichen des Kunden fest, worüber berichtet werden soll. Diese Liste prüfen wir bewusst noch nicht daraufhin, was sich tatsächlich erheben lässt: das folgt im nächsten Schritt. Berichte, die auf ungeprüften Wünschen aufbauen, fallen beim ersten Kontakt mit echten Daten auseinander.

2. Kann die Anwendung das überhaupt erheben?

Danach stellen wir diese Anforderungen den Möglichkeiten der Anwendung gegenüber. In einem Workshop in Kanada kamen zum Kundenteam die Menschen dazu, die die Anwendung am besten kennen und wissen, welche Daten sich mit ihr realistisch erheben lassen. Dort trifft die Bedarfsliste des Kunden auf die Möglichkeiten des Systems. Das Ergebnis: der gesamte Umfang aufgeteilt in konkrete Bereiche, etwa die Durchführung der Außendienstbesuche oder die Umsetzung von Promotions, jeder mit den Daten, die er braucht. Erst so bestätigte Anforderungen gehen an unser Reporting-Team.

3. Wir entwerfen schlank, weil die Performance schon beim ersten Entwurf eine Grenze setzt

Für jeden Bereich entsteht ein erster Entwurf: was er zeigen soll und wie. Die einzelnen Ansichten, also die Tabellen und Auswertungen innerhalb eines Bereichs, fassen wir so zusammen, dass dieselben Daten nicht wiederholt und nicht über den Bedarf hinaus vervielfacht werden. Bei sehr vielen Nutzern müssen die Daten eines ganzen Tages in einem engen Zeitfenster verarbeitet und versendet werden, damit der Kunde jeden Tag den vollständigen Satz an Berichten rechtzeitig bekommt. Jede überflüssige Ansicht verlängert diese Verarbeitung und frisst einen Teil dieses Zeitfensters.

4. Den fertigen Entwurf prüfen wir mit dem Kunden live, mit Testdaten

Gezeigt haben wir ihn in einem Workshop in Salzburg. Aufgebaut haben wir ihn mit Testdaten, um zu zeigen, wie die Berichte funktionieren und was sie zeigen, noch bevor echte Daten vorlagen. Gemeinsam mit dem Reporting-Team des Kunden sind wir alles durchgegangen, Ansicht für Ansicht. Einen Teil der Lösungen haben wir vor Ort nachgeschärft, und dabei kamen weitere Bereiche auf, über die sich berichten lohnt. Skizziert haben wir sie gleich, gemeinsam.

Eine gut vorbereitete Demo bringt von sich aus neue Ideen. Der Kunde sieht eine fertige Ansicht und sagt sofort: Das wollen wir auch messen.

Daniel Janik

Der Seceda-Grat in den Dolomiten, aufgenommen von unserem Reporting-Verantwortlichen auf der Reise nach dem Workshop
Nach dem Workshop: die Aussicht, die unseren Reporting-Verantwortlichen erwartete.

5. Produktion, ein Bereich nach dem anderen

Heute sind wir in der Produktion. Am Ende werden es fünf Reporting-Bereiche sein, einschließlich der in Salzburg entdeckten, mit durchschnittlich drei Ansichten je Bereich. Zwei sind fertig und werden auf Kundenseite getestet: einer betrifft Fragebögen und die Daten, die der Außendienst erhebt, der andere zeigt, ob und wie geplante Besuche durchgeführt wurden. Nach den Tests meldet der Kunde Anmerkungen, wir setzen die Korrekturen um. So schließen wir jeden Bereich ab, bevor wir den nächsten angehen.

Sie fragen sich, wo ein solches Reporting im Produkt sitzt? In Sales & Retail Execution heißt es OneView.

Ruderboote am Pragser Wildsee im Morgenlicht, aufgenommen von unserem Reporting-Verantwortlichen auf der Reise nach dem Workshop
Morgen am Pragser Wildsee.
Über den Autor
Daniel Janik, Project Manager, Asseco Platform

Daniel Janik

Project Manager, Asseco Platform

Verantwortet den Reporting-Bereich in einem Retail-Execution-Projekt für den US-Markt. LinkedIn

Planen Sie eine Einführung, bei der das Reporting vom ersten Tag an funktionieren muss?

Sprechen wir darüber →