In breve: per integrare gestionale, CRM ed e-commerce senza duplicare i dati bisogna stabilire quale sistema è autorevole per ogni informazione, usare identificativi stabili, progettare sincronizzazioni ripetibili, registrare gli errori e prevedere una riconciliazione. Collegare le API non basta: serve governare l’intero ciclo del dato.

Perché nascono i duplicati?

Un cliente può registrarsi nell’e-commerce, essere inserito dal commerciale nel CRM e arrivare nel gestionale attraverso un ordine. Se ciascun sistema crea un record con un identificativo proprio e non esiste una regola di corrispondenza, la stessa azienda può comparire tre volte.

Il problema non si risolve soltanto cercando nomi uguali. Ragione sociale, email, partita IVA e indirizzi possono cambiare o essere incompleti. È necessario definire identità, ownership e modalità di aggiornamento prima di scrivere il collegamento.

Una possibile divisione delle responsabilità

Dato Possibile fonte autorevole Destinatari Decisione da esplicitare
Lead e opportunità CRM Gestionale, report Quando un lead diventa cliente
Catalogo amministrativo Gestionale/ERP E-commerce, CRM Quali campi sono pubblicabili
Contenuti commerciali E-commerce/PIM Canali di vendita Separazione da prezzo e disponibilità
Ordine online E-commerce alla creazione Gestionale, CRM Quando diventa definitivo
Fatturazione Gestionale CRM, area cliente Quali documenti e stati restituire
Disponibilità ERP/WMS E-commerce, commerciale Tempo reale, riserva o aggiornamento periodico
Consensi marketing Sistema definito dal processo privacy CRM e strumenti autorizzati Prova, scopo e revoca

Questa tabella non è universale. L’architettura dipende dal processo. Il valore sta nel decidere una sola responsabilità primaria per ogni informazione.

1. Creare un inventario dei sistemi

Per ogni applicazione servono proprietario aziendale, referente tecnico, versione, ambiente di test, documentazione, metodo di autenticazione, limiti e modalità di assistenza. Vanno inclusi anche file SFTP, esportazioni pianificate, plugin e automazioni costruite nel tempo.

Le integrazioni “invisibili” sono spesso le più rischiose: una macro, un file copiato ogni notte o una casella email che attiva attività manuali può essere indispensabile al processo pur non comparendo nei diagrammi ufficiali.

2. Definire identificativi e regole di corrispondenza

Ogni entità deve avere un identificativo interno stabile. I codici dei sistemi esterni vanno memorizzati come riferimenti, non usati senza verifica come identità universale.

Per clienti e aziende una strategia può usare partita IVA o codice fiscale quando disponibili, email per alcuni contesti e una coda di verifica per corrispondenze ambigue. La fusione automatica di record deve essere prudente: un falso abbinamento può essere più dannoso di un duplicato visibile.

3. Scegliere evento, direzione e frequenza

Ogni flusso deve rispondere a tre domande:

  • quando: evento immediato, sincronizzazione pianificata o richiesta manuale;
  • verso dove: unidirezionale o bidirezionale;
  • quanto: singolo record, variazioni dall’ultimo controllo o intero archivio.

Il tempo reale non è automaticamente migliore. Per disponibilità o pagamenti può essere necessario; per un catalogo secondario un aggiornamento pianificato può essere più controllabile e meno costoso.

4. Rendere le operazioni ripetibili senza duplicare

Una sincronizzazione può essere eseguita due volte per timeout, ritentativo o messaggio duplicato. L’operazione deve riconoscere che l’evento è già stato elaborato oppure produrre lo stesso risultato senza creare un secondo ordine, pagamento o cliente.

In pratica servono chiavi univoche, identificativo dell’evento, stato di elaborazione e regole di aggiornamento. Il semplice “se non trovo il nome, creo” non è sufficiente.

5. Progettare errori, retry e coda manuale

Gli errori non sono eccezioni rare: connessioni lente, credenziali scadute, dati non validi e indisponibilità dei fornitori fanno parte del funzionamento normale di un sistema integrato.

Tipo di errore Risposta corretta Da evitare
Timeout temporaneo Ritentativo controllato con intervallo crescente Creare nuovamente l’operazione
Dato non valido Bloccare il record e spiegare il campo Scartare silenziosamente
Autorizzazione negata Allarme e sospensione del flusso interessato Ritentativi infiniti
Conflitto Applicare ownership o revisione umana Sovrascrivere l’ultimo dato
Servizio indisponibile Coda persistente e modalità degradata Bloccare l’intera applicazione

