Raccogliere i requisiti per la migrazione a Power BI

Questo articolo descrive la fase 1, che riguarda la raccolta e la definizione delle priorità dei requisiti durante la migrazione a Power BI.

Nota

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

L'accento sulla fase 1 riguarda la raccolta e la pianificazione delle informazioni per una singola soluzione di cui verrà eseguita la migrazione a Power BI.

L'output della fase 1 include requisiti dettagliati che sono stati classificati in ordine di priorità. Tuttavia, le attività aggiuntive nelle fasi 2 e 3 devono essere completate per stimare completamente il livello di sforzo.

Importante

Le fasi 1-5 rappresentano le attività correlate a una soluzione specifica. Esistono decisioni e attività a livello di organizzazione/tenant che influiscono sul processo a livello di soluzione. Alcune di queste attività di pianificazione di livello superiore sono illustrate nell'articolo Panoramica della migrazione di Power BI. Se appropriato, rinviare le decisioni a livello di organizzazione per l'efficienza e la coerenza.

La roadmap per l'adozione dell'infrastruttura descrive questi tipi di considerazioni strategiche e tattiche. Ha un'enfasi sull'adozione dell'organizzazione.

Suggerimento

La maggior parte degli argomenti illustrati in questo articolo si applica anche a un progetto di implementazione standard di Power BI.

Requisiti di compilazione

L'inventario degli elementi bi esistenti, compilati nei passaggi di pre-migrazione, diventa l'input per i requisiti della nuova soluzione da creare in Power BI. La raccolta dei requisiti riguarda la comprensione dello stato corrente, nonché gli elementi che gli utenti desiderano modificare o eseguire il refactoring quando i report vengono riprogettati in Power BI. I requisiti dettagliati saranno utili per la pianificazione della distribuzione della soluzione nella fase 2, durante la creazione di un modello di verifica nella fase 3 e quando si crea la soluzione pronta per la produzione nella fase 4.

Raccogliere i requisiti dei report

Compilare informazioni complete, facili da fare, sui report, ad esempio:

• Scopo, gruppo di destinatari e azione prevista: identificare lo scopo e il processo aziendale applicabili a ogni report, nonché il gruppo di destinatari, il flusso di lavoro analitico e l'azione prevista da intraprendere dai consumer di report.
• Utilizzo del report da parte degli utenti: è consigliabile rivolgersi ai consumer di report del report esistente per comprendere esattamente le operazioni eseguite. È possibile apprendere che alcuni elementi del report possono essere eliminati o migliorati nella nuova versione di Power BI. Questo processo comporta un investimento in tempo aggiuntivo, ma è utile per i report o i report critici usati spesso.
• Proprietario ed esperto in materia: identificare il proprietario del report e gli esperti di materia associati al report o al dominio dei dati. Potrebbero diventare i proprietari del nuovo report di Power BI in futuro. Includere eventuali requisiti specifici di gestione delle modifiche (che in genere differiscono tra le soluzioni gestite dall'IT e quelle gestite dall'azienda), nonché le approvazioni e gli accessi, che saranno necessari quando verranno apportate modifiche in futuro. Per altre informazioni, vedi questo articolo.
• Metodo di distribuzione del contenuto: chiarire le aspettative degli utenti del report per la distribuzione di contenuti. Potrebbe trattarsi di esecuzione interattiva su richiesta, incorporata in un'applicazione personalizzata o recapito in base a una pianificazione tramite una sottoscrizione di posta elettronica. Potrebbero essere previsti anche requisiti per attivare le notifiche di avviso.
• Esigenze di interattività: determinare i requisiti di interattività necessari e interessanti, ad esempio filtri, azioni di drill-down o azioni drill-through.
• Origini dati: assicurarsi che vengano individuate tutte le origini dati richieste dal report e che siano comprese le esigenze di latenza dei dati (aggiornamento dei dati). Identificare i dati cronologici, le tendenze e i requisiti degli snapshot dei dati per ogni report in modo che possano essere allineati ai requisiti dei dati. La documentazione dell'origine dati può essere utile anche in un secondo momento durante l'esecuzione della convalida dei dati di un nuovo report con i dati di origine.
• Requisiti di sicurezza: chiarire i requisiti di sicurezza ( ad esempio visualizzatori consentiti, editor consentiti e eventuali esigenze di sicurezza a livello di riga), incluse eventuali eccezioni alla normale sicurezza dell'organizzazione. Documentare qualsiasi livello di riservatezza dei dati, privacy dei dati o esigenze di conformità/normative.
• Calcoli, indicatori KPI e regole business: identificare e documentare tutti i calcoli, gli indicatori KPI e le regole business attualmente definiti all'interno del report esistente in modo che possano essere allineati ai requisiti dei dati.
• Usabilità, layout e requisiti cosmetici: identificare esigenze specifiche di usabilità, layout e cosmetici correlate alle visualizzazioni dei dati, ai requisiti di raggruppamento e ordinamento e alla visibilità condizionale. Includere eventuali considerazioni specifiche relative alla distribuzione di dispositivi mobili.
• Esigenze di stampa ed esportazione: determinare se sono presenti requisiti specifici per l'esportazione o il layout pronto per la stampa. Queste esigenze influiranno sul tipo di report più adatto, ad esempio power BI, Excel o report impaginato. Tenere presente che i consumatori di report tendono a posizionare un sacco di importanza su come hanno sempre fatto le cose, quindi non avere paura di sfidare il loro modo di pensare. Assicurarsi di parlare in termini di miglioramenti invece di cambiare.
• Rischi o preoccupazioni: determinare se sono presenti altri requisiti tecnici o funzionali per i report, nonché eventuali rischi o preoccupazioni riguardanti le informazioni presentate.
• Problemi aperti ed elementi di backlog: identificare eventuali future operazioni di manutenzione, problemi noti o richieste posticipate da aggiungere al backlog in questo momento.

