Domande pertinenti

Completato

I consulenti spesso fanno affidamento su informazioni parziali quando creano una soluzione Dynamics 365 perché il cliente ha risposto solo a ciò che gli veniva chiesto. Porre domande pertinenti è essenziale per assicurarsi di avere un quadro esauriente e offrire una soluzione quanto più possibile completa.

I clienti non forniscono di proposito informazioni errate o incomplete. È invece possibile che ci si sia imbattuti in alcuni ostacoli durante il tentativo di ottenere informazioni da loro, come ad esempio:

  • Un cliente non ha tempo per fornire risposte dettagliate.

  • Si ottengono solo risposte semplici.

  • Non si ha accesso oppure si ha un accesso limitato al cliente effettivo.

  • I requisiti o le specifiche ricevuti sono chiaramente incompleti quando invece avrebbero dovuto essere esaustivi.

  • Si stanno ricevendo informazioni contrastanti.

  • Non vengono comunicati gli ostacoli incontrati durante il percorso.

  • I dipendenti sono inesperti e non sanno come funzionano i processi.

Accesso al cliente

A seconda del ruolo ricoperto nel team di progetto e di come il team interagisce con il cliente, si potrebbe avere o meno accesso diretto al cliente. Indipendentemente da ciò, si ha comunque bisogno di informazioni adeguate per portare a termine il lavoro assegnato. Svolgere un lavoro senza disporre delle necessarie informazioni perché non si riesce a ottenere risposte alle proprie domande non è in alcun caso accettabile. Se non si riesce a ottenere accesso diretto, preparare le domande per qualcuno che ha accesso e può far presente l'esigenza di ottenere risposte precise. Porre domande pertinenti per contribuire a perfezionare la soluzione è un buon modo per dimostrare che sarebbe opportuno avere un accesso più diretto al cliente.

Domande aperte

Se ci si rende conto di ricevere risposte brevi alle domande presentate, probabilmente non si stanno ponendo domande aperte. Le persone che hanno fretta o non sono interessate a intrattenere una conversazione di solito forniranno risposte brevi e non si soffermeranno su dettagli che potrebbero rivelarsi utili. Idealmente, iniziare con una domanda migliore potrebbe essere di aiuto. Ad esempio, è possibile che la domanda sia stata: "Le richieste di supporto scadute sono sottoposte a escalation?" Una risposta facile a questa domanda è "Sì". Un'opzione migliore sarebbe chiedere: "Potrebbe aiutarmi a capire gli scenari in cui le richieste di supporto vengono sottoposte a escalation?". Questa domanda richiede di fatto una risposta più dettagliata e favorisce una comprensione più completa.

Se si riceve una risposta breve, è sempre possibile aggiungere una domanda di follow-up per recuperare. Ad esempio, si potrebbe chiedere: "Cosa succede quando le richieste di supporto vengono sottoposte a escalation?". A volte, le risposte sì e no sono utili. Tuttavia, in genere hanno solo la funzione di indirizzare l'indagine o di confermare a chi pone la domanda che la situazione è stata compresa correttamente. Un buon uso delle domande a risposta chiusa è ribadire la propria comprensione e chiedere conferma, ad esempio "Quindi i casi vengono sottoposti a escalation una volta scaduti oppure su richiesta, ho capito bene?"

Come presentare una domanda

È possibile adottare vari approcci quando si pongono domande per ottenere informazioni. L'approccio può influenzare la qualità e l'utilità della risposta che si ottiene. Gli esempi seguenti illustrano alcuni approcci e i vantaggi di ciascuno di essi:

  • Interazione verbale: questo approccio è vantaggioso perché consente domande e risposte interattive. Quando si intraprende questo tipo di interazione in una riunione online, è possibile usare l'opzione di registrazione, che permette di concentrarsi sull'ascolto senza dover prendere appunti. Inoltre, questo approccio consente di riascoltare in tutto o in parte la conversazione.

  • Dimostrazione: chiedere all'utente di mostrare come viene completato un processo nel sistema corrente. Questo approccio può essere prezioso perché, mentre l'utente dimostra il processo, si potrebbero notare dettagli che non erano stati comunicati.

  • E-mail: un approccio e-mail permette al cliente di rispondere in base ai propri tempi. Tuttavia, questo approccio può anche causare ritardi e richiedere un follow-up per sollecitare una risposta. I messaggi e-mail possono anche offrire una buona traccia di come sono state prese le decisioni se le domande vengono poste in un successivo momento.

  • Richiesta di un esempio: questo approccio funziona bene per ottenere informazioni dettagliate sui report correnti o su altri output per i quali sono necessari dei chiarimenti.

Uso dei requisiti esistenti

Si consideri uno scenario in cui si sta implementando Dynamics 365 Field Service. Si è chiesto al cliente se poteva dedicare del tempo a rispondere ad alcune domande. Il cliente però si è limitato a inviare la documentazione del sistema corrente, sostenendo che lì ci fossero le risposte a tutte le domande. Sebbene tale documentazione possa essere utile, è improbabile che fornisca una risposta a ogni domanda.

