Se una metrica non guida una decisione, toglietela

Quasi ogni azienda ha qualche dashboard. Molte ne hanno troppe. Poche hanno una Single Source of Truth: un vocabolario di misura che direzione, marketing, sales e IT usano senza litigare.

Il sintomo tipico: tre file Excel, due Power BI e un export dal CRM che raccontano storie diverse sullo stesso mese. Il problema raramente è «manca Power BI» o «serve BigQuery». È a monte: fonti sporche, integrazioni assenti, metriche senza responsabile.

Il vero obiettivo della BI non è costruire dashboard. È ridurre il tempo tra una domanda di business e una decisione affidabile.

In Syncronika questo percorso vive nel perimetro data analytics e nella scheda reporting esecutivo. Warehouse, lake, BI e AI entrano quando servono al percorso, non come progetto di moda.

Il percorso in sette tappe

Questa non è una lista di definizioni. È un cammino: ogni tappa sblocca la successiva.

Percorso: problema, fonti, pulizia, integrazione, warehouse, BI, AI

Problema · numeri discordanti, decisioni lente
Fonti dati · CRM, e-commerce, ads, gestionale (OLTP)
Pulizia · qualità, deduplica, regole
Integrazione · batch o streaming, ETL / ELT
Warehouse · modello, storico, Single Source of Truth
BI · lettura + semantic layer («ricavo» uguale per tutti)
AI mirata · solo dopo definizioni e pipeline

Potete saltare sezioni. Non saltate l’ordine: mettere Power BI o l’AI al passo 1 riproduce il caos, in più bello.

1. Il problema: niente verità unica

Una dashboard ha senso solo se risponde a domande che qualcuno pone davvero, con una cadenza e un seguito.

Esempi onesti:

Quali lead merita chiamare questa settimana? (SaaS / servizi B2B)
Dove si rompe il funnel tra campagna e ordine? (e-commerce)
Il costo del supporto sta salendo per volume o per qualità dati? (servizi / helpdesk)
Il margine del canale X regge dopo i resi? (retail / produzione)

Se nessuno agisce sul numero, togliete il riquadro. Meno grafici, più indicatori con owner.

Single Source of Truth significa: una definizione condivisa di ciascuna metrica critica, alimentata da fonti governate, leggibile da tutti i ruoli senza «la mia versione Excel».

Senza di essa, ogni meeting riparte da «i miei numeri dicono altro».

2. Fonti dati: dove nasce (o muore) tutto

CRM, e-commerce, ads, helpdesk, gestionale: tipicamente database OLTP (Online Transaction Processing). Qui vivono anagrafiche, ordini, ticket. Se i campi sono doppi, vuoti o contraddittori, nessun BI a valle li salva.

Prima data enrichment e CRM intelligence, poi i report.

Esempi per settore

Contesto	Fonti tipiche	Domanda che deve tornare
E-commerce	Shopify / Magento, ads, magazzino	Ordini netti vs resi per canale
SaaS B2B	CRM, billing, product analytics	Pipeline e churn nello stesso vocabolario
Produzione	ERP, MES, qualità	Costo, scarti, lead time su un solo modello
Servizi	CRM, helpdesk, timesheet	Margine per progetto e SLA

3. Pulizia: regole prima dei grafici

Deduplica clienti, campi obbligatori, controlli in ingresso, mapping tra ID (CRM vs e-commerce vs fatturazione). È lavoro poco glamour e decisamente più utile del terzo Power BI.

Senza pulizia, ogni pipeline copia la confusione nel warehouse.

4. Integrazione: come i dati arrivano al modello

Dal CRM alla decisione: ETL, warehouse, Power BI, manager

Batch o streaming

Batch (finestre periodiche: notte, ora, chiusura giorno): ideale per anagrafiche, ordini consolidati, export ads, snapshot gestionale. Più semplice da auditare e riprocessare. Limite: il dato in BI è fermo alla finestra precedente.

Streaming (o quasi in tempo reale: webhook, code, CDC, clickstream): ha senso per inventario, anomalie, supporto live, campagne che devono reagire in minuti. Costa di più in complessità. Se nessuno agisce sul minuto, è teatro.

Ibrido (la norma): batch per finance e warehouse «ufficiali»; streaming solo dove la latenza cambia una decisione operativa.

La frequenza di ingestion deve seguire la frequenza della decisione, non il reverse.

ETL ed ELT: come arrivano i dati nel warehouse

ETL (Extract, Transform, Load): estraete, trasformate (pulizia, join, regole), poi caricate nel warehouse. Utile quando volete controllare la trasformazione prima di toccare il magazzino analitico.

ELT (Extract, Load, Transform): caricate prima (anche grezzo) nel warehouse o nel lake, poi trasformate lì dentro (SQL, dbt, procedure). Utile con motori cloud elastici (BigQuery, Snowflake, Fabric) dove la trasformazione scala meglio «a destinazione».

Non è una guerra di sigle. È una scelta di dove vive la logica di business e chi la versiona.

Quando disegnate le integrazioni, chiedete: batch, streaming o entrambi? ETL o ELT? Quale SLA di freschezza? Chi riprocessa se un carico fallisce?

5. Warehouse (e lake): il posto della verità analitica

OLTP e OLAP: due database, due mestieri

Confronto OLTP e OLAP

OLTP: scrive il presente. Esempi: PostgreSQL, MySQL / MariaDB, SQL Server, Oracle (spesso dietro CRM o e-commerce, o su RDS / Cloud SQL).

