Identificazione dei componenti della soluzione
Durante il processo di individuazione, alcune idee sulla soluzione dovrebbero iniziare a chiarirsi. Questa unità spiega come identificare i componenti della soluzione che potrebbero andare a formare la soluzione proposta al cliente. Essendo ancora nella fase di prevendita del progetto, l'obiettivo è descrivere al cliente l'aspetto della soluzione proposta una volta creata e, quindi, spiegare in che modo raggiungerà gli obiettivi stabiliti. È anche il momento adatto per iniziare a pensare a una roadmap del prodotto e al modo in cui i componenti verranno implementati per mostrare un valore immediato rispetto alle iterazioni.
Mapping delle esigenze alle funzionalità
Gli incontri con il cliente dovrebbero aver chiarito le sue esigenze chiave. Per identificare i componenti, è necessario riflettere su queste esigenze nel loro complesso e associarle alle app Dynamics 365 esistenti, a un'app Microsoft Power Platform o, in alcuni casi, a uno sviluppo personalizzato. Per i progetti più grandi potrebbe essere necessario ricorrere a più app o spaziare in tutte e tre le categorie.
Non tutti i progetti iniziano da zero. Molte aziende usano già dei sistemi e stanno semplicemente migliorando o integrando gli strumenti esistenti. Ad esempio, un cliente con Dynamics 365 Customer Service potrebbe voler aggiungere alcune funzionalità multicanale per soddisfare un'esigenza specifica.
Alcune esigenze potrebbero richiedere il mapping a più app. Ad esempio, il mapping delle vendite a Dynamics 365 Sales potrebbe migliorare l'app Dynamics 365 Finance esistente grazie al rilevamento delle commissioni e ai pagamenti.
Prestare attenzione al mapping e non proporre al cliente di sostituire o aggiungere un'altra app con le stesse funzionalità di una già in uso. È comprensibile se l'intento è aiutare il cliente, ma, se c'è già un sistema ERP non Microsoft e si propone di aggiungere Dynamics 365 Finance perché semplifica l'implementazione della soluzione, la proposta non sarà accolta con favore.
Per i componenti chiave della soluzione, si consiglia di spiegare con chiarezza dove verranno usate le funzionalità preconfigurate e dove sarà necessario personalizzare alcuni aspetti. Ad esempio, è opportuno sottolineare che verranno usate funzionalità di vendita standard per tutto, ad eccezione di uno strumento di configurazione prodotto. A questo punto, deve essere presentata la soluzione proposta, ad esempio una Power App personalizzata incorporata nell'app o magari una soluzione di configurazione di terze parti.
Uso delle immagini per spiegare le idee complesse
È possibile creare un diagramma/immagine a pagina singola che descriva la soluzione in modo più semplice. Includere tutte le persone che interagiscono con il sistema per chiarire in che modo ognuna di loro userà la soluzione. Evitare di aggiungere troppi dettagli per non rendere troppo complesso il diagramma/immagine e per non elaborare eccessivamente le idee. Mantenendo l'illustrazione concisa e nitida, potrà diventare il punto di riferimento per le discussioni future e un fattore di differenziazione rispetto alla concorrenza. Nei punti in cui sono necessari maggiori dettagli è possibile creare diagrammi correlati dedicati a determinate aree.
Modellazione dei dati
La modellazione dei dati formale fa parte della progettazione della soluzione e di solito avviene dopo la stipula di un contratto. Tuttavia, durante la fase di prevendita, la concettualizzazione generale della modellazione dei dati viene eseguita costantemente per identificare i gruppi di dati più ampi e per decidere dove collocarli. Se viene eseguito un modello di verifica, questa attività viene spesso impiegata come prototipo di ciò che viene mostrato al cliente. Le informazioni dettagliate del modello di dati vengono trasferite anche nel processo di progettazione per avviare rapidamente il ragionamento sulla modellazione dei dati. Potrebbe essere utile avere un modello di dati di riepilogo e uno dettagliato da condividere. Il modello dettagliato verrà usato da chi progetta e realizza il sistema. Il modello di riepilogo viene condiviso con gli stakeholder che hanno bisogno di una panoramica complessiva della soluzione, senza dettagli specifici.
Modellazione dei processi
La fase di individuazione dovrebbe aver chiarito anche quali siano i processi chiave del cliente. Quando si propone una soluzione, è essenziale riuscire a comunicare in che modo la soluzione proposta è in grado di allinearsi ai processi di business chiave del cliente.
In alcuni casi, il processo proposto potrebbe essere simile a quello in uso, ma nella maggior parte dei casi sono diversi. Dopo aver identificato i componenti della soluzione, è importante evidenziare le differenze chiave e il modo in cui le modifiche ai processi proposte permettono di raggiungere gli obiettivi stabiliti, ad esempio velocizzare del 20% la risoluzione dei casi, fornendo allo stesso tempo più informazioni ai clienti.
Esperienza utente
I clienti si concentreranno sempre sull'esperienza utente. Durante l'individuazione dovrebbero essere emersi alcuni dettagli, ad esempio se gli utenti lavorano sempre da remoto, solo a volte o mai, oppure altre esigenze specifiche relative all'esperienza utente. Quando si identificano i componenti della soluzione proposta, è importante eseguire il mapping di queste esigenze. Se opportuno, questi componenti dovrebbero essere mostrati con un modello di verifica o un wireframe che illustri la soluzione proposta.
I wireframe potrebbero includere i seguenti elementi:
Moduli principali
Dashboard
Esperienza per dispositivi mobili
Visualizzazioni (ad esempio, Power BI)
L'immagine seguente mostra un esempio di wireframe e il modulo effettivo creato in base al wireframe.
Integrazioni
La maggior parte delle soluzioni non è isolata e si avvale di integrazioni interne o esterne. Nell'ambito dell'identificazione dei componenti della soluzione, è opportuno evidenziare come verranno gestite queste integrazioni. Questo processo potrebbe includere la definizione degli strumenti o dei servizi usati per completare le integrazioni. In una soluzione multisistema è necessario definire confini chiari tra un sistema e l'altro. Questi confini diventano "contratti" tra i responsabili della creazione e della manutenzione. Occorre studiare le attività all'interno di questi confini per cercare di definire chiaramente chi è responsabile della creazione delle interfacce e chi le userà. Questo chiarimento è particolarmente importante quando sono coinvolti fornitori di terze parti o team di sviluppo interno.
Opzioni di distribuzione
Microsoft fornisce un modello basato su sottoscrizione di Microsoft Dynamics 365. Con questa opzione, è possibile accedere a Dynamics 365 dal cloud senza dover investire ulteriormente in licenze hardware e software per la rete IT. Non è richiesta alcuna distribuzione locale dell'applicazione e gli utenti possono accedere a Dynamics 365 da più browser. Questo accesso può essere di importanza fondamentale per il personale remoto o fuori sede che ha bisogno di un facile accesso.
Tuttavia, Dynamics 365 Finance e Dynamics 365 Supply Chain Management (precedentemente noto come Dynamics 365 Finance and Operations) possono essere distribuiti in locale, il che consente a un'organizzazione di distribuire le applicazioni localmente.
Per le seguenti applicazioni Dynamics 365, la distribuzione deve essere eseguita con Lifecycle Services:
Dynamics 365 Finance
Dynamics 365 Supply Chain Management
Dynamics 365 Commerce
Per altre applicazioni aziendali Dynamics 365, come quelle nel seguente elenco, le distribuzioni principali vengono eseguite online tramite un set di ambienti di sviluppo-test-produzione standard:
Dynamics 365 Sales
Dynamics 365 Customer Service
Dynamics 365 Customer Insights - Journeys
Dynamics 365 Field Service
È anche possibile creare un ambiente di valutazione dove eseguire test pratici, che consente di rendere operativo il sistema in pochi giorni anziché in settimane o mesi. Non c'è più bisogno della manutenzione continua dei server, né delle licenze a pagamento. Inoltre, è possibile acquistare le licenze utente direttamente online senza passare da un fornitore e si possono aggiungere altri utenti online quando serve e in base alle esigenze di crescita dell'azienda.
Le applicazioni aziendali Dynamics 365 offrono più tipi di ambienti. Il tipo di ambiente ne definisce lo scopo e le caratteristiche:
Valutazione: gli ambienti di valutazione supportano le esigenze di test a breve termine e vengono ripuliti automaticamente dopo poco tempo.
Sandbox: si tratta ambienti non di produzione che, se associati a un'istanza di database di Microsoft Dataverse, offrono funzionalità come il ripristino.
Produzione: ambienti usati per il normale lavoro di un'organizzazione. Possono essere creati e di proprietà di un amministratore o di chiunque disponga della licenza per Power Apps.
Predefinito: un ambiente di produzione non personalizzato. Ogni tenant ha un ambiente predefinito che viene creato automaticamente.
Sviluppatore: gli ambienti per sviluppatori vengono creati da utenti con una licenza per il piano Community. Possono essere usati solo dal proprietario. In questi ambienti, la condivisione con altri utenti non è consentita.
Microsoft Dynamics Lifecycle Services
Microsoft Dynamics Lifecycle Services consente di gestire il ciclo di vita dell'applicazione delle implementazioni Microsoft Dynamics 365 Finance e Microsoft Dynamics 365 Supply Chain Management. Lifecycle Services è un portale di collaborazione basato su Microsoft Azure che fornisce un ambiente e un set di servizi regolarmente aggiornati. Il portale fornisce un'area di lavoro collaborativa che clienti e partner possono usare per gestire i progetti Finance e Supply Chain Management. Lifecycle Services supporta l'utente dalla prevendita alla fase di implementazione fino all'ambiente di produzione, sul cloud o in locale. Grazie agli elenchi di controllo e agli strumenti, Lifecycle Services contribuisce alla gestione del progetto, fornendo anche metodologie predefinite per facilitare l'implementazione.
Lifecycle Services offre livelli più alti di prevedibilità, collaborazione e procedure strutturali per l'amministrazione della gestione delle applicazioni. L'obiettivo di Lifecycle Services è ottenere implementazioni prevedibili, ripetibili e di alta qualità semplificando e standardizzando il processo di implementazione.
Passaggi successivi
L'identificazione dei componenti chiave della soluzione consente di definire i passaggi successivi, che cambiano a seconda del contesto, ad esempio se si hanno soluzioni pronte per la demo da adattare al cliente oppure se si sta creando un nuovo modello di verifica/prototipo.
L'obiettivo di questo processo non è creare un progetto dettagliato della soluzione completa. Questa è ancora la fase di prevendita, i cui obiettivi sono comunicare al cliente in che modo la proposta soddisfa le sue esigenze e arrivare a definire con sufficiente precisione la soluzione. Con queste informazioni a disposizione, è possibile passare alla definizione dei prezzi per arrivare infine alla firma del contratto e alla creazione della soluzione.
Esercizio - Identificazione degli usi comuni tra i team della banca Woodgrove
Esaminare il profilo cliente della banca Woodgrove, in particolare i team a contatto con i clienti descritti in precedenza. Identificare i temi comuni nei team. Determinare se i team si sovrappongono nelle funzionalità necessarie. Valutare se un singolo team è talmente diverso dagli altri da giustificare una soluzione separata.