I dati di prodotto raramente hanno origine in un unico luogo. Un produttore potrebbe mantenere le specifiche in un ERP, i prezzi in un foglio di calcolo, le immagini su un'unità condivisa e le descrizioni dei prodotti in un CMS. Ogni sistema contiene un frammento. Nessuno di loro è coerente. Uno chiama l'articolo "Scarpa da Running Blu, Uomo". Un altro ha "Scarpa Running Blu M". Un terzo lo elenca due volte con SKU diversi e dimensioni diverse.
La gestione dei dati master di prodotto (PMDM) è la disciplina che risolve questo problema. Crea un unico record autorevole per ciascun prodotto e rende quel record la fonte da cui ogni sistema collegato attinge. Non una copia. Non una versione locale. Il master.
Cosa sono i Dati Master di Prodotto?
I dati master di prodotto sono le informazioni stabili e fondamentali che definiscono un prodotto. Cambiano raramente e ogni altro sistema dell'organizzazione vi fa riferimento:
- Nome del prodotto, descrizione e SKU
- Codice a barre o GTIN
- Categoria e classificazione
- Attributi fisici: dimensioni, peso, colore, materiale
- Dati su prezzi e costi
- Immagini e risorse digitali
- Dettagli su fornitori e produttori
Questo è diverso dai dati transazionali: ordini di vendita, livelli di inventario, registri di spedizione. I dati transazionali cambiano continuamente e dipendono dalla correttezza dei dati master. Se il record master ha dimensioni errate, ogni prelievo in magazzino e ogni etichetta di spedizione eredita quell'errore.
I dati master di prodotto si collocano anche all'interno di un panorama MDM più ampio che include dati cliente, dati fornitore e dati sulla localizzazione. Questi sono domini di dati separati, ciascuno con i propri requisiti di governance. La PMDM si concentra specificamente sul dominio dei prodotti, ma nella pratica raramente opera in isolamento. Un record di prodotto si collega a record di fornitori, record di clienti e record di localizzazione. I sistemi MDM multi-dominio gestiscono tutti questi insieme. Le implementazioni a singolo dominio gestiscono solo i prodotti. L'approccio più adatto dipende dalla complessità organizzativa e dai requisiti di integrazione.
L'obiettivo della gestione dei dati master di prodotto è rendere il record master abbastanza affidabile che tutti smettano di mantenere la propria versione locale.
Perché le Organizzazioni Ne Hanno Effettivamente Bisogno
Nei progetti implementati per produttori industriali, incontriamo frequentemente lo stesso schema. Un'azienda lancia un prodotto. L'ERP riceve una serie di attributi dal team di ingegneria. La piattaforma di e-commerce riceve una versione diversa dal marketing. Il partner al dettaglio riceve una terza versione esportata da un foglio di calcolo aggiornato sei mesi fa. Nel momento in cui il prodotto raggiunge lo scaffale, tre sistemi hanno tre descrizioni diverse, due pesi diversi e almeno un prezzo conflittuale. Seguono i resi dei clienti. Poi un esercizio di riconciliazione manuale che richiede settimane.
Il costo dei dati di prodotto scadenti non è teorico. Si manifesta in spedizioni restituite, audit di conformità falliti e lanci di prodotti ritardati, il tutto misurabile.
Le industrie regolamentate lo sentono più acutamente. Secondo il regolamento REACH dell'UE (CE 1907/2006), i produttori e gli importatori di sostanze chimiche devono registrare i dati sulle sostanze presso l'Agenzia Europea delle Sostanze Chimiche e fornire informazioni accurate sulla sicurezza in tutta la catena di approvvigionamento (fonte: Commissione Europea: Regolamento REACH). Una classificazione di pericolo errata o una scheda di dati di sicurezza mancante non è a quel punto un problema di qualità dei dati. È un problema legale, con potenziali conseguenze per l'accesso al mercato. La gestione dei dati master di prodotto fornisce la struttura di governance per catturare questi errori prima che raggiungano un sistema downstream, un audit di conformità o un cliente.
Gartner stima che la scarsa qualità dei dati costi alle organizzazioni una media di 12,9 milioni di dollari all'anno, con le incoerenze nei dati di prodotto tra i driver più frequentemente citati di guasti operativi nella produzione e distribuzione (fonte: integrate.io: The Cost of Poor Data Quality).
Per le aziende al di fuori delle industrie regolamentate, il business case è comunque concreto: meno errori d'ordine, onboarding dei fornitori più veloce, time-to-market più breve e meno rielaborazione manuale tra i team.
Tre Casi d'Uso della Gestione dei Dati Master di Prodotto
Gartner descrive tre scenari in cui le organizzazioni hanno effettivamente bisogno di gestire i dati master di prodotto. Comprenderli aiuta a definire l'ambito di un'implementazione prima di selezionare gli strumenti.
Lo scenario buy-side coinvolge prodotti e materiali acquistati da fornitori. I dati di prodotto hanno origine al di fuori dell'organizzazione e gli attributi che arrivano con essi sono spesso incompleti o incoerenti con gli standard interni. L'MDM viene utilizzato qui per convalidare, arricchire e riclassificare i dati dei fornitori in arrivo prima che entrino nei sistemi operativi.
Lo scenario interno copre i dati di prodotto mentre si spostano da sistema a sistema all'interno dell'organizzazione: da PLM o ERP a PIM, da PIM a piattaforme di e-commerce. Ogni passaggio è un punto in cui i dati possono degradarsi. Flussi di lavoro strutturati e regole di convalida gestiscono queste transizioni.
Lo scenario sell-side riguarda la pubblicazione dei dati di prodotto su canali esterni: partner al dettaglio, marketplace, distributori e piattaforme di commercio diretto. La sindacazione dei canali, la distribuzione dei dati corretti nel formato corretto a ogni destinazione, è la preoccupazione principale qui.
La maggior parte delle organizzazioni affronta tutti e tre contemporaneamente. Ma le implementazioni che tentano di risolvere tutti e tre contemporaneamente tendono ad avere problemi di ambito. Iniziare con lo scenario più urgente è quasi sempre il percorso migliore.
Cinque Componenti di un Sistema Funzionante di Gestione dei Dati Master di Prodotto
La tecnologia da sola non risolve un problema di dati. La PMDM funziona quando tecnologia, processo e accountability sono allineati. Cinque componenti fanno accadere questo.
Modello di dati. Il modello di dati definisce come appare un record di prodotto: quali attributi sono obbligatori, come vengono categorizzati i prodotti, quali convenzioni di denominazione si applicano e come le varianti e i bundle si relazionano ai record padre. Senza un modello di dati condiviso, ogni sistema inventa la propria struttura e il problema di riconciliazione ritorna immediatamente. Gli standard GS1 forniscono un framework ampiamente adottato per gli identificativi di prodotto e lo scambio di dati, particolarmente rilevante per i produttori e i distributori che lavorano con partner al dettaglio.
Regole di qualità dei dati. Le regole di qualità definiscono come appare in pratica un record valido: campi obbligatori compilati, tipi di dati corretti, unità e formati standardizzati. I record che non soddisfano questi controlli vengono contrassegnati prima di raggiungere qualsiasi sistema downstream. La profilazione dei dati, che valuta lo stato attuale dei record per identificare lacune, duplicati e incoerenze, è in genere il primo passo per comprendere cosa devono coprire le regole.
Governance dei dati master. Chi può creare un record di prodotto? Chi può modificarlo? Chi risolve un conflitto quando due sistemi non concordano? La governance assegna queste responsabilità attraverso ruoli definiti: un proprietario dei dati stabilisce la politica, gli steward dei dati gestiscono la supervisione operativa e la risoluzione delle eccezioni e i custodi tecnici gestiscono l'integrazione e la convalida. Senza proprietari nominati e processi definiti, il sistema PMDM diventa un altro luogo in cui i dati si accumulano e nessuno è responsabile di essi.
Integrazione di sistema. Il sistema MDM deve connettersi al resto del panorama: ERP, PLM, piattaforme di e-commerce, portali dei fornitori, marketplace. Il livello di integrazione è ciò che rende utile il record master. Le modifiche si propagano verso l'esterno. I sistemi downstream smettono di mantenere le proprie copie.
Flusso di lavoro e approvazioni. La maggior parte dei problemi di qualità dei dati entra in un sistema nel punto di creazione, non dopo. I flussi di lavoro strutturati controllano come un record di prodotto si muove dalla creazione attraverso l'arricchimento, la revisione e l'approvazione prima della pubblicazione, il che impone la qualità alla fonte piuttosto che richiedere una pulizia successiva.
Come Funziona la Gestione dei Dati Master di Prodotto in Pratica
Un nuovo prodotto entra nel sistema. Ecco cosa accade in un ambiente PMDM funzionante.
Per prima cosa, il record viene importato da un foglio di calcolo del fornitore, da una voce ERP o da un invio manuale e viene etichettato con la sua fonte. Il sistema esegue quindi il rilevamento dei duplicati. Se il prodotto esiste già con un nome o SKU diverso, il possibile duplicato emerge per la revisione. Quando due record di fonte sono in conflitto sullo stesso attributo, le regole di sopravvivenza determinano quale valore ha la precedenza. Queste regole sono decisioni aziendali: l'ERP può essere autorevole per gli attributi logistici, mentre il PIM governa le descrizioni di marketing. Un record confermato e risolto dal conflitto avanza come record dorato, l'unica fonte di verità per quel prodotto.
Nella fase di arricchimento, il record viene convalidato rispetto al modello di dati. Gli attributi mancanti vengono contrassegnati. I valori non conformi vengono corretti. Contenuto aggiuntivo come descrizioni, immagini e traduzioni viene aggiunto dal team pertinente. Quindi il record passa attraverso l'approvazione: uno steward dei dati o un product manager firma prima della pubblicazione.
Una volta approvato, il record dorato si distribuisce ai sistemi collegati. L'ERP riceve i dati operativi di cui ha bisogno. La piattaforma di e-commerce riceve il contenuto di marketing. I partner al dettaglio ricevono i dati nei formati da loro richiesti. Quando qualcosa cambia, il ciclo si ripete.
Un record dorato è solo buono quanto la governance che lo circonda. La tecnologia è la parte più facile. La parte più difficile è garantire che ogni team che tocca i dati di prodotto lavori dal stesso record e sia d'accordo su chi lo possiede.
Gestione dei Dati Master di Prodotto: Approcci di Implementazione
Esistono tre modelli strutturali per la gestione dei dati master di prodotto. Quale si adatta dipende da quanti sistemi di origine ha l'organizzazione, quanto sono sostituibili e quanto controllo centrale è realistico.
Il modello centralizzato è il più pulito sulla carta. Tutti i dati di prodotto vivono in un sistema. Ogni altra piattaforma consuma da esso e non possiede nulla. Massima coerenza, ma richiede un investimento significativo e vero cambiamento organizzativo, poiché i team che precedentemente possedevano i propri dati devono rinunciarvi, il che raramente accade senza attrito.
Il modello consolidato è più comune in pratica. I dati vengono prelevati da più sistemi di origine in un hub centrale, vengono puliti e fusi in un record dorato e i sistemi di origine continuano a funzionare indipendentemente. Un distributore chimico con cui abbiamo lavorato aveva dati di prodotto distribuiti tra tre istanze ERP regionali, ciascuna mantenuta da un team diverso per paese. Nessuno poteva essere dismesso. L'approccio consolidato ha permesso loro di costruire un record centrale pulito senza smantellare ciò che stava già funzionando. I sistemi di origine sono rimasti al loro posto; l'hub MDM è diventato il punto di riferimento da cui tutto veniva pubblicato.
Il modello federato salta completamente l'hub centrale. Ogni sistema gestisce i propri dati, ma standard e identificativi condivisi sono concordati nell'organizzazione e il livello MDM coordina i conflitti. Questo funziona in grandi aziende decentralizzate come conglomerati e produttori multi-brand, dove nessun singolo team ha l'autorità di centralizzare tutto. Ma dipende pesantemente dalla governance. Senza di essa, i conflitti si spostano semplicemente dal livello dei dati al livello dei processi.
La maggior parte delle organizzazioni che iniziano per la prima volta utilizza un approccio consolidato, limitato a una singola categoria di prodotto o punto di integrazione. Un rollout limitato di successo costruisce le abitudini di governance organizzativa e la fiducia che un'implementazione più ampia dipende.
Strumenti per Gestire i Dati Master di Prodotto
Quattro categorie di strumenti sono rilevanti qui. Comprendere la differenza tra loro evita un sacco di tempo di valutazione perso.
Le piattaforme MDM dedicate sono costruite per la governance dei dati su scala aziendale. Le loro capacità principali sono deduplicazione, sopravvivenza, creazione di record dorati e integrazione con panorami di sistema complessi. Sono potenti e costose e richiedono team di dati dedicati per funzionare efficacemente. Gli esempi includono Informatica MDM, Stibo STEP, SAP Master Data Governance e IBM InfoSphere MDM.
I sistemi PIM si concentrano sull'arricchimento dei contenuti e sulla distribuzione dei canali. Supportano descrizioni di marketing, gestione delle risorse digitali, localizzazione e sindacazione ai canali di vendita e marketplace. Gestiscono bene i contenuti dei prodotti ma non sono costruiti per la governance multi-dominio o la deduplicazione complessa. Gli esempi includono Akeneo, Salsify, Syndigo e Plytix.
I sistemi ERP gestiscono le operazioni aziendali principali: inventario, approvvigionamento, finanza, gestione degli ordini. Contengono dati di prodotto come parte di processi operativi più ampi ma non sono progettati per la governance o il lavoro sui contenuti. Servono come fonte di dati primaria e punto di integrazione piuttosto che come soluzione PMDM. I sistemi PLM occupano una posizione simile: autorevoli per i dati di ingegneria e sviluppo dei prodotti, ma non costruiti per la distribuzione cross-channel o la governance dei dati master.
Le piattaforme ibride combinano capacità MDM e PIM in un unico sistema, il che elimina la necessità di mantenere due strumenti separati e semplifica l'architettura.
Pimcore è una piattaforma open-source che integra capacità MDM, PIM, DAM e CMS. È costruita intorno a un modello di dati completamente configurabile e basato su oggetti e si adatta alle organizzazioni più grandi che hanno bisogno di una soluzione altamente personalizzata.
AtroPIM è un sistema PIM modulare open-source costruito sulla piattaforma AtroCore, che stessa funziona come livello di gestione dei dati master e integrazione del sistema. AtroCore fornisce la fondazione PMDM: entità configurabili, gestione degli attributi, autorizzazioni basate sui ruoli, automazione del flusso di lavoro e un'API REST che copre il 100% della funzionalità del sistema includendo le configurazioni personalizzate. AtroPIM estende questo con capacità specifiche per i prodotti: pubblicazione multi-canale, gestione dei cataloghi, DAM, contenuti multilingue e integrazioni native con piattaforme di e-commerce inclusi Magento 2, Shopware, WooCommerce e Shopify, nonché sistemi ERP. L'architettura modulare significa che le organizzazioni possono iniziare con il core gratuito e aggiungere moduli premium per l'arricchimento assistito da IA, la gestione avanzata della qualità dei dati e i feed di importazione/esportazione automatizzati man mano che crescono le loro esigenze, senza migrare piattaforme o sostenere costi di licenza crescenti. Sono supportati sia la distribuzione cloud che on-premises.
Per le organizzazioni di medie dimensioni che hanno bisogno di più di un PIM di base ma non sono ancora pronte per il costo e la complessità di una piattaforma MDM aziendale dedicata, i sistemi ibridi come AtroPIM meritano una stretta osservazione.
| Capacità | Piattaforme MDM | Sistemi PIM | ERP / PLM | Ibrido (AtroPIM, Pimcore) |
|---|---|---|---|---|
| Scopo principale | Governance dei dati e record dorato | Arricchimento dei contenuti e distribuzione dei canali | Gestione dei processi aziendali e ciclo di vita dei prodotti | Governance e contenuti in un unico sistema |
| Utenti principali | Architetti di dati, IT, steward dei dati | Product manager, marketer | Ingegneria, finanza, operazioni | Misto, dipende dalla configurazione |
| Qualità dei dati e deduplicazione | Forte | Da basico a moderato | Limitato | Da moderato a forte |
| Arricchimento dei contenuti | Limitato | Forte | Minimo | Forte |
| Sindacazione dei canali | Limitata | Forte | Non supportata | Forte |
| Flusso di lavoro e approvazioni | Avanzato | Da moderato a avanzato | Moderato | Da moderato a avanzato |
| Complessità di integrazione | Alta | Moderata | Alta | Moderata |
| Migliore per | Grandi aziende con ecosistemi di dati complessi | Brand e rivenditori con cataloghi ampi | Gestione dei processi operativi e ciclo di vita dei prodotti | Organizzazioni che desiderano una soluzione unificata MDM e PIM |
Molte organizzazioni più grandi eseguono tutti e tre in combinazione: ERP per le operazioni, una piattaforma MDM dedicata per la governance e un PIM per i contenuti e la distribuzione. Le aziende di medie dimensioni più spesso si consolidano in una piattaforma ibrida per ridurre la complessità dell'architettura e il costo totale.
Cosa Fare Bene Prima di Iniziare la Gestione dei Dati Master di Prodotto
Le iniziative PMDM falliscono più spesso per motivi organizzativi che tecnici. Queste sono le aree che vale la pena risolvere prima di impegnarsi in un'implementazione.
Patrocinio esecutivo. La PMDM si estende su IT, prodotto, marketing e operazioni. Senza il supporto senior, è difficile allineare gli stakeholder o assicurare il budget tra questi team. L'iniziativa si blocca al primo conflitto dipartimentale sulla proprietà dei dati.
Proprietà dei dati. Ogni record di prodotto ha bisogno di un proprietario nominato. Non un team. Un ruolo, idealmente una persona. L'ambiguità qui produce lacune di accountability che si compongono nel tempo e sono difficili da correggere dopo che il sistema è live. La ricerca di Info-Tech Research Group scopre che fino al 75% delle iniziative di governance fallisce principalmente perché la proprietà non è chiara.
Volume e struttura dei dati attuali. Il numero di prodotti, fonti di dati e tasso di cambiamento plasmeranno l'ambito e la selezione dello strumento. Valuta questo prima di valutare le piattaforme, non durante.
Panorama del sistema esistente. La soluzione PMDM dovrà integrarsi con ciò che è già in atto. Le organizzazioni costantemente sottovalutano la complessità e il costo dell'integrazione quando saltano questa valutazione.
Ambito. Iniziare con una categoria di prodotto, un mercato o un punto di integrazione riduce il rischio. Un rollout limitato di successo costruisce la fiducia organizzativa e le abitudini di governance dei dati su cui dipende un'implementazione più ampia.
Manutenzione in corso. I dati di prodotto cambiano continuamente. La PMDM non è un progetto con una data di fine. È una capacità operativa. I processi di personale, manutenzione e governance devono essere definiti dall'inizio. I KPI di qualità dei dati come tassi di completezza dei record, conteggi dei duplicati e tassi di errore di convalida devono essere definiti prima del go-live e tracciati dal primo giorno.
Modelli di Fallimento Comuni
La maggior parte dei progetti PMDM ha gli stessi pochi problemi. Alcuni sono evitabili con una pianificazione migliore. Alcuni sono semplicemente sottovalutati fino a quando emergono. Ma il modello negli implementazioni fallite di gestione dei dati master di prodotto è coerente abbastanza da meritare l'esame prima di iniziare.
Lo scope creep è il più comune. I team tentano di risolvere ogni problema di dati contemporaneamente, il progetto cresce ingestibile e i risultati richiedono troppo tempo per materializzarsi. La fiducia degli stakeholder si erode prima che il sistema fornisca qualcosa di utile.
La migrazione dei dati è costantemente sottovalutata. I dati storici contengono incoerenze, duplicati e lacune che non sono visibili fino a quando la migrazione inizia. Le organizzazioni che bilanciano realisticamente la profilazione dei dati e la pulizia tendono ad avere implementazioni più fluide. Quelle che non lo fanno passano il primo anno a combattere i problemi di qualità dei dati nel loro nuovo sistema.
La negligenza della manutenzione dopo il go-live è l'altro modello persistente. Senza processi di stewardship attiva per mantenere il record dorato attuale, il sistema PMDM gradualmente diverge dalla realtà operativa. Entro diciotto mesi, i team iniziano di nuovo a mantenere copie locali, il che è da dove la maggior parte di loro ha iniziato.
I nostri clienti sono venuti da noi esattamente con questa situazione. Un produttore di medie dimensioni di attrezzature industriali è andato live con una nuova configurazione MDM, l'ha eseguita bene per il primo anno, poi ha perso le due persone responsabili della stewardship dei dati in una riorganizzazione. Nessuno le ha sostituite formalmente. Diciotto mesi dopo, i product manager avevano ricostruito i propri fogli di calcolo lateralmente perché i record master non erano più affidabili. Il sistema era ancora in esecuzione. La governance attorno ad esso non era.
La maggior parte dei fallimenti MDM non sono tecnici. Il sistema funziona. La governance attorno ad esso no.