OLAP: spiega il passato e prepara la decisione. Esempi: BigQuery, Snowflake, Amazon Redshift, Microsoft Fabric / Azure Synapse, Databricks SQL; in contesti snelli anche ClickHouse. Power BI di solito legge da qui, non dal Postgres di produzione.

Errore classico: report pesanti sul MySQL/Postgres di produzione. Errore opposto: warehouse che copia fonti sporche.

Quando il warehouse diventa utile

Il warehouse diventa utile quando le decisioni iniziano a dipendere da dati provenienti da più sistemi, quando serve mantenere uno storico affidabile, quando volete versionare i KPI, o quando il database operativo non è più il posto giusto per fare analisi (lock, timeout, numeri che si muovono mentre qualcuno salva).

Non è «solo se siete grandi». È «quando l’analisi non può più vivere dentro il gestionale».

Un data lake conserva grezzo o semi-strutturato (log, eventi, file). Serve a volumi alti o esperimenti. Non serve se il problema è «il commerciale non si fida del CRM».

In sintesi: lake = archivio grezzo, warehouse = modello per decisioni, BI = lettura.

Denormalizzare per il BI

Nei database OLTP i dati sono spesso normalizzati. Sul lato OLAP conviene denormalizzare in modo controllato: modello a stella (fatti + dimensioni ampie), chiavi canoniche, meno join inventati in Power BI.

Non è un CSV monstre. È un modello di lettura su cui marketing e finance ottengono lo stesso numero.

dbt (citazione essenziale)

dbt (data build tool) è oggi uno standard di fatto per modellare trasformazioni nel warehouse: SQL versionato, test, documentazione, ambienti. Non sostituisce BigQuery o Snowflake: li rende governabili. Se qualcuno vi parla solo di «caricare tabelle» senza come versionate le trasformazioni, chiedete di dbt (o equivalente).

6. BI e semantic layer: «ricavo» uguale per tutti

Power BI eccelle a visualizzare e distribuire report in aziende Microsoft. Looker, Metabase e altri funzionano altrettanto bene. Lo strumento conta meno di tre condizioni:

Definizioni condivise
Pipeline affidabile
Rituale di revisione (metriche che si possono togliere)

Il semantic layer

Il vero problema oggi spesso non è il dashboard. È avere «ricavo» uguale per tutti.

Il semantic layer (modello semantico) è lo strato dove vivono metriche e relazioni di business, indipendenti dal singolo report:

Power BI Semantic Model / Microsoft Fabric Semantic Model
LookML (Looker)
dbt Metrics / MetricFlow
Cube, AtScale, Transform e altri metric layer

Senza di esso, ogni analista reinventa il KPI in DAX o SQL. Con esso, la Single Source of Truth diventa consultabile.

Se due team devono discutere la formula di «ricavo netto» dentro il grafico, il semantic layer non c’è ancora.

7. Dove entra l’AI (e dove no)

L’AI sul dato è utile in punti precisi. Non come sostituto di un modello di misura.

Ha senso quando:

classificate ticket, note o documenti (vedi document processing);
segnalate anomalie («tasso di reso fuori soglia sul canale Y»);
sintetizzate metriche già governate per la direzione;
accelerate mapping e pulizia con supervisione umana.

Non ha senso quando:

chiedete a un modello di inventare il KPI che manca;
un agente racconta numeri discordanti come una sola verità;
comprate un copilota BI prima di owner, definizioni e semantic layer.

Come in AI ovunque? Spesso basta senza AI, molte aziende risolvono prima con regole, integrazioni e qualità dati.

Data governance: chi decide sulla metrica

Non basta sapere chi aggiorna il dato. Serve sapere:

chi può modificarlo;
chi approva una metrica;
chi cambia una definizione (es. «lead qualificato»);
dove vive la documentazione (semantic layer, dbt, wiki).

Questa è data governance. Senza di essa, la Single Source of Truth decade al primo turnover o al primo «hotfix» in Power BI.

Il rituale breve di revisione (cadenza, azioni, metriche da togliere) è governance in pratica, non solo policy.

Checklist operativa (senza progetto triennale)

Inventario fonti e owner
Pulizia e regole di qualità
Metriche minime condivise (anche su CRM + foglio controllato)
Integrazioni stabili (batch/streaming, ETL/ELT)
Modello denormalizzato + trasformazioni versionate (dbt o equivalente)
Warehouse quando multi-fonte, storico o separazione dall’operativo lo richiedono
BI agganciata al semantic layer, non alle API a caso
AI mirata, con metriche di controllo

Ogni passo ha uno stop. È reporting esecutivo collegato a stack reali, non data platform da brochure.

Cosa chiedere al prossimo fornitore (o al team interno)

Quali decisioni cambieranno?
Chi possiede ciascuna metrica e chi ne approva la definizione?
Quali sistemi, con quale freschezza (batch/streaming), ETL o ELT?
Come costruite la Single Source of Truth e il semantic layer?
Usate dbt (o equivalente) per versionare le trasformazioni?
Dove proponete l’AI, e come misurate meno errori vs più slide?

Se le risposte sono vaghe, state comprando tool, non decisioni.

Dove iniziare

Se oggi convivono Excel paralleli, un Power BI poco usato e un CRM che nessuno si fida, non partite dal logo del cloud. Partite dalle decisioni e dalle fonti. Poi integrazione, warehouse, semantic layer. L’AI arriva dopo.