Per i professionisti dell'e-commerce e per chi è coinvolto nella trasformazione digitale, la gestione delle informazioni sui prodotti (PIM) è probabilmente il sistema più importante da considerare. Mantiene la coerenza e la qualità in tutti i canali di vendita. Quando le aziende prendono in considerazione l'implementazione di un nuovo sistema PIM, una domanda fondamentale è se valga la pena di rischiare un'implementazione completa o se un'implementazione proof of concept (POC) sia la strada più prudente.
Nel caso del PIM, saltare il proof of concept (POC) può sembrare il modo più veloce per risparmiare risorse, ma probabilmente causerà costose rielaborazioni, ritardi e dipendenti arrabbiati e sopraffatti. Il POC è più di un semplice test: è una polizza assicurativa strategica che aiuta a evitare disallineamenti tecnici e di business.
In circa il 50% dei casi in cui il PIM viene implementato da grandi aziende come Acer o Bridgestone (entrambe nostre clienti), viene condotto un progetto di proof-of-concept (POC) prima di procedere all'implementazione completa di AtroPIM.
Perché preoccuparsi di un POC?
Un POC (proof of concept) è un'iniziativa breve e altamente mirata che fornisce la convalida che la piattaforma software selezionata soddisferà i vostri specifici requisiti tecnici e di business prima di un investimento sostanziale. Il POC trasforma il progetto da un concetto teorico a una realtà pratica.
Il POC deve essere preso in considerazione quando:
- Pianificazione di flussi di lavoro complessi: Un POC assicura che la piattaforma sia in grado di elaborare flussi di dati di prodotto unici o complessi per le vostre organizzazioni (ad esempio, localizzazione linguistica personalizzata a più livelli, ereditarietà dinamica dei dati o processi di approvazione complessi).
- Valutazione di funzionalità specifiche: Quando i requisiti diventano più personalizzati, specifici per il settore o oltre il limite (ad esempio, pantaloni con regole aziendali) per complessità, una POC è fondamentale per valutare il rischio di incompatibilità con la piattaforma.
- PIM come strumento strategico e scalabile: Quando il PIM è considerato uno strumento strategico, destinato a diffondersi rapidamente tra diversi marchi, regioni o canali, il POC deve convalidare l'architettura del sistema, le sue possibili prestazioni e la sua scalabilità prima di un'adozione generalizzata.
Oltre a tutti gli elementi complessi descritti sopra, un POC diventa obbligatorio in un caso importante:
Quando avete la sensazione che il PIM non possa funzionare per voi.
Questa sensazione di solito deriva da:
- Nessuna esperienza interna di PIM: I vostri collaboratori sono nuovi al PIM e non hanno ancora valutato la fattibilità tecnica e l'usabilità.
- Dubbio dei principali stakeholder: I proprietari di aziende chiave, specialmente nel marketing, nello sviluppo del prodotto, ecc. non sono convinti che il sistema risolverà davvero i loro problemi.
Cosa è possibile fare per lavorare su un POC PIM?
Un POC mirato consente al vostro team di mettere le mani sul sistema e di convalidare alcuni elementi critici fondamentali con una piccola parte dei vostri dati.
1. Flessibilità del modello dei dati (quasi sempre)
Verificate che il sistema PIM sia in grado di modellare accuratamente le vostre intricate strutture di prodotto. A tale scopo, potete costruire una gerarchia di prodotti campione e stabilire attributi e gruppi di attributi personalizzati. Potete anche testare la gestione di varianti/SKU complesse per prodotti complessi, come l'abbigliamento con una matrice taglia/colore.
2. Flessibilità dei processi aziendali e gestione degli accessi
Determinate se il sistema può adattarsi ai vostri specifici flussi di lavoro per la creazione e la qualità dei contenuti. È possibile utilizzare un semplice flusso di lavoro di arricchimento dei dati (ad esempio, passare da Bozza a Pronto per il Web) per stabilire i ruoli e le autorizzazioni degli utenti, nonché le regole di qualità dei dati definite (ad esempio, campi obbligatori per la completezza).
Implementate ruoli chiave per gli utenti che rispecchino la vostra struttura organizzativa (ad esempio, product manager, content writer, approvatore, amministratore di sistema). Assicuratevi che ogni ruolo abbia la visibilità e i permessi di modifica appropriati per elementi di dati specifici, come attributi, categorie e canali.
Verificare che il sistema possa limitare l'accesso in base a sottoinsiemi di dati. Ad esempio, assicuratevi che un redattore di contenuti per la regione X possa visualizzare e modificare solo i prodotti assegnati alla categoria X o alla versione linguistica dei dati, verificando così la granularità del modello di sicurezza.
3. Funzionalità di integrazione del sistema per l'integrazione dei dati e del sistema (in casi rari)
Verificare la fattibilità tecnica della connettività del PIM con altri sistemi aziendali chiave. Verificare l'integrazione, la latenza e la mappatura dei dati. Stabilire una connessione API fondamentale, di sola lettura, a un sistema ERP di dati anagrafici o a un sistema DAM di beni per vedere se i dati ospitati diventano visibili.
Questo è l'aspetto più difficile da verificare, perché è necessario sviluppare l'integrazione prima di testarla. Di conseguenza, nella maggior parte dei casi, il costo sarebbe da sostenere qui, rispetto al caso d'uso "normale", non al caso "POC".
Quando si può saltare il POC?
In alcune circostanze giustificate, un'organizzazione può tranquillamente evitare una prova formale del concetto (POC), soprattutto quando il rischio è basso e l'obiettivo è un'implementazione rapida e semplice.
In particolare, il POC spesso non è necessario quando:
- Small Scope, Phased Rollout: L'implementazione iniziale è intenzionalmente limitata a un numero ridotto di SKU, a pochi attributi fondamentali e a un singolo canale non critico (ad esempio, un sito di e-commerce di base). Si prevede di espandere le funzionalità in fasi successive.
- Soluzione standard riconosciuta dal settore: Avete scelto un sistema PIM che è un leader comprovato nel vostro settore e che è dotato di integrazioni standard, pubblicamente documentate, per tutti i sistemi comuni del vostro stack tecnologico (ad esempio, connettori per i principali ERP o piattaforme di e-commerce).
- Incentrazione sui processi aziendali: Avete stabilito che la sfida principale sta nel definire e concordare i requisiti dei dati di prodotto (un problema di business) piuttosto che nella capacità tecnica o nella fattibilità del software PIM stesso.
- Alta competenza interna: Il vostro team ha già avuto esperienze di successo nell'implementazione della specifica piattaforma PIM che state considerando, dando alla vostra azienda un alto grado di competenza interna e di fiducia nella piattaforma.
- Modello di dati semplificato: La struttura dei dati del vostro prodotto è intrinsecamente piatta, semplice e non basata su varianti, e richiede una personalizzazione minima del modello di dati predefinito del PIM.
- Open-Source con supporto agli sviluppatori: State adottando una piattaforma PIM open-source altamente attiva e disponete di un forte team di sviluppatori interni che si trovano a proprio agio con la personalizzazione diretta della piattaforma e la risoluzione dei problemi, riducendo la dipendenza dai metodi collaudati dai fornitori.
In queste situazioni, è meglio utilizzare il vostro tempo e le vostre risorse per concentrarvi sulla documentazione dei requisiti e avviare una piccola implementazione pilota piuttosto che creare un POC formale autonomo.
Esiste un ponte tra l'implementazione del PIM e l'esperienza del cliente. Un POC è uno stress test ingegneristico che assicura che il ponte non crollerà sotto la pressione delle vostre richieste aziendali.