Pianificazione dell'implementazione di Power BI: pianificazione della soluzione BI

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sul carico di lavoro di Power BI all'interno di Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo illustra come pianificare soluzioni che supportano la strategia di Business Intelligence (BI). È destinato principalmente a:

• Responsabili o amministratori di business intelligence e analisi: decision maker responsabili della supervisione del programma BI e delle soluzioni BI importanti in modo strategico.
• Centro di eccellenza (COE), TEAM IT e BI: i team che progettano e distribuiscono soluzioni bi aziendali per la propria organizzazione.
• Esperti in materia (PMI) e proprietari e creatori di contenuti: i team e i singoli utenti che supportano l'analisi in un reparto e progettano e distribuiscono soluzioni per scenari di utilizzo self-service, business intelligence del reparto o bi del team.

Una strategia di business intelligence è un piano per implementare, usare e gestire dati e analisi. Per definire la strategia di business intelligence, iniziare con la pianificazione strategica di BUSINESS Intelligence. La pianificazione strategica consente di identificare le aree e gli obiettivi di interesse bi. Per determinare il percorso di avanzamento verso gli obiettivi bi, è necessario descrivere risultati chiave specifici usando la pianificazione tattica. Si ottengono quindi progressi verso questi risultati chiave pianificando e distribuendo soluzioni BI.

Nota

Nel quadro degli obiettivi e dei risultati chiave (OKR), gli obiettivi sono chiari e di alto livello delle descrizioni di ciò che si vuole raggiungere. Al contrario, i risultati chiave sono specifici, risultati raggiungibili per misurare lo stato di avanzamento verso uno degli obiettivi.

Inoltre, le iniziative o le soluzioni sono processi o strumenti creati per ottenere uno o più risultati chiave. Le soluzioni rispondono alle esigenze specifiche dei dati per gli utenti. Una soluzione può assumere molte forme, ad esempio una pipeline di dati, un data lakehouse o un modello semantico o un report di Power BI.

Per altre informazioni sugli OKR, vedere Ottenere informazioni sugli OKR (Microsoft Viva Goals).

Esistono molti approcci per pianificare e implementare soluzioni BI. Questo articolo descrive un approccio che è possibile adottare per pianificare e implementare soluzioni bi che supportano la strategia di business intelligence.

Il diagramma generale seguente illustra come eseguire la pianificazione della soluzione BI.

Per eseguire la pianificazione della soluzione BI, seguire questa procedura.

Step	Descrizione
1	Assemblare un team di progetto che raccoglie i requisiti e definisce la progettazione della soluzione.
2	Pianificare la distribuzione della soluzione eseguendo la configurazione iniziale di strumenti e processi.
3	Eseguire un modello di verifica della soluzione (POC) per convalidare i presupposti sulla progettazione.
4	Creare e convalidare il contenuto usando cicli di sviluppo e convalida iterativi.
5	Distribuire, supportare e monitorare la soluzione dopo il rilascio nell'ambiente di produzione.

Nota

La pianificazione della soluzione BI si applica sia ai progetti BIself-service che a progetti bi aziendali.

Per altre informazioni, vedere la serie di migrazione di Power BI. Anche se la serie riguarda la migrazione, le azioni e le considerazioni principali sono rilevanti per la pianificazione della soluzione.

Passaggio 1: Raccogliere i requisiti

Si inizia la pianificazione della soluzione raccogliendo prima i requisiti e definendo la progettazione della soluzione.

Nota: la pianificazione strategica e tattica è guidata da un team di lavoro che guida l'iniziativa. Al contrario, la pianificazione della soluzione è guidata da un team di progetto, costituito da proprietari e creatori di contenuti.

La raccolta dei requisiti giusti è fondamentale per ottenere una corretta distribuzione e adozione di soluzioni. Un modo efficace per raccogliere i requisiti consiste nell'identificare e coinvolgere gli stakeholder giusti, definire in modo collaborativo il problema da risolvere e usare la comprensione condivisa del problema per creare una progettazione di soluzioni.

Ecco alcuni vantaggi derivanti dall'uso di un approccio collaborativo per raccogliere i requisiti.

• L'input utente produce progettazioni più utili: coinvolgere gli utenti nelle discussioni incentrate per raccogliere i requisiti, è possibile acquisire in modo più efficace le esigenze dei dati aziendali. Ad esempio, gli utenti possono dimostrare ai creatori di contenuti come usano soluzioni esistenti e forniscono feedback sull'efficacia percepita di queste soluzioni.
• Evitare presupposti e attenuare le richieste di modifica: le discussioni con gli utenti spesso rivelano sfumature, eccezioni e complessità nascoste. Queste informazioni dettagliate riducono la probabilità di richieste in fase di ritardo, che possono essere costose da risolvere.
• L'onboarding degli utenti aumenta l'adozione della soluzione: coinvolgere gli utenti nello sviluppo iniziale e nella progettazione, offre loro l'opportunità di influenzare il risultato finale. Il coinvolgimento può anche dare agli utenti un senso di proprietà intellettuale e responsabilità per la soluzione. Gli utenti altamente coinvolti saranno più propensi a approvare la soluzione e guidare la propria community di pratica nell'usarla in modo efficace.
• Le progettazioni definiscono le aspettative per gli stakeholder e gli utenti aziendali: producendo simulazioni o illustrazioni della progettazione della soluzione, è possibile mostrare chiaramente agli stakeholder cosa offrirà la soluzione. Consente inoltre di creare una comprensione reciproca del risultato previsto del progetto. Questo processo è noto anche come pensiero progettuale e può essere un modo efficace per affrontare e comprendere problemi complessi.

È possibile adottare approcci diversi per coinvolgere gli utenti e raccogliere i requisiti. Ad esempio, è possibile raccogliere i requisiti con progettazione aziendale e progettazione tecnica (descritti in dettaglio nelle sezioni successive di questo articolo).

