Modello di dati master di prodotto: La guida completa

Punti chiave

Progettate il modello prima di toccare qualsiasi configurazione PIM/MDM. La maggior parte dei problemi di dati sono problemi di modello, non problemi di dati.

Non comprimete mai tutto in un unico record. Categoria, Variante, Asset, Canale, Fornitore, Prezzo e Unità di misura sono entità distinte. Fonderle è facile da fare e costoso da disfare.

La portata degli attributi è la decisione progettuale con il maggiore impatto. Classificate ogni attributo come globale, specifico per lingua o specifico per canale. Un errore in questa fase compromette la logica di pubblicazione a valle.

Tre errori di varianti/bundle da evitare:

• Introdurre retroattivamente le varianti in una struttura di prodotto piatta
• Memorizzare la composizione del bundle in un campo note invece che in un'entità strutturata
• Definire gli assi delle varianti senza vocabolari controllati ("rosso" / "Rosso" / "ROSSO" compromette la ricerca a faccette)

ID interno, SKU, GTIN, EAN e MPN svolgono ciascuno un ruolo diverso; non confondeteli mai. Usate una tabella di mappatura tra sistemi. Due record che condividono lo stesso GTIN indicano che uno è un duplicato; applicatelo come regola di validazione rigida.

I dati principali appartengono al record base. Le sostituzioni per lingua e canale appartengono a record collegati separati. Definite regole di completezza per combinazione: una descrizione italiana mancante deve bloccare la pubblicazione sul negozio web italiano.

Versionate il modello, assegnate le responsabilità e mantenete un documento vivo leggibile sia dagli sviluppatori che dagli stakeholder aziendali. Senza governance, i problemi di qualità dei dati che avete risolto torneranno gradualmente.

Cos'è un modello di dati master di prodotto?

La maggior parte dei problemi di dati di prodotto non sono problemi di dati. Sono problemi di modello. I dati sono spesso presenti. Sono semplicemente archiviati nella forma sbagliata, nel posto sbagliato, senza le giuste relazioni. È proprio questo che un modello di dati master di prodotto è chiamato a correggere.

Un modello di dati master di prodotto è un progetto formale. Descrive le entità del vostro dominio di prodotto, i loro attributi e le relazioni reciproche. È il disegno architetturale di tutte le vostre informazioni di prodotto.

Il modello di dati master di prodotto non è la stessa cosa di uno schema di database. Uno schema è l'implementazione tecnica. Il modello di dati è il livello concettuale che lo precede. Prima si progetta il modello, poi si implementa lo schema.

Senza un modello chiaro, i dati di prodotto tendono a crescere in modo caotico. I team aggiungono attributi dove sembrano adattarsi. Gli identificatori vengono duplicati. I dati specifici per canale si mescolano ai record principali. L'assenza di un modello esplicito era quasi sempre la causa radice dei problemi di qualità dei dati. Questo vale in particolare per le aziende che gestiscono decine di migliaia di SKU.

Il modello di dati master di prodotto è il fondamento di qualsiasi iniziativa PIM (Product Information Management) o MDM (Master Data Management). Prima di configurare flussi di lavoro, pipeline di importazione o regole di pubblicazione, è necessario sapere come appare la propria struttura dati.

Entità principali e loro relazioni

Ogni modello di dati master di prodotto ruota attorno a un'entità centrale: Prodotto. Tutto il resto vi si connette.

Le entità correlate più importanti sono:

• Categoria – definisce dove un prodotto si colloca nella gerarchia del catalogo e quali attributi gli si applicano.
• Variante – una versione specifica di un prodotto, che si distingue per uno o più assi come taglia o colore.
• Asset – un file digitale collegato a un prodotto, tipicamente un'immagine, un video o un documento.
• Canale – un punto vendita o di distribuzione come un negozio web, un marketplace o un catalogo stampato.
• Fornitore – l'entità che fornisce il prodotto, con i propri identificatori e dati.
• Prezzo – può essere modellato come entità a sé stante quando sono coinvolti più listini prezzi, valute o gruppi di clienti.
• Unità di misura – definisce come il prodotto viene venduto, confezionato o spedito.

La tabella seguente riassume come ciascuna entità si relaziona con Prodotto e la cardinalità di tale relazione.

