Una finestra di consegna che ha quasi fatto deragliare un intero progetto

La consegna avviene presso un produttore di materiali edili: sabbia, ghiaia, inerti. I camion partono durante tutta la giornata, i carichi vengono consolidati e il reparto spedizioni è il fulcro dell'attività.

Durante i workshop, il responsabile ha avanzato una richiesta precisa: trovare nel nuovo sistema ERP una finestra per raggruppare le spedizioni identica a quella del vecchio sistema.

Con il vecchio strumento, contrassegnava con una croce le linee da spedire, poi regolava le quantità man mano che procedeva, linea per linea.

Il sistema ERP standard che viene implementato funziona in modo diverso: la spedizione consolidata è un unico documento, al quale vengono aggiunte o rimosse righe e le cui quantità vengono aggiornate prima della convalida. Il risultato finale è lo stesso; cambia solo il metodo.

La richiesta sembrava innocua. Eppure, lo sviluppo intrapreso per soddisfarla si è rapidamente orientato verso la modifica del processo stesso di convalida delle spedizioni. Ma modificare la convalida significa modificare la gestione standard dell'inventario: movimentazioni, valutazione, tracciabilità e tutti i test che ne dipendono. Una questione di usabilità si stava trasformando in una revisione completa di un processo critico.

La soluzione alla crisi non è arrivata né da un rifiuto categorico né da un'accettazione totale. Il responsabile del progetto ha raggiunto un compromesso con il responsabile: una nuova finestra, strettamente allineata alle loro consuete procedure di lavoro, basata sul documento standard senza modificare il processo di validazione, in cambio dell'accordo a lavorare in modo leggermente diverso. Il reparto spedizioni ha mantenuto un'interfaccia intuitiva e il progetto ha conservato il suo sistema standard di gestione dell'inventario.

Perché una richiesta ragionevole diventa una deriva

Questa storia riassume il meccanismo dell'ampliamento incontrollato dell'ambito del progetto. Nessuna richiesta, presa singolarmente, sembra irragionevole. La richiesta del responsabile delle spedizioni era legittima: conosceva il suo lavoro, le sue quote di produzione e voleva evitare di perdere tempo al molo di carico. Il problema non derivava dalla sua esigenza, ma dal modo in cui l'aveva espressa.

Un utente raramente descrive un bisogno. Descrive piuttosto una soluzione, il più delle volte una soluzione che già conosce. "Una finestra identica al vecchio sistema" è una soluzione. "Preparare rapidamente un carico che combini più ordini" è un bisogno. Finché il progetto si concentra sulla soluzione richiesta piuttosto che sul bisogno, ogni workshop aggiunge sviluppi e l'ambito si espande senza il consenso di nessuno.

Le condizioni risultano tanto più favorevoli data la vaghezza degli obiettivi iniziali. Un progetto avviato per "modernizzare il sistema informativo" o "migliorarne l'efficienza" non fornisce alcun criterio decisionale. In assenza di un obiettivo misurabile, qualsiasi richiesta può essere giustificata.

Deriva, chiarimento o dimenticanza: tre situazioni da distinguere

Non tutto ciò che viene aggiunto nel corso di un progetto costituisce una deviazione.

Prima di rispondere affermativamente o negativamente, la richiesta deve essere motivata, poiché ogni caso richiede un approccio diverso.

La vera deriva

Nel frattempo è emersa una nuova richiesta, non correlata agli obiettivi approvati: un portale per i fornitori "già che ci siamo", una dashboard aggiuntiva. Ciò richiederà una decisione, una fase successiva o una modifica.

Il chiarimento

Un'esigenza precedentemente confermata sta diventando più chiara: la regola precisa per il calcolo di un prezzo, i dettagli di una fase preparatoria. Questo fa parte del normale funzionamento di un progetto e rientra nell'ambito esistente.

La svista dell'inquadratura

Nell'analisi è stata trascurata un'esigenza presente fin dall'inizio, ad esempio un requisito normativo in materia di tracciabilità. Non si tratta di un capriccio aziendale, bensì di un errore di analisi, che è in fase di risoluzione con il committente, senza attribuire colpe.

La richiesta del responsabile delle spedizioni rientrava in una quarta categoria, la più frequente e la più insidiosa: l'abitudine spacciata per necessità. Merita un'attenta valutazione, seguita da una negoziazione sulla forma che dovrebbe assumere.

Segnali di avvertimento

Alcuni segnali ci permettono di individuare lo scostamento prima che influisca sulla pianificazione. Il primo è il vocabolario: "come prima", "identico al vecchio sistema", "abbiamo sempre fatto così".

