Il problema raramente è che manca un software. Il problema è che ce ne sono cinque e non si parlano, così le persone fanno da ponte a mano fra un sistema e l’altro. Questa guida spiega come si progetta un’integrazione che regge nel tempo.
Quando due sistemi non comunicano, il collegamento non scompare: viene svolto da una persona. Qualcuno esporta un file, lo rielabora, lo reimporta altrove; qualcun altro ricopia a mano i dati di un ordine dal portale al gestionale. Questo lavoro non compare in nessun budget, ma occupa ore ogni settimana ed è la principale fonte di errori nei dati aziendali.
C’è anche un costo meno visibile: il ritardo. Finché un dato non è stato trasferito manualmente, non esiste per il sistema di destinazione. Le decisioni prese in quella finestra si basano su una fotografia vecchia, e nessuno lo sa.
Prima di scrivere qualsiasi connettore si stabilisce quale sistema è la fonte autorevole per ciascun dato. Senza questa decisione si costruiscono integrazioni bidirezionali che si sovrascrivono a vicenda e nessuno sa più quale valore sia quello giusto.
Si definiscono i flussi: cosa scatena il trasferimento, con quale frequenza, in quale ordine e cosa deve accadere se un passaggio fallisce a meta. La gestione degli errori va progettata insieme al percorso principale, non aggiunta dopo.
Sistemi diversi codificano gli stessi concetti in modo diverso: unità di misura, causali, stati, formati di data. La tabella di corrispondenza fra codifiche è un artefatto di progetto che va mantenuto nel tempo, non un dettaglio implementativo.
Registri consultabili, notifiche sugli scarti e un cruscotto che dica se i flussi di oggi sono passati. Il costo di questa parte si recupera al primo problema che viene individuato prima che arrivi al cliente.
Non da tutte le integrazioni possibili, ma da quella che elimina il maggior numero di reinserimenti manuali. È quasi sempre il collegamento fra il sistema dove entrano gli ordini e quello dove vengono evasi: è il punto in cui il lavoro manuale è più frequente e dove un errore ha conseguenze visibili al cliente finale.
Una volta che quel flusso funziona in modo affidabile, l’infrastruttura di scambio, la gestione degli errori e il monitoraggio sono già costruiti: le integrazioni successive costano una frazione della prima.
È il lavoro di far dialogare fra loro sistemi nati separatamente, in modo che un’informazione inserita una volta sia disponibile ovunque serva senza reinserimenti. Non significa sostituire i sistemi esistenti: significa collegarli stabilendo regole chiare su chi produce ciascun dato e chi lo consuma.
Quasi sempre sì. Si lavora sui punti di scambio che il sistema mette a disposizione: esportazioni programmate, tabelle intermedie, cartelle monitorate, accesso in sola lettura alla base dati. È meno elegante di un’API moderna ma altrettanto affidabile, se progettato con registri e controlli adeguati.
Un collegamento fra due sistemi con interfacce documentate si misura in settimane. I tempi crescono quando uno dei due è chiuso o datato, quando i dati vanno normalizzati perché gli stessi concetti sono codificati in modo diverso, o quando servono trasformazioni di logica applicativa e non solo trasferimento di dati.
Deve essere immediatamente visibile a chi lavora, non solo ai tecnici. Un’integrazione ben fatta ha registri consultabili, code di rielaborazione e notifiche che indicano quale documento non è passato e perché. Un’integrazione che fallisce in silenzio produce disallineamenti che vengono scoperti settimane dopo, quando correggerli è molto più costoso.
Sostituire tutto è un progetto molto più grande, più rischioso e più lungo, e raramente si giustifica quando i sistemi esistenti fanno bene il loro lavoro. L’integrazione permette di ottenere il flusso unico di dati mantenendo gli strumenti che le persone già conoscono. La sostituzione ha senso quando un sistema è realmente a fine vita.
