La maggior parte dei progetti PIM non fallisce perché il software era sbagliato. Falliscono per decisioni prese settimane o mesi prima del go-live: modellazione dei dati saltata, sforzo di migrazione sottovalutato, integrazioni rinviate alla "fase 2". I problemi sono prevedibili. Lo sono anche le soluzioni.
Acquistare Prima di Essere Pronti
L'errore più comune in un'implementazione PIM avviene prima che inizi: scegliere una piattaforma mentre il processo interno è ancora indefinito.
I team programmano demo dei vendor, confrontano i tier di prezzo e negoziano contratti mentre la loro tassonomia dei prodotti è incoerente, le fonti dati non sono chiare e nessuno ha stabilito chi possiede i dati di prodotto. Il PIM viene acquistato. Poi rimane in stand-by mentre l'allineamento interno recupera.
Un PIM non risolve un problema di processo. Fornisce l'infrastruttura per eseguire un processo. Se il processo non è definito, stai semplicemente aggiungendo uno strato costoso sopra lo stesso disordine.
Prima di creare una lista ristretta di vendor, come minimo due cose devono essere stabilite: conosci quali sistemi attualmente contengono i dati di prodotto e quali alimenteranno il PIM, e hai un chiaro proprietario interno per la qualità dei dati di prodotto. Senza queste, la selezione del vendor è prematura. L'ambito del canale e la struttura della famiglia di prodotti possono essere affinati successivamente, ma la proprietà dei dati e la mappatura delle fonti devono esistere prima di qualsiasi conversazione sulla piattaforma.
L'Implementazione PIM Inizia con la Preparazione dei Dati
La migrazione dei dati è costantemente la fase più sottovalutata di qualsiasi implementazione PIM, inizia con il piano di implementazione PIM. I team allocano due settimane. Ne occorrono sei.
Il divario quasi sempre viene dallo stesso posto: i dati di prodotto sono sparsi su più sistemi senza un'unica fonte di verità. La denominazione degli attributi differisce tra l'ERP e i fogli di calcolo legacy. Record duplicati che nessuno sapeva esistessero saltano fuori a metà audit. Valori mancanti emergono solo quando qualcuno tenta di mapparli a un campo di destinazione. Ognuno di questi è gestibile di per sé. In combinazione, sono ciò che trasforma una stima di due settimane in una realtà di sei settimane.
I dati dei fornitori sono un problema a parte. I produttori che acquisiscono specifiche di prodotto da dozzine di fornitori in genere scoprono che ognuno consegna dati in un formato diverso, con nomi di campi diversi, unità diverse e livelli di completezza diversi. Normalizzare questo prima dell'importazione non è un compito da poco.
Nei progetti implementati per produttori di apparecchiature industriali, l'audit dei dati ha rivelato regolarmente che dal 30 al 40% degli attributi di prodotto erano incompleti o incoerenti tra i sistemi di origine. Questa scoperta arrivava sempre come una sorpresa per il cliente, anche quando il catalogo era relativamente piccolo.
Audit di ciò che esiste, deduplica, pulisci, mappa i campi di origine agli attributi di destinazione e concordare su cosa significhi "abbastanza buono per migrare" prima di iniziare. Questa ultima parte è importante. Senza una chiara definizione della qualità dati accettabile al momento della migrazione, la migrazione non finisce mai ufficialmente.
Inriver cita ricerche McKinsey che stimano il costo della scarsa qualità dei dati fino al 30% del tempo di lavoro aziendale sprecato. Il costo non è solo lo sforzo di migrazione stesso. È ogni settimana successiva in cui i team lavorano attorno a dati cattivi invece di gestirli.
Saltare la Modellazione dei Dati nell'Implementazione PIM
La preparazione è la pulizia e migrazione di ciò che hai. La modellazione è decidere la struttura in cui i dati dovrebbero vivere. Sono lavori diversi, e saltare la modellazione è l'errore che crea il rifacimento più costoso.
I team importano dati di prodotto nel PIM senza prima definire famiglie di prodotti, gruppi di attributi, unità di misura, o come i prodotti si relazionano tra loro. Il PIM viene popolato. Poi, sei mesi dopo, diventa chiaro che la struttura non corrisponde a come i prodotti devono effettivamente essere presentati, e gran parte di essa deve essere ricostruita.
La fase di modellazione in genere richiede da due a quattro settimane se eseguita correttamente. La maggior parte dei team la tratta come un ritardo. È il lavoro che viene svolto al momento giusto.
Le relazioni tra prodotti sono la cosa più comune che viene saltata. Un sensore industriale che si connette a staffe di montaggio compatibili, accessori di calibrazione e parti di ricambio porta una struttura implicita che deve essere modellata esplicitamente. Saltarla all'inizio e la aggiungerai faticosamente dopo. La logica delle varianti è strettamente correlata: se il modello non separa chiaramente quali attributi definiscono una variante da quali sono condivisi in una famiglia di prodotti, il catalogo diventa difficile da mantenere man mano che cresce. Gli attributi specifici del canale meritano anche di essere affrontati nella fase di modellazione piuttosto che dopo l'arricchimento iniziato. Ciò che il webshop necessita, ciò che va a un catalogo stampato e ciò che i partner retail richiedono spesso differiscono significativamente. Retrofitting questa distinzione è sempre più doloroso che costruirla dall'inizio.
Il modello di dati configurabile di AtroPIM consente ai team di definire e modificare famiglie di prodotti, gruppi di attributi e relazioni senza coinvolgimento degli sviluppatori, il che rende l'iterazione durante la fase di modellazione più veloce. La flessibilità aiuta solo se il lavoro di modellazione viene svolto deliberatamente. Un sistema configurabile con un modello mal pensato ti dà semplicemente più corda.
Struttura del Team Sbagliata
Le implementazioni PIM che vanno storte di solito hanno una cosa in comune: nessuno possiede i dati.
Il proprietario del progetto è responsabile dell'ambito, della timeline e delle decisioni quando le priorità entrano in conflitto. Questo è solitamente un product manager o un responsabile operativo, non un manager IT. L'architetto tecnico gestisce integrazioni, logica di importazione e infrastruttura. Entrambi i ruoli sono tipicamente assegnati senza molto dibattito.
Il data manager è quello che viene saltato. Questa persona possiede la qualità dei dati prima, durante e dopo la migrazione: esegue l'audit, coordina la pulizia, definisce gli standard degli attributi e diventa l'autorità interna su cosa entra nel PIM. Senza un data manager designato, questi compiti vengono distribuiti informalmente a chi ha tempo. Non vengono svolti coerentemente e i problemi emergono tardi.
Nelle aziende più piccole, una persona potrebbe ricoprire due di questi ruoli. È gestibile. La configurazione che non funziona: IT possiede il progetto perché sta distribuendo il software, ma nessuno è incaricato di possedere la qualità dei dati. La preparazione dei dati diventa il problema di tutti, il che significa che diventa il problema di nessuno. Abbiamo visto implementazioni bloccarsi per mesi esattamente in questa configurazione, con dati puliti a metà preparati su tre fogli di calcolo diversi perché nessuna singola persona aveva autorità per consolidare e finalizzare.
Un'implementazione PIM senza un data manager designato è un problema di qualità dei dati in attesa di emergere nel momento peggiore: a metà migrazione, o due settimane prima del go-live.
Perché l'Integrazione nell'Implementazione PIM Viene Rinviata
Le integrazioni ERP e le integrazioni e-commerce vengono pianificate come "fase 2" nelle implementazioni PIM sorprendentemente spesso. La logica ha senso sulla carta: far funzionare prima il PIM, poi connettere i sistemi. In pratica, la fase 2 raramente arriva in modo lineare.
Il PIM va live con l'inserimento manuale dei dati come processo provvisorio. Il processo provvisorio diventa permanente perché c'è sempre qualcosa più urgente del progetto di integrazione. Sei mesi dopo, il team sta mantenendo due flussi di inserimento dati paralleli e il PIM non è l'unica fonte di verità che dovrebbe essere.
L'ambito dell'integrazione deve essere definito dall'inizio, non rinviato. Non tutte le integrazioni devono essere live il primo giorno. Ma l'architettura di integrazione dovrebbe essere progettata in anticipo, i flussi di dati tra i sistemi mappati, e il build messo a risorsa come parte dell'implementazione, anche se il rollout è in fasi.
AtroPIM include connettori nativi per piattaforme ERP e e-commerce comuni, il che riduce considerevolmente lo sforzo di build dell'integrazione. L'esistenza del connettore non importa se l'integrazione non è pianificata e messa a risorsa prima del go-live.
Go-Live Senza un Pilot
Un go-live big-bang, dove il PIM sostituisce tutti i sistemi precedenti su tutti i canali in una singola data, è l'approccio di rollout con il rischio più alto. È anche il più comune, perché sembra più pulito e veloce.
Gli errori a quella scala sono difficili da contenere. Se il modello di dati ha lacune, ogni canale e ogni sistema downstream è interessato simultaneamente. Se l'adozione da parte degli utenti è lenta, l'intera operazione rallenta con essa. E l'UAT eseguita con dati di test quasi mai cattura ciò che gli utenti reali trovano quando lavorano con dati di prodotto live a piena scala del catalogo.
Un rollout in fasi riduce quel rischio. Scegli una categoria di prodotto o un canale e esegui un ciclo completo attraverso il PIM per primo. Usalo come test reale. Ripara ciò che si rompe. Poi espandi.
I produttori che hanno eseguito le implementazioni PIM più fluide che abbiamo visto hanno lanciato con il 10-15% del loro catalogo. Hanno trattato la prima fase come una convalida genuina e hanno costruito fiducia prima di scalare.
L'approccio in fasi crea anche sostenitori interni. Un team che ha utilizzato con successo il PIM per una linea di prodotti prima del rollout completo diventa il gruppo che forma tutti gli altri. Questo cambio di proprietà interno tende a guidare l'adozione più velocemente di qualsiasi programma formale di gestione del cambiamento.
Nessuna Metrica di Successo Prima del Launch
I progetti di implementazione PIM spesso vanno live senza KPI definiti. Ciò rende impossibile dimostrare il ROI in seguito, e rende l'assegnazione prioritaria delle priorità arbitraria.
Le metriche che vale la pena tracciare dipendono da perché il PIM è stato implementato. Quelle comuni: tasso di completezza dei dati per famiglia di prodotto, time-to-market per nuovi prodotti, numero di errori di dati che raggiungono i canali downstream e riduzione del lavoro di esportazione manuale per settimana. Per i produttori, un proxy utile è quanto tempo ci vuole per integrare i dati di prodotto di un nuovo fornitore da file grezzi a catalogo pubblicato. La nostra guida di implementazione PIM spiega come strutturare queste metriche all'interno del piano di progetto più ampio.
Definisci questi KPI prima del go-live, non dopo. Senza una baseline, non puoi mostrare miglioramenti. E senza miglioramenti misurabili, la prossima richiesta di budget per moduli aggiuntivi o personale è una conversazione molto più difficile.
Nessuna Governance Dopo il Go-Live
Il PIM diventa stagnante senza una proprietà definita della qualità dei dati dopo il lancio. Questo passaggio viene quasi sempre saltato.
Il go-live non è la fine del progetto di implementazione PIM. Qualcuno deve possedere le domande continue: chi approva i nuovi tipi di attributo, chi risolve i conflitti quando due team inseriscono valori contraddittori, qual è la cadenza di revisione per la completezza dei dati e come vengono modellate le nuove famiglie di prodotti quando il catalogo cresce. Poiché i requisiti normativi come la Passaporto Digitale Prodotto dell'UE si espandono, il framework di governance deve anche tenere conto dei dati di tracciabilità a livello di prodotto che non erano richiesti al lancio.
Un minimo pratico: assegna una persona come steward dei dati continuativo, definisci una revisione mensile della completezza dei dati per categoria e documenta il processo per aggiungere nuovi attributi. È sufficiente per prevenire la maggior parte dell'entropia che degrada la qualità dei dati PIM nel tempo.
La ricerca McKinsey sulla trasformazione digitale colloca il tasso di fallimento delle implementazioni software al 70%, con scarsa adozione da parte degli utenti come causa primaria. Un PIM che il team trova confuso o disconnesso dai flussi di lavoro quotidiani verrà utilizzato minimamente, indipendentemente dalle sue capacità tecniche. La pianificazione dell'adozione non è un flusso di lavoro separato. Appartiene dentro il progetto di implementazione dall'inizio.
Cosa Determina il Successo
Le implementazioni PIM che reggono nel tempo condividono un modello: i team hanno investito più nella preparazione di quanto pianificato, e hanno mantenuto l'ambito di lancio più piccolo di quanto desiderassero gli stakeholder. Questa combinazione è scomoda da difendere internamente quando c'è pressione per mostrare risultati velocemente. È coerentemente ciò che funziona.
La scelta del software importa meno di questo. Un PIM ben implementato su una piattaforma flessibile e configurabile supererà uno mal implementato su un sistema tecnicamente superiore. AtroPIM è costruito esattamente per questo tipo di approccio iterativo: funzionalità core per primo, con moduli che lo estendono man mano che le esigenze crescono, e pieno controllo sul modello di dati in tutto.