Agile Non Standard, l’approccio vincente al Mes

Negli ultimi anni si è assistito al proliferare di ‘prodotti’ configurabili per realizzare sistemi Mes (Manufacturing Execution Systems) o Mom (Manufacturing Operations Management). Tuttavia, anche un progetto basato su tali soluzioni richiede rilevanti attività di progettazione e personalizzazione perché il fine principale di tali sistemi è supportare i processi di business sui quali sono fondate le operation, colmando il gap tra produzione e gestione strategica, diversi da azienda ad azienda e molto variabili, per la necessità dell’azienda stessa di adattarsi a un mercato in continua evoluzione.

Un progetto Mes / Mom ha normalmente una durata considerevole, con costi importanti e un rischio intrinseco elevato, dal momento che impatta pesantemente (e potenzialmente negativamente) sulle operation e sulla capacità produttiva dell’azienda, soprattutto durante la fase di implementazione e di apprendimento da parte degli utenti.

Per mitigare il rischio e l’impatto economico di questi progetti sono necessari una profonda attenzione al project management e un ben definito processo di ‘Software Development Management LifeCycle’ (Sdlc).

Tuttavia, i tradizionali approcci di project management difficilmente si adattano alla gestione di progetti Mes e Mom, a causa della variabilità, di cui occorre necessariamente tenere conto se si vuole garantire il successo del progetto stesso. Difficilmente, nella mia esperienza, ho visto progetti terminare con gli stessi User Requirement definiti in fase iniziale e spesso mi è capitato di vedere produzioni e organizzazioni cambiare anche più volte nel corso della realizzazione del progetto.

Approcci tipici di project management

Una gestione standard ‘monolitica’ prevederebbe le fasi di: General Specification; User Requirement Specification (Urs); Functional Requirements Specification (Frs); Detailed Design Specification (Dds); System Build; Testing; Implementation; Maintenance.

Tra la stesura delle specifiche iniziali e il momento in cui il cliente inizia a toccare con mano quanto realizzato passa molto tempo. Ciò implica che ogni possibile errore di valutazione commesso nelle fasi iniziali abbia un impatto pesante nel momento in cui è rilevato, poiché esso può influenzare un numero molto elevato di funzionalità, nonché componenti comuni, quali la struttura del database su cui il sistema si basa. Inoltre, come detto prima, non è infrequente che le necessità del cliente si modifichino durante la fase realizzata portando a un sistema non più rispondente alle reali necessità. Ma la cosa che più spesso mi è capitata di vedere è che il cliente stesso è impreparato a valutare l’impatto che l’adozione di un sistema Mes avrà sulle proprie procedure organizzative, pertanto tende a definire i ‘requisiti utente’ basandosi sull’esperienza passata. La semplice adozione del sistema porta però, già fin dalle primissime fasi di utilizzo, a modificare la propria organizzazione e la scala delle priorità. Funzionalità ritenute indispensabili perdono importanza e altre che non erano nemmeno considerate diventano molto più che dei ‘desiderata’.

Un altro tipico approccio alla gestione del progetto potrebbe essere quello ‘agile’, con il quale il sistema è sviluppato e implementato in piccoli ‘sprint’. Questo approccio favorisce la sinergia tra utenti e sviluppatori, che mantengono una relazione molto più stretta e frequente, consentendo di valutare in maniera più tempestiva e semplice eventuali modifiche durante il ciclo di vita del progetto. Quello che però è più importante è che il cliente inizia a beneficiare del sistema molto più velocemente e ciò gli permette non solo di trarne beneficio e anticipare il ritorno dell’investimento, ma di ‘abituarsi’ all’utilizzo e avviare fin da subito quegli aggiustamenti organizzativi e procedurali che il sistema induce. Essi possono pertanto essere considerati negli sprint successivi, minimizzando il loro impatto sul costo e sulla durata del progetto.

Anche l’approccio ‘agile’ tuttavia presenta alcuni limiti. In particolare la sua ‘frammentazione’ può indurre a procedere senza una chiara visione degli obiettivi di progetto, perdendo organicità in ciò che si realizza.

Una valida alternativa

Sulla base della mia esperienza, l’approccio migliore, almeno nella maggior parte dei progetti, è quello ‘Agile non standard’, in cui sono preservate le prime due fasi del Software Development Management LifeCycle tradizionale (‘General specification’ e ‘User Requirements Specifications’), per poi procedere nella fase implementativa attraverso sprint. Questo garantisce che il progetto sia affrontato con una visione complessiva, anche se non immutabile, degli obiettivi, delle necessità e delle attese del cliente, in grado di fornire una linea guida in tutta la fase realizzativa. In particolare cerchiamo che le ‘User Requirement Specification’ siano organizzate in capitoli corrispondenti ai moduli che, opportunamente organizzati sulla base di priorità condivise con il cliente, saranno poi realizzati mediante specifici sprint. Ogni capitolo riporta la mappatura ‘as-is’ dei processi, la mappatura ‘to-be’ degli stessi, e la descrizione funzionale specifica di quanto da realizzare.

Ciò consente, in occasione di ciascuno sprint, di rianalizzare la parte di Urs a esso specifica, valutando se alla luce di quanto realizzato fino a quel punto e delle modifiche intervenute nell’organizzazione e nei processi (indotte o meno dall’adozione del sistema), i requisiti sono ancora validi o necessitano qualche adattamento. Solo allora procediamo alla stesura delle specifiche funzionali del modulo e alle fasi realizzativa, di test e implementazione.

Quest’approccio ha sicuramente influenzato in modo molto positivo i progetti in cui è stato adottato. Esso ha consentito di affrontare il progetto con la corretta visione d’insieme, mitigando al contempo il rischio e l’impatto legato alle modifiche emergenti in corso d’opera. Statisticamente ciò ha portato al rispetto dei tempi di progetto, a un maggiore coinvolgimento del cliente e, in definitiva, a una sua maggiore soddisfazione. Il cliente, infatti, ha potuto: beneficiare del sistema prima, sfruttando i benefici dei primi moduli per finanziare la prosecuzione del progetto; ridurre i tempi di adozione e accettazione da parte degli operatori; ottenere uno strumento più attinente alle proprie necessità, anche se queste si sono modificate in corso d’opera, senza che ciò modificasse in maniera rilevante il costo del progetto. Inoltre, cosa assolutamente rilevante, ha migliorato il clima di fiducia fra system integrator e cliente, creando un ambiente collaborativo più flessibile e fluido.