Pricing e what-if
Prima dell’avvio di ogni stagione un’azienda di calzature e abbigliamento sportivo deve decidere a che prezzo vendere migliaia di articoli, su più brand, collezioni e mercati. I listini sono molti, ognuno con le sue regole, e dipendono spesso uno dall’altro: il prezzo finale di un listino diventa la base su cui se ne calcola un altro, con una maggiorazione, arrotondamenti e altre regole, tutte formule decise dai manager. Tenere sotto controllo i costi e valutare gli scenari avversi è fondamentale per basare le scelte di vendita su dati solidi. Il portale di pricing che abbiamo realizzato con l’ufficio recupera i dati della stagione precedente, riceve prodotti e costi dal sistema PLM, propone i prezzi in base alla configurazione di ogni listino e consegna i prezzi definitivi all’ERP e alla business intelligence.
La Richiesta
Ogni stagione il pricing partiva da fogli Excel: ogni utente lavorava alla sua divisione, per tutti i listini, poi un responsabile metteva insieme tutti i file e li caricava a mano, molto lentamente, nel sistema. Tra un foglio e l’altro le dipendenze tra listini si perdevano: se cambiava un prezzo, andavano ricalcolati a mano tutti quelli che ne derivavano. Capitava che due persone sovrascrivessero lo stesso file e che un prezzo cambiasse dopo la chiusura di una fase.
Le simulazioni (what-if) su dazi, costi di trasporto, tassi di cambio, markup e FOB si facevano in Excel, in file da centinaia di migliaia di celle, senza tener conto delle dipendenze: il cambio di un FOB o di un tasso di cambio toccava anche altri listini, e un dazio simulato su un prodotto valeva in realtà per tutti quelli con lo stesso codice doganale. Ogni what-if si basava così su dati parziali, incompleti e non congruenti.
L’ufficio pricing ci ha chiesto un portale che:
- dialogasse con PLM, ERP e business intelligence;
- recuperasse i dati della stagione precedente e proponesse i prezzi in base alla configurazione di ogni listino;
- gestisse listini collegati tra loro, con maggiorazioni, arrotondamenti e altre formule decise e configurate in autonomia dai manager;
- offrisse un’esperienza d’uso simile a Excel, con copia dei dati, formule e così via, ma senza dipendere da Excel;
- permettesse a più persone di lavorare sullo stesso listino senza sovrascriversi;
- consentisse, come secondo passo, di fare il what-if: simulare variazioni di dazi, costi di trasporto, tassi di cambio, markup, FOB e così via, con l’effetto propagato a tutti i listini e a tutti i prodotti coinvolti.
Analisi del problema
Il pricing di una stagione procede per fasi. Il punto di partenza è una collezione con una stagione di confronto, poi si definiscono i listini per mercato e, articolo per articolo, si ragiona su prezzo al pubblico, ricarico e prezzo all’ingrosso. Ogni listino ha le sue regole e molti dipendono da altri: il prezzo finale di uno diventa la base di un altro, con maggiorazioni e arrotondamenti. Ogni persona segue una divisione, ma i numeri finiscono tutti nello stesso riepilogo.
Ogni numero dipende da altri numeri, e ogni persona ne tocca solo una parte. Tanto lavoro di ricalcolo, pochissimo tempo per ragionare sulle scelte: era questo lo squilibrio da correggere. La sfida più grossa è stata gestire nel browser centinaia di migliaia di celle, con filtri, in tempi ragionevoli, e tenere insieme due esigenze: evitare le sovrascritture tra utenti e garantire dati sempre coerenti.
La progettazione
Il portale si apre da browser, senza nulla da installare, e si usa come il foglio di calcolo che gli utenti conoscono da sempre: i prezzi si modificano direttamente nelle celle, con copia dei dati, formule che si trascinano e filtri sulle colonne.
La regola è semplice: chi apre un file per modificarlo lo prende in carico, gli altri lo vedono in sola lettura, e le modifiche diventano definitive solo al salvataggio, così non ci sono sovrascritture. A fine fase il responsabile può congelare i dati, e il portale ne conserva una fotografia separata.
Il what-if è il secondo passo. Le simulazioni sono scenari a sé, con cambi, dazi, costi di trasporto, markup, FOB, Made In e anche i prezzi modificabili, e non toccano i prezzi ufficiali finché non vengono confermati. Ogni variazione si propaga a tutti i listini e a tutti i prodotti coinvolti: un dazio vale per tutti gli articoli con lo stesso codice doganale, un cambio per tutti i listini che ne dipendono. Cinque ruoli stabiliscono chi può fare cosa.
La realizzazione
Per prima cosa abbiamo costruito lo scambio dei dati con i sistemi aziendali: dal PLM arrivano prodotti, stagioni, brief, costi, cambi e dazi. In uscita il portale invia all’ERP e alla business intelligence solo gli articoli marcati per l’esportazione.
Su queste basi sono nati i file di pricing, con i totali e i riepiloghi. Il what-if è arrivato dopo, come secondo passo. Ogni novità è stata verificata in un ambiente di prova prima di arrivare agli utenti.
Importazione di costi, cambi e dazi, creazione dei file per divisione e listino, proposta dei prezzi e invio ai sistemi aziendali sono passaggi automatici.
I risultati
- Poche ore invece di diversi giorni per preparare il pricing di una nuova stagione: i dati arrivano dal PLM e i prezzi partono già proposti in base alla configurazione di ogni listino.
- Sovrascritture azzerate e un solo dato per tutti: chi lavora su un listino lo prende in carico, gli altri lo vedono in sola lettura, e non serve più mettere insieme a mano i file di ciascuno.
- What-if che si aggiorna subito, come in Excel, e con dati coerenti: a ogni modifica di una cella la variazione di un FOB, di un tasso di cambio o di un dazio si propaga da sola a tutti i listini e a tutti i prodotti coinvolti, e si confronta con lo scenario di partenza.
- Prezzi consegnati in automatico all’ERP e alla business intelligence, con data e ora dell’ultima esportazione: niente più caricamenti manuali e niente errori di trascrizione.
Le riunioni sul prezzo ora partono da scenari già pronti, compresi quelli avversi. L’ufficio discute di strategia, di mercati e di margini su dati coerenti, invece di verificare se i conti tornano.
