Power BI Dataflow e Datamart per PMI: self-service BI senza data warehouse (2022)

Lunedì mattina, riunione commerciale. Il direttore vendite apre una dashboard Power BI con il report di fine stagione: fatturato per categoria, marginalità per cliente, sell-through del canale retail. Il problema arriva quando il responsabile marketing chiede la stessa vista filtrata per campagna Google Ads, e il controller chiede il confronto stagione su stagione con i costi di logistica. Tre analyst aprono Power BI Desktop e ognuno ricostruisce da capo l’ETL: query SQL al gestionale, foglio Excel del fornitore, API Google Ads. Tre versioni della stessa estrazione, tre logiche che divergeranno entro sei mesi, tre dataset che pesano sullo stesso database transazionale ogni volta che qualcuno preme “Aggiorna”.

Power BI Dataflow cambia le regole per una PMI italiana. Il dataflow è ETL self-service nel cloud Microsoft: si costruisce una volta la pipeline di estrazione e pulizia, si schedula il refresh, ogni analyst consuma la stessa entità preparata. Dal 2021, con Power BI Premium Per User a 20 dollari/mese, questa architettura non è più riservata alle multinazionali con capacity Premium da 5.000 euro al mese. Una PMI da 30 dipendenti adotta lo stesso pattern di Banca Mediolanum o Coca-Cola pagando 3-5 licenze PPU per il team analytics e tenendo i consumer su Pro.

Cos’è Power BI Dataflow: ETL self-service nel cloud

Un dataflow Power BI è una collezione di entità (tabelle) costruite con Power Query Online, archiviate in Azure Data Lake Storage Gen2 e refreshate secondo schedule. La differenza rispetto a un dataset tradizionale è netta: il dataset vive dentro un file pbix e si aggiorna quando qualcuno preme “Aggiorna”. Il dataflow è una risorsa di workspace condivisa, governata, e i dataset ne consumano l’output via connettore dedicato.

L’editor è Power Query Online, versione browser dello stesso Power Query Editor di Excel e Power BI Desktop. Stessa interfaccia, stesso linguaggio M, stessi steps applicati. Chi sa pulire una tabella in Power BI Desktop sa costruire un dataflow: curva di apprendimento quasi zero.

I dati finiscono su ADLS Gen2 in formato Common Data Model, set di file CSV con manifest JSON che descrive schema e metadati. Conseguenze: i dati sono leggibili anche fuori da Power BI (Azure Synapse, Databricks, Azure ML possono attaccarsi allo stesso ADLS), e l’organizzazione mantiene la propria copia “dorata” in uno standard aperto, non in un formato proprietario.

Dataset, Dataflow, Datamart: cosa fa cosa

Microsoft ha tre concetti con nomi simili che fanno lavori diversi. Vale la pena fissarli.

Dataset. Modello tabulare che alimenta i report. Contiene tabelle, relazioni, misure DAX, gerarchie. Pensato per il consumo.

Dataflow. Pipeline ETL che prepara i dati prima che diventino dataset. Contiene entità, trasformazioni Power Query, schedule di refresh. Pensato per la preparazione: estrazione, pulizia, unioni, calcoli che non variano in base al report.

Datamart. Annunciato come evoluzione 2022, mette insieme dataflow + dataset + database Azure SQL gestito in un’unica esperienza browser. La promessa è preparare dati, modellarli e interrogarli in SQL o DAX da un unico editor, senza saltare tra Power Query Online e Power BI Desktop. Per le PMI è il pezzo che mancava per chiudere il cerchio “self-service BI senza data warehouse dedicato”.

Regola pragmatica: se il calcolo è “pulizia comune che serve a tutti i report” va nel dataflow; se è “misura business specifica del report” va nel dataset. Mescolare i due livelli è l’errore architetturale più costoso nelle prime implementazioni.

Architettura tipica: dalla sorgente al consumo

Vista dall’alto, l’architettura ha quattro strati. Sorgenti: SQL on-premise del gestionale, SharePoint del controlling, Dynamics 365, Salesforce, API REST del marketplace, export FTP del fornitore. Power BI Dataflow ha oltre 80 connettori nativi che coprono il 90% dei casi PMI senza scrivere codice. Per le sorgenti on-premise serve il Data Gateway, software Windows che fa da ponte autenticato tra cloud e database aziendale; una singola installazione serve decine di dataflow.

