Il peso di un prodotto è riportato nel sistema di gestione dei materiali. La percentuale di materiale riciclato è indicata nel sistema delle formulazioni. Il certificato del fornitore è disponibile in formato PDF su un’unità di rete. Il passaporto del prodotto richiede tutte e tre le informazioni in un unico record di dati, ed è proprio in questo che risiede il progetto di integrazione, non nel collegamento tra due sistemi.
La «perfetta integrazione ERP» è una promessa standard, alla quale nella pratica segue un progetto della durata di tre mesi. Pubblichiamo la nostra guida affinché il Vostro reparto IT possa verificare, prima della firma del contratto, quali dati vengono effettivamente richiesti. Questo articolo illustra quali dati il pass richiede dai vostri sistemi, attraverso quali tre canali ci vengono trasmessi e perché ciò è realizzabile in due settimane.
Cosa deve effettivamente fornire il vostro ERP
Affinché possa essere creato un DPP, abbiamo bisogno, per ogni prodotto, di:
- Dati anagrafici: codice articolo, denominazione, varianti, pesi, dimensioni, immagini
- Dati della distinta base - Componenti con quantità e percentuali di materiale riciclato
- Dati di provenienza - Luogo di produzione, numero di lotto, data di produzione
- Dati ambientali - CO₂eq per unità, consumo idrico, consumo energetico
- Dati dei fornitori - Chi fornisce quale componente (ai fini degli obblighi di diligenza)
Nel Vostro ERP questi dati sono, in teoria, tutti disponibili. In pratica, sono distribuiti in 4-7 moduli: gestione dei materiali, produzione, qualità, anagrafica fornitori, talvolta un modulo separato per i dati ambientali, talvolta un sistema dedicato alle ricette e alle distinte base.
La questione dell’integrazione non è: «Il vostro ERP fornisce dati a un DPP?», bensì: «Come riunite i dati provenienti da 5 sottosistemi in un unico set di dati coerente?»
Tre metodi collaudati
Metodo 1: Recuperare i dati dall’ERP
Funziona bene con gli ERP moderni (SAP S/4HANA Cloud, Dynamics 365, Odoo). Il fornitore del DPP recupera i dati tramite l’interfaccia dell’ERP (tecnicamente OData o REST). Solo le modifiche, secondo una pianificazione o innescate da un evento.
Vantaggi: minimo impegno di sviluppo da parte vostra; voi fornite un’autorizzazione di lettura, mentre il fornitore si occupa della conversione.
Svantaggi: non funziona con le installazioni SAP ECC meno recenti senza un livello di interfaccia aggiuntivo. Sono necessarie regole chiare su chi è autorizzato a leggere quali dati.
Metodo 2: inoltro delle modifiche
Il vostro ERP segnala ogni modifica come evento (tramite SAP Event Mesh, Apache Kafka o RabbitMQ) e il fornitore DPP la riceve.
Vantaggi: quasi in tempo reale, scalabile, i sistemi non dipendono l’uno dall’altro.
Svantaggi: la configurazione è complessa e richiede un’infrastruttura che non tutti i reparti IT possiedono. Per le aziende più piccole è spesso eccessiva.
Metodo 3: Utilizzare il livello di integrazione esistente
Disponete già di un ### livello di integrazione(Mulesoft, Boomi, Informatica, Azure Data Factory) tra l’ERP e i sistemi esterni. Questo livello funge da interfaccia: il fornitore DPP comunica con esso, mai direttamente con l’ERP.
Vantaggi: gli investimenti esistenti sono sfruttabili, le regole rimangono stabili, nessun accesso diretto all’ERP da parte di terzi.
Svantaggi: i costi relativi al livello di integrazione aumentano di conseguenza.
Cosa facciamo diversamente nei progetti concreti
Molti fornitori desiderano collegarsi direttamente al vostro ERP. Noi integriamo sempre una fase intermedia: la nostra interfaccia accetta un formato dati neutro (uno schema JSON), che voi potete compilare con uno strumento di vostra scelta. Ciò significa che:
- Potete occuparvi personalmente della preparazione dei dati, utilizzando gli strumenti che il vostro team conosce
- Potete sostituirci: il formato neutro è portabile
- Potete recuperare l’intero archivio in qualsiasi momento, in formato CSV, XLSX, JSON-LD e SQL, nonché tramite l’API REST
- Forniamo un validatore di importazione che verifica i vostri dati prima del caricamento
Il formato completo e tutte le query sono descritti pubblicamente nella documentazione dell’API, come descrizione dell’interfaccia secondo lo standard OpenAPI. Il vostro reparto IT potrà verificare l’interfaccia prima della firma del contratto, compresi esempi di richieste, risposte di errore e dettagli di autenticazione.
Tempistiche pratiche con questo approccio:
- Giorni da 1 a 2: workshop di mappatura. Quale campo ERP corrisponde a quale campo DPP?
- Giorni da 3 a 5: prime esportazioni JSON dall’ERP, tramite il nostro validatore.
- Dal giorno 6 all’8: correzione degli errori (campi mancanti, codifiche incoerenti).
- Dal giorno 9 al 10: i primi DPP sono attivi.
Due settimane, non tre mesi. Il punto cruciale è il workshop di mappatura: è lì che si decide della qualità dei dati.
Cosa può andare storto: le insidie più comuni
Dati anagrafici di prodotto in più sistemi: SAP contiene il codice articolo, il PIM le immagini e i testi di marketing, il PLM la distinta base. Nessuno ha un quadro coerente. Soluzione: definire prima dell’avvio del progetto quale sistema sia di riferimento per ciascun campo.
Certificati in formato PDF: i fornitori inviano i certificati GOTS, OEKO-TEX o REACH sotto forma di scansioni in formato PDF. Questa non è una fonte di dati strutturata. Soluzione: gli enti di certificazione offrono sempre più spesso la possibilità di effettuare richieste tramite interfaccia (OEKO-TEX è all’avanguardia, GOTS è in ritardo). Oppure: inserirli manualmente, ma indicando la data di validità, in modo che nel DPP non compaiano certificati scaduti.
Riservatezza della formulazione: in particolare nei settori cosmetico, alimentare e farmaceutico, la formulazione completa costituisce un segreto aziendale. Il DPP dovrebbe renderla pubblica? Soluzione: il modello a tre livelli dell’ESPR. La categoria di prodotto è di dominio pubblico, mentre le autorità hanno accesso alla formulazione completa. Non rappresenta quasi mai un ostacolo, ma deve essere chiarito sin dall’inizio.
Dati sulle emissioni di CO₂ a livello di fornitori: il Suo fornitore fornisce un valore medio per l’intero portafoglio, non per singolo lotto. Soluzione: accettarlo temporaneamente, adeguando a lungo termine i contratti con i fornitori. L’ESPR richiede valori specifici per prodotto a partire da una data di riferimento, ma la prassi attuale rappresenta un compromesso.
Versioni linguistiche locali: il Suo sistema ERP contiene solo la denominazione del prodotto in tedesco e in inglese. Per i 27 paesi dell’UE ne occorrono di più. Soluzione: traduzione automatica con banca dati terminologica; a tal proposito disponiamo di un articolo dedicato.
Le domande che dovrebbe porsi prima di avviare il progetto
Prima di inviare una richiesta di offerta (RFP) a tre fornitori, risponda internamente alle seguenti domande:
- Quanti prodotti/codici articolo dovranno disporre di DPP? (10, 10.000, 1 milione?)
- Quali sistemi contengono attualmente dati rilevanti per i DPP?
- Quale reparto gestisce ciascuno di questi sistemi?
- Disponete di un livello di integrazione che dovrebbe essere utilizzato?
- Esiste già un’interfaccia funzionante tramite il vostro ERP?
Le risposte determineranno quale delle tre opzioni sia più adatta alle vostre esigenze.
Le risposte stabiliranno se un progetto durerà due settimane o sei mesi.
Domande relative a questo articolo
È sufficiente l'interfaccia REST, oppure è necessario un middleware?
L’interfaccia è sufficiente. I tre modelli si differenziano per il luogo in cui avviene la trasformazione, non per ciò che riceviamo: la nostra interfaccia accetta uno schema JSON neutro, indipendentemente dallo strumento utilizzato per generarlo. Un pull da un moderno ERP, un flusso di eventi e un livello di integrazione esistente convergono tutti sullo stesso endpoint. È opportuno utilizzare un middleware se ne gestisce già uno e se si desidera che esso rimanga il punto di riferimento contrattuale nei confronti di terzi. Se al momento non ne esiste uno, non ne acquisti uno solo per il Product Pass.
Cosa verrà deciso nel workshop di mappatura?
Quale campo ERP corrisponde a quale campo di riferimento - e quale sistema costituisce la fonte primaria qualora più sistemi contengano lo stesso valore. Il workshop si svolge nei giorni 1 e 2 e rappresenta il punto cruciale dell’intero progetto, poiché è in quella sede che si decidono gli aspetti relativi alla qualità dei dati e non in un secondo momento nel codice. Si prega di coinvolgere le persone che gestiscono i sistemi, non solo i responsabili del progetto: i reparti che si occupano di dati anagrafici, produzione, qualità e acquisti raramente fanno parte di un unico reparto. Tutto ciò che segue, ovvero esportazioni, convalida e correzione degli errori, è una questione di competenza tecnica.
I nostri certificati sono disponibili solo in formato PDF (scansione). Cosa ne facciamo?
Una scansione non costituisce una fonte di dati strutturata e risulta quindi inutilizzabile ai fini del passaporto. Esistono due modalità efficaci: gli operatori di certificazione offrono sempre più spesso interrogazioni tramite API e, laddove queste non siano disponibili, si proceda all’inserimento manuale dei valori, indicando sempre la data di validità, in modo che nessun certificato scaduto rimanga in un passaporto pubblicato. Prevedano la procedura manuale come attività ricorrente, non come compito una tantum.
Il nostro reparto IT può verificare l’interfaccia prima che firmiamo qualcosa?
Sì. Lo schema completo e tutti gli endpoint sono disponibili come specifica OpenAPI nella documentazione dell’API, insieme a richieste di esempio, risposte di errore e dettagli sull’autenticazione. Nessuna di queste informazioni è soggetta a trattative commerciali; il vostro team di integrazione può quindi valutare l’impegno richiesto prima ancora che venga stipulato un contratto. Se un fornitore non rende visibile la propria interfaccia in questa fase, anche questo costituisce una risposta.
Cosa succede ai nostri dati quando cambiamo fornitore?
Sono compatibili. L’interfaccia accetta uno schema JSON neutro anziché un formato proprietario, e l’intero inventario viene restituito in formato CSV, XLSX, JSON-LD e SQL oppure tramite l’API REST. È una scelta voluta: il formato che compilate è portabile, pertanto un cambio di fornitore richiede solo un’esportazione e non una ricostruzione da zero. Ponete la stessa domanda a ogni fornitore prima del workshop di mappatura, poiché in seguito i nomi dei vostri campi saranno integrati nel modello del fornitore stesso.
Quanto tempo richiede effettivamente un collegamento?
Nei progetti che seguiamo, due settimane: due giorni di mappatura, tre giorni fino alle prime esportazioni tramite il nostro validatore, tre giorni per la correzione degli errori, due giorni fino alla pubblicazione dei primi passaporti. Il percorso più lungo non è mai rappresentato dal codice, bensì da ciò che il Validator individua: campi mancanti, codifiche non uniformi, valori di cui nessuno si sente responsabile. Prevedano questi giorni nel loro programma, anziché ridurne la durata. Un progetto che li tralasci finirà per pubblicare anche le lacune.
Dobbiamo collegare tutti i prodotti in una sola volta?
No. Inizi con i prodotti per i quali è necessario un pass in primo luogo e con un sistema di origine: lo schema neutro accetta sia un catalogo parziale che uno completo, e le importazioni sono ripetibili; le esecuzioni successive aggiornano quindi l’inventario. Ciò consente inoltre di mantenere il workshop di mappatura sufficientemente contenuto da poterlo portare a termine in due giorni. L’espansione successiva costituisce un’attività di mappatura, non un nuovo progetto.
