Condividi tramite

Raccogliere i requisiti per la migrazione a Power BI

  • Articolo

Questo articolo descrive la Fase 1, che è incentrata sulla raccolta e l'assegnazione delle priorità dei requisiti durante la migrazione a Power BI.

Il diagramma mostra le fasi di una migrazione di Power BI. Viene evidenziata la Fase 1 per questo articolo.

Nota

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

La Fase 1 è incentrata sulla raccolta di informazioni e sulla pianificazione della migrazione a Power BI di una singola soluzione.

L'output della Fase 1 include i requisiti dettagliati a cui stata assegnata la priorità. Sono tuttavia necessarie attività aggiuntive nelle Fasi 2 e 3 per la stima completa del livello di lavoro richiesto.

Importante

Le Fasi 1-5 rappresentano 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. Nei casi appropriati, rimettersi alle decisioni a livello di organizzazione per garantire efficienza e coerenza.

La roadmap per l'adozione di Fabric descrive questi tipi di considerazioni strategiche e tattiche. Pone enfasi sull'adozione aziendale.

Suggerimento

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

Requisiti di compilazione

L'inventario degli elementi di business intelligence esistenti, compilati nei passaggi di pre-migrazione, diventa l'input per la definizione dei requisiti della nuova soluzione da creare in Power BI. Per raccogliere i requisiti, è necessario capire lo stato corrente, nonché identificare gli elementi che si vorrebbe venissero modificati o sottoposti a refactoring quando i report vengono riprogettati in Power BI. La disponibilità di requisiti dettagliati è particolarmente utile per pianificare la distribuzione della soluzione nella Fase 2, durante la creazione di un modello di prova nella Fase 3 e durante la realizzazione di una soluzione pronta per la produzione nella Fase 4.

Raccogliere i requisiti per i report

Fornire informazioni complete e di facile riferimento sui report, ad esempio:

  • scopo, gruppo di destinatari e azione prevista: identificare lo scopo e il processo aziendale applicabile a ogni report, nonché al gruppo di destinatari, al flusso di lavoro analitico e alle azioni previste da parte degli utenti del report.
  • Modalità di utilizzo del report: è consigliabile rivolgersi agli utenti del report esistente per comprendere esattamente cosa fanno con esso. Si potrà constatare che alcuni elementi del report possono essere eliminati o migliorati nella nuova versione di Power BI. Questo processo comporta un investimento aggiuntivo in termini di tempo, ma è molto utile per la stesura di report critici o usati frequentemente.
  • proprietario e esperto in materia: identificare il proprietario del report e gli esperti di materia associati al report o al dominio dei dati. che in futuro potrebbero diventare proprietari del nuovo report Power BI. Includere eventuali requisiti di gestione delle modifiche (che in genere sono diversi tra le soluzioni gestite dal reparto IT e le soluzioni gestite dal reparto commerciale), oltre ad eventuali approvazioni che saranno necessarie in caso di modifiche future. Per altre informazioni, vedi questo articolo.
  • Metodo di distribuzione dei contenuti: chiarire le aspettative dei consumatori del report riguardo alla distribuzione dei contenuti. che potrebbe essere su richiesta, tramite esecuzione interattiva, incorporata in un'applicazione personalizzata o sulla base di una pianificazione a seguito di una sottoscrizione tramite posta elettronica. Potrebbero essere previsti requisiti anche per attivare le notifiche di avviso.
  • esigenze di interattività: determinare i requisiti essenziali e opzionali per l'interattività, come 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). Per ogni report, identificare i requisiti in termini di dati cronologici, tendenze e snapshot dei dati, in modo che possano essere allineati ai requisiti dei dati correnti. Documentare le origini dei dati può essere utile anche in un secondo tempo, al momento di convalidare i dati di un nuovo report con i relativi 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 il livello di riservatezza dei dati, la privacy dei dati o le esigenze normative/di conformità.
  • 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.
  • Requisiti di usabilità, layout e estetici: identificare le esigenze specifiche di usabilità, layout ed estetici correlate alle visualizzazioni dei dati, ai gruppi di raggruppamento e ordinamento, e alla visibilità condizionale. Includere eventuali considerazioni specifiche relative alla distribuzione su dispositivi mobili.
  • esigenze di stampa e di esportazione: determinare se sono presenti requisiti specifici per l'esportazione o di un layout pronto alla stampa. Questi requisiti contribuiranno a determinare il tipo di report più adatto, ad esempio un report Power BI, Excel o impaginato. Tenere presente che gli utenti finali dei report tendono ad attribuire molta importanza al modo in cui hanno sempre usato i report e non si deve temere di provare a cambiare le loro abitudini. È importante tuttavia parlare in termini di miglioramenti e non di cambiamenti.
  • 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 operazioni di manutenzione future, problemi noti o richieste posticipate da aggiungere al backlog in questo momento.

Suggerimento

Valutare l'opportunità di classificare i requisiti suddividendoli tra necessari e auspicabili. Gli utenti finali chiedono spesso in anticipo tutto ciò di cui potrebbero aver bisogno, poiché ritengono che sia l'unica possibilità di effettuare richieste. Quando si valutano le priorità in più iterazioni, è inoltre opportuno rendere il backlog disponibile a tutti gli stakeholder, in modo da semplificare la comunicazione, il processo decisionale e il monitoraggio degli impegni in sospeso.

Raccogliere i requisiti dei dati

