Indice

Introduzione

Nelle conversazioni con altri imprenditori del settore produttivo torna sempre la stessa domanda: comprare un gestionale pronto o costruirselo su misura? È la classica dicotomia che non ha una risposta giusta, ma ha molte risposte sbagliate. E quelle sbagliate costano decine di migliaia di euro, anni di produttività persa e, nei casi peggiori, la demotivazione di un intero team operativo che si ritrova a combattere con uno strumento che non lo aiuta.

Questo articolo non è una difesa del "build your own" a prescindere. È un tentativo onesto di fornire i criteri reali con cui decidere tra le due strade, basandomi sulle scelte fatte in prima persona e sui casi osservati in altre aziende manifatturiere italiane che gestiscono processi produttivi complessi.

Il mito del "gestionale standard" per settori non standard

Il marketing degli ERP commerciali si regge su una promessa implicita: "il nostro software gestisce tutto, basta configurarlo". In realtà, "tutto" significa "i processi standard di settori maturi" — commercio, distribuzione, manifatturiero tradizionale. Quando il tuo business ha caratteristiche che non rientrano in quelle categorie, la parola "configurare" si trasforma in "personalizzare", e personalizzare in un ERP commerciale ha un costo che il commerciale non ti dice subito.

Prendiamo il caso della stampa digitale grande formato. Il ciclo produttivo non è un magazzino con codici e quantità: è una sequenza di stati — file ricevuto, controllo grafico, coda di stampa su un macchinario specifico, sublimazione o UV-LED, finitura, controllo qualità, imballaggio — che varia a seconda del materiale, del formato, del tipo di applicazione. Ogni combinazione ha regole proprie. Nessun ERP commerciale modella questa logica senza una personalizzazione pesante.

Il consiglio pratico è di fare questo test prima di valutare qualsiasi ERP: prendi il tuo ordine più rappresentativo e chiedi al fornitore di mostrarti — non raccontarti — come lo gestirebbe. Se la dimostrazione richiede "una piccola customizzazione", hai già capito che stai comprando un cantiere, non un prodotto.

Quando il build-in conviene davvero (e quando è un errore)

Costruire un gestionale interno è la scelta giusta in tre situazioni precise. Prima: quando il tuo vantaggio competitivo dipende da processi proprietari che non vuoi — o non puoi — allineare a uno standard di mercato. Seconda: quando il ritmo di cambiamento dei tuoi processi è più veloce di quanto un fornitore esterno possa seguire. Terza: quando hai (o puoi costruire) competenze tecniche interne stabili, non affidate a un freelance che domani potrebbe sparire.

È la scelta sbagliata, invece, quando stai cercando di evitare una spesa. Costruire in casa non è più economico: è diversamente costoso. Invece di pagare licenze e consulenti, paghi sviluppatori, infrastruttura, formazione, manutenzione, documentazione, sostituzione quando qualcuno se ne va. Se pensi che sviluppare internamente sia "gratis perché facciamo tutto noi", ti stai raccontando una bugia che tra due anni ti presenterà il conto.

Il criterio operativo per capire da che parte stare è semplice: se i processi che vuoi informatizzare sono stabili, codificati e ben rappresentati sul mercato, compra. Se i processi sono mutevoli, specifici e rappresentano il tuo modo di fare le cose, costruisci. Nel dubbio, parti ibrido: usa un ERP commerciale per quello che è standard (contabilità, fatturazione, anagrafica clienti) e costruisci un layer applicativo interno per quello che è peculiare del tuo business. È la strada che abbiamo seguito noi e quella che consiglio a chi sta valutando per la prima volta.

Il vero costo di un ERP commerciale personalizzato

Qui serve trasparenza, perché è la parte che fa più male a chi non la conosce in anticipo. Il costo di un ERP commerciale non è il canone di licenza. È la somma di: licenze annuali, giornate uomo del system integrator per l'implementazione iniziale (che durano sempre più del previsto), personalizzazioni, formazione del personale, migrazione dei dati dal sistema precedente, ore di affiancamento post go-live, manutenzione evolutiva ogni volta che cambia un processo interno e — il capitolo più insidioso — le ore del tuo team che sta fermo o funziona a metà durante l'implementazione.

