Da Excel a Power BI: la guida per chi arriva dalle tabelle pivot

Power BI non è "Excel con i grafici più belli": è un motore di modellazione dati dove le tabelle stanno separate e collegate da relazioni, i calcoli vivono come misure DAX e la presentazione è un layer a parte. Se sai usare bene le tabelle pivot hai già in testa metà dei concetti — contesto di filtro, aggregazioni, dimensioni — solo che in Excel sono impliciti e in Power BI diventano espliciti. Il passaggio difficile non è imparare l'interfaccia: è smettere di ragionare per "tabellone piatto".

Il cambio di mentalità: tre layer invece di un foglio

In Excel dato, calcolo e presentazione stanno nello stesso posto. La cella D42 contiene un numero, una formula e una formattazione, e spesso è anche l'input di qualcos'altro. Funziona finché il file è tuo e sta sotto le 100.000 righe.

Power BI separa il lavoro in tre livelli distinti:

1. Power Query (linguaggio M) — recupero e pulizia dei dati. Qui rinomini, tipizzi, filtri, unisci, spivotti. Nessuna presentazione.
2. Modello semantico — tabelle, relazioni, misure DAX, gerarchie, formattazioni. È il "cervello": la logica di business sta qui, una volta sola, per tutti i report.
3. Report — i visual. Non contengono logica: chiedono al modello un numero e lo disegnano.

La conseguenza pratica è che se cambi la definizione di "Fatturato netto", la cambi in un punto e si aggiorna ovunque. In Excel la cambi in 14 fogli e in 3 te ne dimentichi.

Perché il tabellone piatto non scala

L'istinto di chi viene da Excel è costruire un unico foglio con 60 colonne: ordine, cliente, città del cliente, categoria prodotto, agente, area dell'agente, tutto insieme. Poi ci si punta la pivot sopra. In Power BI questo approccio si rompe per tre motivi concreti:

• Compressione. Il motore VertiPaq comprime per colonna: meno valori distinti ci sono, più il modello è piccolo e veloce. Ripetere "Lombardia" 4 milioni di volte in una tabella fatti costa molto più che tenerla una volta sola in una tabella Clienti da 8.000 righe.
• Manutenzione. Se il cliente cambia area commerciale, in una tabella dimensione modifichi una riga. Nel tabellone ne riscrivi 40.000.
• Ambiguità dei filtri. Un tabellone unico non ti permette di filtrare due tabelle fatti diverse (vendite e budget) con lo stesso slicer. Con lo schema a stella — tabelle fatti al centro, dimensioni intorno — sì.

Lo schema a stella non è una raffinatezza da architetti: è il formato che il motore di Power BI si aspetta. Tutto il resto funziona peggio.

Corrispondenze concrete Excel → Power BI

CERCA.VERT non ti serve quasi mai più

Il 90% dei CERCA.VERT esistenti serve a portare un attributo (categoria, area, nome cliente) accanto a una riga di transazione, per poterlo poi usare come campo di riga nella pivot. In Power BI questo è esattamente il lavoro di una relazione uno-a-molti: Clienti[IdCliente] (lato uno) → Vendite[IdCliente] (lato molti). Fatta la relazione, trascini Clienti[Area] in un visual e le misure su Vendite si filtrano da sole.

Le due eccezioni in cui vale ancora la pena "materializzare" il dato:

• Ti serve la colonna dentro Power Query, per un raggruppamento o un calcolo a monte → usa Merge queries (il vero erede del CERCA.VERT).
• Ti serve una colonna in una tabella dimensione per creare una gerarchia → colonna calcolata con RELATED, ma solo lì.

-- Legittimo: colonna in una dimensione, bassa cardinalità
Prodotti[Macrocategoria] = RELATED( Categorie[Macrocategoria] )

Quello che non va fatto è aggiungere RELATED a 5 milioni di righe della tabella fatti solo per "vederle vicine". Il modello raddoppia di peso e non ci guadagni nulla.

Dalle formule alle misure

Una misura è una formula che viene ricalcolata per ogni cella del visual, in base ai filtri attivi in quel punto. È esattamente ciò che fa una pivot, solo che Power BI te lo dice apertamente e ti lascia intervenire.

Fatturato = SUM( Vendite[Importo] )

Numero Clienti = DISTINCTCOUNT( Vendite[IdCliente] )

Scontrino Medio = DIVIDE( [Fatturato], DISTINCTCOUNT( Vendite[IdOrdine] ) )

-- L'equivalente di SOMMA.PIÙ.SE
Fatturato Nord 2026 =
CALCULATE(
    [Fatturato],
    'Calendario'[Anno] = 2026,
    Clienti[Area] = "Nord"
)

-- Confronto con l'anno precedente: in Excel sarebbero due tabelle e una sottrazione
Fatturato AP =
CALCULATE( [Fatturato], SAMEPERIODLASTYEAR( 'Calendario'[Date] ) )

