Come posso contribuire al pensiero sistemico e analitico, in modo che la soluzione raggiunta fornisca un valore esattamente corrispondente alle reali esigenze del business?
Se si parla di requisiti ai business stakeholder, cioè alle parti interessate nel business, si rischia di sentire affermazioni come: «Vorrei un altro schermo che mi mostri i totali di produzione giornalieri. Vorrei che Excel mi visualizzi le vendite per il trimestre precedente. Vorrei sapere quanti dipendenti nuovi si aggiungono ogni mese». Oppure, si sentono racconti come questo: «In qualità di direttore di produzione, vorrei uno schermo che mostri la produzione di ogni fabbrica in modo da vedere la produttività di tutti i nostri stabilimenti». In ciascuno di questi esempi, lo stakeholder sta esprimendo la soluzione da lui percepita per una qualche necessità inespressa. Ma non sappiamo perché lo stakeholder vuole i totali di produzione giornalieri, dato che non ha spiegato cosa farà con i dati di vendita. Solo quando si conosce il motivo per cui qualcuno sta chiedendo qualcosa, allora si è in grado di fornire un valore. Cioè, è possibile fornire una soluzione che corrisponda alla reale esigenza di business, anche se la vera necessità è ancora inespressa. In questo senso, qualsiasi soluzione che non soddisfa un bisogno reale è uno spreco di risorse.
Ascoltare le richieste
Bisogna quindi prendere in considerazione il motivo per cui vengono chieste soluzioni, e cosa si può fare per arrivare alla reale esigenza. In primo luogo, è abbastanza naturale per un essere umano chiedere una soluzione che sia vicina alla propria realtà tangibile. Se si sta progettando un viaggio si è più propensi a dire: «Prendiamo l’autobus delle 9.30» – invece di dire – «Voglio spostarmi da casa al lavoro con mezzi di trasporto che mi portino in tempo al meeting delle 10.15». Qui il punto è che si parla in termini tangibili invece che per astrazioni. Uno skill chiave di business analysis è quello di ascoltare le richieste degli stakeholder, e poi applicare il pensiero analitico e sistemico per scoprire la reale esigenza. E questo scopo si raggiunge soprattutto chiedendosi perché: «Perché avete bisogno dei totali di produzione giornalieri? Per confrontare le unità prodotte con quelle vendute? E poi cosa ne farete? Per regolare il ciclo produttivo della prossima settimana in modo da coprire le previsioni di vendita»?
Il risultato di questa conversazione è che l’analista comincia a comprendere la reale esigenza di business: «In qualità di responsabile di produzione, posso confrontare le unità prodotte ogni giorno con quelle vendute, in modo da sapere come regolare il ciclo produttivo per la prossima settimana e assicurare che siamo in grado di soddisfare tutti gli ordini dei nostri clienti». Va anche notato che adesso vengono usati termini come “posso” invece di “voglio”, dove “posso” indica un bisogno, mentre “voglio” suggerisce una soluzione.
Fornire valore di business
Applicando il pensiero analitico e sistemico, il business analyst scopre cosa può fornire valore al business. Anche se può sembrare strano, spesso gli stakeholder non chiedono direttamente valore di business, e lo fanno per molteplici ragioni. Gli stakeholder pensano in termini di come le cose vengono fatte ora. Non sanno cosa è possibile. La mentalità a silos mette pareti intorno al loro modo di pensare, rendendo difficile vedere il quadro più ampio. Pensano in termini di come fare qualcosa, invece che di quello che deve essere fatto. Il loro pensiero è centrato su se stessi, invece che sul business complessivo. In considerazione di tutto questo, l’analista di business può (e deve) chiedere perché la richiesta è stata fatta: comprendendone la ragione, il business analyst è in grado di fornire una soluzione che produce reale valore di business. Ma l’analista ha anche bisogno di esplorare altre possibilità di miglioramento del business. Per esempio, dovrebbe suggerire idee innovative per migliorare la policy di business esistente: anche se il business analyst non la determina, può però fare raccomandazioni in modo che gli stakeholder di business siano in grado di scegliere le innovazioni che forniranno il massimo valore.
L’analista deve quindi chiedere agli stakeholder: «Quanto sarebbe utile essere in grado di fornire una soluzione che offre un ciclo di produzione giornaliero rettificato al fine di evitare ordini inevasi? Quanti ordini sono inevasi in questo momento? Quanto ci costano questi ordini inevasi? Ci sono altri fattori che causano ordini inevasi? Potrebbe essere utile correlare il programma di produzione con le consegne dei materiali da parte dei fornitori»? Queste domande indicano che l’analista di business sta usando il pensiero sistemico per trovare le reali esigenze, guardando all’intera attività e all’effetto di ciascuna parte sulle altre. È solo trovando la reale esigenza che la soluzione ottimale può essere realizzata. La soluzione ottimale è quella che corrisponde alle reali esigenze e fornisce il massimo valore di business per il suo costo.
La scoperta dei bisogni reali è responsabilità dei business analyst, ma la scelta della soluzione ottimale è di solito responsabilità degli stakeholder: operando insieme, entrambi possono garantire che stanno fornendo il massimo valore di business.
James Robertson
Consulente, insegnante, autore e project leader. La sua opera nel campo della Business Analysis e della raccolta dei requisiti è apprezzata in molte parti del mondo. È co-autore di “Mastering the Requirements Process”, “Requirements-Led Project Management” e dell’approccio Volere per l’engineering dei requisiti. È anche fondatore dell’Atlantic Systems Guild, un think thank conosciuto in tutto il mondo per le sue tecniche innovative di systems engineering.
Suzanne Robertson
Principal dell’Atlantic Systems Guild. Indiscussa autorità nel mondo della system analysis e requirements modeling. È co-autrice con James Robertson di “Complete Systems Analysis: the Workbook, the Textbook, the Answers” e di “Mastering the Requirements Process”. È roving ambassador per il Reuse Group della British Computer Society e ha fatto parte del comitato per Object Technology 97.
Suzanne Robertson presenterà a Roma per Technology Transfer il seminario “Mastering the Requirements Process” il 17-19 ottobre 2016 e James Robertson terrà sempre a Roma il seminario “Mastering Business Analysis” il 20-21 ottobre 2016.
