Il gestionale non si integra con niente: sostituirlo o metterci un’API sopra

Gennaio 2024: entra in vigore l’obbligo di fatturazione elettronica esteso anche ai forfettari sotto i 25.000 euro. Molte PMI si trovano a dover sincronizzare il gestionale con il sistema di invio SDI, e scoprono in quel momento che il loro software non espone nemmeno un endpoint. Nessuna API, nessun file di esportazione strutturato, nessuna documentazione tecnica. Solo un eseguibile che gira da anni e che “funziona”.
Integrare un gestionale vecchio con qualsiasi sistema esterno è uno dei problemi più frequenti che ci vengono portati. La risposta breve è questa: nella maggior parte dei casi conviene costruire un layer di integrazione prima di buttare tutto. Però ci sono situazioni in cui il gestionale è così chiuso da rendere quella strada più costosa della sostituzione. Capire in quale caso ti trovi è il punto da cui partire.

Perché il gestionale “non si integra con niente”

La causa più comune non è che il software sia rotto. È che è stato costruito in un’epoca in cui l’integrazione non era un requisito. I gestionali nati tra gli anni ’90 e i primi 2000 erano pensati per girare su una rete locale, parlare con un database proprietario e basta. L’idea che dovessero scambiare dati con un e-commerce, un CRM o un sistema di magazzino esterno semplicemente non era nel progetto originale.
Questo crea tre tipi di situazione, che richiedono approcci diversi.
Il primo: il gestionale ha un database accessibile (SQL Server, MySQL, anche Access in qualche caso) ma non espone API. Puoi leggerlo direttamente, costruire un middleware che estrae i dati e li traduce nel formato che ti serve. È la situazione più gestibile.
Il secondo: il gestionale esporta file in formati strutturati, CSV o XML, ma in modo manuale o schedulato. Puoi automatizzare quella lettura e costruirci sopra un layer di sincronizzazione. Funziona, anche se è meno elegante.
Il terzo: il gestionale è una scatola nera. Database proprietario e criptato, nessun export utile, nessuna documentazione, fornitore che non risponde o che ha chiuso. Qui le opzioni si restringono, e la sostituzione diventa concreta.

Quando un’API sopra al vecchio gestionale ha senso

Se il gestionale rientra nel primo o nel secondo caso, aggiungere un layer di integrazione è quasi sempre la scelta giusta. I motivi sono pratici.
Primo: i dati storici restano dove sono. Anni di ordini, anagrafiche clienti, movimenti di magazzino non si migrano in un weekend. Ogni migrazione porta con sé perdite, arrotondamenti, formati incompatibili. Tenerli nel gestionale originale e costruire un ponte verso i sistemi nuovi è meno rischioso.
Secondo: i processi interni non cambiano. Chi usa il gestionale da dieci anni sa dove cliccare. Un cambio di sistema impone formazione, resistenza al cambiamento, un periodo di doppio lavoro. Un middleware è invisibile agli utenti finali.
Terzo: i tempi sono più brevi. Costruire un’integrazione su misura richiede qualche settimana, non mesi. Se il problema è che il gestionale non comunica con l’e-commerce, un middleware che sincronizza ordini, giacenze e anagrafiche può essere operativo in tempi ragionevoli.
L’architettura tipica in questi casi è un servizio intermedio, spesso chiamato middleware gestionale, che gira in background, interroga il database del gestionale a intervalli regolari o su trigger, trasforma i dati nel formato richiesto dal sistema di destinazione e li invia via API. Per la direzione inversa fa lo stesso percorso al contrario. Se ti interessa capire quando questa architettura regge e quando no, il pezzo sulle API custom per integrare gestionali aziendali entra nel dettaglio tecnico.

Quando invece conviene sostituire

Sostituire un gestionale è una decisione che molte PMI rimandano all’infinito perché sembra enorme. A volte lo è. Però ci sono segnali che indicano che il layer di integrazione non è la strada giusta.
Il segnale più chiaro: il database è inaccessibile o criptato e il fornitore non collabora. Se non riesci a leggere i dati in nessun modo, non puoi costruire niente sopra. Puoi provare tecniche di scraping dell’interfaccia grafica del gestionale, ma è una soluzione fragile che si rompe a ogni aggiornamento del software.
Un secondo segnale: il gestionale non copre più i processi reali dell’azienda. Se stai usando fogli Excel paralleli per compensare le lacune del gestionale, il problema non è l’integrazione, è che il software non fa quello che ti serve. Aggiungere un’API su un sistema che già non funziona bene non risolve nulla.
Terzo: il gestionale gira su infrastruttura obsoleta che non puoi mantenere. Se è legato a Windows Server 2012 o a una versione di PHP fuori supporto, il rischio di sicurezza e di blocco operativo supera il valore dell’integrazione. Su questo tema abbiamo già scritto in modo diretto: cosa rischi se il tuo software gira su PHP 5 o Windows Server 2012.
La nostra posizione su questo punto è netta: chi ti propone di “integrare a tutti i costi” senza prima verificare la solidità dell’infrastruttura sottostante ti sta vendendo un lavoro a metà. Un middleware ben fatto su un gestionale che sta per collassare è denaro sprecato.
Se sei in questa situazione, vale la pena leggere anche rifare il gestionale o recuperarlo per capire dove stanno i costi reali delle due opzioni.
Se stai valutando la sostituzione, raccontaci il tuo caso e vediamo insieme da dove conviene partire.

