Eseguire un modello di verifica per la migrazione a Power BI

Questo articolo descrive la Fase 3, incentrata sull'esecuzione di un modello di verifica (POC, Proof of Concept) per attenuare i rischi e risolvere le incognite nella fase iniziale della migrazione a Power BI.

Nota

Per una spiegazione completa del grafico precedente, vedere Panoramica della migrazione di Power BI.

La Fase 3 è incentrata sulla risoluzione delle incognite e l'attenuazione dei rischi il prima possibile. Un modello di verifica tecnico può essere usato per la convalida dei presupposti. Può essere eseguito in modo iterativo insieme alla pianificazione della distribuzione della soluzione (descritta nella Fase 2).

L'output di questa fase è una soluzione di Power BI con ambito limitato, che risolve le domande iniziali aperte e viene sottoposta a un lavoro aggiuntivo nella Fase 4 per renderla pronta per la produzione.

Importante

Non si prevede che il modello di verifica sia un lavoro monouso, bensì che si tratti di una prima iterazione della soluzione pronta per la produzione. All'interno dell'organizzazione è possibile fare riferimento a questa attività come prototipo, pilota, mockup, avvio rapido o prodotto minimo funzionante. L'esecuzione di un modello di verifica non è sempre necessaria e può essere eseguita in modo informale.

Suggerimento

La maggior parte degli argomenti illustrati in questo articolo si applica anche a un progetto di implementazione di Power BI standard. Man mano che gli utenti aziendali acquisiscono esperienza con Power BI, la necessità di condurre un modello di verifica diminuisce. A causa della rapida frequenza di rilascio di Power BI e alla continua introduzione di nuove funzionalità, è opportuno eseguire regolarmente modelli di verifica tecnici a scopo di apprendimento.

Impostare gli obiettivi e l'ambito del modello di verifica

Quando si esegue un modello di verifica, concentrarsi sugli obiettivi seguenti:

• Verificare i presupposti sul funzionamento di una caratteristica.
• Apprendere le differenze tra il funzionamento di Power BI e quello della piattaforma di BI legacy.
• Convalidare le supposizioni iniziali di determinati requisiti con esperti in materia.
• Creare un modello semantico di piccole dimensioni con dati reali per comprendere e rilevare eventuali problemi relativi alla struttura dei dati, alle relazioni, ai tipi di dati o ai valori dei dati.
• Sperimentare e convalidare espressioni di sintassi DAX usate dai calcoli del modello.
• Testare la connettività dell'origine dati usando un gateway (se deve essere un'origine del gateway).
• Testare l'aggiornamento dei dati usando un gateway (se deve essere un'origine del gateway).
• Verificare le configurazioni di sicurezza, inclusa la sicurezza a livello di riga, se applicabile.
• Sperimentare le possibili decisioni relative a layout ed elementi cosmetici.
• Verificare che tutte le funzionalità nel servizio Power BI funzionino come previsto.

L'ambito del modello di verifica dipende dalle incognite o dagli obiettivi da convalidare con i colleghi. Per ridurre la complessità, è possibile limitare al massimo l'ambito del modello di verifica.

Quando si esegue una migrazione, molto spesso i requisiti sono ben noti poiché esiste una soluzione di partenza. Tuttavia, a seconda della portata dei miglioramenti da apportare o delle competenze su Power BI esistenti, un modello di verifica può comunque fornire vantaggi significativi. La possibilità di creare rapidamente nuovi prototipi grazie ai feedback degli utenti consente inoltre di identificare al meglio i requisiti, soprattutto se vengono apportati miglioramenti.

Importante

Anche se un modello di verifica include solo un subset di dati o un numero limitato di oggetti visivi, è spesso importante eseguirlo dall'inizio alla fine, ovvero dallo sviluppo in Power BI Desktop alla distribuzione in un'area di lavoro di sviluppo nel servizio Power BI. Si tratta infatti dell'unico modo per raggiungere completamente gli obiettivi del modello di verifica. Questo è particolarmente vero quando il servizio Power BI deve fornire funzionalità critiche mai usate in precedenza, ad esempio un modello semantico DirectQuery che usa l'accesso Single Sign-On. Durante lo sviluppo del modello di verifica, concentrarsi sugli aspetti su cui si è meno sicuri o che devono essere verificati con altri utenti.

