Perché le stime standard falliscono, e cosa guardare davvero
Una stima di implementazione ERP è un esercizio di divinazione quando non sai cosa stai guardando.
Un consulente vi dice “tre settimane di formazione”. Ma formazione di cosa? Su quale contenuto? Per quale livello di profondità? La risposta cambia tutto. E quasi nessuno la pone.
La verità è che il tempo di formazione e avviamento non dipende dal software. Dipende da voi. Dalla chiarezza che avete sui vostri processi, dalla qualità dei vostri dati, dalla capacità del vostro team di assorbire cambiamenti.
Due aziende implementano lo stesso ERP. Una lo stabilizza in quattro settimane. L’altra in quattro mesi. Non è il software che è diverso. Sono loro.
Quello che conta davvero
Quando guardate una stima di progetto, non chiedetevi “quanto tempo ci vuole per implementare il software”. Chiedetevi “quanto tempo ci vuole per farvi capire come dovrebbe funzionare il vostro business”.
Perché l’ERP non vi insegna come funzionare. Vi forza a decidere come funzionare. E se non lo avete ancora deciso, il tempo si allunga indefinitamente.
Durante la formazione, il consulente mostra come inserire un ordine nel sistema. Ma per farlo, dovete decidere: quali informazioni raccogliamo al momento della ricezione dell’ordine? Chi autorizza i prezzi speciali? Come tracciamo i cambiamenti? Che succede se il cliente cambia l’ordine a metà?
Se avete già risposte a queste domande, la formazione è esecuzione di una logica che conoscete. Se non le avete, la formazione diventa discussione di come dovrebbe funzionare il vostro business. E questo non è formazione. È consulenza strategica. Prende il tempo che prende.
Il punto critico: quando iniziare la formazione
Una formazione efficace inizia quando voi sapete già come dovrebbe funzionare il processo nuovo. Non quando pensate di saperlo. Quando lo sapete davvero, documentato e deciso.
Se cominciate la formazione prima di aver fatto questo lavoro, la formazione si trasforma in scoperta. E la scoperta è lenta.
Se fate il lavoro prima (mappare i processi, decidere le regole, documentare le eccezioni), la formazione è veloce. Perché state insegnando qualcosa che è già stato pensato.
Il ruolo della qualità dei dati
Un altro fattore invisibile nei tempi è il stato dei vostri dati attuali.
Se migrate dati sporchi, il sistema parte con sporcizia dentro. Dovete passare settimane dopo il go-live a scoprire errori: articoli duplicati, prezzi incoerenti, fornitori con nomi diversi che sono lo stesso fornitore.
Se pulite i dati prima del go-live, il sistema parte pulito. E la stabilizzazione è questione di giorni, non di settimane.
Ma la pulizia non è lavoro dell’ERP. È lavoro vostro, fatto prima. E questo tempo non è nei “tempi di implementazione” perché nessuno lo conta. È invisibile. E poi vi sorprende.
Disponibilità del team: il moltiplicatore invisibile
Un team che può dedicare il 100% del tempo alla formazione e all’implementazione impara in un tempo X.
Un team che è disponibile al 50% (perché deve continuare il lavoro normale in parallelo) impara nello stesso contenuto, ma ci mette il doppio del tempo. Perché la pratica non può essere densa.
Un team che è disponibile al 30% (emergenze costanti, altri progetti, assenze) non impara davvero. Finisce la formazione e ricominciano gli errori da capo. Perché non c’è stata pratica vera.
La capacità di dedicare attenzione è il moltiplicatore invisibile nei tempi di progetto.
Identificare chi impara… velocemente
Un elemento che quasi nessuno misura è la velocità con cui il vostro team assorbe il nuovo sistema.
Se avete persone che capiscono il sistema in una settimana e possono insegnare agli altri, il progetto scala. Una persona insegna a cinque. Cinque insegnano a venti.
Se non avete queste persone, il consulente deve insegnare a tutti. E uno insegna a uno. Il tempo è lineare, non esponenziale.
Identificare chi sono queste persone, prima di partire, è fondamentale per stimare realisticamente.
La domanda cruciale
Quando vi danno una stima di implementazione, la domanda che dovete fare è questa:
“Avete chiesto al nostro team quanto tempo può dedicare realmente? Avete visto i nostri processi documentati? Avete valutato lo stato dei nostri dati? Avete identificato chi nel nostro team imparerà il sistema velocemente?”
Se la risposta è “no, lo faremo durante il progetto”, allora la stima è azzardata.
Se la risposta è “sì, abbiamo considerato tutto questo”, allora potete chiedervi: questa stima vi sembra realistica in base a voi stessi, non in base al software?
Di cosa disponete per stimare concretamente. E correttamente
Non numeri assoluti. Voi avete i dati che contano:
Sapete quanti giorni uomo potete dedicare. Sapete se i vostri processi sono chiari o caotici. Sapete se i vostri dati sono affidabili o sporchi. Sapete chi nel vostro team è veloce e chi è lento ad apprendere.
Una stima realistica parte da qui. Non da tabelle preparate (pur con cura 🙂 dalla software house.
