Come valutare se un ERP è prematuro

A cosa serve

Questa guida serve a rispondere a una domanda da cinquanta-duecentomila euro prima di firmarla: questo ERP (o CRM, o MES) risolverà i nostri problemi, o li congelerà? Il principio di fondo è noto a chiunque abbia visto implementazioni fallite, e vale la pena dirlo senza giri: il software non mette ordine — richiede ordine. Un sistema informativo codifica processi: se i processi sono chiari e stabili, li accelera e li blinda; se sono confusi, instabili o esistono in versioni diverse per reparto, il software costringe a deciderli in fretta, sotto pressione di progetto, con il fornitore che aspetta — le condizioni peggiori possibili — oppure li fotografa confusi e li rende rigidi. "Prematuro" non significa che l'azienda non meriti lo strumento: significa che comprarlo ora costerebbe più che rimandarlo, perché una parte del prezzo verrebbe pagata in caos codificato.

Quando usarla

Quando un ERP, un CRM, un MES o un WMS è in valutazione — idealmente prima delle demo dei fornitori, perché le demo sono progettate per rendere la domanda "quale?" e far dimenticare la domanda "quando?". Quando l'argomento a favore suona come "ci serve ordine, il sistema ce lo darà" (il segnale d'allarme perfetto: è la premessa rovesciata). E, in versione retrospettiva, quando un sistema già implementato "non ha mantenuto le promesse": quasi sempre la diagnosi è che era prematuro, e la guida aiuta a capire cosa sistemare prima del prossimo tentativo — o del cambio di fornitore, che ripeterebbe l'errore su una piattaforma nuova.

Prima di iniziare

Serve una sola cosa, ma vera: la disponibilità a sentirsi dire "non ancora". La valutazione che segue ha senso solo se il "no, prima X" è un esito accettabile — se la decisione è già presa e si cerca una benedizione, il test darà fastidio e basta. Utile anche mettere sul tavolo il costo pieno del sistema (licenze + implementazione + personalizzazioni + il tempo interno, che nessun preventivo include e di solito pareggia il resto): è il numero contro cui pesare i prerequisiti mancanti.

Sequenza operativa

1. Scrivere il problema che il sistema dovrebbe risolvere — senza nominare il sistema. Una frase per problema: "non sappiamo i margini per commessa", "gli ordini si perdono tra commerciale e produzione", "il magazzino non torna mai". Se la lista non si riesce a scrivere ("ci serve per essere più strutturati"), fermarsi qui: si sta comprando un simbolo di ordine, non uno strumento — ed è la premessa dei fallimenti più costosi.

2. Per ogni problema, il test del processo. Tre domande, in sequenza. Il processo esiste in una versione sola? — se commerciale e produzione descrivono due flussi diversi, il sistema dovrà sceglierne uno, e lo farà il consulente del fornitore (la mappatura leggera dei 2–3 flussi coinvolti, una settimana, dà la risposta vera; la distanza tra nominale e reale qui si paga in personalizzazioni). Le responsabilità sui punti di passaggio sono chiare? — ogni campo di un ERP ha bisogno di qualcuno che lo alimenti e ne risponda: dove la RACI è confusa, i dati nasceranno sporchi, e un ERP coi dati sporchi è un moltiplicatore di sporco. Il processo è stabile o sta cambiando? — codificare un processo in ristrutturazione significa pagare due volte: la configurazione ora e la riconfigurazione tra un anno.

3. Il test del dato. L'ERP vive di anagrafiche: articoli, distinte, listini, clienti, cicli. Domanda secca: queste anagrafiche esistono, sono pulite, e qualcuno ne risponde? Se la risposta è "le sistemeremo durante l'implementazione", tradurre: il progetto includerà mesi non preventivati di pulizia dati fatta di corsa — o partirà sporco. La pulizia delle anagrafiche è lavoro che si può (e conviene) fare prima, a sistema attuale, e vale da sola una parte del beneficio promesso.

4. Il test del problema vero. Per ogni voce del punto 1: è un problema di strumento o di processo/governance travestito? "Non sappiamo i margini" — il gestionale attuale non li calcola, o nessuno carica i consuntivi? "Gli ordini si perdono" — manca il sistema, o manca il proprietario del passaggio? La prova regina è chiedersi: questo problema, potremmo risolverlo domani con un foglio condiviso e una regola? Se sì, il problema non è tecnologico — e il foglio condiviso con la regola è anche il pilota perfetto: se l'organizzazione non riesce a far vivere il foglio, non farà vivere l'ERP, che è il foglio con dieci volte i campi obbligatori.