Suggerimento

Prendere in considerazione i requisiti di classificazione classificandoli come devono avere o bello da avere. Spesso i consumatori chiedono tutto ciò che potrebbero essere necessari in anticipo perché credono che sia la loro unica possibilità di effettuare richieste. Inoltre, quando si indirizzano le priorità in più iterazioni, rendere il backlog disponibile per gli stakeholder. Consente di comunicare, prendere decisioni e tenere traccia degli impegni in sospeso.

Raccogliere i requisiti dei dati

Compilare informazioni dettagliate relative ai dati, ad esempio:

• Query esistenti: identificare se sono presenti query di report o stored procedure esistenti che possono essere usate da un modello DirectQuery o da un modello composito oppure possono essere convertite in un modello di importazione.
• Tipi di origini dati: compilare i tipi di origini dati necessarie, incluse le origini dati centralizzate (ad esempio un data warehouse aziendale) e le origini dati non standard (ad esempio file flat o file di Excel che aumentano le origini dati aziendali a scopo di creazione di report). Anche la ricerca della posizione delle origini dati, ai fini della connettività del gateway dati, è importante.
• Esigenze di struttura e pulizia dei dati: determinare la struttura dei dati per ogni origine dati necessaria e in quale misura sono necessarie le attività di pulizia dei dati.
• Integrazione dei dati: valutare la modalità di gestione dell'integrazione dei dati quando sono presenti più origini dati e come è possibile definire le relazioni tra ogni tabella del modello. Identificare elementi di dati specifici necessari per semplificare il modello e ridurne le dimensioni.
• Latenza dei dati accettabile: determinare le esigenze di latenza dei dati per ogni origine dati. Influirà sulle decisioni sulla modalità di archiviazione dei dati da usare. Anche la frequenza di aggiornamento dei dati per le tabelle del modello di importazione è importante.
• Volume e scalabilità dei dati: valutare le aspettative del volume di dati, che influiranno sulle decisioni relative al supporto di modelli di grandi dimensioni e alla progettazione di modelli DirectQuery o Compositi. Anche le considerazioni relative alle esigenze dei dati cronologici sono essenziali. Anche per i modelli semantici più grandi (noti in precedenza come set di dati), sarà necessario determinare l'aggiornamento incrementale dei dati.
• Misure, indicatori KPI e regole business: valutare le esigenze per misure, indicatori KPI e regole business. Influiranno sulle decisioni relative alla posizione in cui applicare la logica: nel modello semantico o nel processo di integrazione dei dati.
• Dati master e catalogo dati: valutare se sono presenti problemi di dati master che richiedono attenzione. Determinare se l'integrazione con un catalogo dati aziendale è appropriata per migliorare l'individuabilità, l'accesso alle definizioni o produrre terminologia coerente accettata dall'organizzazione.
• Sicurezza e privacy dei dati: determinare se sono presenti considerazioni specifiche sulla sicurezza o sulla privacy dei dati per i modelli semantici, inclusi i requisiti di sicurezza a livello di riga.
• Problemi aperti ed elementi di backlog: aggiungere eventuali problemi noti, difetti di qualità dei dati noti, manutenzione futura o richieste posticipate al backlog in questo momento.

