Problem Analysis e Solution Design

La fase di Problem Analysis e Solution Design consta principalmente in un “esercizio” su carta. I consulenti dell’azienda fornitrice della soluzione APS collezionano tramite vari meeting tenuti dal cliente le informazioni utili alla creazione della descrizione del problema che si vuole gestire tramite l’implementazione del software; sulla base di tale descrizione si procederà poi alla formulazione di una soluzione. In particolare, durante la fase di Solution Design, si rende necessario tipicamente un forte coinvolgimento da parte dei Product Specialist del software APS in maniera tale da poter specificare una soluzione effettivamente realizzabile utilizzando la tecnologia del fornitore. Le fonti di informazione tipiche di questa fase sono le interviste agli utilizzatori della soluzione attualmente utilizzata dall’azienda, la documentazione relativa a tali tool, e la verifica/prova di questi. I risultati delle interviste vengono così processati dai consulenti e restituiti agli intervistati con il fine di verificarne la correttezza. Le interviste in questa fase possono rivelarsi molto complicate o molto semplici, e questo dipende fortemente da (1) il grado di dimestichezza dell’intervistato con le tematiche del problema da affrontare, Figura 3.5.3.A: Schema raffigurante il livello di equilibrio ottimale tra una costruzione del modello di tipo “a cascata” e “interattivo” (Wiers, 2009).

di prendere decisioni su quali elementi includere nel design dell’APS e cosa no. La dimensione ideale del team partecipante all’intervista è di circa tre persone lato cliente, questo perché un gruppo di persone compatto ha minore probabilità di perdersi in discussioni a poco valore aggiunto; allo stesso tempo inoltre le persone avranno molte meno remore nel discutere le affermazioni degli altri partecipanti. Le interviste con più di cinque persone lato cliente presentano solitamente bassi livelli di efficienza (Wiers, 2009).

Un consulente APS dovrebbe mettere in pratica le seguenti tecniche di intervista al fine di ottenere le corrette informazioni (Wiers, 2009):

• Ripetere la stessa domanda più volte, utilizzando parole diverse, per verificare che le risposte siano consistenti e quindi siano corrette.

• Ripetere la stessa domanda a persone diverse, per verificare la consistenza delle risposte.

• Chiedere in continuazione perché le pratiche seguite in azienda siano strutturate così come sono nel momento attuale dell’intervista; in linea teorica sarebbe auspicabile una spiegazione delle pratiche di lavoro sulla base dei processi primari.

• Utilizzare argomentazioni basate sul concetto di “valore vs sforzo” per troncare specifiche discussioni su funzionalità richieste.

• Intervenire quando gli intervistati perdono il punto del discorso ed iniziano a divagare in discussioni non focalizzate. L’obiettivo della sessione di intervista deve essere quello di fornire al consulente il giusto input e nient’altro.

• Riassumere ciò che è appena stato detto dagli intervistati, confrontarsi su quanto riassunto e cercare di non rivisitarlo più in futuro.

• Fare un utilizzo estensivo di esempi, come ad esempio supporti grafici sulle whiteboard.

• Scegliere il giusto livello di dettaglio nelle interviste per evitare di scavare troppo a fondo su argomenti che non richiedono in realtà un elevato livello di analisi.

• Preparare dei “compiti” per gli intervistati, come creare esempi, dei data set rappresentativi del problema o dei brief descriventi il problema, al fine di permettere ai clienti di prendere confidenza con il problema da affrontare.

I seguenti aspetti possono inoltre essere di ragguardevole importanza durante la fase di Problem Analysis e Solution Design (Wiers, 2009):

• Una buona disponibilità da parte del personale competente. Potrebbe sembrare scontato, ma raramente i pianificatori più esperti sono disponibili per un progetto time-intensive come l’implementazione di un APS. Tuttavia, se coinvolti in questa tipologia di progetti, sono tipicamente ben disposti a trovarsi del tempo da dedicarvi, in quanto possono chiaramente prevederne i potenziali benefici.

• La presenza di un buon project manager lato cliente a supporto dei consulenti, che possa tagliare le discussioni inutili, supervisionare i “compiti” assegnati dai consulenti e organizzare riunioni decisionali.