Un produttore di medie dimensioni di sensori industriali illustra perché la separazione delle entità è importante. Ogni sensore appartiene a una categoria, ha più varianti, è collegato a una scheda tecnica in PDF, viene venduto attraverso tre canali ed è fornito da due fornitori. Modellare tutto ciò come campi di testo piatti in un unico record di prodotto rende i dati ingestibili nel giro di pochi mesi.

Architettura degli attributi

Gli attributi sono i singoli campi dati che descrivono un prodotto. Progettare con cura l'architettura degli attributi è una delle decisioni a maggiore leva dell'intero progetto.

I tipi di attributo definiscono quale tipo di valore contiene un campo: testo, numero, booleano, data, enumerazione, multi-enumerazione o relazione. Scegliere il tipo sbagliato crea problemi a valle. Memorizzare un valore di peso come testo invece che come numero rende impossibile il filtraggio e la conversione delle unità in seguito. Memorizzare un paese di origine come testo libero invece che come enumerazione porta "Italia", "IT", "Italy" e "italia" ad apparire tutti come valori separati nei report.

I gruppi di attributi organizzano i campi in pannelli logici all'interno dell'interfaccia. I gruppi comuni includono Generale, Specifiche tecniche, Logistica e Contenuto marketing. Per un prodotto con 80 attributi, gruppi ben definiti fanno la differenza tra un'interfaccia di editing gestibile e una che nessuno vuole usare. Un gruppo Specifiche tecniche per un sensore industriale, ad esempio, potrebbe contenere Temperatura di esercizio, Grado di protezione IP, Segnale di uscita e Campo di misura — campi che vanno insieme e vengono modificati dalla stessa persona.

Le dimensioni di portata determinano se il valore di un attributo è condiviso globalmente o varia per lingua o canale:

• Globale – un unico valore per tutte le lingue e tutti i canali. Esempi chiari sono il GTIN, l'ID interno e la classificazione delle sostanze pericolose. Questi valori sono per definizione fattuali e universali.
• Specifico per lingua – il valore varia per lingua o area geografica, come il nome del prodotto, la descrizione e il testo delle note legali.
• Specifico per canale – il valore varia per canale di vendita, come un titolo di 80 caratteri formattato per Amazon rispetto a un titolo descrittivo completo per il negozio web.

Questa è la singola decisione progettuale con il maggiore impatto a valle. Sbagliare la portata significa o duplicare inutilmente i dati o forzare contenuti specifici per canale in campi globali, il che compromette la logica di pubblicazione.

L'ereditarietà degli attributi consente ai prodotti assegnati a una categoria di ricevere automaticamente il set di attributi definito per quella categoria. Gli attributi vengono definiti una volta a livello di categoria, e tutti i prodotti sottostanti li ricevono. Quando è richiesto un nuovo attributo "Temperatura di esercizio" per tutti i prodotti della categoria Sensori industriali, una singola modifica si propaga istantaneamente a centinaia di prodotti.

Gerarchia e classificazione dei prodotti

La gerarchia dei prodotti è l'albero di categorie che organizza il catalogo sia per la navigazione che per l'assegnazione degli attributi.

Una struttura piatta con pochi livelli è più facile da mantenere ma offre meno granularità per l'ereditarietà degli attributi. Una struttura profonda offre maggiore precisione ma richiede più sforzo di governance. In pratica, da tre a cinque livelli sono sufficienti per la maggior parte dei cataloghi B2B e B2C. Una gerarchia come Componenti > Sensori > Sensori di pressione > Sensori di pressione ceramici è abbastanza specifica da guidare un'ereditarietà degli attributi significativa senza diventare ingestibile.

Categorizzazione e classificazione sono due concetti distinti che vengono spesso confusi. La categorizzazione colloca un prodotto in un albero di navigazione (es. Elettronica > Fotocamere > Reflex). La classificazione assegna un prodotto a una tassonomia standardizzata come eCl@ss o GS1 GPC, spesso richiesta per l'integrazione EDI o marketplace. Entrambe possono coesistere nello stesso modello, archiviate separatamente, con finalità diverse.

