Quando una spedizione va storta la colpa finisce quasi sempre sul magazzino o sul corriere. Nella maggior parte dei casi il problema sta più a monte: due sistemi convinti entrambi di decidere la stessa cosa, oppure nessuno dei due che la decide. Un progetto di integrazione ecommerce si imposta quindi partendo da chi decide cosa.
Quello che segue è pensato per chi deve definire l’architettura prima di un progetto ERP, OMS o WMS, o prima di un replatforming. Non è la descrizione di una soluzione ma un elenco di decisioni, messe nell’ordine in cui si presentano. Vale anche quando parte della catena è esterna: chi ha affidato il magazzino a un fornitore di ecommerce fulfillment ha il WMS fuori dal proprio perimetro, e i confini vanno definiti con più precisione.
La mappa dei sistemi e delle responsabilità
Nel ciclo di spedizione di un ecommerce strutturato intervengono almeno cinque sistemi, e per ciascuno vale la pena scrivere cosa decide e cosa si limita a trasportare.
Il webshop, o il marketplace, raccoglie l’ordine e mostra al cliente le opzioni di consegna con la relativa promessa, ma non è lì che si sceglie il vettore. L’ERP presidia anagrafiche, prezzi, documenti fiscali e contabilità: per quanto sia il sistema più stabile dell’azienda, la logica di routing delle spedizioni non gli appartiene. L’OMS orchestra l’ordine, quindi verifica la disponibilità, decide da quale nodo evadere, gestisce split e priorità e mantiene lo stato commerciale.
Un software WMS governa il magazzino fisico, e quindi ubicazioni, picking, imballaggio, peso e dimensioni reali del collo. La piattaforma di spedizione, per ultima, applica le regole di assegnazione del vettore, crea la spedizione, genera l’etichetta e riporta gli stati di tracking a un formato comune.
Il criterio con cui verificare la mappa è facile da enunciare e faticoso da rispettare: ogni dato ha un solo sistema proprietario, gli altri lo leggono. Dove due sistemi possono scrivere lo stesso campo si crea uno scostamento che passa inosservato finché i volumi restano bassi.
I flussi dati principali del ciclo di spedizione
Definite le responsabilità si passa ai flussi. Sono cinque, e conviene metterli su carta prima di aprire un editor. Chi lavora con un partner di logistica ecommerce dovrebbe disegnarli insieme al fornitore, perché due dei cinque flussi attraversano il confine fra le due aziende.
Proposta dei servizi di consegna al checkout
Il webshop deve mostrare solo le opzioni realmente disponibili per quel carrello, quella destinazione e quel momento della giornata. Entrano in gioco la disponibilità della merce, il nodo da cui partirà l’ordine, il cut-off e i servizi attivi nel paese di destinazione. È il flusso più delicato, perché una promessa esposta al checkout e non sostenuta dai sistemi a valle non genera un ritardo ma un reclamo.
Assegnazione del corriere e integrazione corrieri ecommerce
La scelta del vettore va fatta su dati definitivi, quindi dopo che il magazzino ha confermato peso e dimensioni reali. Assegnare il corriere sul peso teorico di catalogo genera differenze di tariffa e spedizioni rifiutate in fase di creazione, con recupero manuale a valle. In un progetto di integrazione corrieri ecommerce la regola di assegnazione deve stare in un punto solo: duplicarla fra OMS e piattaforma di spedizione lascia due verità e nessun modo di sapere quale delle due ha deciso.
Creazione della spedizione
Alla creazione il sistema riceve dal vettore l’identificativo e i dati di ritiro. Nella pratica capitano tutte e tre le situazioni che di solito vengono considerate marginali: la chiamata che non torna, la spedizione creata due volte per un doppio invio, la chiusura quando nella stessa giornata sono previsti più ritiri. Se non le gestisce il sistema le gestisce una persona, a mano, quando ha meno tempo per farlo.
Generazione delle etichette
Senza etichetta il collo non parte, e questo rende il flusso di stampa il vincolo più rigido di tutta la catena. Vanno decisi il formato accettato da ciascun vettore, il punto della linea in cui si stampa, come si ristampa dopo un errore senza duplicare la spedizione, cosa fa il sistema quando il servizio del corriere non risponde. Un collaudo su pochi ordini misura soltanto il caso migliore.
Tracking e gestione delle eccezioni
Gli stati vanno tradotti in un vocabolario interno unico, altrimenti nessun report è confrontabile fra vettori e ogni analisi torna a essere un lavoro manuale. Va poi deciso chi parla al cliente, su quale canale e in quali momenti: quando webshop, piattaforma di spedizione e assistenza mandano messaggi indipendenti, il cliente riceve informazioni che si contraddicono e chiama. Un tracking delle spedizioni centralizzato serve prima di tutto a evitare questo.
Integrazione diretta con i corrieri o shipping layer?
Su questa scelta pesa soprattutto chi si assume il mantenimento dell’interfaccia nel tempo. Con l’integrazione diretta è il team interno: ogni volta che un corriere modifica un formato o un endpoint, la correzione entra nella coda di sviluppo e compete con le priorità commerciali. Con uno shipping layer quel lavoro passa al fornitore, e il team interno ne mantiene una sola.
Il punto da chiarire in fase contrattuale riguarda i dati: quali informazioni di spedizione e tracking restano estraibili, in quale formato e con che frequenza. È l’elemento che determina quanto è reversibile la scelta e quanto è possibile costruire reportistica indipendente.
Sul piano operativo il layer diventa anche il punto in cui il sistema gestionale e la logistica si scambiano le informazioni sullo stato dell’ordine, senza che ciascun corriere debba essere raggiunto separatamente da entrambi.
Il ruolo dell’OMS software nell’integrazione gestionale ecommerce
Nei progetti di integrazione gestionale ecommerce il software OMS viene sottovalutato con una certa regolarità, perché le sue funzioni finiscono distribuite fra ERP e webshop senza una decisione esplicita. Da lì nascono due conseguenze: la scelta del nodo di evasione la prende un sistema che non vede tutta la giacenza, e lo split degli ordini si regge su soluzioni artigianali che tengono finché i volumi lo permettono.
L’OMS dovrebbe restare proprietario dello stato commerciale dell’ordine e delle decisioni di evasione. Al WMS spettano quelle fisiche, alla piattaforma di spedizione quelle sul vettore. Il vantaggio di questa separazione si vede il giorno in cui qualcosa non torna, perché il perimetro in cui cercare è già definito.
Requisiti delle API spedizioni, sicurezza e ambienti di test
Sul piano tecnico le API spedizioni dovrebbero garantire alcune cose a prescindere dal fornitore. Idempotenza sulle chiamate di creazione, per non generare spedizioni doppie quando una richiesta viene ripetuta. Gestione esplicita di timeout e tentativi. Messaggi di errore che distinguano un problema nei dati da un problema di disponibilità del servizio, perché la reazione operativa è diversa. Versionamento dichiarato, con un preavviso ragionevole sulle modifiche non retrocompatibili.
Sulla sicurezza servono credenziali separate per ambiente, rotazione delle chiavi, tracciabilità di chi ha generato ogni spedizione e attenzione ai dati personali negli indirizzi. Un ambiente di prova separato dalla produzione è la condizione per provare una modifica senza generare spedizioni reali, e va richiesto anche a chi fornisce il servizio di spedizione, non ai soli reparti interni.
La checklist di UAT e cut-over prima del picco
Il collaudo si costruisce sui casi che si rompono. Vale la pena provare un ordine multi-riga che si divide su nodi diversi e produce due spedizioni, un peso rilevato in magazzino diverso da quello di catalogo, un corriere non raggiungibile nel momento della creazione, un’etichetta da ristampare senza duplicare la spedizione, un indirizzo che il vettore non valida, un annullamento arrivato dopo la creazione ma prima del ritiro, un reso avviato su una spedizione già tracciata, una chiusura con due ritiri nella stessa giornata.
Sul cut-over servono una finestra di freeze concordata con tutti i reparti, un piano di rientro scritto e provato almeno una volta, e una data di go-live abbastanza lontana dal picco per avere qualche settimana di esercizio vero prima dei volumi alti. Chi va in produzione a novembre su un flusso di spedizione nuovo si trova a fare debug e stagione insieme.
Quando l’architettura risulta più articolata di quello che il team riesce a presidiare, la conversazione si sposta su quali componenti tenere dentro. Fra le soluzioni logistiche esistono gradi diversi di delega, e la variabile che orienta la scelta è quante persone si possono dedicare al mantenimento delle integrazioni nel corso dell’anno, non solo durante il progetto.