La progettazione aziendale è un approccio per raccogliere i requisiti aziendali. Si concentra sul coinvolgimento degli utenti aziendali nelle sessioni di progettazione aziendale per progettare in modo collaborativo la soluzione. L'output di una progettazione aziendale è costituito da simulazioni di soluzioni e documentazione di progettazione descrittiva.

La progettazione tecnica è un approccio per tradurre i requisiti aziendali in requisiti tecnici e per soddisfare i presupposti di progettazione. Una progettazione tecnica è incentrata sulla convalida del design aziendale e sulla definizione di un approccio tecnico da usare. Per convalidare la progettazione, i creatori di contenuti in genere interagiscono con esperti tecnici in discussioni incentrate denominate sessioni di progettazione tecnica, se necessario.

Importante

La raccolta dei requisiti errati è un motivo comune per cui le implementazioni hanno esito negativo. Spesso, i team raccolgono i requisiti errati perché si occupano di stakeholder sbagliati, ad esempio i decision maker che forniscono richieste top-down per la creazione di soluzioni.

Coinvolgere gli utenti aziendali usando approcci collaborativi come una progettazione aziendale può aiutare a raccogliere requisiti migliori. I requisiti migliori spesso comportano uno sviluppo più efficiente e soluzioni più affidabili.

Nota

Per alcuni team, l'adozione di un processo di raccolta dei requisiti strutturati è un grande cambiamento. Assicurarsi di gestire questa modifica e che non interrompa la pianificazione della soluzione. È consigliabile trovare modi per adattare questi approcci in base al modo in cui funziona il team.

Preparare la pianificazione della soluzione

Prima di tutto è necessario prepararsi per la pianificazione della soluzione considerando i fattori descritti nelle sezioni seguenti.

• Identificare chi eseguirà la pianificazione della soluzione: nell'ambito della pianificazione tattica bi, il team di lavoro ha creato un backlog di soluzioni con priorità. Nella pianificazione della soluzione, un team di progetto è responsabile della progettazione, dello sviluppo e della distribuzione di una o più soluzioni dal backlog. Per ogni soluzione nel backlog, è necessario assemblare un team di progetto che sarà responsabile della soluzione. Oltre all'esecuzione della pianificazione della soluzione BI, il team di progetto deve:
  • Definire sequenze temporali e attività cardine per la pianificazione della soluzione.
  • Identificare e coinvolgere gli stakeholder appropriati per la raccolta dei requisiti.
  • Configurare una posizione centralizzata per la comunicazione, la documentazione e la pianificazione.
  • Coinvolgere gli stakeholder per raccogliere i requisiti.
  • Comunicare e coordinare gli stakeholder e gli utenti aziendali.
  • Orchestrare i cicli di sviluppo e test iterativi con gli utenti aziendali.
  • Documentare la soluzione.
  • Eseguire l'onboarding degli utenti nella soluzione definendo e applicando un piano di formazione.
  • Fornire il supporto della soluzione post-distribuzione.
  • Risolvere le richieste utente ragionevoli di modificare o aggiornare la soluzione dopo la distribuzione.
  • Eseguire la consegna della soluzione dopo la distribuzione, se necessario.
• Centralizzare la comunicazione e la documentazione: è importante che il team di progetto centralizza la comunicazione e la documentazione per la pianificazione della soluzione BI. Ad esempio, il team di progetto deve centralizzare i requisiti, la comunicazione degli stakeholder, le sequenze temporali e i risultati finali. Prendere in considerazione l'archiviazione di tutta la documentazione in un portale centralizzato.
• Raccolta dei requisiti dei piani: il team di progetto deve iniziare pianificando le sessioni di progettazione aziendale per raccogliere i requisiti aziendali. Queste sessioni hanno la forma di riunioni interattive e possono seguire un formato simile ai workshop di pianificazione strategica.

Suggerimento

Prendere in considerazione l'identificazione e il coinvolgimento dei team di supporto responsabili della soluzione nelle fasi iniziali del processo di raccolta dei requisiti. Per supportare efficacemente la soluzione, i team di supporto avranno bisogno di una comprensione completa della soluzione, del suo scopo e degli utenti. Questo è particolarmente importante quando il team di progetto è costituito solo da consulenti esterni.

Raccogliere i requisiti aziendali

Raccogliere i requisiti aziendali corretti è fondamentale per progettare la soluzione corretta. Per raccogliere i requisiti corretti e definire una progettazione efficace della soluzione, il team di progetto può condurre sessioni di progettazione aziendale insieme agli utenti aziendali.

Lo scopo delle sessioni di progettazione aziendale è:

• Confermare l'ambito iniziale della soluzione.
• Definire e comprendere il problema che la soluzione deve risolvere.
• Identificare le parti interessate chiave corrette per la soluzione.
• Raccogliere i requisiti aziendali corretti.
• Preparare una progettazione della soluzione che soddisfi i requisiti aziendali.
• Preparare la documentazione di progettazione di supporto.

Il diagramma seguente illustra come raccogliere i requisiti aziendali e definire la progettazione della soluzione usando un approccio di progettazione aziendale.

Il diagramma illustra i passaggi seguenti.