Trasformazione: Power Query Online. L’analyst sceglie “Ottieni dati”, autentica e costruisce i passaggi (rimuovi colonne, cambia tipi, unpivot, merge, filtro, colonna calcolata in M). Chi vuole apre l’Advanced Editor e scrive M direttamente.

Storage: ADLS Gen2 fornito di default con la licenza, o in setup avanzati un account Azure Storage di proprietà (BYO Storage) per condividere CDM con altri tool Azure.

Consumo: Power BI Desktop, “Ottieni dati” → “Power Platform” → “Dataflows”, selezione entità, costruzione del modello semantico (relazioni, misure DAX, gerarchie), pubblicazione del dataset.

Casi d’uso reali per PMI italiane

Tre scenari ricorrenti coprono la maggior parte delle implementazioni PMI sotto i 250 dipendenti.

Caso A: e-commerce + ERP + marketing. Shop WooCommerce, gestionale MySQL custom, Google Ads, Meta Ads. Prima del dataflow: 4 file pbix, ognuno con la propria estrazione duplicata. Dopo: una pipeline che produce 6 entità (Ordini, Righe, Clienti, Prodotti, CostiAds, Campagne) refreshata 4 volte/giorno. I 4 pbix diventano 4 dataset che attaccano gli stessi entity aggiungendo misure DAX proprie. Tempo del prossimo report: 3 ore invece di 3 giorni.

Caso B: manifatturiero con MES e qualità. 80 dipendenti, MES SQL Server on-prem (cicli macchina, fermi, scarti), gestionale separato per ordini cliente, Excel del responsabile qualità con NCR. Il dataflow centralizza la pulizia: smista i fermi per causale, ricalcola OEE con la formula concordata, lega NCR alle commesse via codice articolo. I dataset di reparto si appoggiano allo stesso dataflow con viste diverse.

Caso C: distribuzione multicanale. Distributore B2B con 3 magazzini, rete agenti in Salesforce e canale e-commerce B2B. Il dataflow unifica il concetto di “cliente” che in Salesforce ha un ID, nel gestionale un altro, nell’e-commerce un terzo. La logica di matching (Partita IVA + codice destinazione) vive nel dataflow, non viene replicata. Quando si aggiunge una nuova codifica, si modifica un solo posto.

Pricing 2022: PPU è il punto di svolta per PMI

Fino ad aprile 2021, le funzionalità avanzate dei dataflow (refresh frequente, computed entity, AI insights, incremental, linked entity) erano riservate a Power BI Premium per capacity: nodo P1 a circa 5.000 EUR/mese, abbordabile solo per organizzazioni con centinaia di consumer. Per una PMI da 30 dipendenti con 5 analyst, l’unica via era restare su dataset Pro classici con ETL duplicato.

Ad aprile 2021 Microsoft ha lanciato Power BI Premium Per User: 20 USD/mese per utente (circa 18-19 EUR in listino italiano). PPU dà al singolo utente tutte le feature Premium: dataflow avanzati, refresh ogni 30 minuti, dataset fino a 100 GB, AI insights, deployment pipelines, XMLA endpoint. Il vincolo: workspace e dataflow PPU sono consumati solo da altri utenti PPU.

Per una PMI il pattern tipico è ibrido: 3-5 licenze PPU per il team analytics, Pro per i consumer. Costo annuo PPU: 1.000-1.500 EUR. Confrontato con i 60.000 EUR/anno di P1 è una rivoluzione. Confrontato con le ore sprecate a rifare lo stesso ETL, il break-even arriva entro il primo trimestre. Nota di realismo: PPU non rende i dataflow “infiniti”: i limiti restano relativi al singolo utente. Sopra i 30-40 utenti analytics, P1 resta la scelta corretta.

Incremental refresh: la feature che salva il refresh notturno

Il refresh incrementale è la differenza tra un dataflow che si aggiorna in 4 minuti e uno che ci mette 4 ore. Senza incremental ogni refresh ricarica tutto: se “Movimenti” ha 8 milioni di righe e cresce di 20.000 al giorno, ricaricarne 8 milioni quando bastava l’ultimo mese è uno spreco massiccio.

Con incremental refresh (PPU/Premium) si configura un range (es. “ultimi 60 giorni di refresh frequente”) e Power BI aggiorna solo le partizioni recenti, lasciando intoccate le storiche. Il filtro va fatto in Power Query con parametri RangeStart e RangeEnd, e la sorgente deve supportare query folding (filtro spinto al database, non applicato in memoria dopo aver caricato tutto).