• Un consulente lato cliente, che abbia una conoscenza profonda dei processi primari e di controllo, che possa aiutare il consulente del fornitore nell’analizzare il problema e nel formulare una soluzione.

Per il consulente del fornitore, la principale attività, sarà poi quella di digerire le informazioni e di creare un documento denominato PA&SD (Problem Analysis and Solution Design). La scrittura di questo documento dovrebbe essere condotta in parallelo alla sessione di intervista, essendo l’ammontare delle informazioni ricevute tipicamente troppo grande per riuscire a mantenerle in memoria. Si riassumono nella tabella seguente le principali attività tipiche di questa fase, correlate da una indicazione di stima della loro durata (Wiers, 2009).

I problemi tipici che possono emergere in questa fase sono (Wiers, 2009):

• Posporre difficili decisioni di design. Il consulente APS più “funzionale” potrebbe Figura 3.5.4.1.A: Attività tipiche della fase PA&SD (Wiers, 2009).

temporali, oppure per paura che la piena complessità del problema possa rivelarsi troppo difficile da gestire.

• Non riconoscere i dettagli ad alto impatto sul progetto. Questo aspetto dipende fortemente dall’esperienza del consulente, che potrebbe farsi sfuggire dettagli in grado di generare conseguenze fortemente impattanti nelle fasi avanzate del progetto. • Attitudine del cliente nel non prendere decisioni. Durante la fase di analisi e design, si prospetteranno molte decisioni da prendere sul come organizzare i processi supportati dall’APS. Nulla si rivela frustrante in un processo di design quanto un cliente che non prende decisioni o che non è in grado di mettere in discussioni decisioni passate per favorire il cambiamento.

• Difficoltà nel trovare un esperto. Accade regolarmente che si rendano necessarie numerose sessioni di interviste per ottenere la persona “giusta” – potenzialmente nascosta in qualche ufficio dell’azienda – in grado di spiegare alcuni aspetti importanti del processo da pianificare. Quando la persona giusta non è nel team di progetto, può anche accadere che l’APS si riveli mancante di alcune importanti funzionalità una volta realizzato.

3.5.4.2 Sviluppo

Durante la fase di sviluppo, il fornitore di APS costruisce il modello sulla base del documento PA&SD realizzato nella fase precedente. Ciò si traduce nella maggior parte dei casi in una bassissima, se non nulla, necessità di interagire con i key users del cliente. Tale regola non è tuttavia sempre valida in quanto dipende dal tipo di APS implementato: quando il modello è interamente customizzabile, sarà necessario un tempo maggiore per sviluppare il modello iniziale da sottoporre agli user come test, mentre un APS che necessita solo di essere parametrizzato richiederà una fase di sviluppo “offline” molto breve. Mentre il fornitore sviluppa il modello, sarebbe auspicabile che il cliente preparasse un’ambiente di prova in grado di simulare le dinamiche della supply chain aziendale col fine di effettuare dei test per la fase di sviluppo interattiva (Wiers, 2009).

I tipici problemi che possono emergere in questa fase sono (Wiers, 2009):

• Mancanza di dati. Se i dati necessari per lo sviluppo non vengono preparati in tempo, ciò si traduce nell’impossibilità degli sviluppatori di lavorare in maniera efficace. • Design funzionale poco chiaro. Quando il design funzionale risulta essere poco chiaro,

gli sviluppatori sono obbligati ad indovinare cosa i consulenti funzionali intendessero quando il documento è stato scritto.

• Distanza fisica. Quando il team di progetto e il cliente, oppure il team di progetto e gli sviluppatori, sono separati fisicamente da una notevole distanza, può accadere che la risoluzione dei problemi di design si riveli difficoltosa. Questo aspetto può essere in parte superato con delle visite nei relativi uffici e fissando dei momenti prestabiliti di incontro dei vari team.

• Disengagement. Poiché agli occhi del cliente non si sta muovendo molto in questa fase, essendo i momenti di sviluppo per lo più a lui nascosti, esiste il rischio che il team lato cliente si “disimpegni”.