In sintesi
- Il guasto non è nel report: quando una dashboard Power BI smette di funzionare dopo un aggiornamento del piano, quasi sempre è cambiata la forma dei dati in uscita, non il modello.
- Quattro cose devono restare ferme: il nome delle colonne, la presenza dei file, il formato di numeri e date, e il significato di ogni campo. Le prime tre si presentano da sole con un errore; l’ultima no.
- Il guasto peggiore non fa rumore: un campo che tiene il nome e cambia contenuto — lavoro invece di durata — lascia la dashboard verde e i numeri sbagliati.
- Verificarlo costa zero: conservare l’intestazione di ogni file e confrontarla al giro dopo, contare le righe, controllare un valore che conosci a memoria.
Il primo lunedì del mese la dashboard Power BI non si aggiorna. Oppure si aggiorna, e i numeri sono diversi da quelli che avevi mostrato in comitato tre settimane fa. Si riapre il modello, si controllano le misure, si scrive a chi l’ha costruito.
Quasi sempre si sta cercando nel posto sbagliato. Il pezzo più fragile di un report non è il report: è il punto in cui i dati escono dal piano.
Il guasto non è quasi mai dentro il report
Un modello di Power BI è un insieme di passi scritti una volta contro una forma precisa: questa colonna si chiama così, contiene quel tipo di dato, sta in quel file. Finché la forma non cambia, quei passi funzionano per anni senza che nessuno li tocchi.
Il problema è che la forma cambia, e cambia altrove. Qualcuno rinomina un campo personalizzato nel piano. L’esportazione viene rifatta con opzioni diverse. Una procedura guidata, lanciata a mano da una persona diversa dal solito, salta un livello di dettaglio perché quella casella era spuntata l’altra volta e stavolta no.
Nessuna di queste cose succede dentro Power BI. Tutte si manifestano lì.
L’esportazione è un contratto, anche se nessuno l’ha firmato
Fra il piano e il report esiste un accordo implicito: quali file arrivano, come si chiamano le colonne, che cosa contengono. Nessuno lo ha mai scritto, e proprio per questo nessuno si accorge quando viene violato — finché qualcosa non si rompe a valle.
Un contratto dei dati non è un documento complicato. È l’elenco di ciò che chi riceve ha il diritto di dare per scontato, e di ciò che chi produce si impegna a non cambiare senza avvisare.
Le quattro cose che devono restare ferme
Non tutto ciò che cambia rompe qualcosa, e non tutto ciò che rompe fa rumore. Queste quattro sono quelle che contano davvero.
E lo spostamento di una colonna? Nel caso più comune non rompe niente: se il file ha l’intestazione nella prima riga e la query la promuove a nomi di colonna, i passi successivi lavorano sui nomi, e finché l’intestazione resta quella il report regge.
Ma «nel caso più comune» va preso alla lettera, perché esiste l’altro. La funzione che legge i CSV accetta anche un elenco fisso di nomi di colonna, e in quel caso i nomi vengono assegnati per posizione, ignorando l’intestazione del file: sposti due colonne e i dati finiscono sotto l’intestazione sbagliata, senza nessun errore. Se invece è fissato solo il numero di colonne, una colonna aggiunta in fondo viene scartata in silenzio, e una in meno arriva piena di valori nulli.
Vale la pena aprire una volta l’editor di Power Query e guardare com’è scritto il primo passo, quello che apre il file. È un minuto, e dice quale dei due mondi è il tuo.
Il guasto silenzioso è il peggiore
Un aggiornamento che fallisce è una seccatura di un’ora. Un aggiornamento che riesce con i dati sbagliati è un altro genere di problema: la dashboard è verde, i grafici si disegnano, e qualcuno prende una decisione.
Succede quando un campo mantiene il nome e cambia contenuto. Il caso più comune nei piani di Microsoft Project è la confusione fra lavoro e durata: due misure diverse, entrambe espresse in unità di tempo, che nessun controllo automatico distingue. Se l’esportazione cambia quale delle due finisce in quella colonna, il report continua a funzionare e a mentire.
Per questo l’ultima riga della tabella qui sopra è la sola che richiede una verifica volontaria: nessuno strumento te la segnala.
Come si verifica, senza strumenti particolari
Non serve una piattaforma di data quality. Servono tre abitudini, e si possono prendere oggi.
- Conserva l’intestazione. La prima riga di ogni file esportato è la firma del contratto. Salvane una copia in un file di testo, accanto al modello. Al giro successivo confronta le due: su Windows basta
fcda riga di comando, e in tre secondi sai se qualcosa si è mosso. - Conta le righe. Un conteggio annotato ogni mese vale più di quanto sembri. Le attività di un progetto non raddoppiano né dimezzano da sole: se succede, l’esportazione ha incluso o escluso qualcosa.
- Controlla un valore che conosci a memoria. Una singola attività di cui sai la durata, un totale di cui ricordi l’ordine di grandezza. È il controllo che intercetta il guasto silenzioso, ed è l’unico che funziona contro di esso.
Se l’esportazione è automatica e gira di notte, aggiungi una quarta abitudine: falla fallire ad alta voce. Una procedura che in caso di problema scrive comunque un file parziale è peggio di una che si ferma, perché il file parziale viene caricato senza obiezioni.
Quello che uno schema stabile non risolve
Vale la pena essere chiari su cosa questo metodo non copre, perché è tutta roba che poi si presenta lo stesso.
- Non rende corretti i dati. Un piano tenuto male esportato benissimo produce un report stabile e inutile. La forma è il contratto; la qualità del contenuto resta un problema di pianificazione.
- Non protegge dai cambiamenti del piano. Se aggiungi un sottoprogetto, cambi la struttura di scomposizione o inizi a usare un campo personalizzato che prima era vuoto, il report andrà rivisto comunque. Il contratto riguarda il tracciato, non ciò che ci metti dentro.
- Non sostituisce il modello. Relazioni sbagliate, misure che sommano ciò che non va sommato, filtri dimenticati: il report può rompersi benissimo da solo, senza aiuto esterno.
- Non dice nulla su chi può leggere cosa. Permessi, percorsi di rete e riservatezza sono un capitolo a parte, e un’esportazione stabile non li tocca.
Se qualcosa non torna
L’aggiornamento si ferma su una colonna che c’è. Guarda gli spazi: un’intestazione con uno spazio finale è un nome diverso, e a occhio sono identiche. Aprendo il file con un editor di testo invece che con Excel si vede.
I numeri sono mille volte più grandi, o mille volte più piccoli. È il separatore delle migliaia interpretato come decimale, o viceversa. Dipendono da due impostazioni locali che devono combaciare: quella della macchina che ha scritto il file e quella con cui la query lo interpreta. Se l’esportazione è passata da un computer a un altro, di solito è l’unica delle due che è cambiata.
Le date sono valide ma sbagliate. Giorno e mese invertiti. Si vede solo nei giorni fino al dodici del mese, e per questo di solito viene scoperto verso metà mese, quando le conversioni cominciano a fallire.
Tutto funziona ma manca l’ultima settimana. Controlla la data di stato del piano e l’orario dell’esportazione: se gira prima dell’aggiornamento dell’avanzamento, il report è corretto e vecchio di sette giorni.
La domanda da fare la prossima volta
Quando un report si rompe, la prima domanda in riunione è quasi sempre «chi ha toccato la dashboard?». È la domanda sbagliata, e manda due persone a cercare per mezza giornata nel posto in cui non è successo niente.
La domanda giusta è: che cosa è cambiato nell’esportazione? Nella maggior parte dei casi, la risposta è lì.
Domande frequenti
Come faccio a sapere se la mia query legge i CSV per nome o per posizione?
Apri l’editor di Power Query e guarda il primo passo, quello che apre il file. Se l’elenco delle colonne è scritto per esteso, i nomi sono assegnati per posizione e l’ordine conta. Se invece c’è solo un numero, o niente, e subito dopo compare il passo che promuove la prima riga a intestazione, allora i nomi vengono dal file e l’ordine non conta.
Il report si aggiorna senza errori: posso stare tranquillo?
No. Un aggiornamento che riesce con i dati sbagliati è il caso peggiore, perché nessuno lo segnala. Succede quando un campo mantiene il nome e cambia contenuto. L’unico controllo che lo intercetta è umano: un valore che conosci a memoria, guardato ogni volta.
Basta tenere fermi i nomi delle colonne?
No. I nomi sono solo la prima delle quattro cose che contano. Restano il formato di numeri e date, che dipende da due impostazioni locali che devono combaciare; la presenza di tutti i file attesi; e il significato di ogni campo, che nessun controllo automatico verifica.
Serve uno strumento per avere un’esportazione stabile?
No. Il metodo descritto qui non richiede nulla: l’intestazione salvata in un file di testo e il comando fc di Windows fanno il grosso del lavoro. Uno strumento serve quando si vuole togliere di mezzo la persona che lancia l’esportazione a mano, non per verificare il tracciato.
Perché le date sbagliate si scoprono sempre a metà mese?
Perché giorno e mese invertiti producono una data valida finché il giorno è minore o uguale a dodici: fino ad allora la conversione riesce, con il valore sbagliato. Dal tredici in poi la conversione fallisce, e solo allora qualcuno se ne accorge.
Trasparenza: oltre alla consulenza di pianificazione e controllo sviluppo anche gli strumenti di cui parlo qui, e il paragrafo che segue va letto per quello che è. Niente di ciò che c’è scritto sopra richiede il mio strumento, né alcuno strumento: l’intestazione conservata in un file di testo e fc costano zero e fanno il grosso del lavoro.
Se vuoi che quel contratto smetta di dipendere da chi lancia l’esportazione, OneClickExporter legge i piani di Microsoft Project senza che Project sia installato e scrive un insieme fisso e documentato di file CSV, sempre gli stessi e sempre nello stesso ordine. La riga di comando fa parte del prodotto ed è compresa nella prova di 15 giorni.
#MicrosoftProject #PowerBI #ContrattoDati #PMO