La maggior parte dei progetti PIM non fallisce perché il software non era adatto. Falliscono per decisioni prese settimane o mesi prima del go-live: modellazione dei dati saltata, sforzo di migrazione sottovalutato, integrazioni rimandate 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 accade prima che inizi: selezionare una piattaforma mentre il processo interno è ancora indefinito.
I team programmano demo con i vendor, confrontano i piani tariffari e negoziano i contratti mentre la loro tassonomia prodotti è incoerente, le fonti di dati sono poco chiare e nessuno ha concordato chi possiede i dati dei prodotti. Il PIM viene acquistato. Poi rimane fermo mentre l'allineamento interno si sviluppa.
Un PIM non risolve un problema di processo. Ti fornisce l'infrastruttura per eseguire un processo su di essa. Se il processo non è definito, stai semplicemente aggiungendo un livello costoso sopra lo stesso caos.
Prima di stilare un elenco ristretto di vendor, due cose dovrebbero essere sistemate: 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 prodotto. Senza quelli, la selezione dei 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 che inizi 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 servono sei.
Il divario emerge quasi sempre dallo stesso luogo: i dati dei prodotti 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 di cui nessuno sapeva esistessero spuntano a metà audit. Valori mancanti emergono solo quando qualcuno tenta di mapparli a un campo target. Ognuno di questi è gestibile di per sé. In combinazione, trasformano una stima di due settimane in una realtà di sei settimane.
I dati dei fornitori sono un problema a parte. I produttori che acquistano le specifiche dei prodotti da decine di fornitori scopriranno tipicamente che ognuno fornisce 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 attrezzature industriali, l'audit dei dati ha regolarmente rivelato che il 30-40% degli attributi dei prodotti era incompleto o incoerente nei sistemi sorgente. Quella scoperta è sempre stata una sorpresa per il cliente, anche quando il catalogo era relativamente piccolo.
Audita ciò che esiste, deduplica, ripulisci, mappa i campi sorgente agli attributi target, e concordi su cosa significhi "sufficientemente buono per la migrazione" prima di iniziare. Quest'ultimo punto conta. Senza una definizione chiara della qualità dei dati accettabile al momento della migrazione, la migrazione non termina mai ufficialmente.
Inriver cita la ricerca McKinsey che quantifica 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 scadenti anziché gestirli.
Saltare la Modellazione dei Dati nell'Implementazione PIM
La preparazione sta pulendo e migrando quello che hai. La modellazione sta decidendo 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 i dati dei prodotti nel PIM senza prima definire le famiglie di prodotti, i gruppi di attributi, le unità di misura, o come i prodotti si relazionano tra loro. 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 tipicamente richiede due-quattro settimane fatta correttamente. La maggior parte dei team la tratta come un ritardo. È il lavoro che viene 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 dopo. La logica delle varianti è strettamente correlata: se il modello non separa chiaramente quali attributi definiscono una variante da quali sono condivisi tra una famiglia di prodotti, il catalogo diventa difficile da mantenere man mano che cresce. Anche gli attributi specifici del canale meritano di essere affrontati nella fase di modellazione piuttosto che dopo che l'arricchimento è iniziato. Quello che serve al negozio web, quello che va a un catalogo stampato, e quello che richiedono i partner al dettaglio spesso differiscono significativamente. Retrofit di quella distinzione è sempre più doloroso che costruirla da zero.
Il modello di dati configurabile di AtroPIM consente ai team di definire e modificare famiglie di prodotti, gruppi di attributi e relazioni senza coinvolgimento dello sviluppatore, il che rende l'iterazione durante la fase di modellazione più veloce. La flessibilità aiuta solo se il lavoro di modellazione viene 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 IT manager. L'architetto tecnico gestisce le integrazioni, la logica di importazione e l'infrastruttura. Entrambi i ruoli vengono generalmente riempiti 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 nominato, quei compiti vengono distribuiti informalmente tra chiunque abbia tempo. Non vengono fatti in modo coerente, e i problemi emergono tardi.
Nelle aziende più piccole, una persona potrebbe svolgere due di questi ruoli. È fattibile. 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 stallarsi per mesi esattamente in questa configurazione, con dati puliti seduti mezzo preparati su tre fogli di calcolo diversi perché nessuna persona singola aveva l'autorità di consolidare e finalizzare.
Un'implementazione PIM senza un data manager nominato è un problema di qualità dei dati in attesa di emergere al momento peggiore: 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: fai girare il PIM prima, poi collega i sistemi. In pratica, la fase 2 raramente arriva in modo ordinato.
Il PIM va live con l'inserimento manuale dei dati come processo temporaneo. Il processo temporaneo diventa permanente perché c'è sempre qualcosa di più urgente del progetto di integrazione. Sei mesi dopo, il team sta mantenendo due flussi di lavoro di inserimento dati paralleli e il PIM non è l'unica fonte di verità che dovrebbe essere.
L'ambito dell'integrazione deve essere definito fin dall'inizio, non rimandato. Non ogni integrazione deve essere live il primo giorno. Ma l'architettura di integrazione dovrebbe essere progettata in anticipo, i flussi di dati tra i sistemi mappati, e la build risorse come parte dell'implementazione, anche se il rollout è in fasi.
AtroPIM include connettori nativi per le 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 finanziata 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ù elevato. È 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 contemporaneamente. 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 quello che gli utenti reali colpiscono quando lavorano con dati di prodotto live a scala di catalogo completa.
Un rollout in fasi riduce quel rischio. Scegli una categoria di prodotto o un canale e esegui un ciclo completo attraverso il PIM prima. Usalo come il vero test. Correggi quello 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 vera validazione e hanno costruito fiducia prima di scalare.
L'approccio in fasi crea anche sostenitori interni. Un team che ha usato con successo il PIM per una linea di prodotto prima del rollout completo diventa il gruppo che allena tutti gli altri. Quel cambiamento nella proprietà interna tende a guidare l'adozione più velocemente di qualsiasi programma formale di gestione del cambiamento.
Nessuna Metrica di Successo Prima del Lancio
I progetti di implementazione PIM spesso vanno live senza KPI definiti. Ciò rende impossibile dimostrare il ROI in seguito, e rende l'assegnazione prioritaria arbitraria.
Le metriche degne di tracciamento 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 a settimana. Per i produttori, un proxy utile è quanto tempo impiega per onboardare i dati dei prodotti di un nuovo fornitore da file grezzi a 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 baseline, non puoi mostrare il miglioramento. E senza un miglioramento misurabile, la prossima richiesta di budget per moduli aggiuntivi o headcount è una conversazione molto più difficile.
Nessuna Governance Dopo il Go-Live
Il PIM diventa obsoleto senza proprietà definita della qualità dei dati dopo il lancio. Questo passo è quasi sempre saltato.
Il go-live non è la fine del progetto di implementazione PIM. Qualcuno deve possedere le domande in corso: chi approva i nuovi tipi di attributo, 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. Poiché i requisiti normativi come il Passaporto Digitale del 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 data steward in corso, 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 attribuisce il tasso di fallimento delle implementazioni software al 70%, con l'adozione da parte degli utenti scadente come causa principale. Un PIM che il team trova confuso o scollegato dai flussi di lavoro quotidiani sarà utilizzato minimamente, indipendentemente dalle sue capacità tecniche. La pianificazione dell'adozione non è un workstream separato. Appartiene all'interno del progetto di implementazione fin dall'inizio.
Cosa Determina il Successo
Le implementazioni PIM che si mantengono nel tempo condividono un modello: i team hanno investito più nella preparazione di quanto avessero pianificato, e hanno mantenuto l'ambito del lancio più piccolo di quanto gli stakeholder volessero. Quella combinazione è scomoda da difendere internamente quando c'è pressione per mostrare risultati velocemente. È costantemente quello 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à di base prima, con moduli che lo estendono man mano che le esigenze crescono, e controllo completo sul modello di dati in tutto.