Eseguire il modello di verifica per eseguire la migrazione a Power BI

Questo articolo descrive la fase 3, che riguarda l'esecuzione di un modello di verifica (POC) per attenuare i rischi e risolvere i problemi sconosciuti il prima possibile durante la migrazione a Power BI.

Diagram shows the stages of a Power BI migration. Stage 3 is emphasized for this article.

Nota

Per una spiegazione completa dell'immagine precedente, vedere Panoramica della migrazione di Power BI.

L'obiettivo della fase 3 consiste nell'affrontare i problemi sconosciuti e attenuare i rischi il prima possibile. Un modello di verifica tecnico è utile per convalidare i presupposti. Può essere eseguita in modo iterativo insieme alla pianificazione della distribuzione delle soluzioni (descritta nella fase 2).

L'output di questa fase è una soluzione Power BI limitata nell'ambito, risolve le domande aperte iniziali ed è pronta per un lavoro aggiuntivo nella fase 4 per renderlo pronto per la produzione.

Importante

Non si prevede che il modello di verifica sia un lavoro eliminabile. Invece, ci aspettiamo che sia un'iterazione anticipata della soluzione pronta per la produzione. Nell'organizzazione, è possibile fare riferimento a questa attività come prototipo, pilota, mockup, avvio rapido o prodotto minimo funzionante (MVP). L'esecuzione di un modello di verifica non è sempre necessaria e potrebbe anche verificarsi in modo informale.

Suggerimento

La maggior parte degli argomenti illustrati in questo articolo si applica anche a un progetto di implementazione standard di Power BI. Man mano che l'organizzazione diventa più esperto con Power BI, la necessità di condurre i POC diminuisce. Tuttavia, a causa della frequenza di rilascio rapida con Power BI e dell'introduzione continua di nuove funzionalità, è possibile condurre regolarmente PC 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 funzionalità.
  • Informare se stessi sulle differenze nel funzionamento di Power BI rispetto alla piattaforma bi legacy.
  • Convalidare le conoscenze iniziali di determinati requisiti con esperti in materia.
  • Creare un piccolo modello semantico (noto in precedenza come set di dati) 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 espressioni di sintassi DAX usate dai calcoli del modello e convalidare.
  • Testare la connettività dell'origine dati usando un gateway (se si tratta di un'origine gateway).
  • Testare l'aggiornamento dei dati usando un gateway (se si tratta di un'origine gateway).
  • Verificare le configurazioni di sicurezza, inclusa la sicurezza a livello di riga, se applicabile.
  • Sperimentare il layout e le decisioni cosmetiche.
  • Verificare che tutte le funzionalità del servizio Power BI funzionino come previsto.

L'ambito del modello di verifica dipende dagli elementi sconosciuti o dagli obiettivi da convalidare con i colleghi. Per ridurre la complessità, mantenere un poC il più piccolo possibile in termini di ambito.

La maggior parte delle volte con una migrazione, i requisiti sono noti perché esiste una soluzione esistente da cui iniziare. Tuttavia, a seconda dell'entità dei miglioramenti da apportare o delle competenze esistenti di Power BI, un modello di verifica fornisce comunque un valore significativo. Inoltre, la creazione rapida di prototipi con feedback degli utenti potrebbe essere appropriata per chiarire rapidamente i requisiti, soprattutto se vengono apportati miglioramenti.

Importante

Anche se un modello di verifica include solo un subset di dati o include solo oggetti visivi limitati, è spesso importante portarlo dall'inizio alla fine. Ovvero dallo sviluppo in Power BI Desktop alla distribuzione in un'area di lavoro di sviluppo nel servizio Power BI. È l'unico modo per raggiungere completamente gli obiettivi del modello di verifica. È particolarmente vero quando l'servizio Power BI deve offrire funzionalità critiche che non sono state usate in precedenza, ad esempio un modello semantico DirectQuery che usa l'accesso Single Sign-On. Durante il modello di verifica, concentrarsi sugli aspetti incerti o sulla necessità di verificarsi 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.

Grazie alla sua estrema flessibilità, esistono alcuni aspetti di Power BI che potrebbero essere fondamentalmente diversi dalla piattaforma bi legacy da cui si esegue la migrazione.

Prendere in considerazione la riprogettazione dell'architettura dei dati

Se si esegue la migrazione da una piattaforma bi legacy con un proprio livello semantico, è probabile che la creazione di un modello semantico di importazione sia un'opzione valida. Power BI funziona meglio con una progettazione di tabelle dello schema star. Pertanto, se il livello semantico legacy non è uno schema star, è possibile che sia necessaria una riprogettazione per trarre vantaggio da Power BI. L'impegno nella definizione di un livello semantico che soddisfa i principi di progettazione dello schema star (incluse le relazioni, le misure comunemente usate e la terminologia aziendale amichevole) funge da punto di partenza eccellente per gli autori di report self-service.

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

Attenzione

Se viene visualizzata la creazione di molti file di Power BI Desktop che comprendono una singola tabella importata, in genere è un indicatore che la progettazione non è ottimale. Se si nota questa situazione, verificare se l'uso di modelli semantici condivisi creati usando una progettazione dello schema star potrebbe ottenere un risultato migliore.

Decidere come gestire le conversioni dei dashboard

Nel settore bi, un dashboard è una raccolta di oggetti visivi che visualizza le metriche chiave in una singola pagina. In Power BI, tuttavia, un dashboard rappresenta una funzionalità di visualizzazione specifica che può essere creata solo nel servizio Power BI. Quando si esegue la migrazione di un dashboard da una piattaforma bi legacy, sono disponibili due opzioni:

  1. Il dashboard legacy può essere ricreato come report di Power BI. La maggior parte dei report viene creata con Power BI Desktop. Anche i report impaginati e i report di Excel sono opzioni alternative.
  2. Il dashboard legacy può essere ricreato come dashboard di Power BI. I dashboard sono una funzionalità di visualizzazione del servizio Power BI. Gli oggetti visivi del dashboard vengono spesso creati aggiungendo oggetti visivi da uno o più report, domande e risposte o Informazioni rapide.

Suggerimento

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

Concentrarsi sull'immagine generale quando si ricreano gli oggetti visivi

Ogni strumento di business intelligence ha i punti di forza e le aree di interesse. Per questo motivo, gli oggetti visivi del report esatti da cui dipende in una piattaforma bi legacy potrebbero non avere un equivalente vicino in Power BI.

Quando si ricreano gli oggetti visivi del report, concentrarsi maggiormente sulle domande aziendali di grandi dimensioni affrontate dal report. Rimuove la pressione per replicare la progettazione di ogni oggetto visivo nello stesso modo. Anche se gli utenti dei contenuti apprezzano la coerenza quando si usano report migrati, è importante non essere coinvolti in dibattiti dispendiosi in termini di tempo su dettagli di piccole dimensioni.

Nell'articolo successivo di questa serie di migrazione di Power BI vengono fornite informazioni sulla fase 4, che riguarda la creazione e la convalida del contenuto durante la migrazione a Power BI.

Altre risorse utili includono:

I partner Power BI esperti sono disponibili per aiutare l'organizzazione a eseguire correttamente il processo di migrazione. Per coinvolgere un partner Power BI, visitare il portale per i partner Power BI.