{"id":1808,"date":"2022-03-04T11:09:00","date_gmt":"2022-03-04T10:09:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/power-bi-dataflow-datamart-pmi-self-service-2022\/"},"modified":"2022-03-04T11:09:00","modified_gmt":"2022-03-04T10:09:00","slug":"power-bi-dataflow-datamart-pmi-self-service-2022","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/power-bi-dataflow-datamart-pmi-self-service-2022\/","title":{"rendered":"Power BI Dataflow e Datamart per PMI: self-service BI senza data warehouse (2022)"},"content":{"rendered":"
Luned\u00ec mattina, riunione commerciale. Il direttore vendite apre una dashboard Power BI con il report di fine stagione: fatturato per categoria, marginalit\u00e0 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”.<\/p>\n
Power BI Dataflow cambia le regole per una PMI italiana. Il dataflow \u00e8 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\u00e0 preparata. Dal 2021, con Power BI Premium Per User a 20 dollari\/mese, questa architettura non \u00e8 pi\u00f9 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.<\/p>\n
\n
TL;DR \u2014 Power BI Dataflow per PMI in 6 punti<\/p>\n
\n
Dataflow Gen1<\/strong> (lanciato 2018) \u00e8 ETL Power Query Online nel servizio Power BI, output in Azure Data Lake Storage Gen2 in formato Common Data Model.<\/li>\n
Dataflow Gen2<\/strong> (preview 2021, dentro Power Platform) aggiunge orchestrazione con Power Automate e output multipli (Dataverse, Azure SQL, Lakehouse Synapse).<\/li>\n
Datamart Power BI<\/strong> \u00e8 annunciato come prossima evoluzione (database Azure SQL gestito + dataset + dataflow in un’unica esperienza no-code) \u2014 disponibilit\u00e0 prevista 2022.<\/li>\n
Pricing PMI<\/strong>: Premium Per User 20 USD\/utente\/mese sblocca dataflow avanzati (refresh ogni 30 min, incremental, AI insights, linked entities) senza capacity P1 da 5.000 EUR\/mese.<\/li>\n
ROI tipico<\/strong>: una PMI che oggi ha 8-12 dataset Power BI Desktop autonomi rientra dell’investimento PPU in 3-4 mesi grazie a ETL non duplicato e refresh notturni centralizzati.<\/li>\n
Errori da evitare<\/strong>: ignorare query folding, saltare l’incremental refresh per dataflow grandi, mescolare logica business e pulizia dati nello stesso entity.<\/li>\n<\/ul>\n<\/div>\n
Cos’\u00e8 Power BI Dataflow: ETL self-service nel cloud<\/h2>\n
Un dataflow Power BI \u00e8 una collezione di entit\u00e0 (tabelle) costruite con Power Query Online, archiviate in Azure Data Lake Storage Gen2 e refreshate secondo schedule. La differenza rispetto a un dataset tradizionale \u00e8 netta: il dataset vive dentro un file pbix e si aggiorna quando qualcuno preme “Aggiorna”. Il dataflow \u00e8 una risorsa di workspace condivisa, governata, e i dataset ne consumano l’output via connettore dedicato.<\/p>\n
L’editor \u00e8 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.<\/p>\n
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.<\/p>\n
Dataset, Dataflow, Datamart: cosa fa cosa<\/h2>\n
Microsoft ha tre concetti con nomi simili che fanno lavori diversi. Vale la pena fissarli.<\/p>\n
Dataset.<\/strong> Modello tabulare che alimenta i report. Contiene tabelle, relazioni, misure DAX, gerarchie. Pensato per il consumo.<\/p>\n
Dataflow.<\/strong> Pipeline ETL che prepara i dati prima che diventino dataset. Contiene entit\u00e0, trasformazioni Power Query, schedule di refresh. Pensato per la preparazione: estrazione, pulizia, unioni, calcoli che non variano in base al report.<\/p>\n
Datamart.<\/strong> Annunciato come evoluzione 2022, mette insieme dataflow + dataset + database Azure SQL gestito in un’unica esperienza browser. La promessa \u00e8 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 \u00e8 il pezzo che mancava per chiudere il cerchio “self-service BI senza data warehouse dedicato”.<\/p>\n
Regola pragmatica: se il calcolo \u00e8 “pulizia comune che serve a tutti i report” va nel dataflow; se \u00e8 “misura business specifica del report” va nel dataset. Mescolare i due livelli \u00e8 l’errore architetturale pi\u00f9 costoso nelle prime implementazioni.<\/p>\n
Architettura tipica: dalla sorgente al consumo<\/h2>\n\nL’architettura tipica di un Power BI Dataflow per PMI: sorgenti eterogenee, Power Query Online come ETL, ADLS Gen2 come storage CDM, dataset Power BI come livello di consumo.<\/figcaption><\/figure>\n
Vista dall’alto, l’architettura ha quattro strati. Sorgenti<\/strong>: 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.<\/p>\n
Trasformazione<\/strong>: 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.<\/p>\n
Storage<\/strong>: ADLS Gen2 fornito di default con la licenza, o in setup avanzati un account Azure Storage di propriet\u00e0 (BYO Storage) per condividere CDM con altri tool Azure.<\/p>\n
Consumo<\/strong>: Power BI Desktop, “Ottieni dati” \u2192 “Power Platform” \u2192 “Dataflows”, selezione entit\u00e0, costruzione del modello semantico (relazioni, misure DAX, gerarchie), pubblicazione del dataset.<\/p>\n
Casi d’uso reali per PMI italiane<\/h2>\n
Tre scenari ricorrenti coprono la maggior parte delle implementazioni PMI sotto i 250 dipendenti.<\/p>\n
Caso A: e-commerce + ERP + marketing.<\/strong> 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\u00e0 (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.<\/p>\n
Caso B: manifatturiero con MES e qualit\u00e0.<\/strong> 80 dipendenti, MES SQL Server on-prem (cicli macchina, fermi, scarti), gestionale separato per ordini cliente, Excel del responsabile qualit\u00e0 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.<\/p>\n
Caso C: distribuzione multicanale.<\/strong> 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.<\/p>\n
Pricing 2022: PPU \u00e8 il punto di svolta per PMI<\/h2>\n
Fino ad aprile 2021, le funzionalit\u00e0 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.<\/p>\n
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\u00e0 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.<\/p>\n
Per una PMI il pattern tipico \u00e8 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 \u00e8 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.<\/p>\n
Incremental refresh: la feature che salva il refresh notturno<\/h2>\n
Il refresh incrementale \u00e8 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 \u00e8 uno spreco massiccio.<\/p>\n
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).<\/p>\n
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.<\/p>\n
Entity reference e linked entity: il riuso senza duplicazione<\/h2>\n\nIl riuso delle entit\u00e0 \u00e8 la chiave: un dataflow “anagrafica clienti” alimenta vendite, marketing, customer service senza duplicare la pipeline di estrazione.<\/figcaption><\/figure>\n
Due meccanismi rendono il dataflow architettura, non solo ETL: entity reference<\/strong> nello stesso dataflow e linked entity<\/strong> tra dataflow diversi.<\/p>\n
L’entity reference costruisce una nuova entit\u00e0 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.<\/p>\n
La linked entity \u00e8 lo stesso pattern tra dataflow diversi, anche cross-workspace (PPU\/Premium). Pattern tipico: workspace “Data Hub” con dataflow “Anagrafica Clienti” (fonte di verit\u00e0 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.<\/p>\n
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 \u00e8 sufficiente.<\/p>\n
AI insights nel dataflow: feature engineering low-code<\/h2>\n
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.<\/p>\n
Quattro funzioni utili. Anomaly detection<\/strong> su serie temporale (vendite giornaliere, consumi). Forecasting<\/strong> con intervallo di confidenza. Auto-cluster<\/strong> per segmentazione clienti su feature numeriche. Sentiment analysis e key phrase extraction<\/strong> via Azure Cognitive Services su recensioni, ticket, note commerciali.<\/p>\n
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\u00f9 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.<\/p>\n
Dataflow Gen1 vs Gen2 (Power Platform Dataflows)<\/h2>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Per una PMI che fa solo Power BI, Gen1 \u00e8 la scelta semplice. Per chi usa anche Power Apps e Power Automate, Gen2 permette architettura unificata: stesso ETL alimenta dashboard Power BI ed entit\u00e0 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.<\/p>\n
Gateway on-premises e sicurezza dei dati aziendali<\/h2>\n
L’obiezione ricorrente in CDA \u00e8 “ma i dati del gestionale escono dall’azienda?”. La risposta tecnica precisa fa la differenza tra progetto che parte e progetto che muore.<\/p>\n
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): \u00e8 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.<\/p>\n
I dati vengono crittografati in transito e a riposo su ADLS Gen2. Il datacenter per clienti italiani \u00e8 Europa Nord (Dublino) o Europa Ovest (Amsterdam), con pinning a Milano su esigenza specifica. Per la maggior parte delle PMI italiane, storage in Europa \u00e8 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\u00e0 sono spesso oltre il necessario; per organizzazioni regolate diventano requisito di audit.<\/p>\n
Self-service vs IT-led: chi possiede il dataflow<\/h2>\n\nIl modello “shared dataflow” libera l’analyst dall’ETL ripetitivo e l’IT dalle richieste di estrazione ad hoc: chi conosce il business modella, chi conosce il dato governa.<\/figcaption><\/figure>\n
La domanda organizzativa che divide successo e fallimento: chi possiede il dataflow? Tre modelli funzionano per PMI.<\/p>\n
Centrale (IT-led).<\/strong> 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.<\/p>\n
Shared.<\/strong> 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\u00e0. Richiede convenzioni chiare e un data steward. Pattern consigliato a 8 PMI su 10.<\/p>\n
Distribuito.<\/strong> Ogni team possiede i propri dataflow end-to-end; IT fornisce solo la piattaforma. Velocit\u00e0 massima ma rischio frammentazione. Adatto a PMI sotto 50 dipendenti o startup con cultura data matura.<\/p>\n
Consiglio pratico: partire centrale, evolvere a shared dopo 6-9 mesi. Saltare al distribuito \u00e8 la ricetta del “dataflow Western”: pipeline non documentate, ognuna con la propria interpretazione di “cliente attivo”.<\/p>\n
Errori comuni nei primi 90 giorni<\/h2>\n
Cinque errori ricorrenti nelle prime implementazioni PMI.<\/p>\n
1. Mescolare ETL e business logic.<\/strong> Mettere misure DAX-equivalenti in Power Query \u00e8 sbagliato: la misura va nel dataset. Nel dataflow le colonne come fatto fisico (importo, quantit\u00e0, data); nel dataset le aggregazioni e calcoli condizionali. Mescolando, ogni modifica costringe il refresh dell’intero dataflow.<\/p>\n
2. Ignorare il query folding.<\/strong> 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 \u2192 View Native Query. Se grigio, il folding \u00e8 rotto da quel passaggio in poi.<\/p>\n
3. Saltare l’incremental refresh.<\/strong> Vale la pena configurarlo dal primo giorno su entit\u00e0 sopra 500.000 righe con crescita superiore al 5% mensile. Configurarlo a posteriori richiede di ricaricare lo storico.<\/p>\n
4. Workspace caotici.<\/strong> Prefisso DEV-, UAT-, PROD- e deployment pipeline Premium (o copia manuale con PPU) per promuovere dataflow tra ambienti.<\/p>\n
5. Niente documentazione.<\/strong> Il dataflow \u00e8 codice. Descrizione delle entit\u00e0, naming convention coerente, commenti M sui passaggi non ovvi, owner identificato. Un dataflow senza owner \u00e8 un dataflow che nessuno aggiorna.<\/p>\n
Roadmap di implementazione 60 giorni<\/h2>\n
Per una PMI che parte da zero, roadmap realistica in due mesi.<\/p>\n
Giorni 1-10: assessment e setup.<\/strong> Inventario sorgenti dati. Mappatura delle dashboard esistenti e dei dataset che le alimentano. Identificazione delle 5-8 entit\u00e0 pi\u00f9 riusate. Attivazione di 2-3 licenze PPU per il team analytics. Installazione del Power BI Gateway. Creazione workspace “Data Hub” centrale.<\/p>\n
Giorni 11-25: primo dataflow Core.<\/strong> Dataflow “Anagrafiche” con Clienti, Fornitori, Articoli, Centri di Costo. Refresh notturno schedulato. Test di consumo da Desktop. Documentazione di naming convention e owner.<\/p>\n
Giorni 26-40: secondo dataflow Core.<\/strong> Dataflow “Transazioni” con Ordini, Righe Ordine, Fatture, Movimenti Magazzino. Incremental refresh range 90 giorni. Verifica query folding sulle SQL al gestionale.<\/p>\n
Giorni 41-55: migrazione primi dataset.<\/strong> Riconnessione dei 2-3 dataset pi\u00f9 consumati (cruscotto direzione, dashboard commerciale, report magazzino) al dataflow invece che alle sorgenti dirette. Validazione che i numeri coincidono.<\/p>\n
Giorni 56-60: governance e formazione.<\/strong> 4 ore di formazione su convenzioni, pattern linked entity, diagnostica refresh fail. Processo di richiesta nuove entit\u00e0. Monitoraggio refresh fail via email al data steward.<\/p>\n
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.<\/p>\n
Come costruire il primo dataflow: 5 passi<\/h2>\n\n
Aprire app.powerbi.com<\/strong> con account PPU o Premium, entrare nel workspace di destinazione, click su “Nuovo” \u2192 “Dataflow”.<\/li>\n
Scegliere “Aggiungi nuove tabelle”<\/strong>, selezionare il connettore (es. SQL Server), inserire server, database, credenziali e selezionare il gateway on-premise se necessario.<\/li>\n
Selezionare le tabelle\/viste<\/strong> di interesse, applicare le trasformazioni Power Query (rimuovi colonne PII non necessarie, cast tipi corretti, filtri sulle righe storiche).<\/li>\n
Salvare il dataflow<\/strong> con nome descrittivo (es. “DF_Vendite_Core”), aggiungere descrizione, salvare e tornare al workspace.<\/li>\n
Configurare il refresh schedulato<\/strong> (es. ogni notte alle 03:00) e l’incremental refresh sulle entit\u00e0 grandi. Eseguire il primo refresh manuale e verificare il successo nel log.<\/li>\n<\/ol>\n
\n
Vuoi un’architettura BI con Power BI Dataflow senza budget data warehouse?<\/p>\n
Calcola in pochi minuti il preventivo per setup dataflow, gateway, governance e formazione del team analytics. Approccio PMI, licenze PPU e roadmap 60 giorni.<\/p>\n
![\"Architettura](\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/powerbi-dataflow-architecture.jpg\")
![\"Team](\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/powerbi-dataflow-team.jpg\")
![\"Business](\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/powerbi-dataflow-analyst.jpg\")