Connettere due sistemi non è un’integrazione. È l’inizio del problema.
C’è un momento che molte organizzazioni conoscono bene. Due sistemi che devono parlarsi: un ERP e un CRM, una piattaforma di e-commerce e il gestionale, un’applicazione legacy e un servizio cloud. Qualcuno propone un collegamento. I tempi sembrano ragionevoli. Il budget anche.
Sei mesi dopo, i dati non sono allineati, le sincronizzazioni saltano, e ogni modifica a uno dei due sistemi diventa un problema per l’altro.
Il collegamento funziona. L’integrazione non è mai esistita.
Il malinteso che costa caro
Integrazione è una parola che nel mondo IT viene usata per descrivere cose molto diverse. A volte significa un file CSV che passa da un sistema all’altro una volta al giorno. A volte un webhook configurato in fretta. A volte uno script scritto da qualcuno che non lavora più in azienda.
Nessuna di queste è un’integrazione. Sono connessioni. E le connessioni, senza architettura, diventano dipendenze fragili.
La differenza tra una connessione e un’integrazione è la stessa che passa tra un percorso e una strada: uno esiste perché qualcuno ci ha camminato, l’altra è stata progettata per reggere il traffico nel tempo.
Il problema non è tecnico, almeno non all’inizio. È concettuale. Quando si collega due sistemi senza chiedersi come cambieranno nel tempo, chi li gestirà, cosa succede se uno dei due cade: si sta costruendo debito, non infrastruttura.
Cosa succede quando il sistema cambia
Un’organizzazione può gestire correttamente l’integrazione tra e-commerce ed ERP finché i volumi restano stabili e i flussi sono prevedibili. Il problema emerge quando arrivano nuovi marketplace, più sedi operative o logiche promozionali differenti: ciò che era stato costruito come collegamento diventa rapidamente un collo di bottiglia e spesso un punto cieco.
Le conseguenze non si vedono subito. Si accumulano.
Il primo segnale è quasi sempre nei dati: ordini duplicati, clienti creati due volte nel CRM, campi che esistono in un sistema e sono vuoti nell’altro.
Poi arrivano le eccezioni operative. Sincronizzazioni notturne che saltano senza alert. Casi limite che richiedono intervento manuale ogni volta.
Poi i blocchi strutturali: API point-to-point ingestibili al terzo sistema aggiunto, dipendenza da un unico sviluppatore che “sa come funziona” e senza il quale nessuno osa toccare nulla.
A quel punto il costo reale emerge. Non era il progetto iniziale. Sono le ore di supporto, le correzioni manuali, i rallentamenti operativi, le decisioni prese su dati sbagliati.
Tre domande che non vengono mai fatte prima
Un’integrazione progettata correttamente comincia da domande che raramente entrano nelle richieste di offerta.
Come cambieranno questi sistemi nei prossimi tre anni? Un’integrazione costruita su una versione specifica di un software diventa un problema al primo aggiornamento maggiore. La robustezza si misura sulla capacità di assorbire l’evoluzione dei sistemi che connette, non solo sul funzionamento iniziale.
Cosa succede quando qualcosa va storto? Ogni integrazione deve prevedere scenari di errore: timeout, dati malformati, indisponibilità temporanea. Se questi scenari non sono stati progettati, vengono gestiti in emergenza con costi e rischi proporzionali.
Chi sarà responsabile nel tempo? Un’integrazione non è un progetto con una data di fine. È un sistema che vive, che si aggiorna, che richiede manutenzione. Se questa responsabilità non è definita dall’inizio, nel tempo non appartiene a nessuno.
L’integrazione come architettura
Le organizzazioni che gestiscono ecosistemi digitali complessi hanno imparato che l’integrazione non è un problema da risolvere caso per caso. È una competenza da costruire.
Significa avere un layer di integrazione coerente: standard definiti per lo scambio di dati, protocolli condivisi, visibilità su tutti i flussi, capacità di intervenire senza rimettere mano all’intera architettura.
Non è un investimento che si vede subito. Si vede quando arriva il cambiamento: un nuovo sistema, un’acquisizione, una migrazione cloud e l’ecosistema lo assorbe senza traumi invece di rompersi.
Per questo un progetto di system integration efficace parte dall’architettura dei flussi, dalla gestione degli errori, dalla governance dei dati e dalla capacità evolutiva dei sistemi, non dal semplice collegamento tra API.
La domanda giusta da fare
Prima di avviare qualsiasi progetto di integrazione, vale la pena fermarsi su una domanda sola: stiamo costruendo qualcosa che regge nel tempo, o stiamo risolvendo un problema oggi creandone uno più grande domani?
La risposta dipende da come viene affrontato il progetto fin dall’inizio. Non dagli strumenti scelti, non dal budget allocato ma da chi si occupa di progettare prima di connettere.
In TC Consulting affrontiamo la system integration come un problema di architettura, governance ed evoluzione nel tempo. Perché un’integrazione efficace non si misura quando viene rilasciata, ma quando l’organizzazione cambia e il sistema continua a reggere.