Raccogliere i requisiti per la migrazione a Power BI

Questo articolo descrive la Fase 1, che è incentrata sulla raccolta e l'assegnazione delle priorità dei requisiti durante la migrazione a 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.

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, destinatari e azione prevista: identificare lo scopo e il processo aziendale da applicare a ogni report, nonché i destinatari, il flusso di lavoro analitico e l'azione prevista da parte degli utenti del report.
• Modalità di utilizzo del report da parte degli utenti finali: valutare l'opportunità di parlare con gli utenti del report esistente per comprendere esattamente come viene usato. 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 ed esperto di dominio: identificare il proprietario del report ed eventuali esperti 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 degli utenti finali del report in merito 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 di interattività necessari e auspicabili, ad esempio i filtri, il drill-down o il drill-through.
• Origini dati: verificare che tutte le origini dati richieste dal report vengano individuate e che siano chiari i requisiti 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 i visualizzatori e gli editor consentiti e le eventuali esigenze di sicurezza a livello di riga, incluse possibili eccezioni alla normale sicurezza aziendale. Documentare il livello di riservatezza dei dati, la privacy dei dati o le esigenze normative/di conformità.
• Calcoli, indicatori KPI e regole di business: identificare e documentare tutti i calcoli, gli indicatori KPI e le regole di business attualmente definiti nel report esistente, in modo che possano essere allineati con i requisiti dei dati.
• Requisiti di usabilità, layout e cosmetici: identificare specifiche esigenze di usabilità, layout e cosmetiche relative ai requisiti di visualizzazione, raggruppamento e ordinamento dei dati e alla visibilità condizionale. Includere eventuali considerazioni specifiche relative alla distribuzione su dispositivi mobili.
• Esigenze di stampa ed esportazione: determinare se sono presenti requisiti specifici per l'esportazione o il layout pronto per la 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 l'eventuale presenza di altri requisiti tecnici o funzionali per i report, nonché di eventuali rischi o problemi relativi alle informazioni presentate.
• Elementi di backlog e problemi aperti: identificare eventuali requisiti di manutenzione futura, problemi noti o richieste posticipate da aggiungere al backlog in questa fase.

Raccogliere i requisiti dei dati

Fornire informazioni dettagliate inerenti ai dati, ad esempio:

• Query esistenti: identificare se sono già presenti query o stored procedure di report esistenti che possono essere usate da un modello di DirectQuery o da un modello composito o che potrebbero essere convertite in un modello di importazione.
• Tipi di origini dati: specificare i tipi di origini dati necessari, incluse eventuali origini dati centralizzate (come un data warehouse aziendale) e origini dati non standard (come file flat o file di Excel che incrementano le origini dati aziendali ai fini della creazione di report). Ai fini della connettività del gateway data, è importante anche trovare la posizione delle origini dati.
• Struttura dei dati ed esigenze di pulizia: determinare la struttura dei dati per ogni origine dati necessaria e stabilire in quale misura sono necessarie attività di pulizia dei dati.
• Integrazione dei dati: valutare il modo in cui dovrà essere gestita l'integrazione dei dati in presenza di più origini dati e il modo in cui potranno essere definite le relazioni tra ogni tabella di modello. Identificare gli specifici elementi dati necessari per semplificare il modello e ridurne le dimensioni.
• Latenza 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.
• Scalabilità e volume dei dati: valutare le aspettative in termini di volume dei dati, che influiranno sulle decisioni relative al supporto di modelli di grandi dimensioni e sulla progettazione di DirectQuery o di modelli compositi. È 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 di business: valutare le esigenze per misure, indicatori KPI e regole di business. 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 relativi ai dati master a cui prestare 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 esistono specifiche considerazioni sulla sicurezza o la privacy dei dati da applicare ai set di dati, inclusi eventuali requisiti di sicurezza a livello di riga.
• Elementi di backlog e problemi aperti: aggiungere al backlog eventuali problemi o difetti di qualità dei dati noti, requisiti di manutenzione futura o richieste posticipate.

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 varie tecniche come 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 di efficienza: durante la raccolta dei requisiti è spesso possibile identificare i 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 dati: un modello semantico autorevole e certificato svolge la funzione di backbone per la Business Intelligence in modalità 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.

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:

• 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.