"Il nostro gestionale è vecchio, non si integra con niente." Lo sentiamo dire spesso, e quasi sempre è falso. Vecchio non vuol dire chiuso: vuol dire che la porta d'ingresso è diversa e costa di più.

Le porte sono tre. Vale la pena conoscerle anche se il lavoro lo farà qualcun altro, perché sapere quale avete cambia completamente cosa è ragionevole chiedere e quanto è ragionevole pagare.

Porta 1: la API

È la porta principale, quella pensata apposta. Il gestionale espone un indirizzo a cui altri programmi possono chiedere dati in modo ordinato, con un'autenticazione e delle regole. I software di fatturazione moderni e i gestionali in cloud ce l'hanno quasi tutti.

Cosa la rende comoda: il fornitore si prende la responsabilità di non romperla senza avvisare, i permessi si scelgono (leggo i clienti, non tocco le fatture), e quando qualcosa va storto ve lo dice con un errore chiaro invece di lasciare dati a metà.

Il tranello da evitare: chiedere più permessi di quelli che servono. Un connettore che deve solo leggere non deve avere il diritto di scrivere. Non è una formalità: è la ragione per cui un errore nel codice non può fare danni, perché anche volendo non gli è permesso.

Porta 2: il database, in lettura

Il gestionale è installato in sede, non ha API, ma il suo archivio sta su un database che si può leggere. Si concorda un utente con soli permessi di lettura e si va a prendere quello che serve.

Cosa la rende praticabile: funziona anche con software che non ricevono aggiornamenti da anni, e i dati sono tutti lì, senza i limiti di quello che il fornitore ha deciso di esporre.

Il prezzo da pagare: dovete capire come è fatto l'archivio, che nessuno vi documenterà, e resta il rischio che un aggiornamento del gestionale cambi le tabelle sotto i piedi. Per questo un collegamento così va scritto con l'aspettativa che un giorno si romperà, e con un controllo che se ne accorga subito.

La regola non trattabile: sola lettura, e mai scrivere dentro l'archivio di un gestionale dalla porta di servizio. Un dato fiscale sistemato a mano nel database è un danno che si scopre in sede di controllo.

Porta 3: l'export periodico

Nessuna API, niente accesso al database, ma il gestionale sa produrre un file: un export di clienti, uno del venduto, uno dello scadenzario. Si prende quel file a intervalli regolari e lo si riversa nel CRM.

Cosa la rende accettabile: costa poco, non richiede permessi sul sistema di nessuno ed è la strada più veloce per iniziare a vedere qualcosa.

Cosa dovete sapere prima: i dati non sono aggiornati al minuto ma a ieri, o alla settimana scorsa. Per l'anagrafica e il fatturato va benissimo. Per una disponibilità di magazzino, no. Il punto non è la qualità della soluzione, è dire chiaramente a chi la userà quanto è vecchio quello che sta guardando.

La domanda prima di tutte: chi comanda il dato

Qualunque porta scegliate, la decisione che conta viene prima ed è sempre la stessa: per ogni dato, quale sistema è il padrone. Il CRM legge dal padrone e mostra. Non lo corregge.

Sembra un dettaglio filosofico, ed è invece la differenza fra un'integrazione che regge negli anni e una che dopo sei mesi produce due verità diverse per lo stesso cliente, con le persone divise in due partiti su quale delle due sia giusta.

Quando serve davvero scrivere nei due sensi, per esempio il calendario, si può fare: ma la regola su chi vince nei conflitti va decisa e scritta prima di accendere il collegamento, non il giorno in cui capita il primo conflitto.

Come lo verifichiamo noi

Prima di preventivare un'integrazione facciamo una ricognizione: che porta ha il vostro gestionale, quanto sono puliti i dati che ne escono, quali campi hanno un significato univoco e quali sono stati usati per dieci cose diverse negli anni. Il risultato è un foglio con la strada percorribile e cosa comporta.

È la fase meno spettacolare del lavoro ed è quella che decide se il progetto finisce bene. Trovate come lavoriamo nella pagina delle integrazioni del CRM, e se volete sapere in quale dei tre casi siete, di solito bastano trenta minuti.