Come si costruisce un’integrazione che regge nel tempo

Ammesso che la strada dell’API abbia senso, il modo in cui viene costruita fa tutta la differenza. Un’integrazione fatta male è peggio di nessuna integrazione: crea dati doppi, sincronizzazioni parziali, errori silenziosi che scopri settimane dopo.
Alcune cose che separano un’integrazione solida da una fragile.
Gestione degli errori esplicita. Ogni chiamata API può fallire. Il middleware deve sapere cosa fare quando fallisce: ritentare, loggare, avvisare qualcuno. Un’integrazione che si blocca in silenzio è un problema che scopri quando il danno è già fatto.
La sincronizzazione deve essere idempotente. Significa che se la stessa operazione viene eseguita due volte, il risultato è lo stesso di una volta sola. Sembra ovvio, ma la maggior parte delle integrazioni fatte in fretta non lo garantisce, e il risultato sono ordini duplicati o giacenze sbagliate.
Serve un log consultabile. Non per fare debug una volta sola, ma per poter rispondere alla domanda “perché ieri sera quell’ordine non è arrivato nel gestionale?” anche tre settimane dopo. Senza log, ogni anomalia diventa un’indagine.
Il formato dei dati va documentato. Quando il gestionale cambia un campo, o l’e-commerce aggiorna la sua API, qualcuno deve sapere dove mettere le mani. Un’integrazione non documentata è un debito tecnico che paghi a ogni aggiornamento.
Su quest’ultimo punto: la manutenzione software custom non è un optional. Un middleware che nessuno mantiene si rompe in silenzio, di solito nel momento peggiore.
Un aspetto spesso sottovalutato: la direzione della sincronizzazione. Molte integrazioni nascono in una sola direzione (dal gestionale verso l’e-commerce, per esempio) e poi si scopre che serve anche l’inverso. Progettare l’architettura con entrambe le direzioni in mente dall’inizio evita di riscrivere tutto dopo sei mesi.

Prima di decidere, fai questa verifica

Non serve un’analisi lunga mesi. Serve rispondere a tre domande.
Il gestionale espone qualcosa? Un database accessibile, un’API anche parziale, un export schedulato. Se la risposta è sì, l’integrazione è percorribile. Se la risposta è no, la sostituzione va messa sul tavolo.
I processi interni funzionano? Se il gestionale fa bene il suo lavoro e il problema è solo la comunicazione con l’esterno, il layer di integrazione risolve. Se il gestionale è già un problema operativo, l’integrazione non lo aggiusta.
L’infrastruttura regge? Se il sistema operativo o il database sono fuori supporto, qualsiasi lavoro di integrazione va fatto su una base instabile. Prima si stabilizza l’infrastruttura, poi si integra.
Queste tre domande non richiedono un’analisi tecnica approfondita per essere poste. Richiedono però risposte oneste, che a volte è più facile ottenere da chi guarda il sistema dall’esterno.
Se hai già le risposte e vuoi capire quale strada ha senso per il tuo caso specifico, scrivici e ti diciamo cosa faremmo noi al tuo posto.

Q: Quando conviene mettere un’API su un gestionale vecchio invece di sostituirlo?
A: Quando il gestionale copre bene i processi interni, ha dati storici che non puoi perdere e il problema è solo la mancanza di comunicazione con sistemi esterni. Un middleware ben fatto risolve in tempi brevi senza toccare il cuore del sistema.
Q: Cos’è un middleware gestionale e a cosa serve?
A: È uno strato software che si mette tra il gestionale e gli altri sistemi aziendali. Traduce i dati da un formato all’altro, gestisce le chiamate e sincronizza le informazioni senza che i due sistemi debbano parlarsi direttamente.
Q: Il gestionale non comunica con l’e-commerce: da dove si parte?
A: Prima si verifica se il gestionale espone già qualche endpoint o file di esportazione. Se sì, si costruisce un layer di integrazione. Se non espone nulla e non ha documentazione tecnica, si valuta se è più veloce un middleware custom o la sostituzione.
Q: Quanto tempo richiede un’integrazione API su un gestionale esistente?
A: Dipende da cosa espone il gestionale. Con un database accessibile, un’integrazione base richiede qualche settimana. Se il gestionale non ha nessun punto di accesso, i tempi si allungano e spesso conviene rivalutare la sostituzione.