Articolo	Descrizione
	Il team di progetto inizia la progettazione aziendale confermando l'ambito della soluzione documentato per la prima volta nella pianificazione tattica. Devono chiarire le aree aziendali, i sistemi e i dati che la soluzione includerà.
	Il team del progetto identifica gli stakeholder chiave della community degli utenti che saranno coinvolti nelle sessioni di progettazione aziendale. Gli stakeholder chiave sono utenti con conoscenze e credibilità sufficienti per rappresentare le aree di interesse della soluzione.
	Il team di progetto pianifica sessioni di progettazione aziendale. La pianificazione implica l'informazione degli stakeholder, l'organizzazione di riunioni, la preparazione dei risultati finali e l'interazione con gli utenti aziendali.
	Il team di progetto raccoglie e ricerca le soluzioni esistenti usate dagli utenti aziendali per soddisfare le esigenze dei dati aziendali esistenti. Per accelerare questo processo, il team di progetto può usare ricerche pertinenti dalla pianificazione strategica bi, documentata nell'hub di comunicazione.
	Il team del progetto esegue sessioni di progettazione aziendale con gli stakeholder. Queste sessioni sono riunioni interattive di piccole dimensioni, in cui il team di progetto guida gli stakeholder a comprendere le esigenze e i requisiti dei dati aziendali.
	Il team di progetto conclude la progettazione aziendale presentando una bozza di progettazione della soluzione agli stakeholder e ad altri utenti per il feedback e l'approvazione. La progettazione aziendale ha successo quando gli stakeholder accettano che la progettazione li aiuterà a raggiungere i propri obiettivi aziendali.

Il design aziendale si conclude con i risultati finali seguenti.

• Progettazioni di soluzioni: i mock-up, i prototipi o i diagrammi wireframe illustrano la progettazione della soluzione. Questi documenti convertono i requisiti in un progetto di progettazione concreto.
• Elenco delle metriche aziendali: campi quantitativi previsti nella soluzione, incluse le definizioni aziendali e le aggregazioni previste. Se possibile, classificarli in base all'importanza per gli utenti.
• Elenco degli attributi aziendali: attributi pertinenti e strutture di dati previste nella soluzione, incluse le definizioni aziendali e i nomi degli attributi. Se possibile, includere gerarchie e classificare gli attributi in base all'importanza per gli utenti.
• Documentazione supplementare: descrizioni dei principali requisiti funzionali o di conformità. Questa documentazione deve essere il più precisa possibile, ma il più concisa possibile.

I risultati finali della progettazione aziendale vengono usati e convalidati dalla progettazione tecnica.

Suggerimento

I mock-up, i prototipi o i diagrammi wireframe della soluzione possono creare una chiara comprensione del risultato previsto, sia per gli sviluppatori che per gli utenti finali. La creazione di mock-up efficaci non richiede abilità artistica o talento. È possibile usare semplici strumenti come Microsoft Whiteboard, PowerPoint o anche solo una penna e un foglio per illustrare la progettazione.

Raccogliere i requisiti tecnici

Dopo aver completato la progettazione aziendale, il team di progetto convalida i risultati usando una progettazione tecnica. Il design tecnico è un approccio simile al design aziendale. Mentre la progettazione aziendale è incentrata sulle esigenze dei dati aziendali, la progettazione tecnica è incentrata sugli aspetti tecnici di una soluzione. Un risultato chiave della progettazione tecnica è il piano della soluzione, che descrive la progettazione finale della soluzione e stime informate dello sforzo per implementarlo.

Nota

A differenza del design aziendale, il design tecnico è in gran parte un'indagine indipendente sui dati di origine e sui sistemi condotti da creatori e proprietari di contenuti.

Lo scopo di un progetto tecnico è:

• Convalidare i risultati della progettazione aziendale.
• Risolvere i presupposti tecnici nella progettazione corrente.
• Identificare le origini dati pertinenti nell'ambito e definire i calcoli dei campi e i mapping delle origini campo per ogni origine dati.
• Tradurre i requisiti aziendali in requisiti tecnici.
• Produrre stime dello sforzo richiesto per l'implementazione.

Il team del progetto coinvolge gli stakeholder tecnici o funzionali in sessioni di progettazione tecnica limitate e incentrate. Queste sessioni sono riunioni interattive con gli stakeholder funzionali per raccogliere i requisiti tecnici. Gli stakeholder sono responsabili di aree funzionali specifiche necessarie per il funzionamento efficace della soluzione.

Esempi di stakeholder in una progettazione tecnica possono essere:

• Team di sicurezza e rete: responsabile della sicurezza e della conformità dei dati.
• Team funzionali e amministratori dei dati: responsabile della cura dei dati di origine.
• Architetti: proprietari di piattaforme, strumenti o tecnologie specifici.

Il team del progetto coinvolge gli stakeholder nelle sessioni di progettazione tecnica per affrontare gli aspetti tecnici della soluzione. Gli aspetti tecnici possono includere:

• Connessioni all'origine dati: informazioni dettagliate su come connettersi e integrare le origini dati.
• Rete e gateway dati: informazioni dettagliate sulle reti private o sulle origini dati locali.
• Mapping delle origini dei campi: mapping dei dati delle metriche aziendali e degli attributi ai campi dell'origine dati.
• Logica di calcolo: traslazione di definizioni aziendali in calcoli tecnici.
• Funzionalità tecniche: funzionalità o funzionalità necessarie per supportare i requisiti aziendali.

Suggerimento

Il team di progetto che ha condotto la progettazione aziendale deve anche condurre la progettazione tecnica. Tuttavia, per motivi pratici, diversi individui potrebbero condurre la progettazione tecnica. In questo caso, iniziare la progettazione tecnica esaminando i risultati della progettazione aziendale.

Idealmente, le persone che guidano la progettazione tecnica devono avere una conoscenza approfondita dei risultati e degli utenti aziendali.

Il diagramma seguente illustra come convertire i requisiti aziendali in requisiti tecnici usando una progettazione tecnica.

Il diagramma illustra i passaggi seguenti.