Crescita YoY % =
VAR Corrente = [Fatturato]
VAR Precedente = [Fatturato AP]
RETURN
    DIVIDE( Corrente - Precedente, Precedente )

Nota due cose. Primo: [Fatturato] viene riusato dentro le altre misure — si scrive una volta e si compone, cosa che in Excel non fai quasi mai. Secondo: DIVIDE restituisce vuoto (o il terzo argomento) se il denominatore è zero, quindi ti risparmi il SE.ERRORE.

Power Query lo sai già usare (forse senza saperlo)

Se in Excel hai mai usato Dati → Recupera e trasforma, hai già usato Power Query: è lo stesso motore, lo stesso linguaggio M, la stessa interfaccia. Le query si copiano da Excel a Power BI con un copia-incolla nell'editor.

La regola operativa è semplice: tutta la pulizia si fa in Power Query, non in DAX. Power Query gira una volta al refresh; DAX gira ad ogni interazione dell'utente.

let
    Origine = Excel.Workbook(File.Contents("C:\Dati\Vendite2026.xlsx"), null, true),
    FoglioVendite = Origine{[Item = "Vendite", Kind = "Sheet"]}[Data],
    Intestazioni = Table.PromoteHeaders(FoglioVendite, [PromoteAllScalars = true]),
    Tipizzata = Table.TransformColumnTypes(Intestazioni, {
        {"Data", type date},
        {"IdCliente", type text},
        {"IdProdotto", type text},
        {"Importo", type number},
        {"Quantita", Int64.Type}
    }),
    SenzaVuoti = Table.SelectRows(Tipizzata, each [Importo] <> null),
    ColonneUtili = Table.SelectColumns(SenzaVuoti,
        {"Data", "IdCliente", "IdProdotto", "Importo", "Quantita"})
in
    ColonneUtili

Il caso che da solo giustifica il passaggio a Power BI è la cartella di file mensili. Al posto di aprire 12 file e incollarli uno sotto l'altro:

let
    Cartella = Folder.Files("C:\Dati\VenditeMensili"),
    SoloXlsx = Table.SelectRows(
        Cartella,
        each Text.EndsWith([Name], ".xlsx") and not Text.StartsWith([Name], "~$")
    ),
    ConDati = Table.AddColumn(
        SoloXlsx,
        "Dati",
        each Excel.Workbook([Content], true){[Item = "Vendite", Kind = "Sheet"]}[Data]
    ),
    Espansa = Table.ExpandTableColumn(
        ConDati, "Dati", {"Data", "IdCliente", "IdProdotto", "Importo"}
    ),
    Pulita = Table.SelectColumns(Espansa, {"Data", "IdCliente", "IdProdotto", "Importo"}),
    Tipizzata = Table.TransformColumnTypes(Pulita, {
        {"Data", type date}, {"Importo", type number}
    })
in
    Tipizzata

A gennaio prossimo aggiungi il file nella cartella e premi Aggiorna. Fine.

Cosa NON portarti dietro da Excel

• Celle unite, titoli decorativi, righe vuote di respiro. Power Query li legge come dati. Prima di connetterti, il foglio sorgente deve essere una tabella rettangolare: una riga di intestazione, poi solo dati.
• Righe di totale dentro i dati. Finiscono nella tabella fatti e raddoppiano i numeri. I totali li calcola il modello.
• La formattazione come informazione. "Le righe gialle sono gli ordini in ritardo" non esiste in Power BI: serve una colonna Stato.
• Più tabelle nello stesso foglio, separate da colonne vuote.
• Dati sporchi: date salvate come testo, importi con separatore delle migliaia dentro una colonna testo, "N/D" e "-" al posto del vuoto, spazi finali, Milano / MILANO / milano . Ognuno di questi ti crea valori distinti diversi e relazioni che non funzionano.
• Colonne calcolate ovunque. In Excel aggiungere una colonna è gratis, in Power BI occupa memoria in modo permanente e non reagisce ai filtri. Nella maggior parte dei casi vuoi una misura.
• Il file come fonte di verità. Se il .xlsx sta sul tuo desktop, il refresh in cloud non funzionerà. Mettilo almeno su SharePoint/OneDrive (nessun gateway richiesto), o meglio ancora prendi il dato dal database.

Il tuo primo progetto, passo per passo

1. Connetti la sorgente (Recupera dati → Excel/cartella/database) e importa solo le colonne che ti servono.
2. Pulisci in Power Query: tipi corretti, colonne inutili rimosse, passaggi rinominati in italiano leggibile ("Rimuovi ordini annullati" invece di "Righe filtrate1").
3. Separa fatti e dimensioni. Dal tabellone ricava Vendite (le transazioni) più Clienti, Prodotti, Agenti. In Power Query: duplica la query, tieni le colonne descrittive, Rimuovi duplicati.
4. Crea la tabella Calendario e marcala come tabella delle date (Strumenti tabella → Contrassegna come tabella data). Senza, la time intelligence sbaglia ai bordi dei periodi.