Importante

La riutilizzabilità dei dati può essere ottenuta con modelli semantici condivisi, che facoltativamente possono essere certificati per indicare affidabilità e migliorare l'individuabilità. La riutilizzabilità della preparazione dei dati può essere ottenuta con i flussi di dati per ridurre la logica ripetitiva in più modelli semantici. I flussi di dati possono anche ridurre significativamente il carico nei sistemi di origine perché i dati vengono recuperati meno spesso. Più modelli semantici possono quindi importare dati dal flusso di dati.

Identificare le opportunità di miglioramento

Nella maggior parte dei casi, si verificano alcune modifiche e miglioramenti. È raro che si verifichi una migrazione diretta uno-a-uno senza alcun refactoring o miglioramento. È possibile considerare tre tipi di miglioramenti:

• Consolidamento dei report: è possibile consolidare report simili usando tecniche quali filtri, segnalibri o personalizzazione. Avere meno report, che sono ognuno più flessibile, può migliorare significativamente l'esperienza per i consumer di report. Valutare la possibilità di ottimizzare i modelli semantici per domande e risposte (query in linguaggio naturale) per offrire maggiore flessibilità ai consumer di report, consentendo loro di creare visualizzazioni personalizzate.
• Miglioramenti dell'efficienza: durante la raccolta dei requisiti, è spesso possibile identificare miglioramenti. Ad esempio, quando gli analisti compilano i numeri manualmente o quando un flusso di lavoro può essere semplificato. Power Query può svolgere un ruolo importante nella sostituzione delle attività manuali attualmente eseguite. Se gli analisti aziendali si trovano a eseguire le stesse attività per pulire e preparare regolarmente i dati, i passaggi di preparazione dei dati di Power Query ripetibili possono produrre risparmi significativi in termini di tempo e ridurre gli errori.
• Centralizzazione del modello di dati: un modello semantico autorevole e certificato funge da backbone per la BI self-service gestita. In questo caso, i dati vengono gestiti una sola volta e gli analisti hanno la flessibilità di usare e aumentare i dati per soddisfare le esigenze di creazione di report e analisi.

Nota

Per altre informazioni sulla centralizzazione dei modelli di dati, vedere disciplina al centro e flessibilità al perimetro.

Classificare e valutare la complessità

A questo punto, l'inventario iniziale è disponibile e può includere requisiti specifici. Quando si assegna la priorità al set iniziale di elementi bi pronti per la migrazione, i report e i dati devono essere considerati collettivamente e indipendentemente l'uno dall'altro.

Identificare i report con priorità elevata, che possono includere report che:

• Portare valore significativo all'azienda.
• Vengono eseguite frequentemente.
• Sono richiesti dai dirigenti o dai dirigenti senior.
• Implica un livello ragionevole di complessità (per migliorare le probabilità di successo durante le iterazioni iniziali della migrazione).

Identificare i dati ad alta priorità, che potrebbero includere dati che:

• Contiene elementi di dati critici.
• Dati aziendali comuni che servono molti casi d'uso.
• Può essere usato per creare un modello semantico condiviso per il riutilizzo da parte di report e molti autori di report.
• Implica un livello ragionevole di complessità (per migliorare le probabilità di successo nelle iterazioni di migrazione iniziali).

Contenuto correlato

Nell'articolo successivo di questa serie di migrazione di Power BI vengono fornite informazioni sulla fase 2, che riguarda la pianificazione della migrazione per una singola soluzione 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

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.