Caso pratico: dataflow “Vendite” su SQL del gestionale, storico 5 anni, refresh notturno. Senza incremental: 35 minuti e timeout occasionali del gateway. Con incremental sulle ultime 8 settimane: 3 minuti, niente timeout, storico immutabile per analisi anno su anno.

Entity reference e linked entity: il riuso senza duplicazione

Due meccanismi rendono il dataflow architettura, non solo ETL: entity reference nello stesso dataflow e linked entity tra dataflow diversi.

L’entity reference costruisce una nuova entità a partire da un’altra del medesimo dataflow, senza ri-eseguire l’estrazione. Esempio: “OrdiniRaw” estratta dal gestionale; da questa si referenziano “OrdiniChiusi” e “OrdiniAperti” filtrate per stato. Power BI esegue la query alla sorgente una sola volta per refresh.

La linked entity è lo stesso pattern tra dataflow diversi, anche cross-workspace (PPU/Premium). Pattern tipico: workspace “Data Hub” con dataflow “Anagrafica Clienti” (fonte di verità aziendale). I workspace “Vendite”, “Marketing”, “Customer Service” hanno dataflow di linea che fanno link all’Anagrafica. Quando il data steward aggiorna una regola di pulizia, la modifica si propaga a tutti i workspace consumer al refresh successivo.

Questo emula un data warehouse a tre strati (staging, refined, presentation) usando solo dataflow Power BI. Non sostituisce un DWH vero per miliardi di righe con SLA severi, ma per PMI con decine di milioni di righe e refresh orari è sufficiente.

AI insights nel dataflow: feature engineering low-code

La categoria “AI insights” nei dataflow incapsula modelli pre-addestrati di Azure Machine Learning come trasformazioni Power Query, applicate riga per riga durante il refresh.

Quattro funzioni utili. Anomaly detection su serie temporale (vendite giornaliere, consumi). Forecasting con intervallo di confidenza. Auto-cluster per segmentazione clienti su feature numeriche. Sentiment analysis e key phrase extraction via Azure Cognitive Services su recensioni, ticket, note commerciali.

Le trasformazioni vivono nel dataflow, quindi ogni dataset consumer eredita la feature derivata. Il commerciale che vuole il “cluster cliente” vede una colonna in più sulla tabella, non sa di consumare un modello ML. Caveat: AI insights richiedono PPU/Premium. Per modelli custom serve un workspace Azure Machine Learning collegato. Per la PMI media le funzioni pre-addestrate sono il punto di partenza: valore senza data scientist in pianta stabile.

Dataflow Gen1 vs Gen2 (Power Platform Dataflows)

A novembre 2021 Microsoft ha lanciato in preview Power Platform Dataflows, informalmente “Dataflow Gen2”. Vale la pena capire la differenza per scegliere l’architettura dei prossimi 18-24 mesi.

Gen1 vive nel servizio Power BI, output su ADLS Gen2 in CDM, integrazione stretta con dataset. Maturo e stabile, default per chi costruisce per Power BI puro.

Gen2 vive nel Power Platform Admin Center: output multipli (Dataverse, Azure SQL Database, Azure Data Lake, Lakehouse Synapse), orchestrazione integrata con Power Automate (trigger event-driven, non solo schedule), nuova UI Power Query Online, destinazioni multiple dalla stessa pipeline.

Per una PMI che fa solo Power BI, Gen1 è la scelta semplice. Per chi usa anche Power Apps e Power Automate, Gen2 permette architettura unificata: stesso ETL alimenta dashboard Power BI ed entità Dataverse che fanno da database alle Power Apps. Le competenze sono trasferibili al 95%: Power Query Online e M sono gli stessi; cambia orchestrazione e destinazione.

Gateway on-premises e sicurezza dei dati aziendali

L’obiezione ricorrente in CDA è “ma i dati del gestionale escono dall’azienda?”. La risposta tecnica precisa fa la differenza tra progetto che parte e progetto che muore.

Quando il dataflow legge da sorgente on-premise, il traffico passa attraverso il Power BI Gateway dentro la rete aziendale. Il gateway tiene aperta una connessione outbound autenticata (porta 443, TLS 1.2): è il gateway a eseguire la query locale e spedire indietro i risultati. Nessuna porta in ingresso sul firewall, nessuna VPN tra Azure e datacenter, nessuna esposizione del database.

