Punti chiave:
- La maggior parte dei fallimenti nell'implementazione PIM avviene prima ancora di toccare la configurazione, nella fase di concept e requisiti.
- Le decisioni sulla migrazione dati e sull'architettura di integrazione prese all'inizio determinano quanti lavori di correzione sarà necessario fare dopo.
- Il change management non è una questione secondaria. Determina se il sistema verrà effettivamente utilizzato.
- Rilasciare una soluzione funzionante e iterare è meglio che aspettare quella perfetta.
I progetti di implementazione PIM sono quasi sempre sottovalutati. Le aziende che introducono un sistema di product information management (PIM) per la prima volta non hanno alcun riferimento interno per comprendere veramente cosa comporta il progetto: quanto tempo richiede la migrazione dei dati, quanti casi limite emergono nel modello dati, quant'allineamento tra i reparti è necessario prima che un singolo record di prodotto sia completo.
Queste 21 practice provengono da implementazioni reali. Alcune sono decisioni di processo, altre sono tecniche, e altre ancora riguardano la gestione delle persone.
1. Investire Tempo nella Fase di Concept Prima di Toccare il Software
Gli errori più costosi nell'implementazione PIM vengono commessi nelle prime due settimane, non nelle ultime. Precipitarsi nella configurazione prima che i requisiti PIM siano documentati e concordati porta a lavori di correzione che costano da tre a cinque volte quello che avrebbe comportato la decisione originale.
La fase di concept dovrebbe produrre due cose: un elenco documentato dei requisiti aziendali che il sistema deve soddisfare, e una comprensione condivisa tra il tuo team e l'appaltatore su ciò che sarà costruito. Per i requisiti ambigui, i mockup valgono l'investimento di tempo. Emergono i disaccordi prima che il lavoro inizi, non dopo.
Nei progetti che abbiamo implementato per produttori 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 la configurazione immediatamente. La differenza non era nella capacità. Era nella chiarezza.
2. Assicurare l'Allineamento degli Stakeholder e il Sostegno Esecutivo all'Inizio
L'implementazione PIM coinvolge più reparti di quanto la maggior parte delle persone anticipi. Marketing, e-commerce, product management, IT, procurement, e talvolta vendite e logistica, interagiscono tutti con i dati dei prodotti in modi che il nuovo sistema cambierà. Se gli stakeholder che gestiscono questi reparti non sono allineati prima dell'inizio del progetto, riprenderanno a discutere le decisioni durante la costruzione.
Lo sponsorizzazione esecutiva è importante per un motivo diverso. Un progetto PIM che compite per budget e risorse di engineering con altre priorità sarà deprioritizzato quando quelle priorità entrano in conflitto. Un sponsor esecutivo con un interesse diretto nel risultato risolve quei conflitti più rapidamente e a un livello inferiore rispetto all'escalation attraverso un comitato di progetto.
Ottenere il consenso è più facile quando il progetto viene inquadrato in termini aziendali: time-to-market più rapido, meno errori nei dati dei prodotti 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 dell'Inizio dell'Implementazione
I team di progetto tendono a dedicare tempo alle cose che comprendono ed evitare le cose che sono difficili da definire. Un modello comune: una discussione estesa su dove i campi appaiono sullo schermo del prodotto, mentre la domanda su quali attributi sono obbligatori rispetto a opzionali non viene mai affrontata.
Gli attributi obbligatori e opzionali determinano le regole di completezza dei dati, che determinano la logica del workflow, che determina come gli utenti sono ritenuti responsabili della qualità. Sbagliare questo nella fase di concept crea problemi di data governance che sono difficili da risolvere dopo.
Affrontate le domande difficili all'inizio: quali attributi sono richiesti prima che un prodotto possa essere pubblicato, chi possiede ogni dominio di dati, e cosa significa "completo" per un record di prodotto. Sono più difficili da rispondere rispetto alle domande di layout, ma sono quelle che contano.
4. Valutare il Partner di Implementazione Presto e Agire Rapidamente Se Qualcosa Non Va
Il ruolo del partner di implementazione è aiutarti a evitare gli errori, non solo eseguire istruzioni. Se il consulente è passivo nelle prime settimane, aspettando che il tuo team definisca tutto, non segnalando rischi, non facendo le domande giuste, è un segnale che vale la pena prendere sul serio.
I segnali di allarme 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 una spiegazione chiara.
- 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 Inizi l'Integrazione PIM
Un sistema PIM è un nodo in un ecosistema di dati più ampio. Si posiziona tra i sistemi operativi (ERP, procurement) che generano dati sui prodotti e i canali di vendita (webshop, marketplace, portali retail) che li consumano. Il design dell'integrazione deve rispondere a una domanda chiaramente: per ogni campo dati, quale sistema è la fonte autorevole?
Senza questo, le sincronizzazioni bidirezionali causano corruzione dei dati silenziosa. Un aggiornamento di prezzo dall'ERP sovrascrive un aggiornamento di descrizione dal PIM, o viceversa, a seconda di quale sincronizzazione viene eseguita per ultima. Questi conflitti sono difficili da diagnosticare dopo.
La regola che funziona nella pratica: il PIM possiede i contenuti dei prodotti correlati a marketing e vendite. L'ERP possiede i dati commerciali e operativi. Dove c'è sovrapposizione (nomi di prodotti, unità di misura, specifiche tecniche), documentate la proprietà esplicitamente e applicate tecnicamente dove possibile limitando l'accesso in scrittura nel sistema non autorevole.
Il PIM funge quindi da fonte unica di verità per tutti i contenuti dei prodotti che fluiscono al canale, con l'ERP come fonte autorevole per i dati operativi che lo alimentano. Questa distinzione vale la pena formalizzare nella documentazione del progetto.
6. Trattare il Change Management Come un Deliverable di Progetto, Non Come un Ripensamento
Un'implementazione PIM può fallire con software eccellente e configurazione solida se le persone che lo utilizzano resistono al cambiamento o non comprendono perché li benefici. Questo è più comune di quanto i piani di progetto tengano in considerazione.
Le due forme più comuni di resistenza: l'adozione passiva (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).
Entrambi sono affrontabili se coinvolgi i reparti interessati all'inizio, spieghi i benefici in termini del loro lavoro piuttosto che della strategia aziendale, e li coinvolgi nelle decisioni che influenzano il modo in cui utilizzeranno il sistema. Un product manager che ha aiutato a definire il workflow è più probabile che lo segua rispetto a uno che l'ha ricevuto già pronto.
Un sistema complicato porta a cicli di formazione più lunghi e costi di supporto successivi più elevati. La semplicità nella configurazione ha un beneficio di costo diretto.
7. Pianificare un Rollout Graduale Piuttosto che un Lancio Big Bang
Tentare il go-live con il catalogo completo dei prodotti, tutte le integrazioni e ogni gruppo di utenti contemporaneamente è uno dei modi più affidabili per far fallire visibilmente un progetto PIM. Scope, complessità e timeline si compongono. Quando qualcosa si rompe, è più difficile isolare e risolvere.
Un rollout graduale inizia con un pilota gestibile: una categoria di prodotti, un canale, un team. Il pilota emerge i problemi di configurazione reali in un ambiente controllato dove il costo di risolverli è basso. Produce anche la prima versione funzionante del sistema, che costruisce fiducia all'interno dell'organizzazione e dà al progetto qualcosa di concreto a cui puntare.
Dal pilota, espandete metodicamente. Aggiungete gruppi di prodotti, poi canali, poi ruoli utente. Ogni fase dovrebbe avere criteri di ingresso e criteri di uscita definiti. Questo mantiene il progetto gestibile senza aggiungere burocrazia.
8. Costruire Flessibilità per i Requisiti che Cambieranno Durante il Progetto
I requisiti cambiano durante l'implementazione. Questo non è un fallimento della pianificazione. È una caratteristica normale dei progetti dove gli utenti interagiscono con un sistema reale per la prima volta e scoprono di cosa hanno effettivamente bisogno.
L'approccio utile non è prevenire 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 a metà progetto: valutate l'impatto su scope, costo e timeline, decidete se includere nella fase attuale o differire 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 traduzioni accesso diretto al PIM per localizzare le descrizioni dei prodotti. Questo non era nell'ambito 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 Intorno ai Vostri Vecchi
Una delle abitudini più costose nell'implementazione PIM è trattare il processo attuale come un vincolo piuttosto che come un punto di partenza. I team mappano i loro workflow esistenti, inclusa ogni eccezione, workaround e passo manuale, nel nuovo sistema, e finiscono con qualcosa di più complesso di quello da cui hanno iniziato.
Lo scopo di un sistema PIM è migliorare l'efficienza dei processi e la qualità dei dati dei prodotti. Se l'implementazione ricrea il processo attuale in uno strumento diverso, nessuno dei due risultati è raggiunto.
I processi standard gestiscono la maggior parte dei casi nella maggior parte dei cataloghi. Le configurazioni speciali per accomodare i casi limite aggiungono complessità di implementazione, aumentano l'overhead di manutenzione con ogni aggiornamento del sistema, e sono spesso aggirate 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 Vostra Unica Fonte di Dati
Un progetto PIM che risulta nell'uso parallelo di Excel e il PIM non è un'implementazione di successo. È una versione più costosa di quello che l'azienda aveva prima.
Il problema pratico è la divergenza dei dati: quando due fonti contengono informazioni sui prodotti sovrapposte e vengono aggiornate indipendentemente, alla fine si contraddiranno. Identificare quale versione è corretta e riconciliare la discrepanza costa tempo, crea errori nei contenuti pubblicati, e erode la fiducia in entrambi i sistemi.
Il piano di transizione dovrebbe includere un cutoff esplicito: una data dopo la quale i dati dei prodotti 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 moderni sistemi PIM lo fanno. Se il vostro non lo fa, è un gap nei requisiti da affrontare prima del go-live.
11. Sapere Quando la Configurazione Finisce e lo Sviluppo Personalizzato Inizia
Nessun sistema PIM pronto all'uso soddisferà completamente ogni requisito così com'è. La maggior parte coprirà la maggioranza attraverso la configurazione: regolando tipi di campo, regole di validazione, workflow e layout senza scrivere codice. Per i requisiti che cadono al di fuori di quello che la configurazione può gestire, ci sono generalmente due opzioni: acquistare un modulo esistente o commissionare uno sviluppo personalizzato.
Lo sviluppo personalizzato richiede più tempo e costa di più all'inizio. Ti dà anche qualcosa che si adatta al tuo processo precisamente piuttosto che qualcosa a cui devi adattare il tuo processo.
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 personalizzato su funzionalità PIM mirate ha prodotto costantemente risultati migliori a lungo termine rispetto al tentativo di forzare il requisito in una configurazione per cui non era stato progettato.
La valutazione è se il requisito è centrale per la vostra operazione o periferica. I requisiti centrali meritano lo sviluppo personalizzato. Quelli periferici solitamente no.
AtroPIM supporta entrambi i percorsi: configurazione estesa attraverso il suo modello dati flessibile e il sistema di moduli, e sviluppo personalizzato via la sua architettura aperta e la documentazione OpenAPI per singola istanza.
12. Coinvolgere Ogni Reparto Interessato Prima di Selezionare il Sistema PIM
I reparti che utilizzeranno un sistema PIM raramente sono quelli che lo selezionano. IT o la gestione prende la decisione, e marketing, e-commerce, product management e i team della stampa 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 dei prodotti, compresi quelli che attualmente gestiscono i dati in modi non visibili alla gestione, come i team che mantengono fogli di calcolo locali o schede di prodotto in unità condivise, e coinvolgerli nella raccolta dei requisiti prima di valutare qualsiasi sistema.
Quello che imparerete da queste conversazioni spesso cambia significativamente i criteri di selezione. Un reparto che gestisce 40 attributi di prodotto per SKU ha requisiti diversi da uno che gestisce 10. Un team che pubblica su sei canali ha esigenze diverse da uno che pubblica su due.
Coinvolgere questi team nell'implementazione accorcia anche il tempo di adozione. Gli utenti che hanno aiutato a plasmare il sistema lo comprendono meglio e sono più disposti a lavorare con esso.
13. Costruire Dapprima una Soluzione Funzionante, Estenderla Dopo
L'impulso a 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 sui prodotti imparano di cosa hanno effettivamente bisogno usando il sistema, non teorizzando su di esso. In pratica, l'overhead di manutenzione di una categoria aggiuntiva o di un secondo set di regole di validazione che copre uno scenario che non si è verificato raramente vale l'investimento iniziale.
L'obiettivo è un sistema che risolve i problemi che il vostro team incontra nel lavoro quotidiano. Risolvete quelli bene. Costruite abbastanza flessibilità per estendere il sistema quando nuovi requisiti diventano chiari. E lo diventeranno. Ma non cercate di risolvere problemi che non esistono ancora.
14. Progettare il Modello Dati e la Tassonomia PIM 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 è organizzata la tassonomia, come i canali sono mappati) sono difficili e costose da cambiare dopo.
Lasciate spazio al sistema per crescere. Questo significa alcune cose specifiche nella pratica: evitate di hardcodare valori che sono probabili che cambino (nomi di canali, codici locale, strutture di categorie), usate uno schema di attributi modulare che consenta l'aggiunta di nuovi gruppi di attributi senza ristrutturare i quelli esistenti, e prendete decisioni sui formati di export e le integrazioni API con la consapevolezza che il numero di punti di integrazione aumenterà.
I sistemi che invecchiano meglio sono quelli costruiti per essere cambiati, non quelli costruiti per essere completi.
AtroPIM's l'architettura modulare supporta questo direttamente: nuove capacità possono essere aggiunte attraverso moduli premium senza modificare il modello dati di base, il che preserva l'investimento nella configurazione originale mentre consente al sistema di crescere con l'azienda.
15. Iniziare la Migrazione Dati PIM Prima di Quanto Pensiate Necessario
La migrazione dei dati è quasi sempre l'elemento che supera la pianificazione. 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 prima, e il processo di importazione rivela lacune o inconsistenze nel modello dati che richiedono aggiustamenti prima che i dati possano essere caricati correttamente.
Un inizio anticipato vi dà tempo per affrontare tutti e tre. Identificate ogni fonte di dati master (export ERP, fogli di calcolo dei fornitori, database legacy, unità condivise) all'inizio del progetto, non alla fine. Valutate la qualità di ogni fonte prima di pianificare la migrazione. Create tempo per il bonificamento nella pianificazione.
Il miglioramento della qualità dei dati non è una fase di migrazione. È un processo continuo. Ma la migrazione è quando l'ambito completo del problema di qualità diventa visibile, e quello è un momento difficile per incontrarlo due settimane prima del go-live.
16. Migrare Dati Come Sono Prima, Poi Migliorarli
L'istinto di pulire e ristrutturare i dati prima di migrarli è ragionevole ma solitamente controproducente. Prendere decisioni su cosa mantenere, rimuovere o ristrutturare richiede di comprendere come i dati si comportano nel nuovo sistema. Non avete questa comprensione finché i dati non sono lì.
Trasferite i dati invariati nel PIM. Eseguite controlli di completezza, identificate i valori mancanti e segnalate i problemi strutturali una volta che i dati sono nel sistema. Poi prendete decisioni di pulizia basate su quello che potete vedere, non su quello che vi aspettate di trovare. L'arricchimento dei dati (aggiunta di attributi mancanti, standardizzazione dei valori, miglioramento delle descrizioni) è un'attività post-migrazione, non pre-migrazione.
Questo approccio previene anche la perdita accidentale di dati. I dettagli che sembrano non necessari durante la migrazione spesso si rivelano 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 Requisito Centrale, Non Elemento di 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 inconsistenze. Le inconsistenze producono errori nei contenuti pubblicati che sono lunghi da identificare e risolvere.
La distribuzione omnichannel mette una pressione particolare sulla qualità dell'integrazione. Se il vostro sistema di gestione delle informazioni sui prodotti deve spingere dati coerenti a un webshop, più marketplace, portali di partner retail e produzione di stampa in tempo quasi reale, gli export batch basati su file non si adattano. L'integrazione basata su API con aggiornamenti guidati da eventi per dati che cambiano rapidamente è 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, sincronizzazione bidirezionale dove necessario e logica di risoluzione chiara dei conflitti. Se la capacità di integrazione è limitata o richiede lavoro personalizzato significativo per raggiungere la connettività di base, quello è un problema di selezione, non un problema di configurazione.
I nostri clienti che hanno sostituito la sincronizzazione ERP basata su file con l'integrazione basata su API attraverso AtroPIM riportano costantemente una riduzione degli errori nei dati e una diminuzione significativa del tempo tra un aggiornamento ERP e il suo apparire nel canale di vendita.
18. Scrivere la Documentazione Durante l'Implementazione, Non Dopo
La documentazione scritta dopo l'implementazione è basata sulla memoria e tende a descrivere come il sistema doveva funzionare piuttosto che come funziona effettivamente. La documentazione scritta durante l'implementazione è più accurata, più dettagliata e più utile.
Questo non significa documentare ogni funzione del sistema: il fornitore PIM fornisce quella. L'obiettivo è documentare le decisioni specifiche della vostra implementazione: perché determinati attributi erano strutturati nel modo in cui lo erano, quali sono le regole del workflow di approvazione e quali eccezioni esistono, come i template di importazione e esportazione 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 la documentazione quando si verificano è costantemente più alto del costo di crearla.
19. Definire KPI Prima del Go-Live e Misurare il ROI Dopo
Un'implementazione PIM senza metriche di successo definite è difficile da giustificare e difficile da migliorare. I risultati che il sistema doveva fornire (time-to-market più rapido, meno errori nei dati raggiungono il canale, tempo ridotto speso per l'inserimento dati manuale, tassi di completezza dei dati dei prodotti più elevati) devono essere stabiliti come target misurabili prima del go-live, non descritti in retrospettiva.
I KPI utili per un'implementazione PIM includono: percentuale di record di prodotto che soddisfano la definizione di completezza, tempo dalla creazione del prodotto alla prima pubblicazione, tasso di errore nei dati distribuiti del canale e numero di passaggi di integrazione manuale sostituiti dalla sincronizzazione automatizzata. Queste metriche sono abbastanza specifiche da tracciare e mappare direttamente ai problemi operativi che il sistema è stato introdotto per risolvere.
Il ROI da un'implementazione PIM si materializza sia sul lato dei costi che su quello dei ricavi. I risparmi operativi provengono dalla riduzione della gestione manuale dei dati e da meno errori del canale che richiedono correzione. Dal lato dei ricavi, gli elenchi più veloci su nuovi canali e la conversione più elevata da contenuti di prodotto completi e arricchiti dipendono direttamente dalla qualità di quello che il PIM produce. Documentare la 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à dei dati in un sistema PIM raramente sono causati da azioni malevole. Sono causati da utenti che avevano accesso che non avrebbero dovuto avere, o che non è stato impedito loro di lasciare un campo vuoto o 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 i gate di pubblicazione basati su workflow che impediscono ai record incompleti di raggiungere il canale.
Dove la logica di validazione è troppo complessa per essere configurata in modo dichiarativo, può essere programmata. L'investimento si ripaga rapidamente in tassi di errore ridotti e overhead editoriale inferiore.
21. Utilizzare la Capacità Completa 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 assumere funzioni che riducono il numero totale di sistemi che un'azienda ha bisogno di mantenere.
AtroPIM, costruito sulla piattaforma AtroCore, è progettato per questo. Oltre alle funzioni standard di gestione delle informazioni sui prodotti, può agire come middleware tra ERP e canali di vendita, gestire calcoli di prezzo ed elaborazione di regole aziendali, gestire asset digitali in modo nativo attraverso il suo DAM integrato, generare fogli di prodotto e cataloghi PDF direttamente, supportare workflow di collaborazione con fornitori e gestire la distribuzione omnichannel a qualsiasi numero di canali via la sua API REST. Ogni funzione che il PIM gestisce è un punto di integrazione in meno da mantenere altrove.
Il punto non è espandere lo scope per il bene di se stesso. È 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 dalle migliori prestazioni 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 man mano che i requisiti reali emergevano.
Quello è il modello che vale la pena seguire.