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.
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.
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.

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

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.

