Dalle regole “a voce” a un modello operativo parametrico: scenari, KPI e output ripetibili per governare una gamma ampia
Panoramica
Ho sviluppato in MS Access un motore di forecast articoli basato su scenari configurabili: un sistema che permette di simulare previsioni ripetibili partendo da dati vendite e anagrafica prodotto, con parametri chiari e modificabili dall’utente.
È pensato per chi lavora su gamma e supply chain in un’azienda dell’aftermarket automotive, quando serve trasformare storico e segnali di mercato in un output operativo (e confrontabile) senza dipendere da file “magici” in Excel.
Nel mondo automotive la gestione della gamma è estremamente data-centrica: tra migliaia di codici, applicazioni e clienti, le decisioni non possono basarsi su impressioni. Servono KPI chiari e un modello che trasformi lo storico in indicazioni operative, in modo ripetibile.
Il problema di partenza
In azienda il forecast non era “assenza di regole”: le linee guida c’erano già, almeno a grandi linee. Si sapeva cosa osservare (anni anomali da pesare, articoli nuovi da trattare in modo prudente, rischio di dipendenza da un solo cliente, casi da revisionare a mano).
Il punto debole era un altro: mancava un modello vero, integrato in uno strumento, che rendesse quelle regole applicabili in modo coerente e ripetibile.
- Le regole vivevano tra appunti, abitudini e file diversi, quindi l’esecuzione cambiava da persona a persona.
- Ogni aggiornamento richiedeva ricalcoli e controlli manuali, con rischio di errori e interpretazioni “a sentimento”.
- Non esisteva una gestione strutturata di scenari e parametri, per confrontare ipotesi (es. anni “distorti” vs anni “tipici”) senza ricominciare da zero.
Cosa fa lo strumento
Gestione scenari e parametri
Il cuore del progetto è la gestione “a scenari”: ogni scenario rappresenta un set completo di impostazioni, validabile e attivabile con un click.
- Creazione e clonazione scenari per testare ipotesi diverse senza perdere il riferimento “base”.
- Regola chiave: uno scenario attivo alla volta, con gestione automatica delle incoerenze (se più scenari risultano attivi).
- Parametri organizzati per aree (anni/pesi, fattori di correzione, soglie, livelli di rischio), modificabili da maschera in modo ordinato.
- Validazione scenario: lo strumento controlla che lo scenario sia completo (anni definiti, set minimi di fattori presenti, soglie e bande configurate) prima di considerarlo “pronto”.
- Possibilità di lavorare anche sullo scenario attivo (scelta voluta): taratura rapida senza passaggi intermedi.
Import e gestione dati
Lo strumento parte da sorgenti interne già esistenti e costruisce una base “pulita” per l’elaborazione.
- Lettura dei dati vendite dal gestionale (già filtrati per escludere movimenti non rilevanti).
- Integrazione con anagrafica articoli e flag operativi (es. prodotto nuovo, a esaurimento, bloccato).
- Selezione dinamica dello storico tramite “anni scenario”: il perimetro è sempre coerente con lo scenario attivo.
- Preparazione di dataset intermedi ottimizzati per calcoli e controlli (senza copia/incolla e senza passaggi manuali).
- Logica “catalog-driven”: l’output finale contiene una riga per ogni articolo, anche se nel periodo selezionato non ha vendite.
KPI e analisi che alimentano il forecast
Un forecast credibile non deve copiare lo storico “così com’è”: alcuni anni sono influenzati da fattori esterni al mercato e falsano il segnale reale.
Per questo lo scenario permette di selezionare e pesare gli anni dello storico vendite a disposizione: l’output cerca una domanda più “tipica” e realistica, evitando che annate drogate guidino decisioni su acquisti, gamma e priorità.
Oltre allo storico vendite, il sistema calcola KPI utili a capire la struttura della domanda e il rischio commerciale.
- KPI sul periodo selezionato: vendite totali, numerosità clienti, dipendenza dal primo cliente (effetto “whale”).
- Classificazioni in classi di vendita (A/B/C/D) per interpretare rapidamente il peso di un articolo dentro la sua nicchia.
- Identificazione di situazioni ad alta fragilità (es. vendite concentrate su un solo cliente) per evitare forecast “ottimisti” pericolosi.
- Gestione robusta dei casi ambigui (ad esempio più clienti con lo stesso volume massimo), per rendere i risultati stabili e confrontabili.
- Supporto a logiche “prudenziali” tramite fattori e soglie scenario-driven.
Modello di forecast con regole operative
Il forecast non è una “formula unica”: è un modello composto da regole semplici, esplicite e tarabili.
- Selezione dello storico tramite anni + pesi: utile quando alcuni anni non rappresentano un mercato “normale” (picchi, shortage, eventi eccezionali).
- Base di forecast costruita su storico pesato, con correzioni tramite fattori (classe vendita, classe circolante, struttura clienti).
- Regole di sicurezza: articoli bloccati o a esaurimento vanno a previsione zero (policy stabile).
- Gestione dedicata per articoli nuovi: previsione “seed” prudente per evitare buchi informativi in assenza di storico.
- Tag operativi in output: segnali utili per interpretare subito il numero (rischio whale, cliente unico, alta concentrazione, necessità di revisione manuale).
Output ed export
Il risultato è pensato per diventare subito materiale di lavoro, non un file da “sistemare”.
- Output strutturato con storico per anno (solo gli anni dello scenario) + forecast finale + KPI e tag.
- Pronto per esportazioni e condivisione verso Excel (reportistica, pivot, analisi di supporto).
- Coerenza garantita: lo scenario attivo determina in modo univoco quali anni entrano nel modello e quali colonne di storico vengono prodotte.
- Tracciabilità: ogni run produce log e controlli, così è chiaro cosa è successo e quando.
Controlli qualità e tracciabilità
Ho dato molta importanza al fatto che un forecast sia “difendibile” e ripetibile.
- Validazione di completezza scenario prima dell’uso operativo.
- Controlli minimi di accettazione (coerenza record, perimetro articoli, anni effettivamente usati).
- Log dettagliato di esecuzione: utile sia per debug sia per audit interno.
- Invarianti anti-regressione: gli anni e i dati devono restare “puliti” per scenario (niente contaminazioni tra scenari).
Cosa cambia nella pratica
Questo progetto trasforma un’attività fragile e artigianale in un flusso ripetibile.
- Da file e passaggi manuali a uno strumento unico, con parametri espliciti.
- Da “ogni volta diverso” a scenari confrontabili (stessa base dati, impostazioni chiare).
- Da controlli a occhio a validazioni e log che riducono errori e discussioni.
- Da ore di sistemazione e verifiche a run più rapidi, con output già pronto per l’analisi in Excel.
- Migliore dialogo tra reparti: il forecast non è più “un numero”, ma un numero con contesto (KPI e tag).
Il mio ruolo nel progetto
Ho seguito il progetto end-to-end: ho raccolto le esigenze interne, definito la struttura a scenari e costruito un flusso che fosse pratico per me e per chiunque altro usi lo strumento.
Ho progettato la parte di configurazione (anni, pesi, fattori e soglie), ho realizzato le maschere di gestione e le validazioni, e ho integrato lo strumento nel flusso operativo tramite runner. Durante i test ho individuato e risolto punti critici (ad esempio la contaminazione degli anni tra scenari) e ho iterato finché l’esperienza utente non è diventata solida.