Moda e retail
Catalogo e marketplace: una pipeline di integrazione
Le informazioni di prodotto di un'azienda non hanno una sola forma. Il modo in cui il catalogo vive nei sistemi interni e il modo in cui ogni canale esterno pretende di riceverlo sono cose diverse: categorie, attributi obbligatori, varianti, identificativi e regole cambiano da una destinazione all'altra.
Per un'azienda di moda e retail con vendita multicanale è stata progettata e sviluppata una pipeline di integrazione che porta il catalogo aziendale verso più canali esterni senza duplicare la stessa logica in ogni collegamento.
Il dato aziendale resta uno solo. Ciò che cambia da un canale all'altro è isolato nelle regole di mapping e di validazione, così una nuova destinazione si aggiunge riutilizzando le parti comuni.
Contesto
L'organizzazione opera nel settore moda e retail con vendita multicanale. Le informazioni di prodotto provengono da sistemi aziendali differenti e devono alimentare canali esterni che utilizzano modelli, classificazioni, attributi e regole differenti.
Il progetto nasce dall'esigenza di introdurre un livello di integrazione capace di separare il dato aziendale dalle peculiarità dei singoli canali.
Il problema
Lo stesso prodotto non è descritto allo stesso modo dentro l'azienda e fuori. Ogni destinazione impone la propria rappresentazione, e le differenze non sono di dettaglio:
- le categorie interne non coincidono con le classificazioni richieste dai canali;
- ogni destinazione ha attributi obbligatori propri, che il modello interno non prevede nella stessa forma;
- le varianti di un prodotto vengono rappresentate con logiche diverse;
- gli identificativi non sono gli stessi da un sistema all'altro;
- le immagini hanno requisiti di numero, formato e ordine differenti;
- la disponibilità cambia di continuo e va propagata con i tempi e le modalità di ciascun canale;
- descrizioni e contenuti testuali devono essere disponibili nelle lingue richieste;
- ogni canale applica regole proprie su cosa può essere pubblicato e in quale forma.
Il problema non era creare un collegamento punto a punto verso ciascuna destinazione, ma costruire una pipeline riutilizzabile e controllabile: tanti collegamenti separati avrebbero moltiplicato la stessa logica in altrettanti punti da mantenere.
I vincoli
- mantenere i sistemi sorgente già in uso;
- non modificare il modello dati interno a ogni nuovo canale;
- permettere a ogni destinazione di avere regole proprie;
- acquisire i dati da sorgenti multiple;
- gestire modalità e frequenze di aggiornamento diverse;
- isolare gli errori, in modo che il problema di un canale non fermi gli altri;
- rendere tracciabile ogni fase della lavorazione;
- rendere ripetibili le trasformazioni sugli stessi dati;
- poter aggiungere una nuova destinazione senza riscrivere la parte comune.
Sono vincoli che spingono in un'unica direzione: ciò che è comune deve stare in un punto solo, e ciò che appartiene a un singolo canale deve restare separato e sostituibile.
Il ruolo di Andrea
Il progetto è svolto per un cliente diretto. L'analisi viene condotta insieme allo staff del cliente, partendo dai processi reali, dai dati disponibili e dai requisiti dei diversi canali esterni. A partire da questa analisi Andrea segue direttamente:
- progettazione dell'architettura di integrazione;
- definizione dei modelli intermedi;
- progettazione delle regole di acquisizione, trasformazione, mapping e validazione;
- sviluppo dei processi e dei connettori;
- gestione degli aggiornamenti e degli errori;
- successive evoluzioni della pipeline.
Lo sviluppo viene svolto da Andrea. I test tecnici vengono eseguiti durante lo sviluppo; la verifica pre-produzione viene effettuata con lo staff del cliente sul comportamento reale dei flussi e sui dati destinati alla pubblicazione.
La soluzione
La soluzione è una pipeline: il dato di prodotto attraversa fasi distinte, ciascuna con una responsabilità propria. Ogni fase può essere osservata, ripetuta e modificata senza rimettere in discussione le altre, e ciò che riguarda una singola destinazione resta confinato nelle fasi che le appartengono.
Acquisizione
I dati di prodotto vengono recuperati dalle sorgenti aziendali e dalle fonti esterne che li completano, con le modalità e le frequenze proprie di ciascuna. L'acquisizione non interpreta il dato: lo porta dentro la pipeline nella forma in cui è stato ricevuto.
Staging
Il dato ricevuto viene tenuto separato dal dato destinato alla pubblicazione. È la separazione che rende possibile tutto il resto: si può rielaborare a partire da ciò che è stato realmente ricevuto, senza tornare a interrogare la sorgente e senza alterare l'originale.
Normalizzazione
Le informazioni provenienti da sorgenti diverse vengono ricondotte a un modello coerente, indipendente sia dalle sorgenti sia dalle destinazioni. È questo modello intermedio il riferimento della pipeline: i canali non vedono i sistemi interni, e i sistemi interni non devono conoscere i canali.
Arricchimento
Il modello normalizzato viene completato e trasformato con le informazioni che le destinazioni richiedono e che la sorgente non fornisce già nella forma attesa. L'arricchimento lavora sul modello comune, non sulla singola destinazione.
Mapping per destinazione
Qui, e soltanto qui, entrano le regole specifiche di ciascun canale: corrispondenze fra categorie, attributi obbligatori, rappresentazione delle varianti, identificativi, immagini. Aggiungere una destinazione significa aggiungere il suo mapping, non riscrivere la pipeline.
Validazione
Prima dell'invio i dati vengono controllati rispetto ai requisiti della destinazione. Un prodotto incompleto o non conforme viene fermato prima della pubblicazione, dove l'errore costa di più ed è più difficile da ricostruire.
Pubblicazione
I dati validati vengono trasmessi alla destinazione attraverso l'interfaccia che essa prevede, nella forma e con le modalità che richiede.
Aggiornamenti
Un catalogo non si pubblica una volta sola. Le variazioni delle informazioni di prodotto e i flussi di disponibilità vengono propagati nel tempo, con la frequenza che ciascun canale richiede e sostiene.
Errori, log e riesecuzioni
Ogni fase registra cosa ha elaborato e con quale esito. Quando qualcosa non va, la fase che ha prodotto l'errore è identificabile e la lavorazione può essere ripetuta da quel punto sui soli dati coinvolti, senza rifare tutto il percorso e senza propagare il problema alle altre destinazioni.
Localizzazione
I contenuti testuali vengono resi disponibili nelle lingue richieste dai canali che le prevedono. La localizzazione è una fase della pipeline come le altre: entra nel modello comune e viene poi mappata sulla forma che ogni destinazione si aspetta.
Cosa mette in relazione
- Sistemi gestionali e catalogo interno
- Fonti dati esterne
- Piattaforme eCommerce
- Marketplace e canali commerciali
- Sistemi di classificazione
- Servizi esterni raggiunti tramite interfacce applicative
- Sistemi di gestione delle immagini
- Strumenti di localizzazione
- Flussi di disponibilità
I sistemi sono indicati per categoria funzionale. Ciò che conta nel progetto non è quale piattaforma stia a un capo del flusso, ma il fatto che la pipeline resti la stessa quando quel capo cambia.
Il risultato
Il valore principale è la separazione delle responsabilità: il dato aziendale da una parte, i requisiti delle destinazioni dall'altra, e in mezzo un modello comune che non appartiene a nessuna delle due. Il sistema permette di:
- mantenere il dato aziendale indipendente dalle destinazioni;
- isolare in un punto solo i mapping specifici di ciascun canale;
- individuare la fase in cui un errore si è prodotto;
- ripetere le elaborazioni sui dati coinvolti;
- gestire requisiti diversi senza adattare il modello interno;
- aggiungere nuovi flussi riutilizzando le parti comuni;
- far evolvere un canale senza intervenire sugli altri.
Nessuna di queste proprietà è un risultato una tantum: sono le condizioni che permettono al sistema di restare manutenibile mentre i canali cambiano.
Non vengono pubblicate percentuali, tempi risparmiati o altri indicatori quantitativi: non esistono dati documentati e autorizzati, e un numero senza fonte non dimostra nulla.
Stato attuale
Il progetto è attivo dal 2010 e continua a supportare i flussi di integrazione fra i sistemi aziendali e i diversi canali esterni.
Nel tempo la pipeline è stata adattata ed estesa per seguire l'evoluzione dei modelli dati, dei requisiti delle destinazioni, delle modalità di pubblicazione e dei flussi di aggiornamento.
L'architettura è quindi parte di un sistema in esercizio che continua a evolvere insieme ai canali e ai processi dell'organizzazione.
Cosa dimostra questo progetto
Il dato aziendale e la rappresentazione richiesta dai sistemi esterni non sono la stessa cosa, e trattarli come se lo fossero è ciò che rende ingestibili le integrazioni multicanale. Una pipeline serve a rendere esplicito quello che altrimenti resta implicito dentro il codice di ogni singolo collegamento: come il dato viene acquisito, come viene trasformato, come viene mappato sulla destinazione, come viene validato e come viene pubblicato.
È il tipo di lavoro in cui la manutenibilità non è una qualità che si aggiunge alla fine: dipende da come le responsabilità sono state separate all'inizio.
Servizi collegati
Integrazioni e automazione
Dati allineati fra i sistemi senza doverli rifare, con connettori progettati per durare e per essere controllati. Le attività manuali ripetitive spariscono dove conviene farle sparire, lasciando tracciabilità.
Sviluppo ed evoluzione software
Un'applicazione costruita sui processi reali, oppure un sistema esistente rimesso in sicurezza e fatto evolvere senza riscritture forzate, con una sola responsabilità dall'analisi alla produzione e alla manutenzione.
Devi collegare sistemi che rappresentano gli stessi dati in modi diversi?
Possiamo partire dalle sorgenti, dalle destinazioni e dalle regole che oggi vengono gestite manualmente o duplicate nei diversi sistemi, e progettare un'integrazione che resti controllabile nel tempo.