Articolo	Descrizione
	Il team di progetto inizia la progettazione tecnica definendo l'ambito dell'origine dati in base ai risultati della progettazione aziendale. L'ambito dell'origine dati dichiara i dati necessari per compilare la soluzione. Per identificare le origini dati corrette, il team di progetto consulta le PMI aziendali e funzionali.
	Il team del progetto identifica gli stakeholder tecnici o funzionali da coinvolgere in un secondo momento nelle sessioni di progettazione tecnica.
	Il team di progetto prevede sessioni limitate incentrate con stakeholder funzionali per affrontare gli aspetti tecnici della soluzione. La pianificazione implica l'informazione degli stakeholder, l'organizzazione delle riunioni e la preparazione dei risultati finali.
	Il team di progetto ricerca i requisiti tecnici. La ricerca include la definizione di calcoli sul campo e i mapping delle origini dati e anche la gestione dei presupposti di progettazione aziendale con analisi tecnica e documentazione.
	Se necessario, il team di progetto coinvolge gli stakeholder nelle sessioni di progettazione tecnica. Le sessioni si concentrano su un aspetto tecnico specifico della soluzione, ad esempio connessioni di sicurezza o origini dati. In queste sessioni, il team del progetto raccoglie feedback qualitativo da stakeholder e PMI.
	Il team di progetto prepara i risultati usando un piano di soluzione, che presenta agli stakeholder e ai decision maker. Il piano è un'iterazione e un'estensione dei risultati della progettazione aziendale che include la progettazione finale, le stime e altri risultati finali.
	La progettazione tecnica dovrebbe concludersi con una riunione finale con gli stakeholder e i decisori per decidere se procedere o meno. Questa riunione offre un'opportunità finale per valutare la pianificazione della soluzione prima che le risorse si impegnino a sviluppare la soluzione.

Nota

La progettazione tecnica potrebbe rivelare complessità impreviste che potrebbero rendere impossibile la pianificazione della soluzione in base alla disponibilità attuale delle risorse o all'idoneità dell'organizzazione. In questo caso, la soluzione deve essere rivalutata nel successivo periodo di pianificazione tattica. A seconda dell'urgenza delle esigenze dei dati aziendali, un decision maker, come lo sponsor esecutivo, potrebbe comunque voler procedere con un modello di verifica o solo una parte della soluzione pianificata.

La progettazione tecnica si conclude con un piano di soluzione, costituito dai risultati finali seguenti.

• Strumenti e tecnologie: elenco degli strumenti tecnici pertinenti necessari per implementare la soluzione. L'elenco include in genere nuove opzioni di licenza pertinenti (ad esempio capacità infrastruttura o Premium per utente), funzionalità e strumenti.
• Elenco definito delle metriche aziendali: calcoli e mapping delle origini dei campi delle metriche aziendali per tutte le origini dati nell'ambito. Per produrre questo risultato finale, il team di progetto usa l'elenco delle metriche aziendali create nella progettazione aziendale.
• Elenco definito di attributi aziendali: mapping di origini campo degli attributi aziendali per tutte le origini dati nell'ambito. Per produrre questo risultato finale, il team di progetto usa l'elenco degli attributi aziendali creati nella progettazione aziendale.
• Progettazioni riviste: revisioni alla progettazione della soluzione in base a modifiche apportate o presupposti non validi relativi alla progettazione aziendale. I progetti rivisti sono versioni aggiornate dei mock-up, dei prototipi o dei diagrammi wireframe prodotti nella progettazione aziendale. Se non sono necessarie revisioni, comunicare che la progettazione tecnica convalida la progettazione aziendale.
• Stima dello sforzo: stima delle risorse necessarie per sviluppare, supportare e gestire la soluzione. La stima indica alla decisione finale se procedere con l'implementazione della soluzione o meno.

Importante

Assicurarsi che il team del progetto comunichi agli stakeholder eventuali modifiche o individuazioni impreviste dalla progettazione tecnica. Queste sessioni di progettazione tecnica devono comunque coinvolgere gli utenti aziendali pertinenti. Tuttavia, assicurarsi che gli stakeholder non siano inutilmente esposti a informazioni tecniche complesse.

Suggerimento

Poiché gli obiettivi aziendali si evolvono invariabilmente, è previsto che i requisiti cambieranno. Non presupporre che i requisiti per i progetti BI siano fissi. Se si hanno difficoltà a modificare i requisiti, potrebbe essere un'indicazione che il processo di raccolta dei requisiti non è efficace o che i flussi di lavoro di sviluppo non incorporano sufficientemente commenti e suggerimenti regolari.

Elenco di controllo : quando si raccolgono i requisiti, le decisioni chiave e le azioni includono:

• Chiarire chi possiede la pianificazione della soluzione: per ogni soluzione, assicurarsi che i ruoli e le responsabilità siano chiari per il team di progetto.
• Chiarire l'ambito della soluzione: l'ambito della soluzione deve essere già documentato come parte della pianificazione tattica bi. Potrebbe essere necessario dedicare tempo e impegno aggiuntivi per chiarire l'ambito prima di iniziare la pianificazione della soluzione.
• Identificare e informare gli stakeholder: identificare gli stakeholder per i progetti aziendali e i progetti tecnici. Informarli in anticipo sul progetto e spiegare l'ambito, gli obiettivi, gli investimenti in tempo necessari e i risultati finali della progettazione aziendale.
• Pianificare e condurre sessioni di progettazione aziendale: moderare le sessioni di progettazione aziendale per ottenere informazioni dagli stakeholder e dagli utenti aziendali. Richiedere agli utenti di illustrare come usano soluzioni esistenti.
• Documentare metriche e attributi aziendali: usando le soluzioni esistenti e l'input degli stakeholder, creare un elenco di metriche e attributi aziendali. Nelle progettazioni tecniche eseguire il mapping dei campi all'origine dati e descrivere la logica di calcolo per i campi quantitativi.
• Bozza della progettazione della soluzione: creare simulazioni iterative in base all'input degli stakeholder che riflettono visivamente il risultato previsto della soluzione. Assicurarsi che i mock-up rappresentino in modo accurato e rispondano ai requisiti aziendali. Comunicare agli utenti aziendali che i mock-up devono comunque essere convalidati (e possibilmente modificati) durante la progettazione tecnica.
• Creare il piano di soluzione: ricercare i dati di origine e le considerazioni tecniche pertinenti per garantire che la progettazione aziendale sia raggiungibile. Se pertinente, descrivere i rischi principali e le minacce per la progettazione e qualsiasi approccio alternativo. Se necessario, preparare una revisione della progettazione della soluzione e discuterla con gli stakeholder.
• Creare stime di lavoro: come parte del piano finale della soluzione, stimare lo sforzo necessario per creare e supportare la soluzione. Giustificare queste stime con le informazioni raccolte durante le sessioni di progettazione aziendale e progettazione tecnica.
• Decidere se procedere con il piano: per concludere il processo di raccolta dei requisiti, presentare il piano finale agli stakeholder e ai decision maker. Lo scopo di questa riunione è determinare se procedere con lo sviluppo di soluzioni.