6. Registrare ciò che serve a capire e recuperare

Un log utile deve consentire di rispondere a: quale flusso, quale record, quale evento, quando, con quale esito e quale tentativo. Non deve esporre password, token o dati personali non necessari.

Dashboard e avvisi devono distinguere un errore isolato da un flusso fermo. Per gli operatori serve una vista comprensibile che consenta di correggere il dato e ripetere l’operazione senza interventi sul database.

7. Aggiungere la riconciliazione

Anche un flusso monitorato può perdere un evento o ricevere un aggiornamento tardivo. La riconciliazione confronta periodicamente quantità e stati tra sistemi: ordini creati, totali, pagamenti, documenti e record senza corrispondenza.

Non sostituisce il monitoraggio in tempo reale. È un controllo indipendente che trova differenze rimaste invisibili e produce una lista lavorabile.

8. Gestire versioni e cambiamenti delle API

Un fornitore può aggiungere campi, modificare regole o dismettere una versione. Il progetto deve registrare versioni usate, dipendenze, scadenze comunicate e test di compatibilità. Le risposte esterne vanno validate anche quando provengono da un servizio noto.

L’OWASP API Security Top 10 include il consumo non sicuro di API: fidarsi automaticamente dei dati esterni, seguire reindirizzamenti o non limitare tempi e risorse può introdurre vulnerabilità nel sistema interno.

9. Proteggere accessi e dati

  • credenziali diverse per ambiente e integrazione;
  • privilegi minimi e rotazione dei segreti;
  • connessioni cifrate;
  • validazione di input e output;
  • limiti di frequenza e consumo;
  • inventario degli endpoint esposti;
  • log senza segreti;
  • revoca rapida in caso di incidente.

I controlli di autorizzazione devono verificare sia la funzione sia l’oggetto: un utente autorizzato a leggere ordini non deve poter ottenere l’ordine di un’altra area modificando un identificativo.

10. Collaudare con casi reali e casi negativi

Il test non deve coprire soltanto il percorso riuscito. Servono duplicati, dati mancanti, volumi elevati, risposte lente, record modificati contemporaneamente, credenziali non valide e ripetizione dello stesso evento.

Prima del rilascio è utile eseguire un confronto completo su un periodo campione e concordare chi decide in caso di differenza.

Roadmap di progetto

  1. inventario dei sistemi e dei flussi manuali;
  2. matrice della fonte autorevole;
  3. selezione del primo flusso ad alto valore;
  4. verifica tecnica di API e ambienti;
  5. mappa dati e regole di identità;
  6. progettazione di errori, log e riconciliazione;
  7. sviluppo e test con casi negativi;
  8. esecuzione parallela controllata, se necessaria;
  9. rilascio con monitoraggio rafforzato;
  10. misura di reinserimenti, errori e tempi eliminati.

Domande frequenti

Serve un’integrazione bidirezionale?

Solo quando entrambi i sistemi devono originare modifiche autorizzate. La bidirezionalità aumenta conflitti e complessità; se una fonte può essere autorevole, il flusso unidirezionale è più semplice da governare.

Webhook o sincronizzazione pianificata?

I webhook riducono il ritardo ma richiedono ricezione affidabile, sicurezza e recupero. La sincronizzazione pianificata è più semplice per dati non urgenti. Spesso si usano entrambi: evento rapido e riconciliazione periodica.

Come evitare ordini duplicati?

Usando identificativi univoci dell’ordine e dell’evento, operazioni idempotenti, vincoli nel database e log dello stato di elaborazione. Il nome del cliente non è una chiave sufficiente.

Che cosa accade se il gestionale non ha API?

Si valutano con il fornitore esportazioni, file strutturati o connettori supportati. L’accesso diretto al database va considerato soltanto con responsabilità e compatibilità chiarite; una procedura manuale controllata può essere preferibile a un collegamento fragile.

Approfondimenti

Leggi quali dati collegare tra e-commerce e gestionale, come sviluppiamo web app e integrazioni software e il caso Alfonso Forni, in cui e-commerce, flussi interni e sistemi aziendali devono condividere informazioni controllate.

Mappa un flusso tra i tuoi sistemi

Fonti tecniche