Calendario =
VAR MinData = MIN( Vendite[Data] )
VAR MaxData = MAX( Vendite[Data] )
RETURN
    ADDCOLUMNS(
        CALENDAR( DATE( YEAR( MinData ), 1, 1 ), DATE( YEAR( MaxData ), 12, 31 ) ),
        "Anno", YEAR( [Date] ),
        "Mese", MONTH( [Date] ),
        "Nome Mese", FORMAT( [Date], "mmmm" ),
        "Anno-Mese", FORMAT( [Date], "yyyy-mm" ),
        "Ordine Mese", YEAR( [Date] ) * 100 + MONTH( [Date] ),
        "Trimestre", "T" & ROUNDUP( MONTH( [Date] ) / 3, 0 )
    )

5. Crea le relazioni uno-a-molti dalle dimensioni ai fatti, con direzione del filtro singola. Sono i tuoi CERCA.VERT, fatti una volta sola.
6. Scrivi 4-5 misure base in una tabella dedicata (_Misure) e formattale subito: valuta con zero decimali, percentuali con uno. La formattazione si imposta sulla misura, non sul visual.
7. Costruisci una sola pagina con 4-6 visual: le card dei KPI in alto a sinistra, il trend accanto, il dettaglio sotto. Resisti alla tentazione di replicare il tuo foglio da 40 colonne.
8. Pubblica nel Service, imposta l'aggiornamento pianificato e condividi tramite app o tab di Teams.

Per i colleghi che non molleranno mai Excel c'è Analizza in Excel: dal Service, tasto destro sul modello semantico, e si apre una tabella pivot collegata live al modello. Loro continuano a fare le loro pivot, ma su numeri governati. È il modo più efficace per far accettare il cambio.

Una nota sul 2026: Microsoft Fabric, OneLake e Direct Lake esistono e sono ottimi, ma non ti servono per iniziare. Se la tua sorgente è un Excel da 200.000 righe, la modalità Import classica è la scelta giusta e più veloce. Direct Lake ha senso quando i dati stanno già in OneLake e parliamo di decine di milioni di righe, e richiede una capacità Fabric a pagamento.

Gli errori tipici di chi viene da Excel

• Importare il tabellone unico e fermarsi lì. Funziona con dati giocattolo, si pianta a un milione di righe.
• Colonne calcolate al posto delle misure. Una colonna calcolata è congelata al refresh e non reagisce ai filtri; una misura sì. Se il numero deve cambiare quando l'utente clicca uno slicer, è una misura.
• Nessuna tabella Calendario, o una tabella date presa dai fatti. SAMEPERIODLASTYEAR su Vendite[Data] sembra funzionare e sbaglia sistematicamente i mesi senza vendite.
• Relazioni bidirezionali "per sicurezza". Creano percorsi di filtro ambigui e risultati che nessuno sa spiegare. Bidirezionale solo con motivo esplicito.
• Scrivere i totali a mano. In Power BI il totale di riga di una matrice non è la somma delle celle: è la misura ricalcolata sul contesto totale. Se Margine % fa 43% nel totale e le righe fanno 51%, 38%, 40%, non è un bug.
• Usare / invece di DIVIDE e ritrovarsi Infinity nei visual.
• Formattare i numeri nel visual invece che sulla misura, e rifarlo in ogni pagina.
• Trattare Power BI come un esportatore. Se il progetto finisce con "poi esporto in Excel e faccio le pivot lì", il modello è sbagliato o mancano le misure giuste.
• Confondere gratis e licenze. Power BI Desktop è gratuito, ma per pubblicare e condividere serve una licenza Pro per utente (o una capacità Fabric F-SKU, che permette ai lettori di restare Free). Scoprirlo il giorno della presentazione è spiacevole.
• Cercare di "modificare la cella". In un report i dati sono in sola lettura: le correzioni si fanno alla fonte o in Power Query. È una feature, non un limite.

Quanto ci vuole davvero

Chi usa bene Excel arriva a un primo report pubblicato e funzionante in poche sere: la parte di connessione, pulizia e visual è intuitiva. Le due cose che richiedono studio vero sono il contesto di filtro in DAX (perché una misura restituisce un numero diverso a seconda di dove la metti) e la modellazione a stella. Sono anche le due che separano un report che regge dall'ennesimo file che nessuno apre.

Se preferisci farlo con un percorso ordinato invece che a colpi di video sparsi, il corso Power BI Pro parte esattamente da qui — interfaccia, Power Query, modello, DAX e poi Fabric e Copilot — con esercizi svolti a ogni lezione: inizia dalla prima lezione o dai un'occhiata ai prezzi.