La maggior parte dei progetti PIM non fallisce perché il software sbagliato. Fallisce per decisioni prese settimane o mesi prima del go-live: data modeling saltato, sforzo di migrazione sottovalutato, integrazioni rinviate alla "fase 2". I problemi sono prevedibili. E lo sono anche le soluzioni.
Acquistare prima di essere pronti
L'errore più comune in un'implementazione PIM accade prima ancora che inizi: selezionare una piattaforma mentre il processo interno è ancora indefinito.
I team programmano demo con i vendor, confrontano i piani tariffari e negoziano contratti mentre la loro tassonomia dei prodotti è incoerente, le fonti dati sono poco chiare e nessuno ha concordato chi possiede i dati dei prodotti. Il PIM viene acquistato. Poi rimane inattivo mentre l'allineamento interno raggiunce il passo.
Un PIM non risolve un problema di processo. Ti dà l'infrastruttura per eseguire un processo. Se il processo non è definito, stai solo aggiungendo un livello costoso sopra lo stesso pasticcio.
Prima di creare una shortlist di vendor, almeno due cose dovrebbero essere definite: sai quali sistemi attualmente contengono i dati dei prodotti e quali alimenteranno il PIM, e hai un chiaro proprietario interno per la qualità dei dati dei prodotti. Senza quelli, la selezione del vendor è prematura. L'ambito del canale e la struttura della famiglia di prodotti possono essere affinati in seguito, 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 è consistentemente la fase più sottovalutata di qualsiasi implementazione PIM, inizia con il piano di implementazione PIM. I team allocano due settimane. Ne servono sei.
Il divario quasi sempre viene dallo stesso posto: i dati dei prodotti sono sparsi in 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 emergono durante l'audit. Valori mancanti che emergono solo quando qualcuno prova a mapparli in un campo target. 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 forniscono specifiche di prodotto da dozzine di fornitori in genere scoprono che ognuno consegna i 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 piccolo.
Nei progetti che abbiamo implementato per produttori di apparecchiature industriali, l'audit dei dati ha regolarmente rivelato che il 30-40% degli attributi dei prodotti erano incompleti o incoerenti nei sistemi di origine. Questa scoperta è arrivata sempre come sorpresa al cliente, anche quando il catalogo era relativamente piccolo.
Audit di ciò che esiste, deduplica, pulisci, mappatura dei campi di origine agli attributi target, e concordare cosa significa "abbastanza buono da migrare" prima di iniziare. Quest'ultima parte è importante. Senza una chiara definizione della qualità dei dati accettabile al momento della migrazione, la migrazione non finisce mai ufficialmente.
Inriver cita la ricerca McKinsey che colloca 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 dopo in cui i team lavorano intorno ai dati scadenti invece di gestirli.
Saltare il data modeling nell'implementazione PIM
La preparazione sta pulendo e migrando ciò che hai. La modellazione decide la struttura in cui i dati dovrebbero vivere. È un lavoro diverso, e saltare la modellazione è l'errore che crea il rework più costoso.
I team importano i dati dei prodotti nel PIM senza prima definire famiglie di prodotti, gruppi di attributi, unità di misura, o come i prodotti si relazionano l'uno all'altro. Il PIM diventa 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 fatta correttamente. La maggior parte dei team la tratta come un ritardo. È il lavoro fatto al momento giusto.
Le relazioni tra prodotti sono la cosa più comune che viene persa. 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 incollerai goffamente più tardi. 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 mentre cresce. Gli attributi specifici del canale meritano anche di essere affrontati nella fase di modellazione piuttosto che dopo che l'arricchimento è iniziato. Ciò che il negozio online ha bisogno, ciò che va in un catalogo stampato, e ciò che richiedono i partner al dettaglio spesso differiscono significativamente. Adattare quella distinzione è sempre più doloroso che costruirla dall'inizio.
Il modello dati configurabile di AtroPIM consente ai team di definire e modificare famiglie di prodotti, gruppi di attributi e relazioni senza l'intervento dello sviluppatore, il che rende l'iterazione durante la fase di modellazione più veloce. La flessibilità aiuta solo se il lavoro di modellazione è fatto deliberatamente. Un sistema configurabile con un modello mal pensato ti dà solo più corda.
Struttura del team sbagliata
Le implementazioni PIM che vanno di traverso 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 è di solito un product manager o un responsabile operativo, non un responsabile IT. L'architetto tecnico gestisce le integrazioni, la logica di importazione e l'infrastruttura. Entrambi i ruoli sono tipicamente ricoperti senza molti dibattiti.
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 ciò che entra nel PIM. Senza un data manager nominato, questi compiti vengono distribuiti informalmente tra chiunque abbia tempo. Non vengono fatti in modo coerente e i problemi emergono in ritardo.
Nelle aziende più piccole, una persona potrebbe rivestire due di questi ruoli. È gestibile. La configurazione che non funziona: l'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 fermarsi per mesi esattamente in questa configurazione, con dati puliti semi-preparati in tre fogli di calcolo diversi perché nessuna singola persona aveva l'autorità per consolidare e finalizzare.
Un'implementazione PIM senza un data manager nominato è un problema di qualità dei dati in attesa di emergere al 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 di e-commerce vengono pianificate come "fase 2" nelle implementazioni PIM sorprendentemente spesso. La logica ha senso sulla carta: far funzionare il PIM prima, poi connettere i sistemi. In pratica, la fase 2 raramente arriva con pulizia.
Il PIM entra in funzione con l'immissione manuale dei dati come processo provvisorio. Il processo provvisorio diventa permanente perché c'è sempre qualcosa di più urgente del progetto di integrazione. Sei mesi dopo, il team sta mantenendo due flussi di immissione dati paralleli e il PIM non è l'unica fonte di verità che doveva essere.
L'ambito dell'integrazione deve essere definito dall'inizio, non rinviato. Non ogni integrazione deve essere attiva nel primo giorno. Ma l'architettura di integrazione dovrebbe essere progettata in anticipo, i flussi di dati tra i sistemi mappati e la build inserita nel preventivo come parte dell'implementazione, anche se il rollout è in fasi.
AtroPIM include connettori nativi per comuni piattaforme ERP e di e-commerce, il che riduce considerevolmente lo sforzo di build dell'integrazione. L'esistenza del connettore non importa se l'integrazione non è pianificata e finanziata prima del go-live.
Go-live senza un pilota
Un go-live big-bang, dove il PIM sostituisce tutti i sistemi precedenti in tutti i canali in una singola data, è l'approccio di rollout a rischio più elevato. È anche il più comune, perché sembra più pulito e veloce.
Gli errori a quella scala sono difficili da contenere. Se il modello dati ha lacune, ogni canale e ogni sistema downstream è interessato contemporaneamente. Se l'adozione da parte dell'utente è lenta, l'intera operazione rallenta con essa. E l'UAT fatto con dati di test quasi mai cattura ciò che gli utenti reali trovano quando lavorano con dati di prodotto live su scala di catalogo completo.
Un rollout graduale riduce quel rischio. Scegli una categoria di prodotto o un canale ed esegui un ciclo completo attraverso il PIM per primo. Usalo come test reale. Correggi 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 validazione autentica e hanno costruito fiducia prima di scalare.
L'approccio graduale crea anche sostenitori interni. Un team che ha usato con successo il PIM per una linea di prodotti prima del rollout completo diventa il gruppo che forma tutti gli altri. Questo cambiamento nella proprietà interna tende a guidare l'adozione più velocemente di qualsiasi programma di gestione del cambiamento formale.
Nessuna metrica di successo prima del lancio
I progetti di implementazione PIM spesso vanno in funzione senza KPI definiti. Questo rende impossibile dimostrare il ROI in seguito e rende l'assegnazione delle priorità arbitraria.
Le metriche che vale la pena tracciare dipendono dal motivo per cui il PIM è stato implementato. Comuni: tasso di completezza dei dati per famiglia di prodotti, 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 impiega l'onboarding dei dati di prodotto di un nuovo fornitore dai file grezzi al catalogo pubblicato. La nostra guida all'implementazione PIM copre come strutturare queste metriche all'interno del piano di progetto più ampio.
Definisci questi KPI prima del go-live, non dopo. Senza una linea di base, non puoi mostrare un miglioramento. E senza un miglioramento misurabile, la prossima richiesta di budget per moduli aggiuntivi o assunzioni è una conversazione molto più difficile.
Nessuna governance dopo il go-live
Il PIM diventa stantio senza una proprietà definita della qualità dei dati dopo il lancio. Questo passaggio è quasi sempre saltato.
Il go-live non è la fine del progetto di implementazione PIM. Qualcuno ha bisogno di possedere le domande in corso: chi approva i nuovi tipi di attributi, chi risolve i conflitti quando due team inseriscono valori contraddittori, quale è la cadenza di revisione per la completezza dei dati e come vengono modellate le nuove famiglie di prodotti quando il catalogo cresce. Mentre i requisiti normativi come la Digital Product Passport dell'UE si espandono, il framework di governance deve anche tener conto dei dati di tracciabilità a livello di prodotto che non erano richiesti al lancio.
Un minimo pratico: assegna una persona come data steward continuo, 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 dell'utente come causa primaria. Un PIM che il team trova confuso o disconnesso dai flussi di lavoro quotidiani sarà 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 avevano pianificato, e hanno mantenuto l'ambito di lancio più piccolo di quanto desideravano gli stakeholder. Quella combinazione è difficile da difendere internamente quando c'è pressione per mostrare risultati rapidamente. È consistentemente ciò che funziona.
La scelta del software conta 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à principale per prima, con moduli che lo estendono man mano che le esigenze crescono, e controllo completo sul modello dati in tutto.