Power BI Fundamentals

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 1 di 14. La maggior parte delle aziende naviga nei dati ma è a corto di veri insight. Hai database, spreadsheet e cloud storage pieni di numeri, ma quando il management chiede come è andato un prodotto nell'ultimo trimestre, tutti vanno nel panico. La soluzione per colmare questo divario tra numeri sparsi e informazioni coerenti è l'ecosistema Power BI. Power BI non è un singolo software. È una raccolta di servizi, app e connettori progettati per funzionare insieme. Il suo compito principale è prendere sorgenti dati non correlate e trasformarle in report interattivi e visivamente immersivi. Una trappola frequente per i nuovi utenti è confondere le diverse parti di questo ecosistema, in particolare la desktop app e il web service. Sono tool completamente diversi, creati per fasi diverse del reporting lifecycle. Per non fare confusione, ricorda semplicemente che uno è la factory e l'altro è lo showroom. La factory è Power BI Desktop. È un'applicazione gratuita che installi su una macchina Windows locale. Power BI Desktop è il tuo tool principale di authoring e creazione. È qui che avviene il lavoro pesante. È qui che ti connetti ai tuoi raw data, li pulisci e progetti il visual layout effettivo del tuo report. Considera un sales manager che riceve un enorme file Excel flat pieno di record di transazioni raw. Fissare un milione di righe di testo non lo aiuta a prendere una decisione. Apre Power BI Desktop sul suo laptop e si connette direttamente a quel file Excel. Usa la desktop app per costruire un report, aggiungendo una mappa per mostrare le vendite per regione e un bar chart per le entrate mensili. Tutta questa creazione avviene in locale sul suo hardware. Una volta finito quel report, il manager ha bisogno che il resto del team lo veda. Inviare un file enorme via email è inefficiente e porta a incubi di version control. È qui che la cosa si fa interessante. Invece di inviare il file, il manager lo pubblica sul Power BI service. Il Power BI service è lo showroom. È una piattaforma software-as-a-service basata sul cloud a cui si accede tramite un web browser. Quando il manager clicca su publish nella desktop app, il report viene caricato sul cloud. Ora, il resto del team di vendita può effettuare il login nel web service. Possono visualizzare le dashboard, filtrare i chart e interagire con i dati. Non hanno bisogno di installare Power BI Desktop e non hanno bisogno di sapere come è stato costruito il report. Consumano semplicemente gli insight. C'è anche un terzo pezzo a completare il quadro, ovvero le app Power BI Mobile. Queste permettono agli utenti su telefoni e tablet di accedere in modo sicuro agli stessi identici report ospitati nel cloud service mentre sono lontani dalla scrivania. Il tipico workflow si muove in una sola direzione. Ti connetti ai dati e costruisci un report in Power BI Desktop. Pubblichi quel report sul Power BI service. Poi, tu e il tuo team visualizzate e interagite con quei report nel service o su mobile. La desktop app è per il creator, e il web service è per il consumer. Costruisci in locale, ma distribuisci a livello globale. Se vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a costruire!

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 2 di 14. Il primo giorno di lavoro fai il login su una nuova piattaforma di business intelligence e ti sembra di entrare nella cabina di pilotaggio di un aereo. Ci sono decine di menu, liste e item con nomi simili, ma tu devi solo trovare le metriche chiave del tuo team senza rompere niente. La soluzione è capire l'architettura del Power BI Service. Il Power BI Service è il portale web accessibile all'indirizzo app.powerbi.com. Quando fai il login, atterri sulla schermata Home. Questa pagina funziona da punto di partenza personalizzato, e mostra gli item che usi più spesso e a cui hai avuto accesso di recente. Ma per navigare davvero nel sistema, usi il pannello sul lato sinistro dello schermo. Il concetto più critico in quel pannello di navigazione è il workspace. Un workspace è un container. Contiene i tuoi contenuti. Hai un container personale chiamato My Workspace, che serve strettamente per le tue bozze e i tuoi esperimenti privati. Non usarlo per le metriche aziendali. Per la collaborazione, ti affidi agli shared workspace. Pensa a uno shared workspace come a una cartella di progetto sicura in cui un team specifico archivia i suoi data asset unificati. All'interno di un workspace, troverai diversi tipi di item distinti, e capire come si incastrano tra loro è il modo per dare un senso alla piattaforma. La base di tutto è il semantic model. Non guardi un semantic model per vedere grafici o chart. È la data structure sottostante, che contiene le tabelle, le relazioni e i calcoli. È il motore. Ogni numero che vedi sullo schermo viene estratto con una query da un semantic model. Sopra a questo motore c'è il visual layer, che di solito prende la forma di un report. Ecco il punto chiave. Le persone usano costantemente le parole report e dashboard come se significassero l'esatta stessa cosa. In Power BI, sono oggetti completamente diversi con comportamenti diversi. Un report è un documento multipagina altamente interattivo. È legato a un solo semantic model. Quando apri un report, puoi cliccare sui chart per fare cross-filter su altri chart, usare i menu a tendina per fare slice sui dati, e navigare tra le diverse tab in fondo allo schermo. I report sono costruiti per un'esplorazione profonda e un'analisi dettagliata. Una dashboard è sempre una pagina singola. È un canvas personalizzato dove puoi pinnare singoli elementi visivi, noti come tile, presi da vari report. Dato che puoi pinnare tile da ovunque, una singola dashboard può combinare dati da molteplici semantic model diversi in un'unica overview ad alto livello. Non puoi filtrare o fare slice dei dati direttamente su una dashboard. Se clicchi su una tile, funziona da shortcut, portandoti all'istante nel report sottostante da cui ha origine quello specifico chart. Le dashboard servono per un monitoraggio rapido, a colpo d'occhio. I report servono per scavare nei dettagli. Quando un team finisce di costruire i propri semantic model, report e dashboard in un workspace, di solito non invita tutta l'azienda in quel workspace a dare un'occhiata. Invece, pacchettizza gli item finiti in un'app. Nel Power BI Service, un'app è una collection compilata e in sola lettura dei contenuti del workspace. Quando un nuovo dipendente ha bisogno di trovare i key performance indicator della sua divisione, di solito clicca semplicemente sull'icona Apps nel pannello di navigazione a sinistra. Le app forniscono una struttura di menu pulita e custom, senza esporre i file raw del workspace a modifiche accidentali. Capire l'ecosistema significa capire questa gerarchia. Se vuoi sapere come una metrica specifica è arrivata sul tuo schermo, segui la chain a ritroso. L'app distribuisce la dashboard, la dashboard estrae i visual dal report, il report visualizza il semantic model, e il semantic model vive in uno shared workspace. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 3 di 14. L'errore più grande che fanno i nuovi utenti di Power BI è creare un report mission-critical nel proprio account personale, andare in vacanza e lasciare l'intero team completamente tagliato fuori dai dati. La soluzione è capire come strutturare correttamente i Workspace e la collaborazione. In Power BI, hai due tipi distinti di ambienti per i tuoi contenuti. Il primo è My Workspace. Questa è la tua sandbox personale. Ogni utente di Power BI ne riceve uno automaticamente. È completamente privato. Lo usi per connetterti a dati di esempio, testare una nuova formula o abbozzare un layout prima che chiunque altro lo veda. Non usare My Workspace per il reporting aziendale ufficiale. Se crei qui la dashboard principale delle vendite e poi lasci l'azienda, il tuo team farà fatica ad accedere o aggiornare quel contenuto. La soluzione è il Workspace standard. Questo è un ambiente condiviso in cui i team collaborano su semantic model, report e dashboard. Un Workspace funziona come un contenitore sicuro per un progetto o un reparto specifico. Quando crei un Workspace, definisci esattamente chi può entrare in quel contenitore e quali azioni può fare. Pensa a un team finance che sta creando un report finanziario per il Q3. Hai bisogno che più persone contribuiscano ai dati, ma ti serve un controllo rigoroso su chi può modificare i numeri finali. Puoi applicare questo controllo usando quattro ruoli distinti del Workspace. Il primo è il ruolo di Admin. L'Admin del Workspace ha il controllo totale sull'ambiente. Può eliminare l'intero Workspace e decide chi ottiene l'accesso. L'amministratore di sistema o il responsabile del team dati finance assume questo ruolo. Poi c'è il ruolo di Member. I Member gestiscono il contenuto e il flusso del Workspace. Possono aggiungere colleghi con permessi inferiori, aggiornare i semantic model e condividere gli elementi del Workspace. Un senior financial analyst che gestisce il processo di reporting del Q3 ha bisogno di questo ruolo. Gli permette di far andare avanti il progetto e gestire l'accesso del team senza dover disturbare l'Admin per ogni piccola modifica. Poi hai il Contributor. Questo è il ruolo principale per i content creator. I Contributor possono creare, modificare ed eliminare report e dashboard all'interno del Workspace. Non possono gestire i permessi e non possono aggiungere nuovi utenti. Agli analisti che creano i grafici e le tabelle vere e proprie per il report del Q3 viene dato l'accesso come Contributor. Costruiscono il contenuto, ma non controllano i perimetri di sicurezza. Infine, c'è il ruolo di Viewer. I Viewer possono guardare i report, fare cross-highlight sui grafici e filtrare i dati, ma non possono cambiare il contenuto o la struttura sottostante. Assegni questo ruolo ai direttori finance che devono revisionare il report del Q3 e interagire con i dati prima che venga rilasciato al resto dell'azienda. Ecco il punto chiave. I permessi in un Workspace si applicano all'intero contenitore. Non puoi concedere a qualcuno l'accesso come Contributor a un Workspace e impedirgli di vedere uno specifico report al suo interno. Il Workspace è un singolo perimetro di sicurezza. Se qualcuno ha accesso al Workspace, può vedere tutto il contenuto al suo interno, limitato solo dal ruolo specifico che gli hai assegnato. La struttura dei Workspace ti costringe a trattare il reporting come un processo di team resiliente. Mantenendo le bozze personali isolate in My Workspace e spostando i progetti di team in Workspace condivisi con ruoli espliciti, la tua architettura dei dati rimane stabile e accessibile indipendentemente da chi è in ufficio. Per questo episodio è tutto. Ci sentiamo alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Power BI, episodio 4 di 14. Il segreto per un report incredibilmente veloce e preciso in realtà non ha nulla a che fare con i grafici sullo schermo. Quando i numeri non tornano tra i vari reparti, il problema raramente è l'interfaccia visiva. È l'architettura dati sottostante. Oggi parliamo del semantic model. Un semantic model, che Power BI prima chiamava dataset, è il cervello invisibile dietro i tuoi report. È un errore comune considerare Power BI solo come un tool che tira dentro una tabella flat di un database o un foglio Excel e ci disegna sopra un grafico. Non è così. Un semantic model è una rete relazionale robusta. Salva le tabelle, ma incapsula anche le relazioni tra di esse, i metadati di formattazione e la business logic predefinita. Si piazza esattamente tra le tue data source grezze e sparse e i tuoi report visivi, facendo da middle layer organizzato. Puoi portarti dentro dati da un database in cloud, da un file locale e da una web API, e cucirli tutti insieme in un'unica struttura coerente. Questa è la parte importante. Non hai assolutamente bisogno di un nuovo modello per ogni singolo report. Un semantic model ben progettato separa la data logic di base dalla presentazione visiva. Prendi uno scenario in cui la tua azienda ha bisogno di un unico modello Customer Truth. Il team di marketing vuole tracciare le performance delle campagne, mentre il team di vendite deve monitorare la sua pipeline giornaliera. In un sistema progettato male, entrambi i team si estraggono i propri dati, si scrivono le proprie business rule e, inevitabilmente, creano versioni della realtà in competizione tra loro. In un'architettura matura, entrambi i team collegano i loro report individuali allo stesso identico semantic model. Sviluppi la logica complessa una volta sola. Quel singolo modello Customer Truth può alimentare tranquillamente dieci report completamente diversi in tutta l'organizzazione. Se la definizione di cliente attivo cambia l'anno prossimo, aggiorni il modello centrale. Tutti e dieci i report ereditano automaticamente la nuova regola. Come questo modello gestisce effettivamente i tuoi dati dipende interamente dallo storage mode che selezioni durante la creazione. I due paradigmi principali sono Import e DirectQuery. L'Import mode tira fuori i dati dalla tua source originale, li comprime e li carica direttamente nell'engine in-memory di Power BI. Questa è la scelta di default per la maggior parte dei progetti. Dato che i dati risiedono interamente in memoria, i calcoli complessi e il filtering interattivo avvengono quasi all'istante. I tuoi report sembrano incredibilmente veloci all'end user. Il limite è che stai mettendo in cache uno snapshot dei dati. Devi programmare dei refresh periodici per recuperare gli update, e ci sono limiti fisici a quanti dati puoi caricare in memoria. DirectQuery adotta l'approccio opposto. Non vengono mai importati dati raw. Il semantic model salva solo i metadati strutturali, come i nomi delle tabelle, i tipi di colonna e le relazioni. Quando un utente clicca su un filtro nel suo report, il modello traduce quel clic in una live query e la rimanda dritta al database sottostante. Ti affidi a DirectQuery quando il tuo dataset è semplicemente troppo massiccio da importare, o quando il business richiede una visibilità quasi in real-time sul sistema sorgente. L'ovvio trade-off sono le performance. Un report che gira in DirectQuery mode è veloce solo quanto il database che risponde alle domande, e ogni interazione mette un compute load diretto sui tuoi sistemi sorgente. I visual nel tuo workspace sono solo finestre leggere che si affacciano sui dati. Il semantic model contiene la verità effettiva, e se imposti bene il modello, i report si costruiscono praticamente da soli. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 5 di 14. La tua dashboard può anche essere bellissima, ma è completamente inutile se i numeri sono vecchi di una settimana. La vera sfida è portare dati freschi nel cloud quando il tuo database effettivo è bloccato dietro un rigido firewall aziendale. Risolvere questo problema è esattamente ciò che fanno i Data Connector e l'On-Premises Data Gateway. Power BI è un contenitore vuoto finché non gli dai in pasto delle informazioni. Per tirare dentro queste informazioni, usi i Data Connector. Microsoft ne fornisce centinaia out of the box per quasi tutti i sistemi che ti vengono in mente. Pensa a un connector come a un traduttore specializzato e pre-costruito. Che i tuoi dati si trovino in un database Oracle, in un data warehouse Snowflake o in un servizio cloud come Salesforce, il connector fa il lavoro pesante. Gestisce le chiamate API specifiche, i metodi di autenticazione e le strutture delle query native necessarie per parlare con quel sistema di destinazione. Tu devi solo fornire le credenziali e selezionare le tabelle che vuoi. Il connector traduce la tua richiesta nell'esatto linguaggio che il sistema sorgente capisce, il che significa che non devi mai scrivere script di estrazione custom. Quando la tua data source è già nel cloud, questo processo è senza intoppi. Power BI esce su internet, si autentica e tira giù i dati. Ma la realtà per molte organizzazioni è molto più complicata. Cosa succede quando i tuoi dati si trovano su un server fisico piazzato nel seminterrato dell'ufficio? Non puoi semplicemente chiedere a un Power BI basato sul cloud di entrare nella tua rete locale privata. Farlo richiederebbe al tuo team IT di aprire delle porte inbound sul firewall, esponendo il tuo database interno all'internet pubblico. Ecco l'intuizione chiave. Non hai bisogno di esporre la tua rete interna al mondo esterno per permettere a Power BI di leggere i tuoi dati. Invece, usi un On-Premises Data Gateway. Il gateway è un piccolo pezzo di software che installi su una macchina all'interno della tua rete locale. Sta dietro al tuo firewall, vicino alle tue data source interne. Agisce come un ponte sicuro in outbound. Invece di avere Power BI che forza l'ingresso nella tua rete, la comunicazione avviene in modo completamente inverso. Il gateway controlla costantemente una coda sicura in cloud usando una normale connessione internet outbound. Chiede semplicemente al cloud se ci sono richieste di dati in sospeso. Dato che la connessione viene iniziata dall'interno della tua rete verso l'esterno, i firewall standard lasciano passare il traffico senza nessuna configurazione speciale. Vediamo uno scenario pratico. Hai un report delle vendite del lunedì mattina che deve fare un refresh automatico alle sei del mattino. I dati grezzi delle vendite si trovano su quel server sotto firewall nel seminterrato. Alle sei in punto, il servizio cloud di Power BI registra una richiesta di refresh schedulato. Pochi istanti dopo, il tuo gateway locale fa polling sulla coda in cloud e prende in carico questa richiesta. Il gateway scarica le istruzioni della query, si connette direttamente al tuo database locale usando le credenziali della tua rete interna ed esegue la query localmente. Una volta che il server nel seminterrato finisce di processare la richiesta, restituisce i dati grezzi al software del gateway. Il gateway comprime e cripta questi dati, poi fa un push verso il servizio cloud di Power BI. Il cloud riceve il pacchetto criptato, lo decripta e aggiorna la tua dashboard delle vendite. Usando questo metodo di polling outbound, il gateway ti dà tutta la potenza analitica del cloud senza richiederti di spostare il tuo database effettivo fuori dal seminterrato. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Power BI, episodio 6 di 14. Se uno stakeholder ha bisogno di più di cinque secondi per capire cosa gli sta dicendo la tua dashboard, hai perso la sua attenzione. Inserire dieci grafici a torta non correlati in una singola schermata non è analisi, è solo rumore visivo. Creare una data story guidata richiede una progettazione mirata, e questo ci porta a L'Arte del Report Canvas. Un report di Power BI è una vista multi-prospettiva sul tuo semantic model sottostante. Il report canvas è lo spazio di lavoro vuoto in cui costruisci questa vista. Non è limitato a una singola schermata. Puoi aggiungere più pagine a un report, proprio come in una presentazione. Questo ti permette di scomporre domande di business complesse in una sequenza logica, dedicando pagine diverse a diversi aspetti dei dati. Popoli il canvas con i visual. Questi sono i tuoi grafici, tabelle e mappe. Scegliere il visual giusto è solo il primo passo. Il layout determina come il tuo utente legge le informazioni. Un canvas ben progettato guida lo sguardo in modo naturale dalle metriche di alto livello fino ai dettagli più granulari. Per gestire layout complessi, usi il grouping. Il grouping ti permette di unire più visual, forme e caselle di testo. Quando raggruppi gli elementi, si ridimensionano e si spostano come un'unica unità. Questo mantiene il tuo layout preciso e impedisce ai grafici allineati con cura di spostarsi quando modifichi la pagina. Per mantenere un aspetto professionale su tutte queste pagine, usi i temi. Un tema è un set di colori, font e regole di formattazione predefiniti. Applichi un tema al report e ogni visual si aggiorna all'istante per adattarsi. Questo garantisce coerenza e ti evita di dover digitare a mano i codici colore in decine di grafici separati. Ecco il punto chiave. La vera potenza del canvas non sta nell'aspetto dei visual, ma nel loro comportamento. In molti tool di reporting, i grafici sono immagini isolate. In Power BI, i visual sulla stessa pagina sono profondamente connessi di default. Fanno cross-filtering tra loro in modo naturale, in base alle relazioni nel tuo semantic model. Pensa a un report sulle performance regionali. Metti un grafico a barre che mostra le vendite per categoria di prodotto a sinistra, e una mappa geografica che mostra le posizioni degli store a destra. Se un utente clicca sulla barra della categoria elettronica, l'intera pagina reagisce. La mappa evidenzia all'istante le regioni specifiche che hanno venduto elettronica, sfumando il resto della mappa. L'utente non ha cercato nulla, e tu non hai scritto alcuna routing logic per far avvenire l'interazione. Il canvas sa che questi visual condividono gli stessi dati sottostanti, quindi toccarne uno cambia automaticamente il contesto degli altri. Questo comportamento trasforma una pagina statica in un tool di esplorazione interattivo. L'arte del report canvas sta nell'imparare a farsi da parte. Combinando layout puliti, temi coerenti e cross-filtering nativo, permetti all'utente di fare le proprie domande semplicemente cliccando sui dati che ha davanti. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a creare!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Power BI, episodio 7 di 14. I migliori report non si limitano a presentare numeri; permettono all'utente finale di dialogare con i dati. Se costruisci una dashboard statica che obbliga ogni stakeholder a guardare gli stessi identici totali aggregati, i tuoi utenti finiranno per esportare quei numeri su uno spreadsheet per trovare ciò che gli interessa davvero. Puoi evitarlo rendendo i dati interattivi. Ci sono due modi principali per dare ai tuoi utenti il controllo dei dati in Power BI. Spesso le persone usano i termini in modo intercambiabile perché entrambi i metodi ottengono un risultato finale simile, ma la user experience è fondamentalmente diversa. Stiamo parlando degli slicer e del Filters pane. Uno slicer è un tipo di visual che trascini direttamente sul canvas del tuo report. Sta proprio lì, accanto ai tuoi bar chart e line graph. Essendo un visual in pagina, è molto in evidenza. Usi uno slicer quando vuoi invitare esplicitamente l'utente a cambiare la vista. Prendi un report sulle vendite nazionali. Un regional manager lo apre, ma in realtà vuole guardare solo il proprio territorio. Se aggiungi uno slicer al canvas e lo configuri come un semplice dropdown, quel manager può selezionare la sua regione specifica. Nel momento in cui fa quella selezione, ogni altro visual sulla pagina si aggiorna immediatamente per riflettere solo quella regione. Gli slicer permettono all'utente di fare drill down esattamente su ciò che gli interessa in quel momento. Puoi formattarli come liste, dropdown o persino slider per range di date, ma il loro scopo principale è sempre un'interazione immediata e visibile. Ora, il secondo elemento è il Filters pane. A differenza di uno slicer, un filtro non viene posizionato direttamente sul canvas. Vive in un pannello laterale dedicato, attaccato al bordo della finestra del report. Il Filters pane è dove controlli lo scope sottostante dei tuoi dati. Opera a più livelli. Puoi trascinare un campo dati nel pannello per filtrare solo un chart specifico, un'intera pagina, o in modo uniforme ogni singola pagina del tuo report. Ecco il punto chiave. La differenza più grande tra uno slicer e un filtro è la visibilità e il controllo. Gli slicer sono sempre visibili all'utente. I filtri non devono esserlo per forza. Come creatore del report, puoi bloccare un filtro in modo che l'utente non possa cambiarlo, oppure puoi nasconderlo completamente. Se vuoi costruire una versione del tuo report che mostri sempre e solo i dati dell'anno fiscale corrente, applicheresti un page-level filter nascosto per l'anno. L'utente finale non vede mai un pulsante o un dropdown. Interagisce semplicemente con un report che è vincolato in modo sicuro al periodo di tempo corretto. Spesso userai entrambi i tool sulla stessa identica pagina. Stabilisci le regole di base dei tuoi dati usando il Filters pane, disegnando di fatto un recinto intorno a ciò che l'utente è autorizzato a vedere. Poi, posizioni alcuni slicer strategici all'interno del canvas in modo che l'utente possa esplorare liberamente all'interno di quel recinto. Questo approccio mantiene pulito il tuo canvas. Se provassi a trasformare ogni possibile variabile in uno slicer, il tuo report diventerebbe illeggibile. Il Filters pane toglie di mezzo le impostazioni secondarie, mantenendo le scelte più critiche in primo piano. Dai ai tuoi utenti degli slicer on-canvas per le domande che devono farsi ogni giorno, e usa i filtri del pannello laterale per far rispettare le regole che non dovrebbero mai infrangere. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 8 di 14. La parte più difficile nel design di un report è la tensione tra chiarezza e profondità. Vuoi una pagina principale pulita, che racconti subito la storia ad alto livello, ma i tuoi power user pretendono ogni singolo data point granulare. Se metti tutto in un'unica pagina, diventa illeggibile. Il modo per risolvere il problema è nascondere la complessità a una sola interazione di distanza, usando dei deep dive contestuali. Per prima cosa, considera i tooltip personalizzati per le pagine del report. Di default, quando un utente fa hover su un data point in un visual, Power BI mostra un semplice box di testo con il valore esatto di quel punto. Questo ti dà un numero, ma non ti dà alcun contesto. Un tooltip della pagina del report ti permette di sostituire quel box di default con un canvas completamente personalizzato. Costruisci una piccola pagina di report nascosta e la configuri per farla apparire quando un utente fa hover su un visual. Invece di un semplice numero, puoi mostrare una piccola trend line o un gauge chart direttamente all'interno della finestra di hover. Prendi un visual a mappa che mostra le vendite totali per città. Quando un utente fa hover con il cursore sulla bubble dei dati di Seattle, appare un tooltip personalizzato. All'interno di quel pop-up c'è un bar chart in miniatura che analizza le vendite di Seattle negli ultimi dodici mesi. L'utente assimila all'istante questo layer extra di informazioni, e non lascia mai la pagina principale della mappa. A volte un rapido hover non basta. Quando un utente ha bisogno di eseguire un audit completo su uno specifico data point, usi una pagina di drillthrough. Il drillthrough è pensato per indagini approfondite. Crei una pagina di report dettagliata e completamente separata, e le assegni un campo specifico, come una posizione geografica o una categoria di prodotto. Questo dice a Power BI che questa pagina è una destinazione per le azioni di drillthrough. Torna a quella stessa mappa. L'utente fa hover su Seattle, vede il trend mensile, ma decide che i numeri richiedono un'occhiata più da vicino. Fa clic destro sulla bubble di Seattle e seleziona drillthrough. Power BI lo porta via dalla mappa e lo fa atterrare sulla tua pagina di dettaglio. Cosa fondamentale, passa la sua selezione. La nuova pagina viene filtrata automaticamente per mostrare solo i dati di Seattle. Ora sta guardando una tabella completa di transazioni raw delle fatture. È facile confondere queste due feature. I tooltip sono degli hover-box personalizzati che mostrano dei mini-visual senza lasciare la pagina corrente. Sono pensati per una rapida occhiata. Il drillthrough porta l'utente su una pagina di dettaglio completamente nuova, filtrata con precisione in base alla sua selezione. Richiede un clic esplicito ed è pensato per analisi approfondite. Ecco il punto chiave. Non hai bisogno di stipare dense tabelle di transazioni accanto ai tuoi executive summary ad alto livello. Usa i tooltip per rispondere alla domanda di follow-up immediata, e affidati alle pagine di drillthrough per gestire gli audit più pesanti. La tua dashboard principale rimane veloce e pulita, mentre i tuoi utenti accedono comunque esattamente ai dati di cui hanno bisogno. Se vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon: ci dà davvero una grande mano. Grazie per averci fatto compagnia. Spero tu abbia imparato qualcosa di nuovo.

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 9 di 14. Puoi spingerti solo fino a un certo punto facendo drag and drop dei field su un canvas. Prima o poi, avrai bisogno che il tuo report risponda a domande complesse che non sono scritte esplicitamente nel tuo database. È qui che entra in gioco Data Analysis Expressions, o DAX. Viene spontaneo pensare a DAX solo come a delle formule Excel avanzate. Sembrano simili, e molti nomi di funzioni sono identici. Ma Excel opera su una griglia di celle statiche e singole. DAX opera interamente su intere colonne e tabelle. Non punti mai DAX alla riga tre, colonna C. Lo punti alla colonna dell'importo delle vendite e lasci che l'engine capisca il resto. Per demistificare DAX, devi solo padroneggiare due concetti strutturali principali. Questi sono le calculated column e le measure. Una calculated column viene valutata riga per riga. Se ti serve una colonna che moltiplica il prezzo unitario per la quantità venduta per ogni singola transazione, usi una calculated column. L'engine calcola il risultato una volta sola quando i dati vengono caricati o aggiornati, e lo salva in memoria. Diventa una parte fisica del tuo dataset, rendendola utile per categorizzare i dati o costruire gli assi su un grafico. Ecco il punto chiave. Le calculated column sono statiche. Non cambiano quando l'utente interagisce con la tua dashboard. Le measure, d'altra parte, sono completamente dinamiche. Una measure non calcola riga per riga, e non salva valori precalcolati in memoria. Invece, calcola un aggregate al volo, guidata da qualcosa chiamato filter context. Filter context significa semplicemente la combinazione di filtri attualmente attivi nel tuo report in un qualsiasi momento. Questa è la parte che conta. Quando un utente clicca su un anno specifico su una timeline, o seleziona una regione particolare da un drop-down, sta cambiando il filter context. La measure DAX ascolta quei clic, restringe le tabelle sottostanti in memoria per farle corrispondere alla selezione, e ricalcola all'istante la risposta finale. Considera uno scenario in cui scrivi una singola measure DAX per la Year over Year Growth. Trattandosi di una measure, non si blocca su una singola view specifica. Se il tuo utente guarda una summary card ad alto livello, quella stessa identica measure calcola la crescita globale per l'intera azienda. Se clicca sulla regione europea su una mappa, la measure si ricalcola all'istante per mostrare solo la crescita europea. Se fa un ulteriore slice per una specifica linea di prodotto a novembre, la stessa measure restituisce la crescita solo per quel prodotto in quel mese. Scrivi la matematica sottostante una volta sola, e il filter context fa il grosso del lavoro applicandola a qualsiasi cosa l'utente voglia vedere. Le calculated column costruiscono la struttura su cui fai slice. Le measure eseguono la matematica dinamicamente basandosi su quegli slice. Afferrare questa distinzione previene enormi performance bottleneck, come cercare di forzare un calcolo per riga memory-heavy a fare il lavoro di un aggregate dinamico. La vera potenza di DAX non sta nel memorizzare centinaia di funzioni diverse, ma nel capire che ogni calcolo avviene all'interno di un confine invisibile e in continuo cambiamento, impostato dall'utente. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 10 di 14. I dirigenti non hanno tempo di cliccare su cinque documenti multipagina diversi solo per capire se il business è in salute. Vogliono i risultati finali, su un'unica schermata, subito. La feature creata appositamente per risolvere questo problema è la Power BI Dashboard. Spesso le persone usano le parole report e dashboard in modo intercambiabile. Nell'ecosistema di Power BI, devi trattarli come concetti completamente diversi. Un report è un tool interattivo multipagina progettato per analisi approfondite, ed è quasi sempre legato a un singolo dataset sottostante. Una dashboard è rigorosamente un canvas a pagina singola. È un executive summary. Inoltre, non costruisci le dashboard in Power BI Desktop. Sono un artefatto esclusivo del Power BI service. Prima crei i tuoi report, li pubblichi, e poi costruisci la dashboard interamente nel browser. Immagina un CEO che vuole controllare tre metriche specifiche sul suo telefono ogni mattina. Ha bisogno di vedere le revenue giornaliere, l'uptime del server e l'attuale punteggio di customer satisfaction. Queste metriche provengono naturalmente da aree di business completamente scollegate tra loro. La metrica delle revenue si trova in un report finanziario complesso. L'uptime del server è tracciato in un report dedicato all'infrastruttura IT. Il punteggio di satisfaction si trova a pagina tre di un report di marketing. Non puoi unire facilmente questi tre dataset distinti in un unico report standard. Invece, crei una dashboard usando un meccanismo chiamato pinning. Navighi verso il report finanziario pubblicato nel tuo browser, selezioni il card visual delle revenue totali e ne fai il pin su una nuova dashboard. Poi apri il report IT, prendi il gauge dell'uptime del server e fai il pin anche di quello sulla stessa dashboard. Infine, fai lo stesso per il punteggio di satisfaction nel report di marketing. Una volta fatto il pin sul canvas della dashboard, questi singoli visual sono noti come tile. La tua dashboard a pagina singola è ora una raccolta selezionata di tile che estraggono dati live da più report diversi, il che significa che fa da ponte tra diversi dataset sottostanti. Questa cross-report aggregation è l'esatto motivo per cui esistono le dashboard. Rompono i confini dei singoli dataset per creare una vista unificata. Quando un dirigente apre questa dashboard, riceve un aggiornamento di stato immediato, a colpo d'occhio. Qui non interagisce con i dati nel modo in cui lo farebbe in un report. Invece, le tile agiscono come entry point. Se la tile delle revenue giornaliere mostra un calo improvviso, il dirigente clicca semplicemente su quella specifica tile. Quell'azione porta immediatamente l'utente fuori dalla dashboard e direttamente nel report finanziario sottostante da cui ha origine quel visual. Ecco il punto chiave. La dashboard non è un rimpiazzo per il tuo reporting layer dettagliato. È un curation layer che ci sta sopra. Una dashboard ben progettata non tenta di rispondere a ogni possibile domanda analitica; indirizza semplicemente l'utente all'esatto report sottostante che contiene le risposte di cui ha bisogno in questo momento. Grazie per l'ascolto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 11 di 14. Se condividi un workspace con cinquecento persone che devono solo visualizzare i dati, stai facendo un errore. Gli stai mostrando il caos della cucina quando sono venuti solo per mangiare. Il modo giusto per distribuire contenuti finiti è pacchettizzare l'esperienza, e questo significa usare una Power BI App. Una Power BI App non è un software standalone che scarichi da uno store sul telefono. In questo contesto, un'App è una raccolta di dashboard e report presentata come un unico pacchetto unificato. È il metodo di distribuzione ufficiale per i tuoi contenuti Power BI finiti. Chiariamo subito il dubbio principale, ovvero la differenza tra un workspace e un'App. Il workspace è la tua cucina. È lì che gli autori dei report si connettono ai dati, costruiscono modelli e testano diversi layout dei grafici. È un'area collaborativa pensata per chi sviluppa, e può essere in disordine con report in bozza e dataset grezzi. L'App è la sala da pranzo. È pulita, organizzata e progettata strettamente per la fruizione. Quando pubblichi un'App, stai prendendo i piatti pronti dalla cucina per presentarli ai tuoi ospiti. Pensa di dover rilasciare le metriche aziendali ufficiali del 2026 a cinquecento dipendenti in diversi dipartimenti. Non vuoi che debbano spulciare un workspace per capire quale report sia la versione finale. E non vuoi nemmeno mandargli cinque link web diversi. Invece, crei un'App. Quando crei un'App, selezioni esattamente quali dashboard e report del tuo workspace includere. Lasci indietro le bozze. Poi, disegni un menu di navigazione custom. Ed è qui che la cosa si fa interessante. Invece di una lista piatta di file, puoi raggruppare i report correlati sotto degli header collassabili. Puoi ordinare le pagine in modo che la storia scorra logicamente, dai riepiloghi ad alto livello fino ai dettagli granulari. Puoi persino applicare un colore di tema specifico e aggiungere il logo della tua azienda. Per l'utente finale, l'esperienza è seamless. Installa l'App una sola volta dalla directory aziendale. Quando la apre, si ritrova con un'interfaccia brandizzata e read-only. Non ci sono pulsanti di edit a distrarlo. Non può cancellare per sbaglio un visual o alterare il dataset. Usa semplicemente il menu laterale per navigare tra i report. Se apre l'applicazione mobile di Power BI, l'App e la sua struttura di navigazione custom funzionano perfettamente anche lì. Ecco il punto chiave per la manutenzione di questi contenuti. Dato che il workspace e l'App sono separati, puoi aggiornare i report senza rompere la user experience. Se una metrica ha bisogno di un ritocco, fai la modifica nella cucina del workspace. I tuoi cinquecento utenti non vedono i tuoi visual rotti o i grafici a metà mentre ci lavori. La loro App rimane esattamente la stessa finché non sei del tutto pronto. Una volta finito, clicchi su update nell'App, e la nuova versione va live per tutti in un colpo solo. Quando devi consegnare un set di report coeso e facile da navigare a un pubblico ampio, costruisci il workspace per i tuoi autori, ma pacchettizza l'App per i tuoi consumatori. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 12 di 14. Il modo più veloce per garantire che nessuno guardi la tua dashboard è costringerli ad aprire una nuova tab del browser, cercare un bookmark e fare il login su un portale separato. Il context switching distrugge l'adozione. Se vuoi che le persone usino i dati, devi metterli esattamente dove stanno già parlando. Questa è l'idea centrale dietro al concetto di andare incontro agli utenti dove lavorano. Per la maggior parte delle organizzazioni, quel posto è Microsoft Teams. Power BI si integra profondamente in Teams per eliminare l'attrito del context switching. Invece di mandare un link a una dashboard in una chat, porti la dashboard direttamente nel workspace. Prendi ad esempio un team di magazzino che deve controllare i livelli delle scorte ogni mattina. Puoi pinnare un report di inventario live direttamente come tab nel loro canale Teams dedicato. Cliccano sulla tab, e i dati sono semplicemente lì, proprio accanto ai loro messaggi mattutini. C'è un malinteso frequente su come si presenta tutto questo. Fare il push di un report su Teams non significa semplicemente mandare uno screenshot statico o un PDF scollegato. Fa l'embed del report Power BI completo, live e interattivo in modo sicuro all'interno del client di Teams. Gli utenti possono fare slice, filtrare e fare drill down sui dati direttamente dentro il canale. I permessi di sicurezza rimangono rigorosamente applicati. Se un utente non ha i permessi per vedere i dati nel servizio Power BI, non potrà vederli in Teams. Puoi anche avviare un thread di conversazione direttamente collegato a uno specifico visual del report, mantenendo la discussione e i dati nell'esatto stesso contesto. Questo copre la comunicazione quotidiana. Ora pensiamo ai meeting esecutivi. Le presentazioni di solito sono il posto in cui i dati vanno a morire. Qualcuno fa uno screenshot di un grafico, lo incolla in una slide, e cinque minuti dopo il database sottostante si aggiorna. La slide diventa all'istante obsoleta. Power BI risolve il problema permettendoti di fare l'embed di pagine di report live direttamente nelle slide di PowerPoint. Quando apri la presentazione, il grafico recupera i numeri più recenti. Ecco il punto chiave. Dato che il report embeddato è completamente interattivo, cambia il modo in cui si svolgono i meeting. Quando uno stakeholder fa una domanda specifica su un picco nelle vendite, non devi segnartela e promettere di fare follow-up più tardi. Puoi cliccare su quel data point direttamente sulla slide della presentazione, fare cross-filter sui visual e rispondere alla domanda live. Infine, abbiamo Excel. Non potrai mai impedire agli utenti business di volere i dati in uno spreadsheet. Invece di combattere questo comportamento e guardare le persone esportare file CSV statici e non controllati, puoi integrare Power BI in modo trasparente con Excel. Gli utenti possono connettere tabelle pivot, grafici e formule standard di Excel direttamente a un dataset Power BI pubblicato. I dati rimangono gestiti centralmente, sicuri e accurati sul server. Nel frattempo, gli utenti possono analizzare quella single source of truth usando l'interfaccia a grid che già conoscono. Non costruisci una cultura data-driven costringendo tutti a imparare una nuova applicazione standalone. Lo fai iniettando dati live e affidabili direttamente nei tool di comunicazione che aprono già ogni singola mattina. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Power BI Fundamentals, episodio 13 di 14. Probabilmente passi troppo tempo a fare il refresh delle dashboard solo per controllare che tutto funzioni correttamente. I tuoi utenti fanno esattamente la stessa cosa, facendo login ogni mattina solo per confermare che i numeri siano nella norma. Smetti di affidarti alle persone per controllare i problemi di routine. Lascia che siano i dati a dirti quando qualcosa va storto. Questa è l'idea alla base della proactive BI, ottenuta combinando i data alert di Power BI con Power Automate. Tradizionalmente, la business intelligence è reattiva. Crei un report, lo pubblichi e aspetti che qualcuno lo apra. La proactive BI ribalta questo modello. Il sistema si monitora da solo e ti fa il push delle informazioni solo quando serve davvero la tua attenzione. Quando una metrica specifica supera una soglia predefinita, il sistema entra in azione immediatamente. Prima di fare il setup, dobbiamo chiarire un malinteso comune. Non puoi attaccare questi alert automatici a un visual qualsiasi, nascosto in una pagina di report complessa. I data alert in Power BI sono strettamente legati a tipi di visual specifici su una dashboard. Puoi configurarli solo su tile a valore singolo, in particolare gauge, KPI e card. Se hai una metrica critica che vuoi monitorare in un report dettagliato, devi prima fare il pin di quel visual specifico su una dashboard per sbloccare la feature di alerting. Vediamo uno scenario concreto. Supponi di tracciare le vendite giornaliere per un importante punto vendita. L'aspettativa di base è di diecimila dollari al giorno. Se le vendite scendono sotto quel numero, aspettare che un manager controlli la dashboard il venerdì è troppo tardi. Hai bisogno di una risposta immediata. Per prima cosa, configuri un data alert sulla card della dashboard che mostra le vendite giornaliere. Definisci una regola che dice a Power BI di triggerare un alert se il valore scende sotto i diecimila. Fai attenzione a questa parte. Power BI non monitora il database sorgente in real-time. Invece, ogni volta che il dataset di Power BI sottostante fa il refresh, il sistema valuta il nuovo numero su quella card. Se la condizione è soddisfatta, l'alert scatta. Di default, un alert triggerato genera semplicemente una notifica all'interno del servizio Power BI o invia un'email di base alla persona che ha creato la regola. Per renderlo davvero utile a livello aziendale, lo integri con Power Automate. Power Automate se ne sta in silenzio e resta in ascolto di quello specifico data alert di Power BI. Quando l'alert scatta, Power BI passa un payload di dati a Power Automate. Questo payload contiene il titolo dell'alert, la soglia che hai impostato e il valore effettivo che ha infranto la regola. Usi questi valori dinamici per costruire un workflow a valle. Puoi configurare il flow in modo che, nel momento in cui la metrica delle vendite scende, succedano automaticamente due cose. Primo, il flow estrae il valore effettivo delle vendite e fa il push di una notifica immediata direttamente sul cellulare del manager del negozio. Secondo, invia un'email automatica al team regionale con le cifre esatte e un link diretto alla dashboard per ulteriori indagini. Nessuno ha dovuto aprire manualmente Power BI per scoprire il problema. Integrando gli alert della dashboard con l'automazione a valle, rimuovi il collo di bottiglia umano dalla risposta agli incidenti. Il vero valore di un sistema di monitoraggio non si misura da quante persone lo fissano ogni giorno, ma da quanto velocemente forza un'azione nel momento in cui viene superato un limite critico. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Power BI, episodio 14 di 14. Fissi una canvas vuota, e ti serve un report di vendita completo entro fine giornata. Invece di fare drag and drop di campi per ore, ti basta fare una domanda in plain text, e il layout si costruisce da solo. Il futuro della business intelligence è conversazionale, guidato da Copilot in Power BI. C'è sempre il timore che l'intelligenza artificiale sia qui per sostituire il data analyst. Ma non è così. Copilot è un assistente potente, progettato specificamente per accelerare la tua prima bozza. Gestisce il noioso setup iniziale, lasciandoti libero di concentrarti sul perfezionamento dei veri e propri insight. Colma il divario tra i dati grezzi e il report finale usando il linguaggio naturale, rendendo la fase di creazione iniziale molto più veloce. Quando apri il report builder, puoi interagire direttamente con il riquadro di Copilot. Digiti un prompt, ad esempio chiedendo di creare un riepilogo delle performance di vendita. Copilot analizza immediatamente il tuo semantic model sottostante. Determina quali metriche contano in base alla tua richiesta, seleziona i tipi di visual appropriati e genera automaticamente una pagina di report completa. Non devi posizionare manualmente i grafici a barre o configurare gli assi per iniziare. Dichiari il tuo intento, e il sistema lo traduce in un layout concreto. Questo cambia radicalmente il tuo approccio alla creazione dei report, passando dalla costruzione manuale a una direzione ad alto livello. Ecco l'insight chiave. Copilot non si limita a creare grafici; scrive la storia dei tuoi dati. Insieme ai visual, genera una text box narrativa che riassume i driver principali e i trend in plain English. Questo non è testo statico. Essendo collegata direttamente al semantic model, la narrazione è completamente dinamica. Se i dati sottostanti cambiano durante la notte, o se un utente clicca su una regione specifica in un visual a mappa, il testo si riscrive all'istante per riflettere quel nuovo contesto. Il riepilogo resta sempre sincronizzato con la view corrente dei dati, senza richiedere alcun aggiornamento manuale. Questa interfaccia conversazionale abbassa drasticamente la barriera all'ingresso per generare insight. Non ti serve una profonda conoscenza tecnica del tool per estrarre valore dai dati. Tuttavia, mantieni il controllo assoluto. Una volta che l'IA ha generato quel layout e quella narrazione iniziali, entri in gioco tu. Puoi ridimensionare i visual, ritoccare la formattazione o modificare la narrazione per adattarla alle tue specifiche esatte. È un workflow collaborativo. Copilot costruisce il grosso delle fondamenta, e tu applichi i tocchi finali per assicurarti che il prodotto finale rispetti gli standard della tua organizzazione. Il vero potere del linguaggio naturale nella business intelligence non sta solo nel risparmiare qualche clic del mouse; sta nel rimuovere completamente l'attrito tra l'avere una domanda di business e il vederne la risposta sullo schermo. Dato che questo è l'ultimo episodio della nostra serie sui fondamenti, ti consiglio vivamente di esplorare la documentazione ufficiale Microsoft e di provare queste feature hands-on con i tuoi semantic model. Se hai idee su cosa dovremmo trattare in futuro, visita devstories dot eu per suggerire argomenti per le prossime serie. Per questo episodio è tutto. Grazie per l'ascolto, e continua a costruire!