Gestire le differenze in Power BI

Power BI può essere usato come strumento basato su modello o come strumento basato su report. Una soluzione basata su modello prevede lo sviluppo di un modello di dati, mentre una soluzione basata su report si connette a un modello di dati già distribuito.

A causa dell'estrema flessibilità di Power BI, è possibile che alcuni aspetti siano sostanzialmente diversi dalla piattaforma di BI legacy da cui viene eseguita la migrazione.

Valutare l'opportunità di riprogettare l'architettura dei dati

Se si esegue la migrazione da una piattaforma di BI legacy che dispone di un livello semantico, è probabile che la creazione di un modello semantico di importazione sia una scelta corretta. Power BI funziona in modo ottimale con una progettazione di tabelle con schema star. Se, pertanto, il livello semantico legacy non è uno schema star, è possibile che sia necessaria una riprogettazione per sfruttare al massimo le potenzialità di Power BI. La definizione di un livello semantico aderente ai principi di progettazione dello schema star (incluse le relazioni, le misure più adottate e la terminologia usata a livello aziendale) costituisce un eccellente punto di partenza per gli autori dei report self-service.

Se si esegue la migrazione da una piattaforma di BI legacy in cui i report fanno riferimento a origini dati relazionali mediante query SQL o stored procedure e se si prevede di usare Power BI in modalità DirectQuery, è possibile giungere a una migrazione quasi uno-a-uno del modello di dati.

Attenzione

Se vengono creati molti file di Power BI Desktop con una sola tabella importata, significa che la progettazione non è ottimale. Se si osserva questa situazione, verificare se potrebbe essere raggiunto un risultato migliore usando modelli semantici condivisi creati con una progettazione basata su uno schema a stella.

Decidere come gestire le conversioni dei dashboard

Nel settore BI, un dashboard è una raccolta di oggetti visivi in cui le metriche chiave vengono visualizzate in un'unica pagina. In Power BI, tuttavia, un dashboard rappresenta una specifica funzionalità di visualizzazione che è possibile creare solo nel servizio Power BI. Quando si esegue la migrazione di un dashboard da una piattaforma di BI legacy, sono disponibili due opzioni:

1. È possibile ricreare il dashboard legacy come report di Power BI. La maggior parte dei report viene creata con Power BI Desktop. Due opzioni alternative possono essere i report impaginati e i report Excel.
2. È possibile ricreare il dashboard legacy come dashboard di Power BI. I dashboard sono una funzionalità di visualizzazione del servizio Power BI. Gli oggetti visivi del dashboard vengono spesso creati mediante l'aggiunta di oggetti visivi di uno o più report, Domande e risposte e Informazioni rapide.

Suggerimento

Poiché i dashboard sono un tipo di contenuto di Power BI, evitare di usare la parola dashboard nel nome del report o del dashboard.

Concentrarsi sul quadro generale quando si ricreano gli oggetti visivi

Ogni strumento di business intelligence presenta aree di interesse e punti di forza diversi. Per questo motivo, è possibile che gli oggetti visivi del report a cui ci si affidava in una piattaforma di BI legacy non abbiano un equivalente esatto in Power BI.

Quando si ricreano gli oggetti visivi del report, è necessario quindi concentrarsi sulle domande aziendali generali a cui fa riferimento il report. In questo modo, infatti, si elimina la necessità di replicare esattamente la progettazione di ogni oggetto visivo. Sebbene gli utenti finali dei contenuti apprezzino la coerenza con il passato quando usano i report migrati, è importante non perdere troppo tempo a discutere dei dettagli.

Contenuto correlato

Nell'articolo seguente in questa serie sulla migrazione a Power BI è possibile ottenere informazioni sulla Fase 4, incentrata sulla creazione e la convalida di contenuti durante la migrazione a Power BI.

Altre risorse utili includono:

• Trasformazione BI di Microsoft
• Pianificazione dell'implementazione di Power BI
• Domande? Contattare la community di Power BI
• inviare suggerimenti, Contribuire con idee per migliorare Power BI

Partner esperti di Power BI sono a disposizione per aiutare le organizzazioni a completare con successo il processo di migrazione. Per collaborare con un partner Power BI, visitare il portale dei partner Power BI.