La «integrazione ERP senza soluzione di continuità» è una promessa standard che, nella pratica, comporta un progetto della durata di tre mesi. Pubblichiamo il nostro API Playbook affinché il vostro reparto IT possa verificare, prima della firma del contratto, quali dati vengono effettivamente richiesti. Ecco cosa dovreste sapere prima di avviare un progetto di integrazione.
Cosa deve effettivamente fornire il vostro ERP
Per creare 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 (per la due diligence)
In teoria, tutti questi dati sono presenti nel vostro ERP. In pratica, sono distribuiti in 4-7 moduli: Gestione dei materiali (MM), Produzione (PP), Qualità (QM), Fornitori (LFA1), a volte un modulo EHS separato per i dati ambientali, a volte un sistema PLM per le formulazioni.
La questione dell’integrazione non è: «Il vostro ERP fornisce dati a un DPP?», ma piuttosto: «Come riunite i dati provenienti da 5 sottosistemi in un unico set di dati coerente?»
Tre modelli di integrazione collaudati
Modello 1: OData / REST-Pull
Funziona bene con gli ERP moderni (SAP S/4HANA Cloud, Dynamics 365, Odoo). Il fornitore del DPP estrae i dati tramite OData o REST. In modo incrementale, pianificato o basato sugli eventi.
Vantaggi: poco lavoro di sviluppo da parte vostra; voi fornite le credenziali di lettura, il fornitore si occupa della trasformazione.
Svantaggi: non funziona con le vecchie installazioni SAP ECC senza un livello API aggiuntivo. È necessaria una governance delle richieste di accesso ai dati.
Modello 2: Integrazione basata sugli eventi
SAP Event Mesh, Apache Kafka, RabbitMQ. Il vostro ERP pubblica gli eventi di modifica, il fornitore DPP li consuma.
Vantaggi: quasi in tempo reale, elegantemente scalabile, disaccoppiato.
Svantaggi: la configurazione è complessa e richiede un’infrastruttura che non tutti i reparti IT possiedono. Per le aziende più piccole è spesso eccessiva.
Modello 3: Middleware / ETL
Si dispone di un livello di integrazione (Mulesoft, Boomi, Informatica, Azure Data Factory) tra l’ERP e i sistemi esterni. Il middleware funge da interfaccia: il fornitore DPP comunica con il middleware, mai direttamente con l’ERP.
Vantaggi: gli investimenti esistenti sono sfruttabili, la governance è stabile, nessun accesso diretto all’ERP da parte di terzi.
Svantaggi: i costi del middleware aumentano proporzionalmente.
Cosa facciamo diversamente nei progetti concreti
Molti fornitori vogliono connettersi direttamente al vostro ERP. Noi integriamo sempre un passaggio intermedio: la nostra API accetta uno schema JSON neutro, che potete compilare con uno strumento a vostra scelta. Ciò significa che:
- Potete occuparvi voi stessi della preparazione dei dati, utilizzando gli strumenti che il vostro team conosce bene
- 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
Lo schema completo e tutti gli endpoint sono documentati pubblicamente su /apidocs come specifica OpenAPI. Il vostro reparto IT può verificare l’interfaccia prima della firma del contratto, compresi le richieste di esempio, le risposte di errore e i dettagli di autenticazione.
Tempistiche pratiche con questo approccio:
- Giorni 1-2: workshop di mappatura. Quale campo ERP corrisponde a quale campo DPP?
- Dal giorno 3 al giorno 5: prime esportazioni JSON dall’ERP, tramite il nostro validatore.
- Dal giorno 6 al giorno 8: correzione degli errori (campi mancanti, codifiche incoerenti).
- Dal giorno 9 al giorno 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 ha il codice articolo, il PIM ha le immagini e i testi di marketing, il PLM ha la distinta base. Nessuno ha un quadro coerente. Soluzione: definire prima dell’inizio del progetto quale sistema sia la «Source of Truth» per ciascun campo.
Certificati in formato PDF: i fornitori inviano i certificati GOTS, OEKO-TEX o REACH come scansioni in formato PDF. Questa non è una fonte di dati strutturata. Soluzione: gli enti di certificazione offrono sempre più spesso interrogazioni tramite API (OEKO-TEX è all’avanguardia, GOTS è in ritardo). Oppure: inserire manualmente i dati, ma indicando la data di validità, in modo che nel DPP non compaiano certificati scaduti.
Riservatezza della formulazione: soprattutto nei settori cosmetico, alimentare e farmaceutico, la formulazione completa è un segreto aziendale. Il DPP dovrebbe renderla pubblica? Soluzione: il modello a tre livelli dell’ESPR. La categoria di prodotto è pubblica, mentre le autorità vedono la formulazione completa. Quasi mai un ostacolo, ma va chiarito tempestivamente.
Dati sulle emissioni di CO₂ forniti dai fornitori: il vostro fornitore fornisce un valore medio per l’intero portafoglio, non per singolo lotto. Soluzione: accettarlo temporaneamente, adeguare i contratti con i fornitori nel lungo termine. 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 vostro ERP contiene solo la denominazione del prodotto in tedesco e inglese. Per i 27 paesi dell’UE ne servono di più. Soluzione: traduzione automatica con database terminologico; a questo proposito abbiamo dedicato un articolo a parte.
Le domande da porsi prima di avviare il progetto
Prima di inviare una richiesta di offerta (RFP) a tre fornitori, rispondete internamente alle seguenti domande:
- Quanti prodotti/codici articolo dovranno avere i DPP? (10, 10.000, 1 milione?)
- Quali sistemi contengono attualmente dati rilevanti per i DPP?
- Quale reparto gestisce ciascuno di questi sistemi?
- Avete già investito in un middleware che dovrebbe essere utilizzato?
- Esiste già un livello API funzionante sopra il vostro ERP?
Le risposte determineranno quale dei tre modelli è più adatto a voi. E stabiliranno se un progetto durerà due settimane o sei mesi.