Data Warehouse su Google Cloud per il Retail: Integrare Più Gestionali in BigQuery

Il Problema: Dati Ovunque, Risposte da Nessuna Parte

Chi lavora in un'azienda retail con più punti vendita conosce bene la situazione. Il gestionale principale registra vendite e movimenti di magazzino, la cassa ha il suo database, l'e-commerce vive su un'altra piattaforma, il marketing usa un CRM separato e l'amministrazione esporta tutto in fogli di calcolo. Ogni sistema funziona, ma nessuno parla con gli altri.

Il risultato è che domande apparentemente semplici diventano piccoli progetti: quanto ha venduto il negozio X rispetto allo stesso periodo dell'anno scorso, considerando anche gli ordini online ritirati in negozio? Per rispondere servono tre export, un paio di VLOOKUP e mezza giornata di lavoro. E la settimana dopo si ricomincia da capo.

Un Data Warehouse risolve esattamente questo problema: è un unico archivio, pensato per l'analisi, in cui i dati di tutti i sistemi vengono raccolti, puliti e collegati tra loro.

Perché Google Cloud e BigQuery

Esistono molte alternative (Snowflake, Azure Synapse, Amazon Redshift, o anche un semplice PostgreSQL ben configurato), ma per una realtà di medie dimensioni BigQuery ha alcuni vantaggi concreti:

• Serverless: non ci sono server da dimensionare o mantenere. Si caricano i dati e si interrogano.
• Costi legati all'uso: si paga lo storage (molto economico) e i dati letti dalle query. Per volumi tipici di un retailer medio, la spesa mensile resta spesso contenuta.
• SQL standard: chi conosce SQL è operativo dal primo giorno.
• Integrazione nativa con Google Workspace: Looker Studio, Google Sheets (tramite Connected Sheets) e Apps Script si collegano a BigQuery senza attriti. Se l'azienda usa già Google Workspace, è un vantaggio enorme.

L'Architettura a Livelli

Il modo più robusto per organizzare un Data Warehouse è dividerlo in livelli, ognuno con una responsabilità chiara. Una struttura molto diffusa è quella a tre strati:

1. Raw (o Bronze)

Qui finiscono i dati così come arrivano dai sistemi sorgente, senza trasformazioni. Se il gestionale esporta un CSV con colonne dai nomi incomprensibili, quel CSV viene caricato tale e quale. Questo livello è la nostra assicurazione: se una trasformazione successiva si rivela sbagliata, possiamo sempre ripartire dai dati originali.

2. Staging (o Silver)

In questo livello i dati vengono puliti e standardizzati: tipi corretti, nomi delle colonne coerenti, codici articolo uniformati, duplicati rimossi. È anche il punto in cui si risolvono le differenze tra sistemi: se un gestionale chiama un negozio "NEG01" e un altro "Negozio Centro", qui si crea la tabella di raccordo.

3. Mart (o Gold)

L'ultimo livello contiene tabelle pronte per l'analisi, modellate attorno alle domande del business: vendite giornaliere per negozio e articolo, giacenze a fine settimana, sell-through per collezione. Sono queste le tabelle a cui si collegano report e dashboard.

-- Esempio di tabella mart: vendite giornaliere per negozio
CREATE OR REPLACE TABLE mart.vendite_giornaliere AS
SELECT
  v.data_vendita,
  n.nome_negozio,
  a.categoria,
  a.stagione,
  SUM(v.quantita) AS pezzi_venduti,
  SUM(v.importo_netto) AS fatturato_netto
FROM staging.vendite v
JOIN staging.negozi n USING (codice_negozio)
JOIN staging.articoli a USING (codice_articolo)
GROUP BY 1, 2, 3, 4;

Il Modello Dati: Fatti e Dimensioni

Il cuore del livello mart è quasi sempre uno schema a stella. Al centro ci sono le tabelle dei fatti, che registrano eventi misurabili (una vendita, un movimento di magazzino, un reso). Attorno ci sono le dimensioni, che descrivono il contesto: l'articolo, il negozio, il cliente, la data.

Nel retail le dimensioni più importanti sono tipicamente:

• Articolo: con gerarchie come reparto, categoria, linea, stagione, collezione, e attributi come taglia e colore.
• Negozio: con zona geografica, superficie, tipo di punto vendita.
• Calendario: una tabella che, per ogni giorno, indica settimana, mese, stagione commerciale, periodo di saldi, festività. Sembra banale, ma è ciò che rende possibili confronti corretti tra anni diversi.