Per una PMI manifatturiera con processi specifici, il conto reale di un'implementazione ERP nei primi tre anni non scende quasi mai sotto i centomila euro, e spesso supera i duecentomila. Non è il canone che ti ammazza, sono le personalizzazioni ricorrenti. Ogni modifica al tuo processo produttivo diventa un ticket al fornitore, un preventivo, un'attesa, una nuova fattura. E ogni aggiornamento di versione rischia di rompere le personalizzazioni, obbligandoti a rifarle.

Un esercizio utile da fare prima di firmare qualunque contratto ERP è chiedere esplicitamente il costo medio di una modifica post go-live — il "costo di un ticket di cambiamento" — e moltiplicarlo per quante modifiche hai fatto al tuo modo di lavorare negli ultimi tre anni. Se il numero ti spaventa, hai appena trovato un motivo serio per valutare la strada interna.

Come partire se decidi di costruirlo: architettura minima

Costruire un gestionale interno richiede disciplina fin dal primo giorno. Non significa scrivere codice di qualità industriale dall'inizio, ma significa prendere alcune decisioni che se fatte male ti costeranno il doppio dopo. Parliamo di quattro scelte minime.

La prima è separare bene i dati dalla logica. Il database deve poter essere interrogato da più applicazioni, non essere cablato dentro il codice di una singola app. Usa viste, procedure, indici fatti bene. Non trasformare il database in un file di appoggio: trattalo come il cuore del sistema, perché è lui che sopravviverà quando riscriverai tutto il resto.

La seconda è progettare per processi, non per moduli. Un processo produttivo è una sequenza di stati con transizioni chiare. Invece di costruire "il modulo magazzino", "il modulo ordini" e "il modulo prestampa" come compartimenti stagni, pensa in termini di "un ordine nel suo ciclo di vita" e progetta il sistema in modo che ogni stato sia tracciabile, rollbackabile e auditabile.

La terza è scegliere uno stack che il mercato supporta ancora tra cinque anni. Non è il momento di usare il framework sperimentale. PHP moderno, Python, Node, Java: stack noiosi, documentati, con tanti sviluppatori disponibili. Il tuo gestionale vivrà quindici anni: lo stack deve essere ancora qui.

La quarta è mettere il logging e le metriche dal giorno uno. Ogni operazione importante deve lasciare una traccia. Quando qualcosa non funzionerà — e accadrà — i log ti salveranno ore di ricerca. È il genere di investimento che non sembra necessario finché non lo è.

Gli errori che ho visto fare alle PMI che ci hanno provato

Gli errori ricorrenti sono quattro, sempre gli stessi.

Il primo è affidare lo sviluppo a un freelance senza un contratto di continuità. Funziona finché la persona c'è. Quando la persona sparisce — perché cambia lavoro, perché alza il prezzo, perché non risponde più — ti ritrovi con un sistema che nessun altro capisce. Soluzione: anche se lavori con un singolo sviluppatore, pretendi documentazione scritta, codice commentato, accesso diretto a tutti i repository e alle credenziali, e coinvolgi almeno un interlocutore tecnico in azienda che sappia leggere il progetto.

Il secondo è costruire troppo prima di misurare. Si parte con la visione del "sistema completo" e si passano mesi a sviluppare funzionalità che poi nessuno usa, mentre il problema operativo vero resta irrisolto. Il consiglio concreto: parti da un processo solo, il più doloroso, fallo funzionare, poi passa al prossimo. Uno alla volta, non tutto in parallelo.

Il terzo è non coinvolgere chi usa il sistema ogni giorno. Un gestionale costruito "per" gli operatori senza "con" gli operatori produce interfacce inutilizzabili, passaggi inutili, campi obbligatori che nessuno capisce. Il test empirico migliore è sedersi accanto a chi lo userà e guardarlo inserire un ordine. Dove si ferma, dove chiede, dove sbaglia: quello è il tuo backlog.

Il quarto è sottovalutare la manutenzione. Il gestionale non si scrive, si allena. Dopo il rilascio iniziale serve uno sforzo continuo di piccoli aggiustamenti, correzioni, ottimizzazioni. Se non pianifichi questo tempo, il sistema si degrada fino al punto in cui nessuno lo usa più correttamente.

Conclusione