I prodotti multi-categoria sono una sfida reale. Un prodotto che appartiene a due categorie con set di attributi in conflitto necessita di una regola chiara. L'approccio più pratico è utilizzare una categoria primaria per l'ereditarietà degli attributi e le categorie secondarie solo per la navigazione. Il modo in cui si risolve questo a livello di gerarchia determina direttamente come vengono definiti gli assi delle varianti nel passaggio successivo.

Modellazione di varianti e bundle

La modellazione di varianti e bundle è il punto in cui molti modelli di dati master di prodotto si rompono. Vale la pena dedicarvi tempo reale durante la fase di progettazione.

I prodotti semplici non hanno varianti: uno SKU, un set di attributi.

I prodotti configurabili hanno un record padre che definisce il concetto di prodotto e record figli che rappresentano ogni combinazione specifica di assi delle varianti. Una maglietta nelle taglie S, M, L, XL e nei colori Rosso, Blu e Verde è un prodotto configurabile con dodici varianti. Il padre contiene i dati condivisi: marca, materiale e istruzioni per la cura. Ogni variante figlia contiene la propria taglia, colore, SKU e livello di stock. Questa struttura mantiene il catalogo ordinato e rende affidabile il filtraggio per taglia o colore.

Gli assi delle varianti devono essere definiti come vocabolari controllati. Non si vuole che "rosso", "Rosso" e "ROSSO" vengano trattati come tre valori diversi. Oltre alla coerenza dei dati, valori di assi delle varianti non controllati compromettono la ricerca a faccette e la logica dei filtri sul frontend, il che significa che i clienti non possono filtrare i prodotti in modo affidabile per colore, taglia o materiale nel vostro negozio web.

I bundle sono prodotti composti da altri prodotti. Un "Kit iniziale" composto da un sensore, una staffa di montaggio e un cavo è un bundle. Il modello necessita di un'entità di composizione bundle che registri quali componenti ne fanno parte e in quali quantità. Se il bundle è virtuale (assemblato al momento dell'ordine) o fisico (pre-assemblato e stoccato come unità) determina il funzionamento della logica di prezzi e stock.

Nei progetti con gamme di prodotti complesse, raccomandiamo sempre di modellare varianti e bundle esplicitamente prima di iniziare qualsiasi lavoro di configurazione.

I tre errori più costosi che vediamo ripetutamente sono:

• Avviare con una struttura di prodotto piatta e introdurre le varianti retroattivamente
• Trattare la composizione del bundle come un campo note manuale invece che come un'entità strutturata
• Definire gli assi delle varianti senza vocabolari controllati. Ciascuno di questi errori è completamente evitabile nella fase di progettazione del modello ed è molto costoso da correggere dopo il go-live.

Strategia degli identificatori

Gli identificatori sono il modo in cui i vostri sistemi riconoscono e referenziano lo stesso prodotto. Una strategia di identificatori debole porta direttamente a record duplicati e a errori di sincronizzazione.

La tabella seguente riassume i principali tipi di identificatori, chi li assegna, la loro portata e il loro utilizzo principale.

Ogni identificatore svolge un ruolo diverso. Confonderli crea problemi. Un pattern di errore comune è utilizzare il numero articolo ERP come ID interno del PIM. Quando il sistema ERP viene sostituito o i numeri articolo vengono ristrutturati, ogni integrazione si rompe.

La soluzione pratica è una tabella di mappatura degli identificatori tra sistemi. Per ogni record di prodotto, il PIM memorizza il proprio ID interno insieme al numero articolo ERP, al GTIN e all'MPN. Le mappature di importazione ed esportazione referenziano questa tabella esplicitamente. Un esempio concreto: un prodotto arriva dall'ERP con il numero articolo "ERP-00447". Il PIM lo memorizza in un campo ID ERP dedicato. L'integrazione con il negozio web mappa il GTIN. Il feed EDI del distributore mappa l'MPN. Ogni sistema parla la propria lingua, e il PIM traduce tra loro senza ambiguità.

Se due record condividono lo stesso GTIN, uno di essi è un duplicato. Rendere questo una regola di validazione rigida a livello di modello impedisce ai duplicati di entrare nel sistema fin dall'inizio. Un modello di identificatori pulito è anche ciò che rende affidabile la pubblicazione specifica per canale: quando ogni prodotto ha un'identità inequivocabile in tutti i sistemi, inviare i dati giusti al canale giusto diventa un'operazione di routine piuttosto che un'attività di riconciliazione manuale.