Fornire informazioni dettagliate inerenti 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 , o possono essere convertite in un modello di importazione.
  • Tipi di origini dati: consente di compilare i tipi di origini dati necessarie, incluse origini dati centralizzate (ad esempio un data warehouse aziendale) e origini dati non standard (ad esempio file flat o file di Excel che aumentano le origini dati aziendali per la creazione di report). Ai fini della connettività del gateway data, è importante anche trovare la posizione delle origini dati.
  • Struttura dei dati e necessità di pulizia: determinare la struttura dei dati per ciascuna origine dati necessaria e in quale misura le attività di pulizia dei dati siano necessarie.
  • integrazione dei dati: valutare come verrà gestita l'integrazione dei dati quando vi sono più fonti di dati e come si possono definire relazioni tra ogni tabella del modello. Identificare gli specifici elementi dati necessari per semplificare il modello e ridurne le dimensioni.
  • Latenza dei dati accettabile: determinare le esigenze di latenza dei dati per ogni origine dati. Influiranno sulle decisioni relative alla modalità di archiviazione dei dati da usare. È importante sapere anche la frequenza di aggiornamento dei dati per le tabelle del modello di importazione.
  • Volume di dati e scalabilità: valutare le aspettative dei volumi di dati, che influiranno sulle decisioni relative al supporto di modelli di grandi dimensioni e alla progettazione di modelli DirectQuery o Composite. È fondamentale applicare anche alcune considerazioni sulle esigenze in fatto di cronologia dei dati. Per i modelli semantici più grandi, sarà necessaria anche la determinazione dell'aggiornamento incrementale dei dati.
  • Misure, indicatori KPI e regole aziendali: Valutare le necessità per misure, indicatori KPI e regole aziendali. Influiscono sulla decisione con cui si determina se applicare la logica al modello semantico o al 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 può essere appropriata per migliorare l'individuabilità, l'accesso alle definizioni o la produzione di terminologia coerente accettata a livello aziendale.
  • 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 noti relativi alla qualità dei dati, manutenzione futura o richieste posticipate al backlog in questo momento.

Importante

La riusabilità dei dati può essere conseguita con modelli semantici condivisi che, facoltativamente, possono essere certificati per indicarne l'attendibilità e migliorarne l'individuabilità. La riusabilità del processo di preparazione dei dati può essere eseguita con flussi di dati per ridurre la logica ripetitiva in più modelli semantici. I flussi di dati, inoltre, possono ridurre significativamente il carico dei sistemi di origine, in quanto i dati vengono recuperati meno spesso: più modelli semantici possono quindi importare contemporaneamente dati dal flusso di dati.

Identificare le opportunità di miglioramento

Nella maggior parte dei casi, si assiste a modifiche e miglioramenti. È raro che si verifichi una migrazione diretta uno-a-uno senza che si verifichi alcun refactoring o miglioramento. È possibile prendere in considerazione l'attuazione di tre tipi di miglioramenti:

  • Consolidamento dei report: è possibile consolidare report simili usando tecniche quali filtri, segnalibri o personalizzazione. La disponibilità di un minor numero di report, più flessibili, può migliorare significativamente l'esperienza degli utenti del report. Valutare l'opportunità di ottimizzare i modelli semantici per le Domande e risposte (query in linguaggio naturale), in modo da offrire una maggiore flessibilità agli utenti dei report e permettere loro di creare visualizzazioni personalizzate.
  • miglioramenti dell'efficienza: durante la raccolta dei requisiti, è spesso possibile identificare miglioramenti. Ad esempio, nei casi in cui gli analisti inseriscono i numeri manualmente o un flusso di lavoro può essere semplificato. Power Query può svolgere un ruolo essenziale nella sostituzione delle attività attualmente eseguite in modo manuale. Se gli analisti aziendali si trovano a dover eseguire sempre le stesse attività per pulire e preparare i dati a intervalli regolari, i passaggi ripetibili di preparazione dei dati di Power Query possono produrre un significativo risparmio 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 possibilità di usare e incrementare i dati per soddisfare le esigenze di analisi e di creazione di report.

Nota

Per altre informazioni sulla centralizzazione dei modelli dati, vedere Disciplina al centro e Flessibilità alla periferia.

Assegnare le priorità e valutare la complessità

A questo punto, l'inventario iniziale è disponibile e potrebbe includere requisiti specifici. Quando si assegnano le priorità al set iniziale di elementi di Business Intelligence pronti per la migrazione, i report e i dati devono essere considerati collettivamente, oltre che indipendenti l'uno dall'altro.

Identificare i report con priorità alta, ovvero i report che:

  • Apportano un valore significativo all'azienda.
  • Vengono eseguiti frequentemente.
  • Sono necessari ai dirigenti o ai team di leadership.
  • Prevedono un ragionevole livello di complessità (per migliorare le probabilità di successo durante le iterazioni della migrazione iniziale).

Identificare i dati con priorità alta, ovvero i dati che:

  • Contengono elementi dati critici.
  • Sono dati aziendali comuni che vengono applicati in molti casi d'uso.
  • Possono essere usati per creare un modello semantico condiviso che possa essere riusato da altri report e molti creatori di report.
  • Prevedono un ragionevole livello di complessità (per migliorare le probabilità di successo durante le iterazioni della migrazione iniziale).

Contenuto correlato

Nell'articolo seguente in questa serie sulla migrazione a Power BI è possibile ottenere informazioni sulla Fase 2, incentrata sulla pianificazione della migrazione a una singola soluzione Power BI.

Altre risorse utili includono:

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