Punti chiave:
- La maggior parte dei fallimenti nelle implementazioni PIM avviene prima della configurazione, nella fase di concept e raccolta dei requisiti.
- Le decisioni relative alla migrazione dati e all'architettura di integrazione prese all'inizio determinano quanto rework sarà necessario in seguito.
- La gestione del cambiamento non è una questione marginale. Determina se il sistema verrà effettivamente utilizzato.
- Pubblicare una soluzione funzionante e migliorarla iterativamente è migliore che aspettare una soluzione perfetta.
I progetti di implementazione PIM sono quasi sempre sottovalutati. Le aziende che introducono un sistema di gestione delle informazioni sui prodotti (PIM) per la prima volta non hanno riferimenti interni su ciò che il progetto comporta realmente: quanto tempo richiede la migrazione dati, quanti casi limite emergono nel modello dati, quanta coordinazione tra dipartimenti è necessaria prima che un singolo record di prodotto sia completo.
Queste 21 pratiche sono tratte da implementazioni reali. Alcune riguardano decisioni di processo, altre sono di natura tecnica e alcune riguardano la gestione delle persone.
1. Investire Tempo nella Fase di Concept Prima di Toccare il Software
Gli errori più costosi nelle implementazioni PIM si commettono nelle prime due settimane, non nelle ultime due. Iniziare la configurazione senza aver documentato e concordato i requisiti PIM causa rework che costa da tre a cinque volte di più della decisione originale.
La fase di concept deve produrre due cose: un elenco documentato dei requisiti aziendali che il sistema deve soddisfare e una comprensione condivisa tra il vostro team e l'implementatore su ciò che verrà realizzato. Per i requisiti ambigui, i mockup valgono l'investimento di tempo. Emergono i disaccordi prima che la realizzazione inizi, non dopo.
Nei progetti che abbiamo implementato per aziende manifatturiere di medie dimensioni, i team che hanno dedicato quattro-sei settimane alla fase di concept hanno completato l'implementazione in circa la metà del tempo rispetto ai team che hanno iniziato subito la configurazione. La differenza non era nella capacità. Era nella chiarezza.
2. Assicurare l'Allineamento degli Stakeholder e l'Approvazione Esecutiva in Anticipo
L'implementazione di un PIM influisce su più dipartimenti di quanto la maggior parte delle persone anticipi. Marketing, e-commerce, product management, IT, procurement e talvolta sales e logistica interagiscono tutti con i dati sui prodotti in modi che il nuovo sistema cambierà. Se gli stakeholder che dirigono questi dipartimenti non sono allineati prima dell'inizio del progetto, riapriranno discussioni durante la realizzazione.
Lo sponsorizzazione esecutiva è importante per un motivo diverso. Un progetto PIM che compete per budget e risorse di ingegneria con altre priorità verrà deprioritizzato quando queste priorità entrano in conflitto. Uno sponsor esecutivo con un interesse diretto nel risultato risolve questi conflitti più velocemente e a un livello inferiore rispetto all'escalation attraverso un comitato di progetto.
Ottenere l'approvazione è più facile quando il progetto è inquadrato in termini aziendali: time-to-market più veloce, meno errori nei dati di prodotto che raggiungono il canale, costo operativo inferiore per SKU pubblicato. L'argomento tecnico non funziona bene quanto quello operativo.
3. Risolvere le Questioni di Data Governance Prima che l'Implementazione Inizi
I team di progetto tendono a dedicare tempo alle cose che comprendono ed evitano le cose difficili da definire. Un modello comune: discussione estesa su dove i campi appaiono nella schermata del prodotto, mentre la questione su quali attributi sono obbligatori rispetto a quelli facoltativi non viene mai affrontata.
Gli attributi obbligatori e facoltativi determinano le regole di completezza dei dati, che determinano la logica del workflow, che determina come gli utenti sono responsabili della qualità. Sbagliare questo nella fase di concept crea problemi di data governance difficili da disentanglare in seguito.
Affrontate le domande difficili in anticipo: quali attributi sono richiesti prima che un prodotto possa essere pubblicato, chi possiede ciascun dominio di dati e cosa significa "completo" per un record di prodotto. Queste sono più difficili da rispondere rispetto alle domande sul layout, ma sono quelle che contano.
4. Valutare il Partner di Implementazione Presto e Agire Rapidamente se Qualcosa Non Va
Il lavoro del partner di implementazione è aiutarvi a evitare errori, non solo eseguire istruzioni. Se il consulente è passivo nelle prime settimane, aspettando che il vostro team definisca tutto, non evidenziando i rischi, non ponendo le domande giuste, è un segnale da prendere sul serio.
Red flag che indicano il partner sbagliato:
- La comunicazione è lenta, vaga o richiede follow-up ripetuti.
- I deliverable iniziali non riflettono ciò che è stato discusso.
- Le stime di budget cambiano ripetutamente senza spiegazioni chiare.
- Il team è reattivo piuttosto che proattivo.
Cambiare partner è doloroso, ma farlo alla settimana tre è significativamente meno doloroso che farlo al mese sei. Più a lungo il progetto continua nella direzione sbagliata, più costosa diventa la correzione.
5. Definire la Proprietà dei Dati Tra i Sistemi Prima che l'Integrazione PIM Inizi
Un sistema PIM è un nodo in un ecosistema di dati più ampio. Si situa tra sistemi operativi (ERP, procurement) che generano dati di prodotto e canali di vendita (webshop, marketplace, portali retail) che li consumano. Il design dell'integrazione deve rispondere chiaramente a una domanda: per ciascun campo dati, quale sistema è la fonte autorevole?
Senza questo, i sync bidirezionali causano corruzione silenziosa dei dati. Un aggiornamento di prezzo dall'ERP sovrascrive un aggiornamento di descrizione dal PIM, o viceversa, a seconda di quale sync viene eseguito per ultimo. Questi conflitti sono difficili da diagnosticare dopo il fatto.
La regola che funziona nella pratica: il PIM possiede i contenuti di prodotto relativi a marketing e vendite. L'ERP possiede i dati commerciali e operativi. Dove c'è sovrapposizione (nomi prodotto, unità di misura, specifiche tecniche), documentate la proprietà esplicitamente e applicatela tecnicamente dove possibile restringendo l'accesso in scrittura nel sistema non autorevole.
Il PIM funziona quindi come l'unica fonte di verità per tutti i contenuti di prodotto che fluiscono verso il canale, con l'ERP come fonte autorevole per i dati operativi che lo alimentano. Questa distinzione vale la pena di essere formalizzata nella documentazione del progetto.
6. Trattare la Gestione del Cambiamento come un Deliverable di Progetto, Non un Ripensamento
Un'implementazione PIM può fallire con software eccellente e configurazione solida se le persone che lo utilizzano resistono al cambiamento o non capiscono perché li avvantaggia. Questo è più comune di quanto i piani di progetto tengono conto.
Le due forme più comuni di resistenza: l'adozione passiva mancata (gli utenti continuano a mantenere file Excel insieme al PIM) e l'attrito attivo (i team sostengono che il sistema non supporta il loro processo esistente).
Entrambe sono risolvibili se coinvolgete i dipartimenti interessati presto, spiegate il vantaggio in termini del loro lavoro piuttosto che della strategia aziendale, e li coinvolgete nelle decisioni che influenzeranno come utilizzeranno il sistema. Un product manager che ha aiutato a definire il workflow è più propenso a seguirlo rispetto a uno a cui è stato consegnato.
Un sistema complicato comporta cicli di training più lunghi e costi di supporto ongoing più elevati. La semplicità della configurazione ha un vantaggio di costo diretto.
7. Pianificare un Rollout Graduale Piuttosto che un Lancio Big Bang
Tentare di andare live con il catalogo completo di prodotti, tutte le integrazioni e ogni gruppo di utenti simultaneamente è uno dei modi più affidabili per far fallire visibilmente un progetto PIM. Scope, complessità e timeline si moltiplicano. Quando qualcosa si rompe, è più difficile isolare e risolvere il problema.
Un rollout graduale inizia con un pilot gestibile: una categoria di prodotto, un canale, un team. Il pilot superficie i problemi di configurazione reali in un ambiente controllato dove il costo per ripararli è basso. Produce anche la prima versione funzionante del sistema, che costruisce fiducia in tutta l'organizzazione e dà al progetto qualcosa di concreto a cui puntare.
Dal pilot, espandete metodicamente. Aggiungete gruppi di prodotto, poi canali, poi ruoli utente. Ogni fase deve avere criteri di entrata e criteri di uscita definiti. Questo mantiene il progetto controllabile senza aggiungere burocrazia.
8. Incorporare Flessibilità per i Requisiti che Cambieranno Durante il Progetto
I requisiti cambiano durante l'implementazione. Non è un fallimento della pianificazione. È una caratteristica normale dei progetti in cui gli utenti interagiscono con un sistema reale per la prima volta e scoprono quello di cui hanno effettivamente bisogno.
L'approccio utile non è impedire i cambiamenti ma organizzare il progetto in modo che i cambiamenti possano essere accomodati senza deragliare la timeline. Stabilite un processo per valutare le richieste mid-progetto: valutate l'impatto su scope, costo e timeline, decidete se includere nella fase corrente o rimandare a un follow-up, e documentate la decisione.
Un produttore con cui abbiamo lavorato ha realizzato a metà progetto che avevano bisogno di concedere a un'agenzia di traduzione l'accesso diretto al PIM per localizzare le descrizioni di prodotto. Questo non era nello scope originale. Aggiungerlo ha aggiunto due settimane al progetto. Escluderlo avrebbe lasciato un collo di bottiglia manuale permanente nel loro processo di localizzazione.
9. Riprogettare i Processi per il Nuovo Sistema, Non Attorno ai Vostri Vecchi
Una delle abitudini più costose nell'implementazione PIM è trattare il processo attuale come un vincolo piuttosto che un punto di partenza. I team mappano i loro workflow esistenti, incluse ogni eccezione, workaround e step manuale, nel nuovo sistema e finiscono con qualcosa di più complesso di quello con cui hanno iniziato.
Lo scopo di un sistema PIM è migliorare l'efficienza dei processi e la qualità dei dati di prodotto. Se l'implementazione ricrea il processo attuale in uno strumento diverso, nessuno dei due risultati viene raggiunto.
I processi standard gestiscono la maggior parte dei casi nella maggior parte dei cataloghi. Configurazioni speciali per accomodare casi limite aggiungono complessità di implementazione, aumentano l'overhead di manutenzione con ogni aggiornamento del sistema e sono spesso bypassate comunque una volta che gli utenti trovano un workaround più veloce.
Riconsiderate ogni processo esistente prima di mapparlo.
10. Sostituire Excel con il PIM come Unica Fonte di Dati
Un progetto PIM che risulta in un uso parallelo di Excel e del PIM non è un'implementazione riuscita. È una versione più costosa di ciò che l'azienda aveva prima.
Il problema pratico è la divergenza dei dati: quando due fonti contengono informazioni di prodotto sovrapposte e vengono aggiornate indipendentemente, alla fine si contraddirranno. Identificare quale versione è corretta e riconciliare la discrepanza costa tempo, crea errori nei contenuti pubblicati ed erode la fiducia in entrambi i sistemi.
Il piano di transizione dovrebbe includere un cutoff esplicito: una data dopo la quale i dati di prodotto vengono mantenuti esclusivamente nel PIM. Questo richiede che il PIM copra effettivamente tutte le funzioni per cui Excel veniva utilizzato: tabelle, calcoli, export strutturati. La maggior parte dei sistemi PIM moderni lo fanno. Se il vostro non lo fa, è un gap di requisiti da affrontare prima del go-live.
11. Sapere Quando la Configurazione Finisce e Inizia lo Sviluppo Custom
Nessun sistema PIM out-of-the-box soddisferà completamente ogni requisito. La maggior parte coprirà la maggioranza attraverso la configurazione: aggiustando i tipi di campo, le regole di validazione, i workflow e i layout senza scrivere codice. Per i requisiti che cadono al di fuori di ciò che la configurazione può gestire, generalmente ci sono due opzioni: acquistare un modulo esistente o commissione sviluppo custom.
Lo sviluppo custom richiede più tempo e costa di più inizialmente. Vi dà anche qualcosa che si adatta al vostro processo con precisione piuttosto che qualcosa a cui dovete adattare il vostro processo per adattarvi.
Nei progetti con cataloghi di produttori complessi che coprono specifiche tecniche con logica condizionale, catene di approvazione che variano per categoria di prodotto e template di export con requisiti di formattazione specifici, lo sviluppo custom su feature PIM mirati ha costantemente prodotto migliori risultati a lungo termine rispetto a cercare di forzare il requisito in una configurazione per cui non era progettato.
Il giudizio è se il requisito è core per la vostra operazione o periferico. I requisiti core meritano sviluppo custom. Quelli periferici di solito no.
AtroCore supporta entrambi i percorsi: configurazione estensiva attraverso il suo modello dati flessibile e il sistema di moduli, e sviluppo custom attraverso la sua architettura aperta e la documentazione OpenAPI per istanza.
12. Coinvolgere Ogni Dipartimento Interessato Prima di Selezionare il Sistema PIM
I dipartimenti che utilizzeranno un sistema PIM raramente sono quelli che lo selezionano. IT o management prendono la decisione, e marketing, e-commerce, product management e i team di catalogo stampato lo scoprono dopo. Questo produce problemi prevedibili: requisiti mancanti, workflow disallineati e resistenza all'adozione.
La sequenza giusta è identificare tutti gli stakeholder che interagiscono con i dati di prodotto, inclusi quelli che attualmente gestiscono dati in modi non visibili al management, come team che mantengono spreadsheet locali o fogli di prodotto in unità condivise, e coinvolgerli nella raccolta dei requisiti prima di valutare qualsiasi sistema.
Quello che imparate da queste conversazioni spesso cambia significativamente i criteri di selezione. Un dipartimento che gestisce 40 attributi di prodotto per SKU ha requisiti diversi da uno che ne gestisce 10. Un team che pubblica su sei canali ha esigenze diverse da uno che pubblica su due.
Coinvolgere questi team anche nell'implementazione accorcia il tempo di adozione. Gli utenti che hanno aiutato a plasmare il sistema lo comprendono meglio e sono più disposti a lavorarvi.
13. Costruire una Soluzione Funzionante Prima, Estenderla Dopo
L'impulso di costruire un sistema completo che gestisca ogni possibile requisito futuro è comprensibile ma controproducente. Estende le timeline, aumenta i costi e produce un modello dati così complesso che la manutenzione diventa difficile.
I team di dati di prodotto imparano quello di cui hanno effettivamente bisogno usando il sistema, non teorizzandoci sopra. In pratica, l'overhead di manutenzione di un albero di categoria aggiuntivo o una seconda serie di regole di validazione che copre uno scenario che non si è verificato è raramente degno dell'investimento iniziale.
L'obiettivo è un sistema che risolva i problemi che il vostro team incontra nel lavoro quotidiano. Risolvete bene questi problemi. Costruite abbastanza flessibilità per estendere il sistema quando emergono nuovi requisiti. E emergeranno. Ma non cercate di risolvere problemi che non esistono ancora.
14. Progettare il Modello Dati PIM e la Tassonomia per Accomodare la Crescita Futura
Ottimizzare per l'utilità non significa costruire qualcosa di usa e getta. Le decisioni architetturali prese durante l'implementazione (come gli attributi sono strutturati, come la tassonomia è organizzata, come i canali sono mappati) sono difficili e costose da cambiare in seguito.
Lasciate spazio al sistema per crescere. In pratica, questo significa alcune cose specifiche: evitate di hardcodificare valori che è probabile cambino (nomi di canali, codici locale, strutture di categoria), usate uno schema di attributi modulare che consenta l'aggiunta di nuovi gruppi di attributi senza ristrutturare quelli esistenti e prendete decisioni sui formati di export e integrazioni API con la consapevolezza che il numero di punti di integrazione aumenterà.
I sistemi che invecchiano meglio sono quelli costruiti per essere modificati, non quelli costruiti per essere completi.
L'architettura modulare di AtroCore supporta questo direttamente: nuove capacità possono essere aggiunte attraverso moduli premium senza modificare il modello dati core, il che preserva l'investimento nella configurazione originale consentendo al sistema di crescere con l'azienda.
15. Iniziare la Migrazione Dati PIM Prima di Quanto Pensiate Sia Necessario
La migrazione dati è quasi sempre l'elemento che slitta. Le ragioni sono coerenti: il volume dei dati è più grande di quanto stimato, i problemi di qualità dei dati emergono durante la preparazione che non erano visibili in precedenza e il processo di import rivela gap o incoerenze nel modello dati che richiedono aggiustamenti prima che i dati possano essere caricati correttamente.
Un inizio precoce vi dà il tempo per affrontare tutti e tre. Identificate ogni fonte di master data (export ERP, spreadsheet di fornitori, database legacy, unità condivise) all'inizio del progetto, non alla fine. Valutate la qualità di ogni fonte prima di pianificare la migrazione. Costruite il tempo per la rimediazione nella schedule.
Il miglioramento della qualità dei dati non è uno step di migrazione. È un processo continuo. Ma la migrazione è quando l'intera portata del problema di qualità diventa visibile, ed è un momento difficile da incontrare due settimane prima del go-live.
16. Migrare i Dati Come Sono, Poi Migliorarli
L'istinto di pulire e ristrutturare i dati prima di migrarli è ragionevole ma di solito controproducente. Prendere decisioni su cosa mantenere, rimuovere o ristrutturare richiede di comprendere come i dati si comportano nel nuovo sistema. Non avete quella comprensione finché i dati non sono lì.
Trasferite i dati invariati nel PIM. Eseguite controlli di completezza, identificate valori mancanti e evidenziate problemi strutturali una volta che i dati sono nel sistema. Poi prendete decisioni di cleanup basate su ciò che potete vedere, non su ciò che vi aspettate di trovare. L'arricchimento dati (aggiunta di attributi mancanti, standardizzazione di valori, miglioramento di descrizioni) è un'attività post-migrazione, non pre-migrazione.
Questo approccio previene anche la perdita accidentale di dati. Dettagli che sembrano non necessari durante la migrazione spesso risultano importanti una volta che il sistema è in uso. Invertire quella decisione dopo il fatto è più lento che aver mantenuto i dati e averli rimossi deliberatamente.
17. Trattare l'Architettura di Integrazione PIM come un Requisito Core, Non un Item della Fase 2
Un PIM che non può connettersi automaticamente ai sistemi che lo alimentano e ai canali che lo consumano produce lavoro di sincronizzazione manuale. La sincronizzazione manuale di migliaia di record di prodotto produce incoerenze. Le incoerenze producono errori nei contenuti pubblicati che sono time-consuming per identificare e correggere.
La distribuzione omnichannel mette una pressione particolare sulla qualità dell'integrazione. Se il vostro sistema di gestione informazioni di prodotto deve spingere dati consistenti verso un webshop, molteplici marketplace, portali di partner retail e produzione di stampa quasi in tempo reale, gli export batch basati su file non si adattano. L'integrazione basata su API con aggiornamenti event-driven per i dati che cambiano velocemente è l'architettura che supporta le operazioni omnichannel senza intervento manuale.
Prima di selezionare un sistema PIM, verificate che supporti le integrazioni che la vostra architettura richiede, non solo in generale ma specificamente: connettività ERP, sync bidirezionale dove necessario e logica di risoluzione dei conflitti chiara. Se la capacità di integrazione è limitata o richiede lavoro custom significativo per raggiungere la connettività di base, è un problema di selezione, non un problema di configurazione.
I nostri clienti che hanno sostituito la sincronizzazione ERP basata su file con integrazione basata su API attraverso AtroCore riportano costantemente una riduzione degli errori di dati e una diminuzione significativa del tempo tra un aggiornamento ERP e la sua apparizione nel canale di vendita.
18. Scrivere Documentazione Durante l'Implementazione, Non Dopo
La documentazione scritta dopo l'implementazione si basa sulla memoria e tende a descrivere come il sistema era destinato a funzionare piuttosto che come effettivamente funziona. La documentazione scritta durante l'implementazione è più accurata, più dettagliata e più utile.
Questo non significa documentare ogni funzione di sistema: il vendor PIM lo fornisce. L'obiettivo è documentare le decisioni specifiche della vostra implementazione: perché certi attributi erano strutturati come lo erano, quali sono le regole del flusso di approvazione e quali eccezioni esistono, come i template di import e export sono organizzati, quali utenti sono responsabili di quali domini di dati.
Questa documentazione serve due scopi: riduce il carico di supporto dopo il go-live e preserva la conoscenza istituzionale quando i membri del team cambiano ruolo o se ne vanno. Entrambi sono eventi prevedibili. Il costo di non avere documentazione quando accadono è costantemente più alto che il costo di crearla.
19. Definire i KPI Prima del Go-Live e Misurare il ROI Dopo
Un'implementazione PIM senza metriche di successo definite è difficile da difendere e difficile da migliorare. I risultati che il sistema era supposto fornire (time-to-market più veloce, meno errori nei dati di prodotto che raggiungono il canale, tempo ridotto speso in data entry manuale, tassi di completezza dei dati di prodotto più elevati) devono essere stabiliti come target misurabili prima del go-live, non descritti in retrospettiva.
KPI utili per un'implementazione PIM includono: percentuale di record di prodotto che soddisfano la definizione di completezza, tempo dalla creazione di un prodotto alla prima pubblicazione, tasso di errore nei dati distribuiti su canali e numero di step di integrazione manuale sostituiti dalla sincronizzazione automatizzata. Queste metriche sono abbastanza specifiche da tracciare e si mappano direttamente sui problemi operativi che il sistema è stato introdotto per risolvere.
Il ROI da un'implementazione PIM si materializza su entrambi i lati del costo e dei ricavi. I risparmi operativi derivano dalla riduzione della gestione manuale dei dati e da meno errori di canale che richiedono correzione. Dal lato dei ricavi, le listing più veloci su nuovi canali e conversioni più elevate da contenuti di prodotto completi e arricchiti dipendono direttamente dalla qualità di ciò che il PIM produce. Documentare il baseline prima del go-live rende il calcolo del ROI significativo piuttosto che approssimativo.
20. Configurare i Controlli di Accesso e le Regole di Validazione dal Primo Giorno
I problemi di qualità dati in un sistema PIM sono raramente causati da azioni malevole. Sono causati da utenti che avevano accesso che non dovevano avere, o che non sono stati impediti di lasciare un campo vuoto o di inserire un valore nel formato sbagliato.
I controlli di accesso e le regole di validazione non sono un compito di pulizia post-go-live. Fanno parte della configurazione iniziale. Definite quali ruoli possono leggere, creare, modificare ed eliminare record. Impostate i campi obbligatori. Configurate la validazione del formato per gli attributi strutturati come codici EAN, dimensioni e classificazioni di prodotto. Abilitate le porte di publishing basate su workflow che impediscono ai record incompleti di raggiungere il canale.
Dove la logica di validazione è troppo complessa per configurarla dichiarativamente, può essere programmata. L'investimento ripaga rapidamente in tassi di errore ridotti e overhead editoriale inferiore.
21. Utilizzare la Piena Capacità del Vostro Sistema PIM
Un sistema PIM configurato e poi utilizzato in modo ristretto, come un foglio di calcolo leggermente migliore, non sta fornendo il suo valore. Le piattaforme PIM moderne, in particolare quelle costruite su piattaforme dati flessibili, possono assumersi funzioni che riducono il numero totale di sistemi che un'azienda deve mantenere.
AtroCore, costruito sulla piattaforma dati AtroCore, è progettato per questo. Oltre alle funzioni standard di gestione informazioni di prodotto, può agire come middleware tra ERP e canali di vendita, gestire calcoli di prezzo ed elaborazione di regole di business, gestire asset digitali in modo nativo attraverso il suo DAM integrato, generare direttamente fogli e cataloghi PDF di prodotto, supportare workflow di collaborazione con fornitori e gestire la sindacazione omnichannel a qualsiasi numero di canali tramite la sua REST API. Ciascuna di queste funzioni che il PIM gestisce è un punto di integrazione in meno da mantenere altrove.
Il punto non è espandere lo scope per il suo bene. È valutare, una volta che il sistema è stabile, se i problemi adiacenti potrebbero essere risolti all'interno della piattaforma che avete già piuttosto che aggiungere un altro strumento allo stack.
Le implementazioni PIM con le migliori performance che abbiamo visto non sono le più sofisticate. Sono quelle in cui il team ha definito un problema chiaro, ha costruito una soluzione focalizzata e ha espanso il sistema deliberatamente mentre i requisiti reali emergevano.
Questo è il modello che vale la pena seguire.