Zanim powstanie pierwszy raport: jak budujemy warstwę raportową dużego wdrożenia
Warstwa raportowa to wszystkie raporty, jakie klient dostaje z systemu. Zbudowanie jej dla dużego wdrożenia retail execution, czyli codziennej pracy przedstawicieli w sklepach, to nie kwestia narysowania kilku tablic z wykresami.
Trzy rzeczy muszą się spotkać, zanim powstanie pierwszy raport
Czego chce klient, co realnie potrafi zebrać aplikacja i czy system zdąży to przeliczyć i wysłać na czas. Pokażemy, jak wygląda to u nas, na przykładzie projektu dla globalnego producenta napojów na rynku amerykańskim, w którym warstwę raportową prowadzi Daniel Janik z naszego zespołu.
Pięć etapów, dwa z nich to zderzenie z rzeczywistością
Lista życzeń nigdy nie idzie prosto do budowy. Najpierw przechodzi dwie bramki: czy aplikacja w ogóle potrafi zebrać te dane i czy klient potwierdza gotowe widoki.
1. Zakres zaczyna się u klienta, ale lista życzeń to dopiero początek
Najpierw zespół analityczny, techniczny i ludzie od strony biznesowej klienta ustalają, co chcą raportować. Tej listy celowo jeszcze nie sprawdzamy pod kątem tego, co naprawdę da się zebrać. To robimy dopiero w kolejnym kroku. Raporty budowane pod życzenia, których nikt nie zweryfikował, rozsypują się przy pierwszym zderzeniu z danymi.
2. Czy aplikacja naprawdę potrafi to zebrać?
Potem zderzamy te wymagania z możliwościami aplikacji. Na warsztatach w Kanadzie do zespołu klienta dołączyli ludzie, którzy najlepiej znają aplikację i wiedzą, jakie dane realnie potrafi ona zebrać. Tam lista potrzeb klienta spotyka się z możliwościami systemu. Efekt: całość podzielona na konkretne obszary, na przykład realizacja wizyt przedstawicieli czy wykonanie promocji, a dla każdego ustalone, jakich danych wymaga. Dopiero tak potwierdzone wymagania trafiają do naszego zespołu raportowego.
3. Projektujemy zwięźle, bo wydajność jest ograniczeniem od pierwszego szkicu
Dla każdego obszaru powstaje wstępny szkic: co i jak ma pokazywać. Poszczególne widoki, czyli pojedyncze tabele i zestawienia w obrębie obszaru, łączymy tak, aby nie powtarzać tych samych danych ani nie mnożyć ich ponad potrzebę. Przy bardzo dużej liczbie użytkowników dane z całego dnia trzeba przetworzyć i wysłać w krótkim oknie czasowym, żeby klient dostawał komplet raportów na czas, każdego dnia. Każdy zbędny widok wydłuża to przetwarzanie i zjada część tego okna.
4. Gotowy projekt sprawdzamy z klientem na żywo, na sztucznych danych
Szkic pokazaliśmy na warsztatach w Salzburgu. Zbudowaliśmy go na sztucznych danych, żeby pokazać, jak raporty działają i co pokazują, jeszcze zanim wpłyną prawdziwe dane. Wspólnie z zespołem raportowym klienta przeszliśmy przez całość, widok po widoku. Część rozwiązań dopracowaliśmy na miejscu, a przy okazji wyszły kolejne obszary warte raportowania. Naszkicowaliśmy je od razu, wspólnie.
Dobrze przygotowane demo samo generuje nowe pomysły. Klient widzi gotowy widok i od razu mówi: to też chcemy mierzyć.
Daniel Janik
5. Produkcja, obszar po obszarze
Dziś jesteśmy w fazie produkcji. Docelowo będzie pięć obszarów raportowych, już z tymi odkrytymi w Salzburgu, każdy średnio z trzech widoków. Dwa są już gotowe i testowane po stronie klienta: jeden dotyczy ankiet i danych zbieranych przez przedstawicieli, drugi pokazuje, czy i jak zrealizowano zaplanowane wizyty. Po testach klient zgłasza uwagi, my nanosimy poprawki. Tak domykamy każdy obszar, zanim ruszymy z kolejnym.
Zastanawiasz się, gdzie takie raportowanie mieści się w produkcie? Warstwa analityczna Sales & Retail Execution nazywa się OneView.
Daniel Janik
Project Manager, Asseco Platform
Odpowiada za obszar raportowy w projekcie retail execution na rynek amerykański. LinkedIn