Passaggio 2: Pianificare la distribuzione

Quando il team di progetto completa la raccolta dei requisiti, la creazione del piano della soluzione e la ricezione dell'approvazione per continuare, è pronta per pianificare la distribuzione della soluzione.

Le attività di pianificazione della distribuzione variano a seconda della soluzione, del flusso di lavoro di sviluppo e del processo di distribuzione. Un piano di distribuzione riguarda in genere molte attività che coinvolgono la pianificazione e la configurazione di strumenti e processi per la soluzione.

Pianificare l'indirizzo delle aree chiave

Il team di progetto deve pianificare le aree chiave della distribuzione della soluzione. In genere, la pianificazione deve affrontare le aree seguenti.

• Conformità: assicurarsi che tutti i criteri di conformità identificati nella raccolta dei requisiti vengano risolti da azioni specifiche. Assegnare ognuna di queste azioni a persone specifiche e definire chiaramente l'intervallo di tempo di recapito.
• Sicurezza: decidere come verranno gestiti i diversi livelli di accesso alla soluzione e i requisiti delle regole di sicurezza dei dati. Verificare se la sicurezza della soluzione sarà più o meno rigida rispetto al contenuto standard nel tenant.
• Gateway dati: valutare se la soluzione richiede un gateway dati per connettersi alle origini dati. Determinare se sono necessarie impostazioni gateway specifiche o cluster a disponibilità elevata. Pianificare chi sarà in grado di gestire le connessioni gateway tramite i ruoli di sicurezza del gateway e come monitorare i gateway. Per altre informazioni, vedere Effettuare il provisioning dell'accesso al gateway.
• Aree di lavoro: decidere come configurare e usare le aree di lavoro. Determinare se la soluzione richiede strumenti di gestione del ciclo di vita come pipeline di integrazione e distribuzione Git e se richiede la registrazione avanzata con Azure Log Analytics.
• Supporto: stabilire chi è responsabile del supporto e della gestione della soluzione dopo la distribuzione di produzione. Se i singoli responsabili del supporto sono diversi dal team di progetto, coinvolgere questi individui nello sviluppo. Assicurarsi che chiunque supporti la soluzione comprenda la progettazione della soluzione, il problema da risolvere, chi deve usarla e come.
• Formazione utente: prevedere gli sforzi necessari per formare la community degli utenti in modo che possano usare efficacemente la soluzione. Valutare se sono necessarie azioni specifiche di gestione delle modifiche.
• Governance: identificare i potenziali rischi di governance per la soluzione. Prevedere lo sforzo necessario per consentire agli utenti di usare in modo efficace la soluzione, riducendo al contempo qualsiasi rischio di governance, ad esempio usando etichette di riservatezza e criteri.

Eseguire la configurazione iniziale

Il team di progetto deve eseguire la configurazione iniziale per avviare lo sviluppo. Le attività iniziali di configurazione possono includere:

• Strumenti e processi iniziali: eseguire la prima configurazione per tutti i nuovi strumenti e processi necessari per lo sviluppo, il test e la distribuzione.
• Identità e credenziali: creare gruppi di sicurezza e entità servizio che verranno usati per accedere a strumenti e sistemi. Archiviare in modo efficace e sicuro le credenziali.
• Gateway dati: distribuire gateway dati per origini dati locali (gateway in modalità enterprise) o origini dati in una rete privata (rete virtuale o rete virtuale).
• Aree di lavoro e repository: creare e configurare aree di lavoro e repository remoti per la pubblicazione e l'archiviazione del contenuto.

Nota

La pianificazione della distribuzione varia a seconda della soluzione e del flusso di lavoro preferito. Questo articolo descrive solo gli elementi di pianificazione e utilità pratica di alto livello.

Per altre informazioni sulla pianificazione della distribuzione, vedere Pianificare la distribuzione per la migrazione a Power BI.

Elenco di controllo : quando si pianifica la distribuzione della soluzione, le decisioni chiave e le azioni includono:

• Pianificare le aree chiave: pianificare gli strumenti e i processi necessari per sviluppare e distribuire correttamente la soluzione. Affrontare sia le aree tecniche ( ad esempio gateway dati o aree di lavoro) sia l'adozione (ad esempio la formazione e la governance degli utenti).
• Eseguire la configurazione iniziale: stabilire gli strumenti, i processi e le funzionalità necessari per sviluppare e distribuire la soluzione. Documentare la configurazione per aiutare altri utenti che dovranno eseguire una prima configurazione in futuro.
• Testare le connessioni all'origine dati: verificare che i componenti e i processi appropriati siano disponibili per connettersi ai dati corretti per avviare il modello di verifica.

Passaggio 3: Eseguire un modello di verifica

