Cambiare gestionale senza farsi guidare da chi te lo vende

Il cambio del gestionale è il progetto informatico più rischioso che una PMI possa affrontare. Non per la tecnologia: per il modo in cui viene deciso.

Il copione è quasi sempre lo stesso. Il gestionale storico mostra i suoi limiti, qualcuno propone di cambiarlo, e partono le demo. Ogni fornitore presenta il proprio prodotto, e ogni presentazione è convincente — perché chi la fa è bravo a venderla, e perché confronta il suo sistema nuovo col vostro vecchio, un confronto che vince sempre. Alla fine l'azienda sceglie fra tre offerte scritte da tre venditori, ciascuna con perimetri diversi, moduli diversi e giornate di avviamento conteggiate in modo diverso. Confrontarle davvero è impossibile, e la scelta cade su chi ha fatto l'impressione migliore.

Il problema è strutturale: in tutto il tavolo non c'è nessuno che sia pagato per fare gli interessi di chi compra. Ogni consulente coinvolto guadagna se vendete — il suo prodotto, le sue giornate di configurazione, la sua assistenza per i prossimi dieci anni. Sono professionisti seri, nella maggior parte dei casi. Ma la loro serietà si esercita dentro un perimetro: il loro.

Cosa cambia con un metodo indipendente

Un progetto ERP guidato dalla parte del cliente si riconosce da tre cose.

Si parte dai processi, non dai prodotti. Prima delle demo viene il lavoro noioso e decisivo: mappare come l'azienda lavora davvero, cosa deve assolutamente restare com'è, cosa può cambiare, quali dati devono migrare e quali possono morire nel vecchio sistema. Da qui nasce un capitolato — un documento che descrive cosa serve, contro cui tutte le offerte devono misurarsi.

Le offerte diventano confrontabili. Con un capitolato uguale per tutti, i fornitori rispondono alle stesse domande: stessi moduli, stesse quantità, stessi livelli di servizio, stesse responsabilità sulla migrazione dei dati. Le differenze di prezzo diventano leggibili, e le esclusioni — dove di solito si nascondono i costi che emergono a progetto avviato — vengono a galla prima della firma.

Il progetto ha un direttore lavori. Dopo la firma, qualcuno deve verificare che quanto promesso venga consegnato: seguire gli stati di avanzamento, validare i collaudi, gestire le varianti, tenere il fornitore sui tempi. Nei cantieri edili nessuno si sognerebbe di lasciare questo ruolo all'impresa che costruisce. Nei progetti ERP succede quasi sempre.

I numeri che nessuno mette nelle demo

Le ricerche di settore raccontano da anni la stessa storia: la maggioranza dei progetti ERP sfora budget o tempi, e una parte consistente non consegna i benefici promessi. Le cause quasi mai sono tecniche. Sono un perimetro definito male in partenza, dati sottovalutati («la migrazione è inclusa» — sì, ma di quali dati, puliti da chi?), formazione compressa per risparmiare, e nessuno con l'autorità di dire al fornitore che no, questo non era nei patti.

Sono esattamente i punti che un capitolato scritto dalla parte del cliente inchioda prima della firma — quando la forza contrattuale è ancora vostra.

La domanda da farsi prima di iniziare

Non è «quale gestionale scegliamo?». È: chi, in questo progetto, guadagna solo se noi spendiamo bene? Se la risposta è nessuno, il progetto parte sbilanciato — e i progetti sbilanciati si pagano due volte: alla firma e negli anni successivi.

Questo blog è curato da 4ZEIT, consulenza informatica indipendente per le PMI di Treviso e Venezia. Maggiori informazioni su www.4zeit.it