Una nota specifica per il fashion: la combinazione articolo + taglia + colore (la SKU) è spesso la granularità giusta per le giacenze, mentre per l'analisi delle vendite si lavora più spesso a livello di modello. Decidere fin da subito a quale granularità tenere ogni tabella evita molti problemi dopo.

Portare i Dati in BigQuery

Il caricamento è la parte che richiede più pazienza, perché ogni sistema sorgente ha le sue particolarità. Le strade principali sono tre:

1. Export programmati: il gestionale esporta file (CSV, Excel) in una cartella o in un bucket di Cloud Storage, e da lì vengono caricati in BigQuery. È la soluzione più semplice quando il software non offre altre possibilità.
2. Connessione diretta al database: se il gestionale usa un database accessibile (SQL Server, PostgreSQL, MySQL), si può estrarre direttamente con script Python o con servizi come Datastream.
3. API: e-commerce e piattaforme cloud espongono quasi sempre API REST, interrogabili con piccoli script schedulati tramite Cloud Functions o Cloud Run.

Per orchestrare il tutto, Cloud Scheduler e qualche funzione serverless sono spesso sufficienti. Quando i flussi crescono, strumenti come dbt per le trasformazioni SQL diventano preziosi, perché portano versionamento, test e documentazione nel codice delle trasformazioni.

Le Lezioni Imparate

Lavorare su un progetto di questo tipo in un'azienda con più negozi insegna alcune cose che nessun tutorial menziona.

I dati sorgente non sono mai puliti come sembrano

Codici articolo scritti in modo diverso, negozi chiusi che compaiono ancora nelle anagrafiche, resi registrati come vendite negative in un sistema e come documenti separati in un altro. Il livello di staging esiste proprio per questo, e conviene dedicargli più tempo del previsto.

Partire da una domanda, non dai dati

La tentazione è caricare tutto e poi vedere cosa farne. Funziona meglio il contrario: scegliere due o tre domande concrete che il business si fa ogni settimana, costruire il percorso completo (sorgente, staging, mart, report) per quelle, e poi allargare. Un primo report utile dopo poche settimane vale più di un'architettura perfetta dopo sei mesi.

Definire le metriche una volta sola

Cosa significa "fatturato"? Lordo o netto? Con o senza resi? Con o senza IVA? Se ogni report calcola la metrica a modo suo, i numeri non tornano mai e la fiducia nel sistema crolla. Le definizioni vanno scritte, condivise e implementate una sola volta, nel livello mart.

Controllare i costi fin dal primo giorno

BigQuery è economico, ma una query scritta male su una tabella enorme può leggere molti più dati del necessario. Partizionare le tabelle per data e clusterizzarle per i campi più filtrati (negozio, articolo) riduce drasticamente i dati letti e quindi i costi.

CREATE TABLE staging.vendite
PARTITION BY data_vendita
CLUSTER BY codice_negozio, codice_articolo
AS SELECT * FROM raw.vendite_export;

Le persone contano più della tecnologia

Il miglior Data Warehouse è inutile se nessuno lo usa. Coinvolgere fin da subito chi lavora ogni giorno con i numeri (commerciale, amministrazione, responsabili di negozio) e mostrare risultati concreti presto è ciò che fa la differenza tra un progetto adottato e uno dimenticato.

Dal Data Warehouse all'AI

Un vantaggio spesso sottovalutato di un Data Warehouse ben costruito è che diventa la base perfetta per l'intelligenza artificiale. Con dati puliti e un modello chiaro, è possibile collegare un LLM al warehouse (ad esempio tramite un server MCP) e permettere a chiunque in azienda di fare domande in linguaggio naturale: "quali sono i 10 articoli con il sell-through più basso nella stagione attuale?". Senza un warehouse, lo stesso assistente dovrebbe navigare tra sistemi incoerenti, con risultati inaffidabili.

Conclusioni

Un Data Warehouse su Google Cloud non è un progetto riservato alle grandi aziende. Con BigQuery, qualche script ben scritto e un'architettura a livelli, anche una realtà retail di medie dimensioni può avere un unico punto di verità per i propri dati. La tecnologia è la parte più facile: la vera sfida è pulire i dati, definire le metriche in modo condiviso e far sì che le persone si fidino dei numeri. Quando succede, le domande che prima richiedevano mezza giornata trovano risposta in pochi secondi.