Prima che esista il primo report: come costruiamo il reporting di un grande rollout
Il reporting è l’insieme dei report che il cliente riceve dal sistema. Costruirlo per un grande rollout di retail execution, cioè il lavoro quotidiano dei venditori nei punti vendita, non è questione di disegnare qualche grafico.
Prima che esista il primo report devono incontrarsi tre cose
Cosa vuole il cliente, quali dati l’applicazione riesce davvero a raccogliere e se il sistema fa in tempo a elaborarli e a consegnarli. Ecco come lo facciamo noi, su un progetto per un produttore di bevande globale sul mercato statunitense, dove il reporting è guidato da Daniel Janik del nostro team.
Cinque fasi, due delle quali sono un confronto con la realtà
Una lista dei desideri non passa mai diretta alla costruzione. Prima supera due controlli: se l’applicazione riesce davvero a raccogliere quei dati e se il cliente conferma le viste finite.
1. Il perimetro parte dal cliente, ma la lista dei desideri è solo l’inizio
Prima il team analitico e quello tecnico si siedono con le persone del business del cliente e definiscono cosa vogliono misurare. Quella lista, volutamente, non la verifichiamo ancora rispetto a ciò che si riesce davvero a raccogliere: lo facciamo nel passo successivo. I report costruiti su richieste che nessuno ha verificato crollano al primo contatto con i dati reali.
2. L’applicazione riesce davvero a raccoglierlo?
Poi mettiamo quei requisiti a confronto con le capacità dell’applicazione. In un workshop in Canada, al team del cliente si sono unite le persone che conoscono meglio l’applicazione e sanno quali dati riesce a raccogliere. È lì che la lista delle esigenze del cliente incontra le possibilità del sistema. Il risultato: tutto il perimetro diviso in aree concrete, per esempio l’esecuzione delle visite dei venditori o la realizzazione delle promozioni, ognuna con i dati che richiede. Solo i requisiti confermati così passano al nostro team di reporting.
3. Progettiamo in modo essenziale, perché le prestazioni sono un vincolo già dal primo schizzo
Per ogni area nasce una prima bozza: cosa deve mostrare e come. Le singole viste, cioè le tabelle e i prospetti all’interno di un’area, le combiniamo per non ripetere gli stessi dati né moltiplicarli oltre il necessario. Con un numero altissimo di utenti, i dati di un’intera giornata vanno elaborati e inviati in una finestra di tempo stretta, perché il cliente riceva ogni giorno il set completo dei report. Ogni vista superflua allunga quell’elaborazione e si mangia una parte di quella finestra.
4. Il progetto finito lo verifichiamo con il cliente dal vivo, su dati fittizi
La bozza l’abbiamo presentata in un workshop a Salisburgo. L’abbiamo costruita su dati fittizi per mostrare come funzionano i report e cosa mostrano, prima che arrivassero i dati reali. Insieme al team di reporting del cliente abbiamo passato in rassegna tutto, vista per vista. Alcune soluzioni le abbiamo messe a punto sul posto e, nel farlo, sono emerse altre aree che vale la pena misurare. Le abbiamo abbozzate subito, insieme.
Una demo preparata bene genera nuove idee da sola. Il cliente vede una vista finita e dice subito: vogliamo misurare anche questo.
Daniel Janik
5. Produzione, un’area alla volta
Oggi siamo in fase di produzione. Alla fine ci saranno cinque aree di reporting, comprese quelle emerse a Salisburgo, con una media di tre viste ciascuna. Due sono già pronte e in test sul lato del cliente: una riguarda i questionari e i dati raccolti dai venditori, l’altra mostra se e come sono state realizzate le visite pianificate. Dopo i test il cliente segnala le osservazioni, noi applichiamo le correzioni. È così che chiudiamo ogni area prima di passare alla successiva.
Ti chiedi dove si collochi nel prodotto un reporting come questo? Il livello analitico di Sales & Retail Execution si chiama OneView.
Daniel Janik
Project Manager, Asseco Platform
È responsabile dell’area di reporting in un progetto di retail execution per il mercato statunitense. LinkedIn