I dati vengono crittografati in transito e a riposo su ADLS Gen2. Il datacenter per clienti italiani è Europa Nord (Dublino) o Europa Ovest (Amsterdam), con pinning a Milano su esigenza specifica. Per la maggior parte delle PMI italiane, storage in Europa è GDPR-compliant senza configurazioni speciali. La governance avanzata Premium aggiunge sensitivity label, audit log in Microsoft 365 Compliance Center, lineage view. Per PMI sotto 50 dipendenti queste funzionalità sono spesso oltre il necessario; per organizzazioni regolate diventano requisito di audit.

Self-service vs IT-led: chi possiede il dataflow

La domanda organizzativa che divide successo e fallimento: chi possiede il dataflow? Tre modelli funzionano per PMI.

Centrale (IT-led). IT costruisce e mantiene tutti i dataflow; gli analyst consumano dataset. Governance massima ma collo di bottiglia IT. Adatto a settori regolati o team data engineering in pianta stabile.

Shared. IT possiede i dataflow “Core” (anagrafiche, vendite, magazzino); i business analyst di reparto possiedono dataflow di linea con linked entity ai Core. Bilanciamento tra governance e agilità. Richiede convenzioni chiare e un data steward. Pattern consigliato a 8 PMI su 10.

Distribuito. Ogni team possiede i propri dataflow end-to-end; IT fornisce solo la piattaforma. Velocità massima ma rischio frammentazione. Adatto a PMI sotto 50 dipendenti o startup con cultura data matura.

Consiglio pratico: partire centrale, evolvere a shared dopo 6-9 mesi. Saltare al distribuito è la ricetta del “dataflow Western”: pipeline non documentate, ognuna con la propria interpretazione di “cliente attivo”.

Errori comuni nei primi 90 giorni

Cinque errori ricorrenti nelle prime implementazioni PMI.

1. Mescolare ETL e business logic. Mettere misure DAX-equivalenti in Power Query è sbagliato: la misura va nel dataset. Nel dataflow le colonne come fatto fisico (importo, quantità, data); nel dataset le aggregazioni e calcoli condizionali. Mescolando, ogni modifica costringe il refresh dell’intero dataflow.

2. Ignorare il query folding. Quando la sorgente supporta folding (SQL Server, Oracle, Synapse), Power Query traduce le trasformazioni in SQL. Quando il folding si rompe, Power Query carica tutto in memoria. Diagnosi: click destro sul passaggio → View Native Query. Se grigio, il folding è rotto da quel passaggio in poi.

3. Saltare l’incremental refresh. Vale la pena configurarlo dal primo giorno su entità sopra 500.000 righe con crescita superiore al 5% mensile. Configurarlo a posteriori richiede di ricaricare lo storico.

4. Workspace caotici. Prefisso DEV-, UAT-, PROD- e deployment pipeline Premium (o copia manuale con PPU) per promuovere dataflow tra ambienti.

5. Niente documentazione. Il dataflow è codice. Descrizione delle entità, naming convention coerente, commenti M sui passaggi non ovvi, owner identificato. Un dataflow senza owner è un dataflow che nessuno aggiorna.

Roadmap di implementazione 60 giorni

Per una PMI che parte da zero, roadmap realistica in due mesi.

Giorni 1-10: assessment e setup. Inventario sorgenti dati. Mappatura delle dashboard esistenti e dei dataset che le alimentano. Identificazione delle 5-8 entità più riusate. Attivazione di 2-3 licenze PPU per il team analytics. Installazione del Power BI Gateway. Creazione workspace “Data Hub” centrale.

Giorni 11-25: primo dataflow Core. Dataflow “Anagrafiche” con Clienti, Fornitori, Articoli, Centri di Costo. Refresh notturno schedulato. Test di consumo da Desktop. Documentazione di naming convention e owner.

Giorni 26-40: secondo dataflow Core. Dataflow “Transazioni” con Ordini, Righe Ordine, Fatture, Movimenti Magazzino. Incremental refresh range 90 giorni. Verifica query folding sulle SQL al gestionale.

Giorni 41-55: migrazione primi dataset. Riconnessione dei 2-3 dataset più consumati (cruscotto direzione, dashboard commerciale, report magazzino) al dataflow invece che alle sorgenti dirette. Validazione che i numeri coincidono.

