Integrare due gestionali che non si parlano: cosa serve sapere prima

Succede in quasi tutte le aziende che hanno più di dieci anni. C'è il gestionale che fa le fatture, c'è il programma della produzione, e in mezzo c'è una persona che ogni mattina apre tutti e due e ricopia. Prima o poi qualcuno chiede: «non si possono collegare?».

Sì, si possono collegare. Ma la parte difficile non è quella che sembra.

Il problema vero non è la connessione

Chi non ci ha mai messo mano immagina che l'ostacolo sia tecnico: far parlare due programmi diversi, magari di due fornitori diversi, magari uno vecchio. Nella pratica quella parte si risolve quasi sempre — con una API, con un database che si legge, nel peggiore dei casi con un file esportato ogni notte. Brutto, ma funziona.

L'ostacolo vero arriva dopo, e ha una forma molto meno interessante: i due programmi non sono d'accordo su cosa sia un cliente. In uno il codice cliente è 1042, nell'altro è CLI-1042. In uno l'azienda è una riga sola, nell'altro ha tre sedi e tre schede. Uno tiene il nome come l'ha scritto il commerciale nel 2018, l'altro come sta in visura.

Finché non si decide quale dei due ha ragione, non c'è integrazione che regga: il collegamento gira, e produce doppioni.

Le tre domande che decidono il progetto

Prima di scrivere una riga di codice servono tre risposte, e non le dà il fornitore: le dà l'azienda.

Chi comanda su ogni dato. Per l'anagrafica cliente il padrone è il gestionale amministrativo; per lo stato di un ordine è la produzione; per il prezzo applicato è il commerciale. Un dato, un padrone. Dove ci sono due padroni, prima o poi si sovrascrivono a vicenda e vince chi ha salvato per ultimo.

Ogni quanto devono allinearsi. Non tutto serve in tempo reale, e il tempo reale costa. Le anagrafiche possono allinearsi una volta al giorno senza che nessuno se ne accorga; lo stato di una spedizione no. Decidere questo prima evita di costruire una cosa complicata dove ne bastava una semplice.

Cosa succede quando qualcosa non torna. È la domanda che nessuno fa e che determina se l'integrazione sopravvive al primo anno. Se arriva un cliente senza partita IVA, il collegamento lo scarta in silenzio? Lo scrive da qualche parte? Avvisa qualcuno? Un'integrazione che fallisce senza dirlo è peggio della persona che ricopiava a mano.

La bonifica viene prima, sempre

Quasi tutti i progetti di integrazione che vanno male vanno male per lo stesso motivo: si collegano due archivi sporchi e si ottiene un archivio sporco grande il doppio.

Prima di collegare si guardano i dati veri. Quanti clienti ci sono nei due sistemi, quanti sono gli stessi scritti in modo diverso, quanti sono chiusi da anni e nessuno li ha mai cancellati. È un lavoro noioso, dura qualche giorno e non si vede — ma è quello che decide se il collegamento reggerà.

Ed è anche il momento in cui salta fuori la cosa utile: spesso si scopre che uno dei due programmi non serve più. Che la produzione usa il gestionale solo per stampare un documento, e che quel documento si può generare dall'altro. Il progetto migliore, a volte, è quello che toglie un sistema invece di collegarlo.

Come si parte senza rischiare

Non si collega tutto insieme. Si prende un flusso solo — l'anagrafica cliente, di solito — e si fa andare in una direzione sola, per due settimane, guardando cosa arriva dall'altra parte. Se in quelle due settimane non nascono doppioni e nessuno si lamenta, si aggiunge il flusso successivo.

E per un po' si tiene acceso anche il vecchio metodo: si ricopia a mano e si confronta. Serve a dormire la notte, e soprattutto serve a scoprire le differenze mentre sono ancora dieci righe e non diecimila.

Se hai due programmi che non si parlano e una persona in mezzo che fa da ponte, parliamone: la prima cosa da capire non è come collegarli, ma quali dati valgono davvero.