Progetti ERP: quando il preventivo iniziale diventa una promessa impossibile

La storia comincia spesso in una sala riunioni, qualche settimana prima della firma. La direzione ha fissato l'avvio al 1° gennaio, perché l'esercizio contabile si apre quel giorno e sembra naturale passare al nuovo sistema nello stesso momento. Il partner, in concorrenza con altri due, presenta un'offerta che rientra nella cifra annunciata. Nessuno mente davvero. Ognuno si limita a scegliere l'ipotesi più favorevole: dati puliti, key user disponibili, esigenze vicine allo standard di Business Central.

Stimare un progetto ERP resta un esercizio difficile. Il costo dipende dallo stato dei sistemi esistenti, dall'entità dei cambiamenti organizzativi, dalla disponibilità dei team e dalla capacità dell'organizzazione di assorbire il cambiamento, variabili che si scoprono per lo più strada facendo. Un preventivo ottimistico non produce soltanto uno sforamento. Crea una pressione che spinge ad accorciare ciò che sembra negoziabile: collaudi, migrazione dei dati e formazione. Sono proprio le fasi che decidono la qualità dell'avvio. Tra i sette principali rischi di un progetto ERP, questo ha una particolarità: è spesso già presente prima del primo workshop.

Manifestazioni e sintomi sul campo

I primi segnali compaiono già nei workshop di analisi. L'analisi degli scostamenti (fit-gap) rivela più sviluppi del previsto, e i consulenti scoprono casi particolari che nessuno aveva menzionato in prevendita: un listino per zona di consegna, una fatturazione per stato di avanzamento, un iter di approvazione degli acquisti su tre livelli. Ogni scoperta è modesta. La loro somma no.

A metà percorso, le giornate consumate superano l'avanzamento reale. Il comitato guida riceve una prima ristima, che raramente approva per intero. Si preferisce ridurre il perimetro senza dirlo o chiedere al team di "recuperare". Le decisioni si fanno attendere, perché ogni risorsa aggiuntiva va ormai giustificata voce per voce.

I key user, che spesso sommano il loro ruolo abituale e il progetto, accumulano serate e fine settimana. I cicli di collaudo si comprimono, la migrazione dei dati passa da tre prove previste a una sola. Poi arriva il rinvio dell'avvio, raramente annunciato in una volta sola. Slitta di un mese, poi di un trimestre, e ogni annuncio intacca un po' di più la credibilità del progetto presso i reparti.

Impatto finanziario, operativo e umano

Lo sforamento finale supera spesso di molto il primo annunciato, ma si vede poco. Una parte si diluisce negli straordinari dei team interni, che non compaiono in nessun budget di progetto. Un'altra riemerge dopo l'avvio, sotto forma di giornate a consumo per correggere ciò che è stato consegnato troppo in fretta. Il confronto onesto tra il budget approvato e il costo completo si fa raramente.

Il calendario produce effetti propri. Un avvio rinviato da gennaio ad aprile obbliga a migrare i saldi a esercizio in corso, a mantenere più a lungo il vecchio sistema e talvolta a prolungare un contratto di manutenzione che doveva scadere. I miglioramenti attesi dalle funzioni aziendali restano in sospeso, perché tutto dipende dal passaggio al nuovo sistema.

Il costo umano è ancora più pesante. Un team esausto perde i suoi elementi migliori proprio quando ne ha più bisogno: un key user che si dimette tre mesi prima dell'avvio porta con sé la conoscenza della configurazione del suo ambito. I collaboratori che hanno sentito più date successive finiscono per non credere più a nessun annuncio, compreso quello giusto.

Analisi delle cause profonde e degli errori di governance

La prima causa è l'ottimismo della fase di lancio. La direzione vede i benefici attesi, il partner vuole aggiudicarsi il contratto, e il preventivo si costruisce su un perimetro descritto in poche pagine. Business Central ha la fama di un ERP rapido da implementare. È vero per un perimetro vicino allo standard, e diventa fuorviante non appena le specificità si accumulano.

Gli impegni sono poi distribuiti male. Si stimano con precisione la configurazione e gli sviluppi, molto meno la migrazione dei dati, i collaudi, la formazione e l'accompagnamento dopo l'avvio. Eppure queste attività rappresentano una quota importante dello sforzo totale, e poggiano in gran parte sui team del cliente, il cui tempo non viene quasi mai messo a budget.

Anche il contratto ha il suo peso. Con un prezzo a corpo, il partner ha interesse a congelare un perimetro stretto, e ogni scostamento diventa una variante che nessuno osa aprire. A consumo, il budget iniziale è solo una stima, e il cliente scopre la realtà fattura dopo fattura. Molti budget, infine, non contengono alcuna riserva per imprevisti. Il minimo contrattempo diventa allora una crisi, per mancanza di margine.

Piano d'azione, misure preventive e correttive

Il preventivo deve anzitutto poggiare su un'analisi preliminare seria. Qualche giornata di workshop prima della firma, concentrata sui processi davvero critici e su un campione di dati, vale più di un'offerta redatta a partire da un capitolato generico. Questa analisi serve anche a misurare lo scostamento dallo standard di Business Central, processo per processo.

Il budget va poi scomposto in pacchetti di lavoro abbastanza fini da poter essere seguiti: configurazione per ambito, ogni sviluppo, ogni ciclo di migrazione, ogni campagna di collaudo, la formazione e l'accompagnamento dopo l'avvio. Il tempo dei team interni vi compare in modo esplicito, con i nomi delle persone e il loro tasso di disponibilità. Un key user disponibile al 20% non può sostenere tre cicli di collaudo.

Una riserva per imprevisti, visibile e gestita dal comitato, completa il dispositivo. Una dotazione dell'ordine del 15-20% del budget è una prassi diffusa. Il suo utilizzo si decide in comitato, il che evita che finanzi richieste di comodità.

La data di avvio, infine, si discute. Nulla obbliga a partire il 1° gennaio: un avvio a esercizio in corso, con migrazione dei saldi a fine mese, è frequente e spesso meno rischioso di un passaggio sovrapposto alla chiusura annuale. Una ristima a ogni tappa, presentata senza ritocchi, permette di annunciare presto un ritardo invece di subirlo tardi.

Conclusione

Un budget sottostimato non è quasi mai un incidente. Nasce da un accordo tacito tra una direzione che vuole una cifra rassicurante e un partner che vuole firmare, e ciascuno ne paga il prezzo più tardi. L'azienda che accetta un preventivo ottimistico finisce per saldare la differenza in un altro modo, con il tempo dei suoi team, la qualità dei suoi dati e la fiducia dei suoi collaboratori.

La responsabilità principale spetta al cliente, perché è lui a convivere con il risultato. In concreto, significa pretendere un'analisi preliminare prima della firma, stimare il proprio tempo come una risorsa del progetto, inserire una riserva per imprevisti nel budget approvato e trattare la data di avvio come una variabile. Un progetto che parte un trimestre dopo con dati affidabili costa meno di uno che rispetta la data e viene riparato per un anno.

Il rischio successivo prolunga direttamente questo. Quando il calendario si stringe, la migrazione dei dati è spesso la prima vittima.