Il team del progetto esegue una verifica del concetto di soluzione (POC) per convalidare i presupposti in sospeso e per dimostrare i vantaggi iniziali per gli utenti aziendali. Un modello di verifica è un'implementazione di progettazione iniziale limitata nell'ambito e nella maturità. Un modello di verifica ben eseguito è particolarmente importante per soluzioni di grandi dimensioni o complesse perché può identificare e risolvere le complessità (o le eccezioni) che non sono state rilevate nella progettazione tecnica.

Durante la preparazione di un modello di verifica è consigliabile prendere in considerazione i fattori seguenti.

• Obiettivi e ambito: descrivere lo scopo del modello di verifica della soluzione e le aree funzionali da affrontare. Ad esempio, il team di progetto potrebbe decidere di limitare il modello di verifica a una singola area funzionale o a un set specifico di requisiti o funzionalità.
• Dati di origine: identificare i dati che verranno usati nel modello di verifica. A seconda della soluzione, il team di progetto potrebbe decidere di usare tipi diversi di dati, ad esempio:
  • Dati di produzione (reali)
  • Dati di esempio
  • Dati sintetici generati che assomigliano ai volumi di dati effettivi e alla complessità osservati negli ambienti di produzione
• Dimostrazione: descrivere come e quando il team di progetto dimostrerà il modello di verifica per gli stakeholder e gli utenti. Le dimostrazioni possono essere fornite durante gli aggiornamenti regolari o quando il modello di verifica soddisfa criteri funzionali specifici.
• Ambiente: descrivere dove verrà compilato il modello di verifica da parte del team di progetto. Un buon approccio consiste nell'usare un ambiente sandbox distinto per il modello di verifica e distribuirlo in un ambiente di sviluppo quando è pronto. Un ambiente sandbox ha criteri più flessibili e contenuti fluidi e si concentra sulla produzione di risultati rapidi. Al contrario, un ambiente di sviluppo segue processi più strutturati che consentono la collaborazione e si concentra sul completamento di attività specifiche.
• Criteri di esito positivo: definire la soglia per quando il modello di verifica ha esito positivo e passare all'iterazione successiva e immettere lo sviluppo formale. Prima di avviare il modello di verifica, il team di progetto deve identificare criteri chiari per quando il modello di verifica ha esito positivo. Impostando questi criteri in anticipo, il team di progetto definisce quando termina lo sviluppo del modello di verifica e quando iniziano i cicli di sviluppo e convalida iterativi. A seconda degli obiettivi del modello di verifica, il team di progetto potrebbe impostare criteri di successo diversi, ad esempio:
  • Approvazione del modello di verifica da parte degli stakeholder
  • Convalida delle funzionalità o delle funzionalità
  • Revisione favorevole del modello di verifica da parte dei peer dopo un tempo di sviluppo fisso
• Errore: assicurarsi che il team di progetto possa identificare l'errore del modello di verifica. L'identificazione anticipata dell'errore consentirà di analizzare le cause radice. Può anche aiutare a evitare ulteriori investimenti in una soluzione che non funzionerà come previsto quando viene distribuita nell'ambiente di produzione.

Attenzione

Quando il team di progetto esegue il modello di verifica, devono rimanere avvisi per presupposti e limitazioni. Ad esempio, il team di progetto non può testare facilmente le prestazioni e la qualità dei dati della soluzione usando un piccolo set di dati. Assicurarsi inoltre che l'ambito e lo scopo del modello di verifica siano chiari agli utenti aziendali. Assicurarsi di comunicare che il modello di verifica è una prima iterazione e sottolineare che non è una soluzione di produzione.

Nota

Per altre informazioni, vedere Eseguire il modello di verifica per eseguire la migrazione a Power BI.

Elenco di controllo : quando si crea un modello di verifica, le decisioni chiave e le azioni includono:

• Definire gli obiettivi: assicurarsi che gli obiettivi del modello di verifica siano chiari a tutte le persone coinvolte.
• Definire l'ambito del modello di verifica: assicurarsi che la creazione del modello di verifica non richiederà troppo lavoro di sviluppo, pur offrendo valore e dimostrando la progettazione della soluzione.Define the scope of the POC: Ensure that creating the POC won't take to to much development effort, while still delivering value and demonstrating the solution design.
• Decidere quali dati verranno usati: identificare i dati di origine che verranno usati per prendere il modello di verifica, giustificare la decisione e delineare i potenziali rischi e limitazioni.
• Decidere quando e come illustrare il modello di verifica: pianificare lo stato di avanzamento presentando il modello di verifica ai decision maker e agli utenti aziendali.
• Chiarire quando termina il modello di verifica: assicurarsi che il team del progetto decida una conclusione chiara per il modello di verifica e descrivere come verrà promossa ai cicli di sviluppo formali.

Passaggio 4: Creare e convalidare il contenuto

Quando il modello di verifica ha esito positivo, il team del progetto passa dal modello di verifica alla creazione e alla convalida del contenuto. Il team di progetto può sviluppare la soluzione BI con cicli di sviluppo e convalida iterativi. Questi cicli sono costituiti da versioni iterative, in cui il team di progetto crea contenuto in un ambiente di sviluppo e lo rilascia in un ambiente di test. Durante lo sviluppo, il team di progetto esegue gradualmente l'onboarding della community degli utenti in un processo pilota in versioni iniziali (beta) della soluzione nell'ambiente di test.

Suggerimento

Il recapito iterativo incoraggia la convalida anticipata e il feedback che possono attenuare le richieste di modifica, promuovere l'adozione della soluzione e realizzare vantaggi prima del rilascio di produzione.

