Punti chiave
- Una struttura dati piatta è la causa radice della maggior parte dei problemi di gestione del database dei prodotti. L'ereditarietà gerarchica degli attributi, dove i prodotti ereditano i campi dalla loro categoria, risolve il problema alla fonte.
- I cataloghi in crescita moltiplicano le varianti per canale e locale più velocemente del numero di prodotti. Un database che non separa i dati di base dal contenuto specifico del canale cede sotto questa pressione.
- La governance funziona solo quando esiste una struttura: la proprietà, i flussi di approvazione e i registri di audit dipendono tutti da definizioni chiare dei campi e da gerarchie di categorie.
- Il momento giusto per progettare la scalabilità è prima che il catalogo cresca, non dopo. Correggere la struttura a 50.000 SKU è un progetto di migrazione; correggerla a 500 costa quasi nulla.
La maggior parte delle aziende inizia a gestire i dati sui prodotti in fogli di calcolo. Funziona finché non smette di funzionare. Nel momento in cui smette di funzionare, il danno è già fatto: record duplicati, denominazione degli attributi incoerente, dati mancanti per metà del catalogo, e nessun modo pulito di inviare informazioni sui prodotti a nuovi canali di vendita.
Questo articolo affronta la gestione del database dei prodotti per team con cataloghi in crescita: quale struttura costruire, cosa si rompe per primo, e quando migrare oltre i fogli di calcolo.
Cosa comporta davvero la gestione del database dei prodotti
Un database dei prodotti è un repository centrale di tutte le informazioni che descrivono i vostri prodotti: nomi, descrizioni, specifiche tecniche, immagini, dimensioni, prezzi, assegnazioni di categorie e contenuti specifici del canale. Funge da unica fonte di verità. Ogni sistema downstream legge da esso: il vostro ERP, la vostra piattaforma e-commerce, il portale del distributore.
Gestire quel database significa mantenere i dati accurati, coerenti e pronti per la pubblicazione su canali diversi mentre il catalogo cresce. Con 200 SKU destinati a un unico canale, è gestibile con tooling di base. Con 5.000 SKU destinati a dieci canali in quattro lingue, richiede una struttura deliberata, una chiara proprietà, e tooling che ne applichi entrambe.
La distinzione tra un database dei prodotti e un foglio di calcolo dei prodotti conta più di quanto possa sembrare. Un foglio di calcolo è una griglia. Un database ha relazioni, tipi di dati applicati, regole di validazione e controlli di accesso. Quella differenza strutturale è ciò che rende uno gestibile su scala e l'altro un vicolo cieco.
Perché i cataloghi in crescita rompono la struttura del vostro database dei prodotti
Nei progetti che abbiamo implementato per produttori nei settori delle attrezzature industriali e dei materiali da costruzione, lo stato iniziale era quasi identico: un file Excel principale, di solito mantenuto da una persona, con colonne aggiunte nel tempo da chiunque ne avesse bisogno. Nel momento in cui un'azienda raggiunge 2.000-5.000 SKU, quel file ha in genere decine di colonne che si applicano a solo una frazione di prodotti, voci duplicate con nomi leggermente diversi, e nessun modo di fare in modo che i campi obbligatori siano effettivamente compilati.
Il problema sottostante è una struttura dati piatta. Ogni prodotto si trova nello stesso formato di riga, indipendentemente dal tipo. Una pompa e una valvola ricevono entrambe le stesse 80 colonne, anche se 40 di queste colonne sono irrilevanti per una di loro.
Un database dei prodotti scalabile utilizza invece un modello di dati gerarchico. I prodotti si trovano all'interno di una gerarchia di categorie e ereditano gli attributi dalla loro categoria, non da un modello universale. Un record di valvola mostra solo i campi rilevanti per la valvola. Un record di pompa mostra i campi rilevanti per la pompa. Definite gli attributi una volta per categoria e il database li applica automaticamente a ogni prodotto assegnato a essa.
Le conseguenze operative sono reali. I team smettono di compilare campi irrilevanti, la qualità dei dati sui prodotti aumenta, e l'onboarding di una nuova categoria di prodotto non richiede di toccare lo schema di ogni prodotto esistente. Le aziende che saltano questo passo di solito lo affrontano di nuovo al prossimo punto critico, solo che a quel punto il catalogo è dieci volte più grande.
La governance segue la struttura. Una volta che avete categorie, ereditarietà degli attributi e definizioni chiare dei campi, potete assegnare la proprietà, richiedere approvazioni prima della pubblicazione dei prodotti e mantenere un registro di audit di ogni modifica. Niente di tutto ciò è possibile in un foglio di calcolo piatto.
Cosa dovrebbe contenere il vostro database dei prodotti
Il record di base per qualsiasi prodotto dovrebbe includere:
- Identificatori: SKU interno, GTIN/EAN, numero di parte del produttore, riferimento del fornitore
- Contenuto descrittivo: nome, breve descrizione, descrizione lunga, punti salienti, parole chiave
- Attributi tecnici: campi specifici per categoria (dimensioni, materiali, certificazioni, tolleranze)
- Media: immagini del prodotto, risorse digitali (disegni, PDF, video), collegate al record del prodotto piuttosto che incorporate
- Relazioni: collegamenti alle varianti, associazioni di accessori/ricambi, sostituti, bundle
- Dati di canale: nomi specifici del canale, descrizioni, prezzi, flag di disponibilità
- Dati logistici: peso, dimensioni, paese di origine, codice HS
- Stato e completezza: stato di pubblicazione, punteggio di completezza, timestamp dell'ultima modifica
La sezione relazioni è dove la maggior parte dei database di piccole e medie dimensioni cade corta. I prodotti non esistono in isolamento. Un sigillo idraulico è un ricambio per cinque pompe diverse. Un sensore è disponibile in dodici varianti. Se il vostro database non ha modo di modellare quelle connessioni, ogni canale che ha bisogno di quell'informazione deve ricostruirla manualmente, o semplicemente non la mostra.
Gestione degli attributi: dove i database dei prodotti cedono
La gestione degli attributi è la sfida ingegneristica principale della gestione del database dei prodotti. Avete bisogno di sufficienti attributi per descrivere completamente ogni prodotto nel vostro catalogo e supportare il processo di arricchimento: aggiungere copy di marketing, traduzioni e contenuti specifici del canale al di sopra della base tecnica. Ma quegli attributi devono anche essere coerenti, accurati e appropriati per il canale per mantenere la qualità dei dati mentre il catalogo cresce.
I due modelli di fallimento sono l'over-engineering e l'under-engineering. L'over-engineering significa creare centinaia di attributi a grana fine fin dall'inizio, la maggior parte dei quali si applica a tre prodotti e crea confusione per chiunque inserisca dati. L'under-engineering significa un singolo campo "descrizione" dove i team riversano tutto, incluse le specifiche tecniche che dovrebbero essere strutturate.
Iniziate con gli attributi richiesti dal vostro canale di vendita a priorità più alta e aggiungete altri quando emergono veri requisiti. Definite i tipi di attributi con precisione (testo, numerico, booleano, elenco enumerato, unità di misura) fin dall'inizio. Questo applica l'integrità dei dati su tutto il catalogo ed evita campi di testo libero per qualsiasi cosa che sarà mai filtrata, confrontata o esportata su un canale che si aspetta dati strutturati.
Le unità di misura meritano un'attenzione particolare. Un peso del prodotto memorizzato come "5 kg" in un campo di testo sembra bene fino a quando non è necessario esportarlo a un rivenditore statunitense che si aspetta libbre, o a una piattaforma che richiede il numero e l'unità in campi separati. Memorizzare il valore numerico e l'unità separatamente, come attributi strutturati, non costa nulla in più quando lo configurate e vi fa risparmiare un lavoro di correzione significativo in seguito. Lo stesso si applica a dimensioni, voltaggi, portate e qualsiasi altra specifica quantitativa nei cataloghi tecnici.
Localizzazione e logica del canale
Un database dei prodotti che contiene solo una versione di ogni campo di testo si rompe nel momento in cui vendete in più di un mercato o attraverso più di un canale. I rivenditori richiedono descrizioni diverse dai distributori. Il mercato tedesco ha bisogno di certificazioni diverse rispetto al mercato statunitense. E come il catalogo cresce, quelle varianti di locale e canale si moltiplicano più velocemente del numero dei prodotti stesso. Un catalogo di 3.000 SKU su cinque canali e tre lingue genera molte più varianti di contenuto rispetto a un catalogo di 10.000 SKU venduti attraverso una singola vetrina.
Il vostro database deve separare il record del prodotto dal contenuto specifico del canale e della lingua sovrapposto ad esso. Gli attributi di base (dimensioni, peso, numero di parte) sono memorizzati una volta. Il contenuto di marketing, le descrizioni, i testi di conformità, i nomi localizzati e le traduzioni sono memorizzati come varianti di quei campi, collegati a una locale o a un canale.
Ottenere questo bene subito previene una ricostruzione in seguito. Sbagliarlo significa che il vostro database dei prodotti è in realtà tre database gestiti in parallelo, incoerentemente.
Il problema della logica del canale si applica anche al prezzo e alla disponibilità. Un prodotto venduto attraverso un distributore all'ingrosso ha diversi livelli di prezzo, quantità di ordine minime e aspettative di tempi di consegna rispetto allo stesso prodotto venduto direttamente. Sono proprietà specifiche del canale dello stesso record di base, non prodotti separati. Un database che non può rappresentare questo costringe i team a mantenere file paralleli o, peggio, record di prodotto duplicati che immediatamente escono di sincronia.
Quando il vostro database dei prodotti supera in crescita un foglio di calcolo
Il punto di flesso di solito non riguarda solo il volume. Le aziende con 500 SKU colpiscono il muro se quei prodotti vanno a quindici canali. Le aziende con 30.000 SKU se la cavano bene se il catalogo è semplice e i canali sono pochi. Ma un catalogo in crescita con requisiti di canale in espansione esporrà una gestione debole del database dei prodotti più velocemente di quasi qualsiasi altra cosa.
I segnali più chiari che avete superato in crescita un database di prodotto basato su foglio di calcolo:
- I dati sui prodotti devono essere riformattati manualmente per ogni esportazione di canale
- Più di una persona ha bisogno di aggiornare gli stessi dati e non c'è controllo di versione
- Le nuove categorie di prodotto richiedono l'aggiunta di colonne che rompono la logica di esportazione esistente
- Non potete rispondere "quanto è completo il nostro catalogo?" senza controllare manualmente
- Gli errori nei dati sui prodotti raggiungono regolarmente i clienti prima di essere catturati internamente
A quel punto, la scelta è di costruire voi stessi un database relazionale strutturato (fattibile per team con forti competenze ingegneristiche) o di utilizzare un sistema di gestione delle informazioni sui prodotti costruito appositamente.
Come un PIM supporta la gestione del database dei prodotti
Un sistema PIM è essenzialmente un database dei prodotti con tutta l'infrastruttura circostante già costruita: il framework di gestione degli attributi, il livello di esportazione del canale, il tracciamento della completezza, il flusso di lavoro per ottenere l'approvazione e la revisione dei prodotti, e gli strumenti di importazione per estrarre dati dai fornitori.
AtroPIM è un PIM open-source costruito sulla piattaforma dati AtroCore. Utilizza un modello di dati dei prodotti completamente configurabile: costruite lo schema intorno ai vostri prodotti, non il contrario.
Per i produttori con cataloghi di prodotti complessi, quella flessibilità conta praticamente. In un progetto con un produttore di equipaggiamenti di sicurezza, il database dei prodotti doveva gestire famiglie di prodotti, varianti di certificazione regionale, documentazione di conformità specifica della lingua e relazioni di ricambi il tutto all'interno dello stesso sistema. Quel tipo di struttura non può essere forzata in uno schema fisso off-the-shelf.
AtroPIM gestisce l'ereditarietà degli attributi attraverso le categorie, quindi gli insiemi di attributi fluiscono ai prodotti automaticamente. La versione di base è gratuita e viene eseguita on-premise o nel cloud. Supporta più canali con override di contenuti specifici del canale, punteggio di completezza a livello di prodotto e canale, e integrazioni dirette con sistemi ERP inclusi SAP, Odoo e Microsoft Business Central. Questo copre il livello di gestione completo di cui un catalogo in crescita ha bisogno senza bloccarvi in un modello di distribuzione fisso.
Costruire un database dei prodotti per la crescita a lungo termine
L'errore comune nella gestione del database dei prodotti è ottimizzare per la dimensione del catalogo di oggi e il numero di canali di oggi. Un catalogo in crescita non aggiunge solo prodotti. Aggiunge categorie, insiemi di attributi, locale e requisiti di canale in combinazioni che una struttura costruita per 500 SKU non può ospitare senza un rework significativo.
Le decisioni strutturali che pagano a lungo termine sono coerenti in ogni catalogo che abbiamo visto. Ereditarietà degli attributi gerarchica su elenchi piatti. Dati di base separati da varianti di canale e locale dal primo giorno. Tipi di dati e campi obbligatori applicati a livello di sistema piuttosto che per disciplina del team. Relazioni dei prodotti modellate esplicitamente piuttosto che sepolte in campi di testo libero. Completezza tracciata in modo che le lacune emergano prima di raggiungere i clienti.
Niente di tutto questo richiede software costoso. Un database relazionale ben progettato gestisce tutto questo. Ma i sistemi PIM costruiti appositamente lo fanno con meno tempo di configurazione, percorsi di aggiornamento mantenuti e strumenti di flusso di lavoro integrati che contano quando i dati dei prodotti sono creati e mantenuti da team piuttosto che da una persona.
L'obiettivo è una struttura che sopravvive all'azienda che cresce, non una che deve essere ricostruita ogni volta che lo fa.
Un test pratico prima di impegnarvi con qualsiasi modello di dati: prendete i vostri cinque prodotti strutturalmente più diversi e cercate di rappresentarli completamente nel modello che state progettando. Se questo esercizio richiede soluzioni alternative, campi di testo libero per dati strutturati o definizioni di attributi duplicate, il modello ha bisogno di revisione prima che lo costruiate sopra. Fissare la struttura a cinque prodotti non costa nulla. Fissarla a cinquantamila è un progetto di migrazione.
Fate bene la struttura e un catalogo in crescita smette di essere un problema di gestione. Diventa qualcosa che il sistema gestisce.