Settembre 15, 2026
0 Comments

Integrare e-commerce ed ERP: dati, flussi e requisiti da definire

Scritto da

Integrare un e-commerce con un ERP significa definire quali informazioni devono passare tra i due sistemi, quale sistema governa ciascun dato, quando deve avvenire lo scambio e cosa deve succedere se qualcosa non funziona. La tecnologia utilizzata per realizzare il collegamento viene dopo queste decisioni.

Un progetto impostato partendo soltanto da un connettore, da un’app o da una API rischia infatti di automatizzare un processo che non è ancora stato chiarito. Prima dello sviluppo conviene quindi descrivere dati, responsabilità, flussi, frequenze di aggiornamento ed eccezioni.

Che cosa significa integrare un e-commerce con un ERP

L’integrazione tra piattaforma e-commerce ed ERP consente a due sistemi distinti di scambiarsi informazioni necessarie alla gestione del canale di vendita e dei processi aziendali.

Lo scambio può riguardare, per esempio, prodotti, prezzi, disponibilità, clienti e ordini. La documentazione ufficiale Shopify descrive l’integrazione con ERP e altri sistemi aziendali come un processo che può coinvolgere dati relativi a clienti, ordini, inventario, cataloghi e prezzi.

Integrare, però, non significa necessariamente copiare ogni informazione in entrambi i sistemi. La prima domanda da porsi è più concreta: quale dato serve a quale processo e quale sistema deve esserne responsabile?

Perché il punto di partenza non è l’API

Una API è un’interfaccia che permette a due software di scambiarsi dati e operazioni secondo regole definite. È uno strumento tecnico importante, ma non stabilisce da sola quali informazioni debbano essere trasferite, chi debba modificarle o come debbano essere gestiti eventuali conflitti.

Lo stesso vale per un connettore già disponibile o per una piattaforma di integrazione: può facilitare il collegamento tecnico, ma deve essere compatibile con il processo reale dell’azienda.

Per questo conviene distinguere due livelli:

livello funzionale: dati, responsabilità, regole, eventi ed eccezioni;
livello tecnico: API, connettori, middleware, app o sviluppi personalizzati utilizzati per implementare quelle regole.

Quali dati possono essere sincronizzati tra e-commerce ed ERP

Le informazioni da scambiare dipendono dal modello operativo dell’azienda. Non esiste una lista valida per ogni progetto, ma alcune aree ricorrono frequentemente.

Area	Esempi di dati	Decisione da prendere
Catalogo	Prodotti, codici, varianti, attributi	Dove vengono creati e aggiornati
Prezzi	Prezzo base, listini, condizioni commerciali	Quale sistema governa il prezzo
Disponibilità	Quantità disponibili e stato delle scorte	Con quale frequenza aggiornare il dato
Clienti	Anagrafica e indirizzi necessari al processo	Quali dati trasferire e quale sistema li aggiorna
Ordini	Righe ordine, quantità, importi, stato	Quando l’ordine deve entrare nell’ERP
Resi e rimborsi	Richieste, quantità, stato operativo	Come coordinare il processo tra i sistemi

La tabella non rappresenta un modello obbligatorio. Serve invece a evidenziare una regola utile: ogni dato sincronizzato dovrebbe essere collegato a un’esigenza concreta del processo.

Non tutti i dati devono necessariamente viaggiare

Replicare informazioni senza una necessità precisa aumenta il numero di dipendenze tra i sistemi e rende più difficile capire dove intervenire quando qualcosa non è coerente.

Prima di aggiungere un flusso è quindi utile chiedersi:

a quale processo serve questo dato;
chi lo utilizza;
dove viene creato o modificato;
quanto deve essere aggiornato;
cosa accade se non viene sincronizzato.

Questo approccio aiuta anche a evitare integrazioni più complesse del necessario.

Stabilire quale sistema è la fonte principale del dato

Uno dei passaggi più importanti consiste nel definire per ciascuna informazione un sistema autorevole, cioè il sistema nel quale quel dato viene governato e considerato di riferimento.

Il principio è coerente con il Master Data Management: la documentazione Microsoft descrive infatti i master data come record autorevoli utilizzati come riferimento per mantenere coerenza e affidabilità delle informazioni.

Nel caso di un’integrazione e-commerce–ERP, la configurazione concreta dipende dall’organizzazione. Un’azienda può, per esempio, decidere che alcune informazioni amministrative o di magazzino siano governate dall’ERP, mentre contenuti editoriali e merchandising rimangano gestiti nella piattaforma e-commerce.

Non è però una regola universale. La decisione deve dipendere da processi, responsabilità e strumenti effettivamente utilizzati.

Evitare due sistemi che modificano lo stesso dato senza regole