I cicli di sviluppo e convalida iterativi procedono fino a quando il team di progetto non arriva a una conclusione predefinita. In genere, lo sviluppo si conclude quando non sono disponibili altre funzionalità da implementare o inviare commenti e suggerimenti degli utenti. Al termine dei cicli di sviluppo e convalida, il team di progetto distribuisce il contenuto in un ambiente di produzione con la versione di produzione finale.

Il diagramma seguente illustra come il team di progetto può distribuire in modo iterativo soluzioni BI con cicli di sviluppo e convalida.

Il diagramma illustra i passaggi seguenti.

Articolo	Descrizione
	Il team del progetto comunica ogni versione alla community degli utenti, descrivendo le modifiche e le nuove funzionalità. Idealmente, la comunicazione include una dimostrazione della soluzione e Q&A, in modo che gli utenti comprendano le novità della versione e possano fornire feedback verbale.
	Durante la convalida, gli utenti forniscono commenti e suggerimenti tramite uno strumento centrale o un modulo. Il team del progetto deve esaminare regolarmente il feedback per risolvere i problemi, accettare o rifiutare le richieste e informare le fasi di sviluppo future.
	Il team del progetto monitora l'utilizzo della soluzione per verificare che gli utenti lo eseseguono il test. Se non è presente alcun utilizzo, il team del progetto deve interagire con la community degli utenti per comprendere i motivi per cui. Un basso utilizzo può indicare che il team di progetto deve eseguire ulteriori azioni di abilitazione e gestione delle modifiche.
	Il team del progetto risponde tempestivamente al feedback degli utenti. Se il team del progetto richiede troppo tempo per rispondere ai commenti e suggerimenti, gli utenti potrebbero perdere rapidamente la motivazione a fornirla.
	Il team di progetto incorpora il feedback accettato nella pianificazione della soluzione. Se necessario, esaminano le priorità di pianificazione per chiarire e delegare le attività prima dell'inizio della fase di sviluppo successiva.
	Il team di progetto continua lo sviluppo della soluzione per la versione successiva.
	Il team di progetto esegue l'iterazione di tutti i passaggi fino a raggiungere una conclusione predefinita e la soluzione è pronta per la distribuzione di produzione.

Le sezioni seguenti descrivono le considerazioni chiave per l'uso di cicli di sviluppo e convalida iterativi per offrire soluzioni BI.

Creare contenuto

Il team di progetto sviluppa la soluzione seguendo il normale flusso di lavoro di sviluppo. Tuttavia, devono prendere in considerazione i punti seguenti durante la creazione di contenuto.

• Durante ogni ciclo di sviluppo, aggiornare la documentazione per descrivere la soluzione.
• Concludere ogni ciclo di sviluppo con un annuncio alla community degli utenti. Gli annunci devono essere pubblicati nel portale centralizzato e devono fornire brevi descrizioni delle modifiche e delle nuove funzionalità in ogni versione.
• Con ogni versione, è consigliabile organizzare sessioni per illustrare le modifiche e le nuove funzionalità della community degli utenti e rispondere a eventuali domande verbali.
• Definire quando si concluderanno lo sviluppo iterativo e i cicli di convalida. Assicurarsi che sia presente un processo chiaro per distribuire la soluzione nell'ambiente di produzione, inclusa una transizione alle attività di supporto e adozione.

Convalidare il contenuto

Ogni ciclo di sviluppo iterativo deve concludersi con la convalida del contenuto. Per le soluzioni BI, esistono in genere due tipi di convalida.

• Convalida dello sviluppatore: il test della soluzione viene eseguito dai creatori di contenuti e dai peer. Lo scopo della convalida dello sviluppatore è identificare e risolvere tutti i problemi critici e visibili prima che la soluzione venga resa disponibile agli utenti aziendali. I problemi possono riguardare la correttezza, la funzionalità o l'esperienza utente dei dati. Idealmente, il contenuto viene convalidato da un creatore di contenuti che non lo ha sviluppato.
• Convalida utente: il test della soluzione viene eseguito dalla community degli utenti. Lo scopo della convalida dell'utente è fornire commenti e suggerimenti per iterazioni successive e identificare i problemi che non sono stati rilevati dagli sviluppatori. I periodi di convalida dell'utente formali vengono in genere definiti test di accettazione utente (UAT).

Importante