Giorni 56-60: governance e formazione. 4 ore di formazione su convenzioni, pattern linked entity, diagnostica refresh fail. Processo di richiesta nuove entità. Monitoraggio refresh fail via email al data steward.

Da giorno 61 si entra in regime: nuovi dataflow di linea dai reparti appoggiati ai Core, dataset progressivamente migrati, retirement dei pbix locali con ETL duplicato. In 6 mesi una PMI tipica completa la transizione e libera 8-15 ore/settimana del team analytics dall’ETL ripetitivo.

Come costruire il primo dataflow: 5 passi

1. Aprire app.powerbi.com con account PPU o Premium, entrare nel workspace di destinazione, click su “Nuovo” → “Dataflow”.
2. Scegliere “Aggiungi nuove tabelle”, selezionare il connettore (es. SQL Server), inserire server, database, credenziali e selezionare il gateway on-premise se necessario.
3. Selezionare le tabelle/viste di interesse, applicare le trasformazioni Power Query (rimuovi colonne PII non necessarie, cast tipi corretti, filtri sulle righe storiche).
4. Salvare il dataflow con nome descrittivo (es. “DF_Vendite_Core”), aggiungere descrizione, salvare e tornare al workspace.
5. Configurare il refresh schedulato (es. ogni notte alle 03:00) e l’incremental refresh sulle entità grandi. Eseguire il primo refresh manuale e verificare il successo nel log.

Domande frequenti su Power BI Dataflow

Serve un data warehouse separato se uso Power BI Dataflow?
Per una PMI con decine di milioni di righe complessive e refresh giornalieri, il dataflow con linked entity emula efficacemente un data warehouse a tre strati senza costi infrastrutturali aggiuntivi. Se l’organizzazione cresce oltre i 100-200 milioni di righe per entità o ha bisogno di SLA real-time, il passo successivo naturale è Azure Synapse o un Datamart Power BI (in arrivo come evoluzione 2022) con database Azure SQL gestito sotto.

Posso usare Power BI Dataflow con licenza Pro standard?
Sì, ma con limitazioni significative: niente incremental refresh, niente entity computed, niente linked entity tra workspace, niente AI insights, refresh limitato a 8 volte/giorno. Per uso esplorativo Pro va bene, per architettura di produzione serve PPU o Premium.

Quanto costa concretamente per una PMI da 30 dipendenti?
Scenario tipico: 5 licenze PPU per team analytics a ~20 USD/utente/mese = ~100 USD/mese (~95 EUR), più 25 licenze Pro per consumer a ~10 USD/utente/mese = ~250 USD/mese (~240 EUR). Totale ~340 EUR/mese per licenze. Il Power BI Gateway è gratuito. ADLS Gen2 incluso nella licenza per uso standard.

Quanto tempo serve per imparare a costruire dataflow?
Un analyst che conosce già Power BI Desktop con Power Query è produttivo in 1-2 giorni: l’interfaccia online è quasi identica a quella desktop. Per costruire pattern avanzati (incremental, linked entity, AI insights) serve una settimana di pratica con casi reali.

I dati nel dataflow sono al sicuro rispetto al GDPR?
Sì, con configurazione standard: storage in datacenter Europa (Dublino o Amsterdam), crittografia in transito TLS 1.2 e a riposo AES-256, gateway che non apre porte inbound sul firewall aziendale. Per requisiti specifici (sensitivity label, audit log esteso) servono Premium o PPU. Per PMI sanitarie o finanziarie consigliamo coinvolgimento del DPO sin dall’assessment.

Posso esportare i dati di un dataflow al di fuori di Power BI?
Sì. I dataflow scrivono in formato Common Data Model su ADLS Gen2 leggibile da Azure Synapse, Databricks, Azure ML, e anche Excel via connettore. In setup “Bring Your Own Storage” si può puntare ADLS Gen2 a un proprio account Azure Storage e accedere ai file CSV/Parquet con qualsiasi tool.

Cosa succede se cambio il database sorgente del gestionale?
Si modifica solo il dataflow Core che attaccava la sorgente originale: cambio di connection string, eventuale rimappatura dei nomi colonna se cambiano. Tutti i dataset che consumavano il dataflow non hanno bisogno di modifiche. Questo è esattamente il valore di disaccoppiamento che il dataflow porta: cambio una volta, tutti consumano la nuova versione.