Livello canale e lingua

Il record prodotto principale contiene dati validi indipendentemente da dove il prodotto viene venduto o in quale lingua. Il livello canale e lingua contiene tutto ciò che varia.

I dati specifici per canale includono tipicamente:

• Un titolo prodotto riformattato per un marketplace specifico
• Immagini ottimizzate per quel canale
• Testo promozionale rilevante solo per un punto vendita

I dati specifici per lingua includono:

• Nomi e descrizioni tradotti
• Unità adattate alla lingua o alla regione
• Testo normativo specifico per paese

Ogni livello risiede nel proprio posto: i dati principali nel record prodotto base, le varianti linguistiche in record di traduzione collegati, le sostituzioni specifiche per canale in record di assegnazione canale. Mantenere questi livelli puliti è ciò che rende gestibile la pubblicazione multicanale su larga scala. AtroPIM gestisce questa separazione in modo particolarmente efficace, consentendo ai team di arricchire e pubblicare i livelli canale e lingua in modo indipendente senza toccare il record prodotto principale.

Le regole di completezza per combinazione canale/lingua sono una funzionalità di governance che appartiene al modello stesso — si definisce quali attributi sono obbligatori prima che un prodotto possa essere pubblicato su un canale specifico.

Un prodotto privo di descrizione in italiano non può essere pubblicato sul negozio web italiano. Un prodotto senza un GTIN valido non può essere inviato a un marketplace retail.

A seconda dei requisiti del canale, queste regole possono essere blocchi rigidi che impediscono completamente la pubblicazione, o avvisi soft che segnalano la lacuna e consentono la pubblicazione con una sostituzione consapevole. Entrambi gli approcci hanno il loro posto, e il modello deve supportarli entrambi.

Governance e responsabilità all'interno del modello

Un modello di dati master di prodotto non è solo un documento tecnico. È un framework di governance.

I campi obbligatori devono essere applicati dal sistema. Le regole di validazione incorporate nelle definizioni degli attributi rilevano gli errori al momento dell'inserimento, prima che si propaghino a valle. Un campo peso deve rifiutare valori negativi. Un campo EAN deve validare la cifra di controllo. Un campo URL deve verificarne il formato. Un campo titolo prodotto può imporre una lunghezza massima di caratteri per canale. Ciascuna di queste regole elimina un'intera categoria di problemi ricorrenti di qualità dei dati.

Il versioning del modello è qualcosa che la maggior parte dei team trascura finché non ne ha bisogno. Quando si aggiunge un nuovo attributo obbligatorio o si ristruttura una gerarchia di categorie, i record esistenti devono essere migrati. Trattare il modello come un artefatto versionato con un registro delle modifiche e script di migrazione lo rende gestibile. Senza versioning, una modifica strutturale al modello diventa una crisi invece che un'operazione di routine.

La responsabilità significa assegnare chiaramente chi è responsabile di ogni parte del modello: chi può aggiungere nuovi attributi, chi approva le modifiche alla gerarchia di categorie e chi dà il via libera a un nuovo livello di canale. Senza una responsabilità definita, il modello deriva. Nuovi attributi vengono aggiunti senza governance. Le categorie vengono ristrutturate da team diversi in modi incompatibili. I problemi di qualità dei dati risolti nell'implementazione iniziale tornano gradualmente.

Altrettanto importante è mantenere un documento di modello vivo. Non si tratta di un diagramma di database chiuso in un repository tecnico. È un riferimento leggibile accessibile sia agli sviluppatori che agli stakeholder aziendali, che descrive ogni entità, attributo, relazione e regola di validazione in linguaggio chiaro. Un buon documento di modello è ciò che consente l'inserimento di nuovi membri del team, supporta le verifiche esterne e mantiene l'allineamento tra i team man mano che il catalogo evolve.

Se state avviando un progetto PIM o MDM, il primo passo corretto è un audit del modello di dati: mappate le vostre entità attuali, identificate dove i dati sono memorizzati in modo incoerente e definite il modello target prima di toccare qualsiasi configurazione. La qualità di quel modello determina la qualità di tutto ciò che vi viene costruito sopra.