Guidare i workshop di solution envisioning

Perché l’envisioning è responsabilità del Solution Architect

Il workshop di solution envisioning è il momento in cui il Solution Architect trasforma un desiderio vago dello sponsor in una visione condivisa e realizzabile. Non è una raccolta requisiti tradizionale: l’obiettivo è far emergere processi di business, obiettivi misurabili e vincoli prima di parlare di tabelle, app o automazioni. In ottica Success by Design (il framework Microsoft per le implementazioni Dynamics 365 e Power Platform), l’envisioning apre la fase di Initiate e alimenta la Solution Blueprint Review.

La competenza chiave, e la più valutata in PL-600, è separare il problema dalla soluzione. Uno stakeholder che dice “ci serve una Canvas app per approvare le ferie” ti sta consegnando una soluzione già confezionata. Il tuo compito è risalire al bisogno: quanto costa oggi il processo? dove sono i colli di bottiglia? qual è il KPI che migliora? Solo dopo puoi decidere se la risposta corretta sia una Canvas app, un flusso di approvazione in Power Automate, una feature di Copilot Studio o addirittura nessuna app.

Strutturare il workshop

Un buon workshop di envisioning ha una progressione precisa:

• Contesto e sponsorship: identifica lo sponsor esecutivo, gli owner di processo e gli utenti finali. Senza uno sponsor con autorità di budget e di priorità, il progetto perde slancio in fase di adoption.
• Mappatura dei processi as-is: usa storyboard o process mapping per rendere visibile il flusso reale, non quello documentato.
• Definizione degli obiettivi: traduci le aspettative in outcome misurabili (riduzione tempi, tasso di errore, self-service) legati a una value proposition.
• Vincoli e non-negoziabili: compliance, data residency, sistemi legacy, licensing, timeline.
• Prioritizzazione: distingui must-have da nice-to-have con lo sponsor presente, così le decisioni difficili sono avallate.

Le domande guida di Success by Design servono ad anticipare i rischi: l’integrazione prevista supera i limiti dell’API? il volume dati richiede considerazioni di storage Dataverse? la personalizzazione erode l’upgradabilità? il modello di sicurezza regge la complessità organizzativa? Portarle in envisioning evita che un rischio architetturale emerga in fase di Go-Live Readiness, quando il costo di correzione è massimo.

Trade-off di design da far emergere

L’envisioning è il posto giusto per esplicitare i compromessi, ancorandoli ai pilastri del Well-Architected Framework (adattato da Power Platform):

• Configurazione vs. personalizzazione (Operational Excellence): preferisci configurazione low-code e componenti out-of-the-box; il codice pro-code va giustificato da un requisito che nessuna capacità nativa copre, perché aumenta il costo di manutenzione.
• Costruire vs. comprare (Cost Optimization): valuta se un’app first-party o una feature esistente risolve il bisogno prima di progettare da zero.
• Automazione ora vs. dopo (Reliability): identifica cosa è core al minimum viable product e cosa può attendere una release successiva.
• Complessità del modello di sicurezza (Security): un requisito di visibilità granulare può richiedere business unit, team owner o row-level security che impattano performance e amministrazione.

Il Solution Architect raccomanda l’opzione, non la subisce: “dato questo requisito di approvazione a due livelli con audit, raccomando un flusso Power Automate con Approvals e log su Dataverse, invece di logica custom in una Canvas app, perché è tracciabile, manutenibile e riusabile”.

Allineare sul valore atteso

Un envisioning riuscito termina con sponsor e utenti allineati sullo stesso outcome. Documenta la visione in modo che chiunque possa ripetere la value proposition in una frase. Questo allineamento è la migliore difesa contro lo scope creep e contro il rischio di adoption, perché lega ogni requisito futuro a un valore concordato.

Trappole tipiche d’esame

• Requisito consegnato come app specifica (“costruiamo una Model-driven app per i ticket”) → non accettarlo come dato: risali al processo e al KPI, valida il bisogno di business, poi scegli la capacità (magari basta Power Automate + Dataverse).
• Sponsor assente o solo IT nel workshop → l’assenza dell’owner di processo o dello sponsor esecutivo è un rischio da segnalare: pianifica una sessione con chi ha autorità di priorità e budget prima di procedere.
• Requisito di personalizzazione pesante presentato come obbligatorio → valuta prima configurazione e componenti nativi; raccomanda pro-code solo se una gap analysis dimostra che nessuna capacità low-code copre il requisito.
• Nessun outcome misurabile definito → rifiuta di chiudere l’envisioning con obiettivi vaghi (“migliorare l’efficienza”): forza la definizione di metriche, altrimenti il valore non sarà dimostrabile né la adoption governabile.
• Rischi architetturali (limiti API, volumi, integrazioni) rimandati al design → applica subito le domande di Success by Design: emergere presto un limite di piattaforma è economico, scoprirlo in Go-Live no.