5. Tirare le somme in tre liste. Verde: problemi con processo unico, responsabilità chiare, dati pronti — qui il sistema renderà, e delimita il perimetro giusto del primo modulo. Gialla: problemi con prerequisiti sistemabili in 60–90 giorni (una RACI da chiarire, un'anagrafica da pulire, un flusso da unificare) — il lavoro pre-ERP, che conviene fare comunque. Rossa: problemi di governance o processi instabili — qui il sistema è prematuro, e la lista rossa è preziosa quanto la verde: è l'elenco di ciò che non va implementato ancora, con il perché.

6. Se si procede: piccolo, in sequenza, con i processi decisi prima. Il perimetro iniziale sui problemi verdi; le decisioni di processo prese e scritte prima che arrivi il consulente (che deve configurare scelte fatte, non farle); le personalizzazioni trattate con sospetto — ogni personalizzazione è spesso una confusione di processo che si rifiuta di essere risolta, comprata a caro prezzo e mantenuta per sempre; e una regola di sequenza: un modulo a regime prima del successivo.

Output atteso

Le tre liste — e in particolare la rossa con le motivazioni: "cosa non implementare ancora, e perché farlo ora costerebbe più che rimandare". Più, tipicamente, un piano di 60–90 giorni di prerequisiti (mappature, RACI, pulizia anagrafiche, un paio di piloti su foglio) che vale da solo una parte del beneficio — e che trasforma l'eventuale acquisto successivo da scommessa a esecuzione.

Errori da evitare

Comprare il sistema per comprare l'ordine (la premessa rovesciata). Lasciare che le decisioni di processo le prenda l'implementatore, per sfinimento e a tariffa oraria. Il big bang — tutti i moduli, tutta l'azienda, una data: il fallimento con il calendario già stampato. Le anagrafiche "da sistemare durante". Le personalizzazioni come default invece che come eccezione motivata. E l'errore simmetrico, che esiste: usare questa guida per rimandare per sempre — quando le liste sono verdi e il dolore è reale, il prematuro è diventato tardivo, e anche quello ha un costo (fogli Excel eroici, dati che non si parlano, decisioni al buio).

Esempio

Un'azienda metalmeccanica da 45 addetti sta per firmare un ERP da 140.000 euro (più implementazione) sull'onda di tre dolori: margini di commessa ignoti, ordini persi nel passaggio commerciale-produzione, magazzino inattendibile. Il test pre-firma, due settimane, ridisegna tutto. Margini: problema giallo-rosso — i consuntivi ore non li carica nessuno perché nessuno ne risponde (RACI, non software: con l'ERP i campi sarebbero rimasti vuoti, solo più costosi). Ordini persi: la mappatura trova tre versioni del flusso ordini, una per commerciale — il sistema avrebbe dovuto sceglierne una in fretta o personalizzarle tutte e tre; il flusso viene unificato prima, in sei settimane, con un passaggio proprietario e un modulo condiviso che da solo azzera gli ordini persi. Magazzino: verde — anagrafiche decenti, processo stabile, responsabile chiaro. La decisione finale: si parte a perimetro ridotto (magazzino e ciclo passivo, 55.000 euro), il resto in sequenza a prerequisiti verificati; il consuntivo ore parte su foglio con owner e review — e quando, otto mesi dopo, entra il modulo commesse, i dati arrivano già vivi. Il titolare, a consuntivo: "il test ci ha fatto spendere meno della metà subito — ma soprattutto ci ha fatto comprare un sistema per un'azienda che nel frattempo era diventata in grado di usarlo".

Collegamento MARTRO

Nella lettura MARTRO la sequenza è un principio, non una preferenza: prima la leggibilità (processi in versione unica, responsabilità chiare, dati proprietari), poi la codifica — perché il software amplifica ciò che trova, in entrambe le direzioni. È lo stesso principio che l'assessment operativo traduce in pratica quando ordina le priorità per dipendenze strutturali: una sezione del report è dedicata proprio a cosa non implementare ancora — perché nelle PMI in crescita il danno tipico non viene dalle cose non fatte, ma dalle cose giuste fatte nell'ordine sbagliato. E la versione accelerata del principio vale per l'AI: il collasso di latenza mostra cosa succede quando si automatizza sopra una governance che non c'è.

Passo successivo

Se il test ha acceso giallo su flussi e responsabilità: Come mappare un processo e Come costruire una RACI sono i prerequisiti operativi. Se il dubbio riguarda strumenti che automatizzano decisioni (pricing, riordini, risposte): il quadro è in Collasso di latenza e Output di modello come input decisionale. Se il sistema è già dentro e non rende: le stesse tre liste, applicate a ritroso, dicono quale prerequisito mancante sta strozzando il ritorno.