Assicurarsi che tutti i problemi di qualità dei dati vengano risolti durante la convalida dello sviluppatore (prima dell'UAT). Questi problemi possono erosi rapidamente la fiducia nella soluzione e possono danneggiare l'adozione a lungo termine.

Suggerimento

Quando si esegue la convalida dell'utente, prendere in considerazione chiamate occasionali e brevi con utenti chiave. Osservarli quando usano la soluzione. Prendere nota di ciò che trovano difficile da usare o quali parti della soluzione non funzionano come previsto. Questo approccio può essere un modo efficace per raccogliere feedback.

Tenere presenti le considerazioni seguenti quando il team di progetto convalida il contenuto.

• Incoraggiare i commenti e suggerimenti degli utenti: con ogni versione, richiedere agli utenti commenti e suggerimenti e dimostrare come possono farlo in modo efficace. Prendere in considerazione la possibilità di condividere regolarmente esempi di feedback e richieste che hanno portato a modifiche recenti e nuove funzionalità. Condividendo esempi, si dimostra che il feedback viene riconosciuto e apprezzato.
• Isolare le richieste più grandi: alcuni elementi di feedback richiedono un maggiore impegno da affrontare. Assicurarsi che il team di progetto possa identificare questi elementi e discutere se verranno implementati o meno. Prendere in considerazione la documentazione di richieste più grandi da discutere nelle sessioni di pianificazione tattica successive.
• Iniziare le attività di gestione delle modifiche: formare gli utenti a usare la soluzione. Assicurarsi di dedicare ulteriore impegno a nuovi processi, nuovi dati e diversi modi di lavorare. Investire nella gestione dei cambiamenti ha un ritorno positivo sull'adozione di soluzioni a lungo termine.

Quando la soluzione raggiunge un livello predefinito di completezza e maturità, il team di progetto è pronto per distribuirlo nell'ambiente di produzione. Dopo la distribuzione, il team di progetto passa dal recapito iterativo al supporto e al monitoraggio della soluzione di produzione.

Nota

Lo sviluppo e il test variano a seconda della soluzione e del flusso di lavoro preferito.

Questo articolo descrive solo elementi di pianificazione e utilità pratica di alto livello. Per altre informazioni sui cicli di sviluppo e test iterativi, vedere Creare contenuto per eseguire la migrazione a Power BI.

Elenco di controllo : quando si crea e si convalida il contenuto, le decisioni chiave e le azioni includono:

• Usare un processo iterativo per pianificare e assegnare attività: pianificare e assegnare attività per ogni versione della soluzione. Assicurarsi che il processo per pianificare e assegnare attività sia flessibile e incorporare il feedback degli utenti.
• Configurare la gestione del ciclo di vita del contenuto: usare strumenti e processi per semplificare e automatizzare la distribuzione e la gestione delle modifiche delle soluzioni.
• Creare uno strumento per centralizzare il feedback: automatizzare la raccolta di feedback usando una soluzione semplice per l'utente e gli utenti. Creare un modulo semplice per garantire che il feedback sia conciso ma interattivo.
• Pianificare una riunione per esaminare i commenti e suggerimenti: incontrarsi per esaminare brevemente ogni elemento di feedback nuovo o in sospeso. Decidere se implementare o meno il feedback, chi sarà responsabile dell'implementazione e quali azioni intraprendere per chiudere l'elemento di feedback.
• Decidere quando termina il recapito iterativo: descrivere le condizioni per quando si concluderanno i cicli di recapito iterativi e quando si rilascerà il contenuto nell'ambiente di produzione.

Passaggio 5: Distribuire, supportare e monitorare

Quando si è pronti, il team di progetto distribuisce la soluzione convalidata nell'ambiente di produzione. Il team del progetto deve eseguire azioni chiave di adozione e supporto per garantire che la distribuzione sia riuscita.

Per garantire una distribuzione corretta, eseguire le attività di supporto e adozione seguenti.

• Comunicare la versione finale: lo sponsor esecutivo, un manager o un'altra persona con autorità e credibilità sufficienti dovrebbe annunciare il rilascio alla community degli utenti. La comunicazione deve essere chiara, concisa e include collegamenti alle soluzioni e ai canali di supporto pertinenti.
• Eseguire la formazione per i consumer di contenuti: la formazione deve essere disponibile per i consumer di contenuti durante le prime settimane dopo il rilascio in produzione. Il training deve concentrarsi su come chiarire l'ambito della soluzione, rispondere alle domande degli utenti e spiegare come usare la soluzione.
• Inviare commenti e suggerimenti e richieste: è consigliabile fornire agli utenti un canale per inviare commenti e suggerimenti e richieste al team di progetto. Assicurarsi che vengano discussi commenti e richieste ragionevoli e, se appropriato, implementati durante il periodo di supporto post-distribuzione. Agire su feedback e richieste dopo il rilascio di produzione è importante. Indica una soluzione agile che risponde alle mutevoli esigenze aziendali.
• Pianificare la connessione con la community degli utenti: anche dopo il termine del periodo di supporto post-distribuzione, assicurarsi che i proprietari delle soluzioni si incontrino regolarmente con la community degli utenti. Queste riunioni sono preziose fonti di feedback per la revisione della strategia di business intelligence. Inoltre, consentono di supportare l'adozione delle soluzioni abilitando gli utenti.
• Azioni di consegna: i membri del team di progetto potrebbero non essere responsabili della gestione della soluzione. In questo caso, il team deve identificare chi è responsabile ed eseguire un passaggio di consegna. Il passaggio dovrebbe avvenire subito dopo il rilascio in produzione e deve gestire sia la soluzione che la community degli utenti.

Attenzione

La mancata esecuzione di un handover efficace può causare problemi evitabili con il supporto e l'adozione delle soluzioni durante il ciclo di vita.

Dopo la distribuzione, il team di progetto deve pianificare di passare alla soluzione successiva nel backlog della soluzione con priorità. Assicurarsi di raccogliere eventuali nuovi commenti e richieste e apportare revisioni alla pianificazione tattica, incluso il backlog della soluzione, se necessario.

Elenco di controllo : quando si considera la distribuzione della soluzione, le decisioni chiave e le azioni includono:

• Creare un piano di comunicazione: pianificare come comunicare il rilascio, il training e altre azioni di supporto o adozione di soluzioni. Assicurarsi che eventuali interruzioni o problemi vengano comunicati e risolti tempestivamente nel periodo di supporto post-distribuzione.
• Seguire questa procedura con un piano di formazione: formare gli utenti per usare la soluzione. Assicurarsi che il training includa sessioni di training live e registrate per diverse settimane dopo il rilascio.
• Eseguire attività di consegna: se necessario, preparare un passaggio dal team di sviluppo al team di supporto.
• Condurre gli orari di ufficio della soluzione: dopo il periodo di supporto post-distribuzione, prendere in considerazione la possibilità di tenere sessioni regolari dell'orario di ufficio per rispondere alle domande e raccogliere feedback dagli utenti.
• Configurare un processo di miglioramento continuo: pianificare un controllo mensile della soluzione per esaminare potenziali modifiche o miglioramenti nel tempo. Centralizzare il feedback degli utenti e rivedere periodicamente i commenti e suggerimenti tra i controlli.

Contenuto correlato

Per altre considerazioni, azioni, criteri decisionali e consigli utili per prendere decisioni di implementazione di Power BI, vedere Pianificazione dell'implementazione di Power BI.