La domanda "gestionale pronto o custom" non ha una risposta universale, ha un criterio di scelta. Se i tuoi processi sono peculiari, se cambiano spesso, se incidono sul tuo vantaggio competitivo, costruire internamente — o almeno costruire un layer interno sopra un ERP standard — diventa una scelta ragionevole, a patto di mettere in conto il costo reale in termini di persone, tempo e disciplina. Se invece sei in un settore maturo con processi consolidati, comprare uno strumento di mercato è quasi sempre la scelta più efficiente.

L'errore vero da evitare è la terza via: un ERP commerciale pieno di personalizzazioni fatte male, senza documentazione, dipendente da un fornitore con cui il rapporto si è già logorato. È la configurazione in cui si trovano moltissime PMI italiane, e spesso è peggio di entrambe le alternative pulite. Se ti riconosci in quella descrizione, il primo passo è fare un audit onesto dello stato attuale prima di decidere dove andare.

Le domande più comuni

Quanto costa sviluppare un gestionale custom da zero?

Dipende dal perimetro funzionale. Un gestionale per una PMI con moduli base (anagrafiche, ordini, magazzino, fatturazione) parte da 30.000-50.000 euro per la prima release. Un sistema più esteso (preventivazione, integrazione produzione, portale clienti, reportistica) arriva a 80.000-150.000 euro. A questi vanno aggiunti 15-25% annuo per manutenzione ed evoluzioni. Il costo reale non è solo lo sviluppo iniziale, è la somma di evoluzione, hosting, sicurezza e supporto nel ciclo di vita del software.

Qual è la differenza tra ERP commerciale e gestionale custom?

L'ERP commerciale porta processi standard collaudati, comunità utenti, aggiornamenti regolari, ma costringe l'azienda ad adattarsi ai suoi flussi. Il gestionale custom ricalca esattamente il modo in cui lavori già, ma richiede sviluppo e manutenzione dedicati. La scelta dipende da quanto i tuoi processi sono peculiari: se sono standard, meglio l'ERP; se sono un vantaggio competitivo reale, il custom li preserva. Non esiste una risposta giusta in astratto.

Quanto tempo serve per sviluppare un gestionale custom?

La prima release utilizzabile (MVP che copre i processi vitali) richiede tipicamente 6-12 mesi di lavoro effettivo. Per arrivare al livello "copre tutti i casi gestionali dell'azienda" servono 18-36 mesi, spesso con rilasci incrementali. Il tempo percepito è più lungo del tempo di sviluppo: gran parte viene consumata da raccolta requisiti, test, migrazioni dati e formazione utenti. Preventivare solo lo sviluppo è il primo errore comune nei progetti custom.

Quali sono i rischi di un gestionale sviluppato internamente?

I due rischi principali sono la dipendenza da poche persone chiave e l'accumulo di debito tecnico. Se il gestionale è scritto da una o due persone senza documentazione e senza test, la loro uscita mette a rischio il sistema intero. Il secondo rischio è che ogni fretta produca compromessi tecnici che nel tempo rendono il software difficile da evolvere. Si mitigano entrambi con code review, documentazione minima obbligatoria e versioning serio.

Quando conviene migrare da un vecchio sistema ASP a PHP?

Quando la manutenzione del legacy inizia a costare più dell'investimento in migrazione. I segnali chiari sono: difficoltà a trovare sviluppatori che conoscano la tecnologia, incompatibilità con browser o server moderni, impossibilità di integrare nuovi strumenti via API, bug ricorrenti di cui nessuno ricorda l'origine. La migrazione va fatta per moduli, mai tutta insieme, e accompagnata da una riscrittura selettiva dei processi più critici. Non è un porting, è un ripensamento.

Come si decide tra sviluppo in-house e fornitore esterno?

In-house conviene quando il software è al centro del vantaggio competitivo e serve evoluzione continua guidata dall'azienda. Esterno conviene quando il bisogno è specialistico e temporaneo, o quando non puoi permetterti il costo fisso di un team interno. Una via spesso efficace è ibrida: architettura e manutenzione ordinaria in-house, picchi di sviluppo affidati a fornitori fidati con cui hai già lavorato. Cambiare fornitore ad ogni progetto costa più del risparmio apparente.