Domande
Quando si è un consulente, porre domande è il metodo migliore per conoscere i clienti e le esigenze degli utenti. Può porre tutte le domande che desidera per capire le necessità degli utenti e come creare al meglio il sistema di cui hanno bisogno.
Di seguito sono riportati degli scenari che consentono di determinare come utilizzare le domande per condurre una valutazione approfondita delle esigenze:
Si intende implementare Microsoft Dynamics 365 Sales, ma nessun venditore è coinvolto nel processo di progettazione. In questo scenario, occorre capire come creare un valido sistema per i venditori.
Si sta implementando Microsoft Dynamics 365 Finance e solo persone del reparto IT sono presenti nel gruppo di progetto. In questa situazione, è necessario anche garantire che il sistema segua gli standard di contabilità.
Si sta implementando Microsoft Dynamics 365 Customer Insights - Journeys e nessuno nel gruppo di progetto conosce le normative locali e le regole di privacy. In questo scenario, occorre determinare come creare un valido sistema per gli utenti che non dispongono di informazioni su queste normative e regole.
La partecipazione degli utenti nel processo di progettazione del sistema è fondamentale perché sono loro i destinatari del sistema. Se non sono disponibili utenti del sistema attuale, e nessuna delle persone coinvolte utilizzerà il nuovo sistema, la sfida è determinare come creare un valido sistema per gli utenti. Pertanto, sarà necessario avere gli utenti nel team di progetto o almeno consultarsi con gli utenti prima di progettare la soluzione Dynamics 365.
Dopo aver aggiunto gli utenti nel gruppo di progetto, è possibile iniziare a porre loro le domande. È solo tramite le domande che si può scoprire come progettare il nuovo sistema.
Alla maggior parte dei clienti piace parlare di sé e della propria società e, se si intende creare un valido sistema per una società, è necessario prima conoscerla. Un ottimo modo per conoscere una società e i processi che adotta è tramite le domande. Si inizia con le domande a risposta aperta, quelle in cui il cliente può parlare apertamente di sé e delle proprie esigenze e dare quante più informazioni possibili.
Esempi di domande aperte sono quelle che richiedono:
Informazioni sulla società.
Informazioni sul servizio offerto.
Informazioni sui dipendenti che utilizzeranno il sistema.
Informazioni sui clienti.
Informazioni su come vengono attualmente completate le attività.
Informazioni sui processi che il sistema deve supportare.
Questi tipi di domande forniscono informazioni dettagliate sulla società e un buon punto di partenza per comprendere il cliente e gli utenti. Con una base su cui lavorare, è quindi possibile porre domande di completamento più approfondite, come ad esempio:
Qual è attualmente il problema più importante in relazione ai processi?
Qual è il livello tecnologico dei dipendenti?
Qual è il livello tecnologico dei clienti?
Per cosa deve servire il nuovo sistema?
Queste domande consentono di ottenere maggiori informazioni sulle esigenze dei clienti e anche di determinare la complessità della soluzione. È necessario progettare una soluzione che si adatti al livello di complessità degli utenti per i quali è destinata. Ad esempio, se gli utenti sanno appena utilizzare un portatile e la soluzione progettata è eccessivamente complessa, molto probabilmente non ne saranno soddisfatti. Se invece si progetta una soluzione semplice, ma gli utenti e i clienti hanno esigenze complesse, non la riterranno vantaggiosa per loro.
È importante che le domande si concentrino sulle esigenze aziendali del cliente piuttosto che sulle informazioni personali. Se la domanda non è rilevante ai fini della progettazione del sistema, è probabile che non sia una buona domanda da porre. Richiedere l'età dei dipendenti non è rilevante per la progettazione, ma è importante invece chiedere informazioni sul livello tecnico. Ad esempio, se i dipendenti non hanno competenze tecniche o quasi, è necessario stimare più tempo per la formazione. Al contrario, se i dipendenti hanno un alto livello di competenze tecniche, è possibile progettare una soluzione più complessa.
Altre domande che si possono porre agli utenti sono:
Quanti sono gli utenti disponibili?
Quale funzionalità potrebbe semplificare il processo?
Qual è la funzionalità ottimale?
Quali sono le attività di base che deve svolgere il sistema?
Queste domande invitano gli utenti a esprimere le loro esigenze mentre aiutano a determinare le attività di base che è necessario fornire. Inoltre, si determina cosa li renderebbe soddisfatti. La capacità di implementare la "funzionalità della soddisfazione" sarà significativa per il cliente.
Oggi gli utenti conoscono solo la soluzione di cui già dispongono. Sapendo ciò di cui il cliente dispone attualmente e ciò che funziona o non funziona, si impara molto sugli utenti e sulle loro esigenze.
Le seguenti domande consentono di acquisire maggiori informazioni sulla soluzione di cui il cliente attualmente dispone:
Cosa funziona attualmente?
Qual è l'aspetto che si ritiene valido nel sistema attuale?
Qual è la caratteristica peggiore del sistema attuale?
Qual è la caratteristica migliore del sistema attuale?
Nel sistema attuale, qual è l'elemento che richiede più tempo?
Qual è un componente utile e uno inutile del sistema attuale?
Come garantire che gli altri utenti siano soddisfatti del nuovo sistema?
Cosa spingerà gli altri utenti a voler utilizzare il nuovo sistema?
Gli utenti sanno cosa hanno e cosa vogliono. Pertanto, è necessario porre domande sul sistema attuale per poter progettare una soluzione che faccia ciò di cui hanno bisogno e altro ancora. Se si implementa un sistema peggiore di quello che hanno attualmente, il cliente non ne sarà soddisfatto. Allo stesso modo, il cliente non sarà felice se si crea un sistema che costa più del previsto e offre funzionalità non necessarie. È necessario determinare cosa soddisfa gli utenti e come bilanciare il sistema con le esigenze.
Inoltre, occorre individuare il tipo di terminologia utilizzata dai clienti. Ad esempio, se utilizzano la stessa terminologia di Microsoft, probabilmente sanno cosa è un ordine di lavoro in Dynamics 365 Field Service o Dynamics 365 Supply Chain Management. Se utilizzano una terminologia diversa, è necessario capire come si devono denominare i vari elementi per personalizzare il sistema in base alle loro esigenze. Il modo in cui si denominano le colonne e il numero di personalizzazioni apportate al sistema influirà sugli utenti e sulla progettazione.
Occorre evitare di porre domande eccessivamente specifiche sul nuovo sistema. È responsabilità del consulente trovare queste informazioni.
Esempi di domande da evitare sono:
Quale parte di Dynamics 365 si deve utilizzare?
È necessario Dynamics 365 Customer Service o Dynamics 365 Field Service?
È più adatto Dynamics 365 Business Central o Dynamics 365 Finance?
Cos'è un ordine di lavoro e come viene utilizzato?
Dopo che i clienti hanno descritto le esigenze, è il momento di esaminare le informazioni che hanno condiviso. Durante le riunioni con i clienti, è sempre opportuno ripetere con parole proprie le informazioni che hanno fornito. Questo riepilogo consente di verificare di aver compreso ciò che hanno detto i clienti ed evita problemi di comunicazione. Intraprendere questo passaggio aiuterà a chiarire i problemi immediatamente piuttosto che al termine della creazione del sistema.
L'obiettivo è sapere di cosa hanno bisogno gli utenti e come progettare un sistema che li soddisfi. Si può creare un sistema straordinario, ma se non è ciò di cui gli utenti hanno bisogno, non sarà gradito.