Il secondo aspetto riguarda l'area interessata: una richiesta che modifica una convalida, un calcolo di magazzino, un costo o una contabilità non è mai una richiesta di poco conto, a prescindere dalla semplicità della schermata che la gestisce.

Successivamente arrivano i segnali premonitori: una serie di deviazioni dall'analisi di conformità che continuano ad aumentare dopo la validazione del progetto, stime di carico che aumentano da un comitato all'altro, richieste accettate in officina senza un preventivo e fasi che si allungano senza una causa tecnica identificabile.

La quota di responsabilità dell'integratore

La deriva non è responsabilità esclusiva delle unità aziendali.

Una parte significativa del processo ha origine presso l'integratore. In un contesto di workshop, quando viene chiesto se una funzione è fattibile, il consulente risponde prontamente "è fattibile", il che è quasi sempre tecnicamente vero. L'utente, tuttavia, sente "è previsto".

La tipologia di contratto aggrava questo fenomeno. Con un contratto a prezzo fisso, ogni aggiunta non prezzata viene fatturata come ricarico o in base alla qualità, e la modifica che nessuno osa aprire finisce per mettere a dura prova il rapporto. Con un contratto a tempo e materiali, il contatore scorre e lo sforamento dei costi è meno evidente fino all'arrivo della fattura. In entrambi i casi, il ruolo del consulente esperto è quello di indicare chiaramente il costo di una richiesta, anche quando la risposta non è soddisfacente.

Quanto costa davvero una deriva

Il costo dello sviluppo non si esaurisce con il suo completamento. Il sistema deve essere testato, documentato, gli utenti formati e poi manutenuto a ogni aggiornamento di versione dell'ERP. Una modifica al processo di convalida delle spedizioni avrebbe richiesto di ritestare tutti i flussi di inventario a ogni aggiornamento, per l'intera durata del sistema.

Il costo umano è altrettanto reale. Quando l'obiettivo continua a spostarsi, il team di progetto perde di vista il traguardo, la data di inizio viene ripetutamente posticipata e il progetto perde credibilità all'interno dell'organizzazione. Con risorse che rimangono costanti, ogni aggiunta viene in definitiva finanziata riducendo la durata dei test, con il risultato di un sistema che copre tutto solo approssimativamente, anziché un ambito solidamente controllato.

Mantenere il controllo del perimetro senza interrompere le operazioni

Un rifiuto categorico raramente funziona; l'utente rifiutato aggirerà il sistema o ne ostacolerà l'adozione. Diverse strategie consentono di mantenere il controllo pur rimanendo reattivi.

Riformulare la soluzione come un bisogno

Per ogni richiesta, la prima domanda si concentra su ciò che l'utente sta cercando di ottenere, non sulla schermata che sta descrivendo. Spesso è proprio qui che si trova il compromesso.

Separare l'interfaccia del motore

Modificare una finestra, un elenco o un collegamento è un'operazione poco costosa e rimane locale. Modificare una convalida, un calcolo di magazzino o una registrazione contabile ha invece ripercussioni sull'intero sistema. Questo confine è fondamentale da proteggere ed è ciò che ci ha permesso di gestire con successo il processo di spedizione.

Poni allo sponsor la domanda giusta

"Cosa, essendo assente all'inizio, impedisce la fatturazione, la spedizione o la chiusura del mese?" Ciò che non supera questo filtro può attendere una fase successiva.

Applicare la regola "un input per un output"

Una volta convalidato il progetto, ogni richiesta aggiuntiva indica cosa sostituisce o sposta.

Riservare un'area perimetrale.

Una riserva di capacità, visibile al comitato direttivo, rende concreto il processo decisionale. Quando questa riserva si esaurisce, le nuove richieste possono attendere.

Tenere traccia delle richieste

Ogni richiesta viene valutata, quantificata e analizzata. Quelle che vengono rinviate sono incluse in un elenco di fase 2 presentato a ciascun comitato, in modo che il rinvio non venga percepito come un rifiuto.

Conclusione

L'ampliamento incontrollato dell'ambito di un progetto non deriva quasi mai da cattive intenzioni. Nasce da richieste legittime, presentate come soluzioni, che nessuno si prende la briga di riformulare. Il responsabile delle spedizioni non aveva torto a voler lavorare in modo efficiente. Aveva semplicemente descritto il suo vecchio strumento invece della sua reale esigenza.

Padroneggiare l'ambito del progetto non significa quindi dire di no, ma sapere cosa si sta proteggendo, lo standard, la tempistica e la capacità del team di portare a termine il lavoro.

Alla prossima riunione del comitato direttivo, basterà un semplice esercizio per iniziare. Aprite l'elenco delle richieste accettate dopo la convalida del progetto e contate quelle per le quali è stato calcolato un costo prima dell'accettazione.