Hai tre persone che ogni mattina esportano file Excel dal gestionale, li rielaborano a mano e li reimportano su un altro sistema. Oppure il tuo e-commerce non parla con il magazzino e le giacenze sono sempre sbagliate. O ancora: il software gestionale che usi da dieci anni non supporta la logica di produzione che hai adottato due anni fa, e hai costruito una serie di workaround che solo Mario in ufficio capisce davvero.
Questi sono i segnali che un'integrazione ERP custom per PMI potrebbe valere l'investimento. Ma "potrebbe" è la parola giusta, perché non sempre la risposta è sviluppare qualcosa di custom.
In questo articolo vediamo come distinguere i casi in cui un connettore o modulo su misura ha senso da quelli in cui stai inseguendo un problema che si risolve più semplicemente.
Prima di ragionare sul "quando", serve chiarire il "cosa", perché sotto questa etichetta ci finiscono cose molto diverse.
Un'integrazione ERP è qualsiasi collegamento che fa circolare dati tra il gestionale aziendale e altri sistemi: l'e-commerce, il CRM, il software di magazzino, la piattaforma di spedizione, i portali dei fornitori. Quando questa integrazione viene sviluppata su misura per la tua azienda, parliamo di connettore ERP personalizzato.
Un modulo ERP custom è invece un'estensione del gestionale stesso: una funzione che il software standard non ha, costruita apposta per coprire un processo specifico del tuo business.
Le due cose hanno costi, tempi e rischi diversi. Un connettore tra due sistemi già documentati è un progetto circoscritto. Riscrivere un pezzo del gestionale è un impegno di tutt'altro livello.
La maggior parte delle PMI italiane usa ERP standard o semi-standard: SAP Business One, Zucchetti, TeamSystem, Sage, o soluzioni verticali di settore. Questi prodotti coprono il 90% dei casi d'uso comuni. Il problema è quel 10% restante.
Ci sono tre situazioni in cui lo sviluppo di un'integrazione gestionale aziendale su misura diventa una scelta razionale.
Prima situazione: processi irriproducibili nel software standard. Alcune aziende hanno logiche operative che non si mappano su nessun ERP esistente. Un'azienda manifatturiera con distinte base dinamiche che cambiano in base alle specifiche del cliente, per esempio, difficilmente trova una soluzione standard che regge senza pesanti personalizzazioni. In questi casi, costruire un modulo custom è spesso più conveniente che pagare anni di customizzazioni al vendor del gestionale.
Seconda situazione: legacy con personalizzazioni accumulate. Hai un gestionale vecchio di dieci anni, modificato nel tempo da più fornitori, con logiche che nessuno ha documentato. Migrare su un ERP nuovo richiede di smontare tutto e ricominciare. Qui la scelta è tra una migrazione completa (costosa, rischiosa) e costruire un layer di integrazione che permette di modernizzare i touchpoint senza toccare il cuore del sistema. Non è la soluzione definitiva, ma spesso è quella pragmatica nel breve periodo.
Terza situazione: costo delle licenze SaaS superiore allo sviluppo custom. Se paghi licenze mensili per un software che usi al 30% delle sue funzionalità, su un orizzonte di due o tre anni il costo totale può superare quello di un sistema sviluppato su misura. Questo calcolo va fatto con attenzione e include manutenzione, aggiornamenti e supporto, non solo il costo iniziale di sviluppo.
Qui vogliamo essere diretti: la maggior parte dei progetti di integrazione ERP custom fallisce non per problemi tecnici, ma perché non andavano fatti.
Il caso più comune è l'azienda che ha processi inefficienti e pensa che un software su misura li risolva. Non è così. Un software custom automatizza i processi che hai, non li migliora. Se il processo è sbagliato, l'integrazione custom ti darà un sistema che esegue in modo efficiente qualcosa che non dovresti fare.
Anche il tema del vendor lock-in con i SaaS è spesso sopravvalutato. Sì, Salesforce o HubSpot ti legano alla loro piattaforma. Ma un modulo ERP sviluppato da un fornitore che non ti ha consegnato il codice sorgente ti lega ancora di più, e con meno alternative di uscita. Il rischio di dipendenza non scompare con il custom: si sposta.
Infine, se il tuo problema si risolve con un connettore no-code (Zapier, Make, o un'integrazione nativa già disponibile), non ha senso sviluppare nulla. Prima di avviare qualsiasi progetto custom, bisogna verificare cosa esiste già.
Una valutazione seria passa da alcune domande concrete.
Primo: quante ore/persona si spendono ogni settimana in attività manuali che un'integrazione eliminerebbe? Se la risposta è "meno di cinque ore totali", i numeri probabilmente non reggono.
Secondo: il processo che vuoi automatizzare è stabile? Se cambia ogni sei mesi, un sistema custom diventa un cantiere permanente.
Terzo: hai già un fornitore in grado di farti una stima su base tecnica, non commerciale? Una stima fatta senza analisi del codice del gestionale esistente non vale nulla.
Quarto: sei disposto a documentare i tuoi processi prima di iniziare? Questo è il punto dove la maggior parte dei progetti si blocca. Lo sviluppo di un erp su misura azienda richiede che i processi siano scritti, non solo "nella testa di Mario".
Se hai risposto sì a tutte e quattro, ha senso procedere con un'analisi tecnica.
Il dibattito "erp custom vs standard" viene spesso impostato male, come se fossero due alternative opposte. In realtà la scelta più frequente nelle PMI è ibrida: gestionale standard per le funzioni comuni (contabilità, fatturazione, magazzino base) e sviluppo custom solo per i moduli o le integrazioni dove il software standard non arriva.
| ERP standard | Modulo/connettore custom | |
|---|---|---|
| Costo iniziale | Basso (licenza) | Più alto, variabile con la complessità |
| Costo nel tempo | Licenze ricorrenti + customizzazioni vendor | Manutenzione + aggiornamenti (controllabili) |
| Adattamento al processo | Sei tu ad adattarti al software | Il software si adatta al tuo processo |
| Tempi di avvio | Rapidi (settimane) | Più lunghi (mesi per soluzioni complesse) |
| Dipendenza dal fornitore | Alta (vendor lock-in) | Alta se il codice non è tuo |
| Quando ha senso | Processi standard, PMI in fase iniziale | Processi differenzianti, legacy complessa |
La colonna "dipendenza dal fornitore" è quella che le aziende sottovalutano di più. Chiedere l'ownership del codice sorgente e la documentazione tecnica non è una clausola opzionale: è la differenza tra un investimento e un affitto.
Un progetto serio di sviluppo modulo ERP o connettore personalizzato ha una struttura abbastanza prevedibile.
Si parte sempre da un'analisi: mappatura dei flussi dati esistenti, documentazione delle API del gestionale, identificazione dei punti di rottura. Questa fase richiede tempo e coinvolgimento del team interno. Chi la salta per "risparmiare" paga il doppio dopo.
Segue la progettazione tecnica: come i sistemi comunicheranno, quali dati si sincronizzeranno, come si gestiscono i conflitti (cosa succede se un ordine viene modificato su due sistemi in contemporanea?).
Poi lo sviluppo vero e proprio, con cicli di test su dati reali. I test su dati reali sono quelli che contano: i casi limite emergono lì, non in ambiente di staging.
Infine il go-live, che nelle PMI va pianificato con attenzione al calendario operativo. Fare un'integrazione gestionale aziendale durante il picco di stagione è una scelta che si paga cara.
Se stai ragionando su un progetto di questo tipo e vuoi capire se i numeri reggono, parlaci del tuo caso: possiamo aiutarti a valutare l'analisi tecnica preliminare.
C'è un'opinione che vale la pena condividere senza troppi giri di parole: la maggior parte dei progetti ERP custom che finiscono male non è colpa del fornitore tecnico. È colpa di un committente che non sapeva cosa voleva, ha cambiato i requisiti a metà progetto e non ha mai documentato i propri processi.
Questo non è un giudizio: è una dinamica strutturale. Le PMI italiane spesso non hanno una figura interna che si occupa di raccogliere e mantenere i requisiti software. Il risultato è che il fornitore costruisce quello che gli viene detto nelle prime riunioni, e quello che viene detto nelle prime riunioni è sempre incompleto.
La soluzione non è scegliere un fornitore migliore. È investire nella fase di analisi almeno quanto si investe nella fase di sviluppo.
Q: Cos'è un'integrazione ERP custom per PMI?
A: È un connettore o modulo sviluppato su misura per far comunicare il gestionale aziendale con altri strumenti (e-commerce, CRM, magazzino) secondo la logica specifica dell'azienda, senza adattarsi ai limiti di un software standard.
Q: Quando conviene sviluppare un connettore ERP personalizzato invece di usare uno standard?
A: Quando i processi si discostano significativamente dal modello del software standard, quando le personalizzazioni accumulate sul vecchio sistema rendono impossibile la migrazione, o quando il costo delle licenze SaaS supera quello dello sviluppo custom su un orizzonte di 2-3 anni.
Q: Quanto tempo richiede lo sviluppo di un'integrazione ERP su misura?
A: Dipende dalla complessità. Un connettore tra due sistemi già documentati può richiedere alcune settimane. Un modulo ERP completo con logiche di business articolate richiede alcuni mesi. La fase di analisi iniziale è quella che pesa di più sul totale.
Q: Quali rischi ci sono nello sviluppo di un modulo ERP personalizzato?
A: Il rischio principale è la dipendenza dal fornitore che ha sviluppato il modulo. Se il codice non è documentato e trasferibile, cambiare fornitore diventa costoso. Serve chiedere esplicitamente ownership del codice sorgente e documentazione tecnica.
Q: ERP custom e ERP standard possono coesistere?
A: Sì, ed è spesso la scelta più pragmatica. Si mantiene il gestionale standard per le funzioni comuni (contabilità, fatturazione) e si sviluppano moduli o connettori custom solo per i processi dove il software standard non basta.
Se gestisci una PMI con un gestionale che non riesce a stare al passo con i tuoi processi, in Press Start possiamo analizzare la situazione tecnica e dirti con chiarezza se un'integrazione custom ha senso o se esistono alternative più rapide. Raccontaci il tuo caso