In genere, le società non vogliono replicare un sistema legacy in una moderna distribuzione di app Dynamics 365. Porre domande esplorative che vanno oltre l'ambito del sistema esistente permette di venire a conoscenza dei dettagli necessari per configurare Dynamics 365 anziché replicare il vecchio sistema.

Informazioni contrastanti

Quando si pongono domande per scoprire i processi dei clienti, occorre mettere in conto la possibilità di ricevere informazioni contrastanti. Di seguito sono elencati alcuni dei motivi più comuni:

  • Utenti diversi hanno sviluppato il proprio modo di usare il vecchio sistema e, in molti casi, portano a termine lo stesso processo adottando metodi differenti.

  • I responsabili potrebbero non comprendere appieno in che modo il personale usa il sistema perché non svolgono il lavoro quotidianamente.

  • Gli utenti potrebbero aver spiegato il processo che seguono con livelli diversi di dettaglio, tralasciando alcuni passaggi chiave.

  • È possibile che non si sia compresa la spiegazione.

Indipendentemente dal motivo, quando si rileva un conflitto nell'indagine, sarà necessario porre domande chiarificatrici per capire ciò che è stato fatto o che deve essere fatto. Occasionalmente, è necessario estendere l'indagine a più utenti in modo da ottenere una prospettiva più ampia. Parlare con un responsabile può fornire una prospettiva su ciò che il cliente ritiene debba essere fatto o sia necessario fare.

"Mai avuto un singolo problema"

Se tutte le risposte indicano che ogni cosa funziona alla perfezione, probabilmente la storia è incompleta. Assicurarsi di ampliare l'ambito delle domande per portare alla luce possibili eccezioni e problemi e scoprire come vengono gestiti attualmente. È consigliabile affrontare queste eccezioni all'inizio dello sviluppo del nuovo processo per evitare di venirne a conoscenza durante il test della distribuzione della nuova app Dynamics 365.

Dipendenti inesperti

Più vecchio è il sistema legacy che si sta sostituendo, più è probabile che gran parte della conoscenza specifica sul funzionamento sia passata ad altre società. Quando si conduce l'indagine, se l'unica risposta che si riceve è "Sono stato assunto da poco e conosco solo la parte di mia competenza", cercare le risorse che possono aiutare a ottenere un quadro completo. Di seguito alcuni suggerimenti per trovare le risposte:

  • Cercare la documentazione o i materiali di formazione del vecchio sistema.

  • Chiedere agli utenti se il loro predecessore ha fornito la documentazione che spiega come eseguire il processo ora di loro competenza.

Approfondimento dell'indagine per conoscere i singoli dettagli

Porre delle domande è un po' come sbucciare una cipolla, dove ogni domanda espone un altro livello e maggiori dettagli. Usare questi dettagli per formulare la domanda successiva. Se la risposta ricevuta non espone un ulteriore livello di dettaglio, porre la domanda in un modo diverso. Le domande esplorative permettono di arrivare al nocciolo della questione e di comprendere appieno ogni aspetto.

Ampliamento dell'ambito o delle aspettative

Quando si pongono le domande, tenere presente l'ambito del progetto su cui si sta lavorando. In genere, la maggior parte dei progetti non prevede tempi e budget illimitati e ha un ambito all'interno del quale il cliente deve rimanere affinché il progetto vada a buon fine. Porre agli utenti domande che suggeriscono che il nuovo sistema potrebbe fare qualcosa che va ben oltre l'ambito dell'impegno potrebbe dar luogo a problemi e incomprensioni. Ad esempio, si potrebbe chiedere a un utente: "Sarebbe di aiuto se potessimo automatizzare l'immissione dei dati nelle cinque app che usate attualmente?". Sapendo che l'ambito non include questo approccio, l'utente potrebbe avere delle aspettative fuori luogo.

Allo stesso modo, in scenari in cui si risponde a una soluzione suggerita da un utente e non ricompresa nell'ambito corrente, può essere più facile affermare "Vedremo cosa possiamo fare". Occorre essere consapevoli che l'obiettivo dell'indagine è completare l'ambito attualmente assegnato e non estenderlo. Tuttavia, se si ha la capacità di entrare in empatia con i clienti, si potrebbe partecipare all'ideazione della soluzione in cui il focus è esplorare le possibilità. L'ideazione della soluzione, o solution envisioning, fa parte in genere di un processo di vendita nell'ambito di un progetto con ambito specifico. Per realizzare la vision, è necessario migliorare uno o più progetti ricompresi nell'ambito per soddisfare le aspettative del cliente.

Non esiste un unico modo corretto di porre domande ai clienti. L'esperienza maturata nel corso dei vari progetti permetterà di affinare tecniche personali. La chiave è continuare a porre domande finché non si ritiene di disporre di informazioni adeguate per supportare una corretta distribuzione dell'app Dynamics 365.