Se entrambi i sistemi possono modificare liberamente la stessa informazione, occorre stabilire quale modifica abbia priorità e come vengano gestiti eventuali conflitti.

Senza questa regola possono verificarsi sovrascritture, differenze tra dati visualizzati e dati gestionali oppure aggiornamenti che si rincorrono tra una piattaforma e l’altra.

La domanda utile non è quindi soltanto “questo dato deve essere sincronizzato?”, ma anche:

“Dove nasce, chi può modificarlo e quale sistema prevale se i valori sono diversi?”

Disegnare i flussi prima di scegliere la tecnologia

Un modo semplice per descrivere un’integrazione consiste nel rappresentare ogni flusso attraverso una sequenza di elementi:

evento → dato → sistema di origine → destinazione → momento → regola → eccezione.

Per esempio, senza riferirsi a una specifica implementazione tecnica:

ordine confermato → dati dell’ordine → e-commerce → ERP → al verificarsi dell’evento previsto → creazione o aggiornamento dell’ordine → gestione dell’errore se il sistema di destinazione rifiuta il dato.

Descrivere i flussi in questo modo rende più semplice confrontare le esigenze aziendali con ciò che un connettore, una API o un software di integrazione è realmente in grado di fare.

Flusso unidirezionale o bidirezionale

Un flusso è unidirezionale quando l’informazione passa da un sistema all’altro senza che il secondo la rimandi indietro come aggiornamento dello stesso dato.

È bidirezionale quando entrambi i sistemi possono partecipare allo scambio.

La bidirezionalità non è automaticamente migliore: aumenta le possibilità di interazione, ma richiede anche regole più precise per gestire priorità, conflitti e modifiche simultanee.

Tempo reale o sincronizzazione programmata

Anche la frequenza deve essere definita in funzione del processo.

Alcune informazioni possono richiedere aggiornamenti molto rapidi; altre possono tollerare alcuni minuti o un’elaborazione programmata. Le piattaforme possono inoltre applicare limiti alle API e prevedere modalità diverse di gestione degli eventi.

La domanda progettuale più utile diventa quindi:

“Quanto può essere vecchio questo dato prima che il ritardo produca un problema operativo o commerciale?”

I requisiti da definire prima dello sviluppo

Una buona specifica di integrazione non dovrebbe limitarsi alla frase “collegare l’e-commerce all’ERP”. Deve tradurre l’esigenza in requisiti verificabili.

Requisiti sui dati

quali informazioni devono essere trasferite;
quali campi sono obbligatori;
come vengono rappresentati i valori;
quali identificativi collegano i record nei due sistemi;
quale sistema è autorevole per ciascun dato;
come vengono gestite eventuali trasformazioni o corrispondenze.

Lo SKU può essere utile in alcuni progetti, ma non va considerato automaticamente come identificativo tecnico universale. Occorre definire in modo esplicito come un prodotto, un cliente o un ordine nel sistema A corrisponde al relativo record nel sistema B.

Requisiti sui processi

quale evento avvia il flusso;
chi è responsabile del dato;
quale stato deve essere raggiunto prima del trasferimento;
cosa accade dopo la ricezione;
quali attività restano manuali.

Requisiti sulla sincronizzazione

direzione del flusso;
frequenza di aggiornamento;
priorità delle informazioni;
condizioni che devono attivare o bloccare la sincronizzazione;
eventuali limiti o dipendenze dei sistemi coinvolti.

Requisiti su errori e controllo

come viene registrato un errore;
chi riceve la segnalazione;
quando è possibile effettuare un nuovo tentativo;
come vengono individuati eventuali duplicati;
come si verifica che i sistemi siano tornati coerenti;
quando è necessario l’intervento umano.

Come gestire errori e disallineamenti

Un’integrazione affidabile non è quella nella quale si presume che ogni scambio vada sempre a buon fine. È quella nella quale un errore può essere rilevato, registrato e gestito secondo regole definite.

Le architetture distribuite devono infatti considerare errori temporanei, timeout e consegne duplicate. Microsoft indica il retry come un pattern utile per ripetere alcune operazioni dopo errori temporanei, ma sottolinea anche la necessità di valutare gli effetti della ripetizione.

In pratica, la gestione può seguire una sequenza come questa:

rilevare che il trasferimento non è andato a buon fine;
registrare l’evento e le informazioni necessarie a comprenderlo;
notificare il soggetto o il sistema responsabile quando necessario;
ritentare l’operazione solo quando il tipo di errore lo consente;
riconciliare i dati per verificare che i sistemi siano nuovamente coerenti.

Prevedere le eccezioni già in fase progettuale

Le eccezioni più utili da discutere prima dello sviluppo non sono soltanto errori tecnici.

Possono riguardare, per esempio:

un prodotto privo dell’identificativo necessario;
un’anagrafica incompleta;
un valore che non trova corrispondenza nell’altro sistema;
un servizio temporaneamente non disponibile;
una richiesta inviata più volte;
due valori differenti per lo stesso dato.

Definire in anticipo questi casi rende molto più chiaro anche il collaudo finale dell’integrazione.

Evitare effetti duplicati durante i nuovi tentativi

Un concetto tecnico utile è quello di idempotenza: un’operazione idempotente può ricevere nuovamente la stessa richiesta senza produrre due volte lo stesso effetto.

Microsoft evidenzia che i sistemi distribuiti possono consegnare lo stesso messaggio più volte e che, senza adeguate protezioni, una nuova elaborazione può generare record o azioni duplicate.

Tradotto in un caso e-commerce: se lo stesso ordine viene trasmesso nuovamente a seguito di un errore di comunicazione, il sistema non dovrebbe creare automaticamente un secondo ordine soltanto perché la richiesta è stata ripetuta.

API, connettori e integrazioni personalizzate: la tecnologia viene dopo i requisiti

Una volta definiti i flussi è possibile confrontare le alternative tecniche.

Nel caso di Shopify, la documentazione ufficiale distingue integrazioni dirette, piattaforme iPaaS che agiscono come intermediari e integrazioni personalizzate basate su API. La scelta dipende dal sistema utilizzato e dalle esigenze aziendali.

In termini generali, le alternative possono comprendere:

funzionalità o integrazioni già disponibili;
app e connettori;
piattaforme middleware o iPaaS;
integrazioni personalizzate tramite API.

La soluzione con il maggiore livello di personalizzazione non è necessariamente la migliore, così come una soluzione standard non è automaticamente sufficiente. Occorre verificare la corrispondenza tra requisiti e capacità effettive dell’integrazione.

Shopify ed ERP come esempio concreto

Shopify espone attraverso la propria Admin API aree relative, tra le altre, a prodotti, inventario, clienti, ordini, fulfillment e webhook. Questo rende possibile costruire integrazioni articolate, ma non elimina la necessità di progettare correttamente dati e processi.

La disponibilità tecnica di un’informazione attraverso una API non significa infatti che debba necessariamente essere sincronizzata né che debba esserlo in entrambe le direzioni.

Checklist: cosa definire prima di integrare e-commerce ed ERP

Prima di avviare lo sviluppo può essere utile verificare che siano state definite almeno queste informazioni:

Sistemi coinvolti: quali piattaforme partecipano al processo.
Dati da scambiare: quali informazioni devono realmente viaggiare.
Fonte principale: quale sistema governa ciascun dato.
Identificativi: come vengono messi in corrispondenza i record.
Direzione: da quale sistema parte il dato e dove arriva.
Evento: cosa attiva lo scambio.
Frequenza: quanto rapidamente deve avvenire l’aggiornamento.
Trasformazioni: quali valori devono essere convertiti o mappati.
Errori: quali problemi possono verificarsi e come vengono segnalati.
Retry e duplicati: quando ritentare e come evitare effetti ripetuti.
Responsabilità: chi interviene quando il flusso non funziona.
Test e controllo: come verificare che dati e processi siano coerenti prima e dopo la messa in esercizio.

Quando conviene fermarsi prima dello sviluppo

In alcuni casi il passo più utile non è iniziare immediatamente la configurazione o lo sviluppo, ma completare l’analisi.

Il progetto richiede probabilmente ulteriori decisioni se:

non è chiaro quale sistema governa un’informazione;
due reparti attribuiscono responsabilità differenti agli stessi sistemi;
non sono state descritte le eccezioni principali;
la scelta del connettore è già stata fatta senza una mappa dei flussi;
non esistono criteri per verificare la riuscita della sincronizzazione;
nessuno è chiaramente responsabile della gestione degli errori.

Questi elementi non indicano necessariamente un problema tecnologico. Spesso indicano che il processo deve essere definito meglio prima di essere automatizzato.

Integrare sistemi significa prima di tutto progettare il processo

Un’integrazione e-commerce–ERP efficace nasce da una sequenza di decisioni: quali dati servono, dove vengono governati, come devono muoversi, quando devono aggiornarsi e cosa deve accadere nelle situazioni anomale.

Solo dopo queste scelte diventa possibile valutare con maggiore consapevolezza una integrazione standard, una piattaforma intermediaria o uno sviluppo personalizzato.

È anche l’approccio con cui DieSSe Ingegneria Digitale affronta i progetti di consulenza e-commerce: partire da processi, requisiti e priorità prima di definire strumenti e modalità di implementazione.

Se stai valutando un’integrazione tra e-commerce, ERP e altri sistemi aziendali, un primo passaggio utile è chiarire dati, responsabilità, flussi e requisiti. Richiedi un primo confronto per analizzare il perimetro del progetto.