Welke kenmerken van het digitaal productpaspoort komen van buitenaf
Een digitaal productpaspoort (DPP) combineert gegevens die een bedrijf al bezit met gegevens die het moet opvragen, en die verdeling is ongelijk.
- Intern aanwezig: productidentificatoren, afmetingen, modelnummers en de meeste commerciële kenmerken die al in het PIM of ERP staan.
- In bezit van directe leveranciers: materiaalsamenstelling, stoffenverklaringen, gerecycled materiaal en productielocatie voor elk onderdeel.
- Verderop in de keten aanwezig: herkomst van grondstoffen, die een tier-one leverancier zelf mogelijk weer moet opvragen bij tier-two.
- Gegenereerd door derden: certificeringen, testrapporten en berekeningen van de ecologische voetafdruk, opgesteld door laboratoria of beoordelaars.
- Aan het einde gecreëerd: reparatie-instructies, demontagehandleidingen en verwerking aan het einde van de levensduur, die vaak als documenten bestaan in plaats van als data.
Alleen de eerste categorie reageert op interne inspanningen. Het in kaart brengen van het datamodel voor het DPP over ERP, PLM en PIM is werk dat een bedrijf kan inplannen. De rest komt binnen in de kwaliteit en frequentie die de toeleveringsketen aankan, wat voor de meeste bedrijven neerkomt op e-mailbijlagen en spreadsheets.
Waarom loopt data voor het digitaal productpaspoort vast bij leveranciers?
Leveranciers zijn niet verplicht om uw format te gebruiken. De verordening betreffende ecologisch ontwerp voor duurzame producten (ESPR) bindt het bedrijf dat een product op de markt brengt, niet de toeleverancier drie stappen verderop. Naleving van de ESPR wordt daarom door de leverancier eerder als een commercieel verzoek dan als een wettelijke verplichting gezien.
Het vermogen varieert meer dan de bereidheid. Een grote leverancier beschikt wellicht over de gegevens, maar slaat deze op in een systeem waaruit de gevraagde informatie niet kan worden geëxporteerd. Een kleine leverancier weet het antwoord misschien wel, maar heeft geen andere manier om het door te geven dan via een e-mail. Beiden werken mee, maar geen van beiden levert gestructureerde data aan.
Daarnaast is er sprake van verloop. Een eenmaal verzamelde materiaalspecificatie is accuraat totdat de leverancier een bron wijzigt; dit gebeurt vaak zonder berichtgeving omdat de wijziging geen invloed heeft op het onderdeelnummer. Het DPP bevat dan een claim die het product niet langer ondersteunt, wat erger is dan een ontbrekende waarde.
Wat kost een handmatig verzamelproces?
Bedrijven beginnen meestal met een spreadsheet-sjabloon dat naar de leveranciers wordt gemaild. De kosten volgen een voorspelbaar patroon:
- Eindeloos achtervolgen: een medewerker van compliance of inkoop besteedt de hele week aan het opvolgen van uitblijvende reacties, en de lijst met openstaande punten wordt bij elke productwijziging gereset.
- Onbruikbare data: vrije tekstvelden, inconsistente eenheden en materiaalaanduidingen die niet overeenkomen met enige standaardterminologie.
- Claims die niet onderbouwd kunnen worden: een percentage gerecycled materiaal staat in het DPP zonder registratie van wie het heeft aangeleverd of wanneer, wat bij een audit tot afkeuring leidt.
- Vertragingen bij productlanceringen: een product mag niet op de markt worden gebracht zonder een volledig DPP, dus één ontbrekend kenmerk van een leverancier blokkeert een hele reeks.
- Stille veroudering: gegevens die achttien maanden geleden zijn verzameld, worden als actueel gepresenteerd omdat er nergens wordt bijgehouden wanneer ze voor het laatst zijn bevestigd.
Geen van deze problemen is een technologisch falen. Elk probleem vloeit voort uit het verzamelen van gereguleerde data via een kanaal dat bedoeld is voor correspondentie, en daarom lopen digitaal productpaspoort-programma's vast in de verzamelfase in plaats van in de modelleringsfase.
Leveranciers behandelen als een datakanaal, niet als een mailinglijst
Bedrijven die dit goed aanpakken, stoppen met het zien van leveranciersgegevens als een verzamelopdracht. Ze behandelen het als een doorlopende uitwisseling, wat hetzelfde vraagstuk is als het onboarden van een handelspartner voor bestellingen.
Dat heeft een praktisch gevolg. Een leverancier die al elektronisch orderbevestigingen en verzendberichten verstuurt, is een leverancier die op dezelfde manier materiaaldeclaraties kan versturen, via een kanaal dat al bestaat. Een leverancier die dat niet kan, heeft een eenvoudigere route nodig, meestal een formulier of een gestructureerd spreadsheet dat bij aankomst wordt gevalideerd in plaats van nadat iemand het heeft gelezen.
Het onderscheid dat ertoe doet, is niet de grootte van de leverancier. Het gaat erom of de gegevens binnenkomen in een vorm die het ontvangende systeem kan controleren. Een kenmerk dat door niemand is gevalideerd, zal bij een audit falen in plaats van bij de inname.
Hoe een integratieplatform omgaat met gegevens voor het digitaal productpaspoort
Er zijn drie routes en elk heeft zijn beperkingen. Een specifiek DPP- of compliance-platform modelleert de vereisten goed, maar moet nog steeds worden gevoed vanuit uw systemen en die van uw leveranciers. Een PIM slaat de kenmerken correct op zodra ze binnenkomen, maar biedt weinig hulp bij het verzamelen ervan. Gegevens verzamelen via e-mail en handmatig consolideren is wat de meeste bedrijven nu doen, en dat beperkt het aantal leveranciers en producten dat het programma kan dekken.
Een Integration Platform-as-a-Service (iPaaS) fungeert als tussenlaag tussen het leveranciersbestand, de interne systemen en het register waar het DPP wordt gepubliceerd. Op het Alumio iPaaS neemt dat werk vier vormen aan:
- Elk leveranciersformaat geaccepteerd: een data Transformer zet gestructureerde berichten, spreadsheets en bestandsuploads om naar één intern kenmerkmodel, zodat de mogelijkheden van de leverancier de innameroute bepalen in plaats van de vraag of ze wel kunnen deelnemen.
- Gecontroleerd voordat het binnenkomt: validatieregels wijzen ontbrekende eenheden, niet-herkende materiaalbenamingen of waarden buiten het bereik direct aan de grens af, met een reden waar de leverancier actie op kan ondernemen.
- Herkomst per kenmerk vastgelegd: gedetailleerde Logs leggen vast welke leverancier welke waarde heeft geleverd en wanneer, wat een DPP-claim verandert in bewijslast.
- Gepubliceerd waar nodig: een event-driven data Route brengt het voltooide record naar het PIM, de webshop en het register, zodat één update van een kenmerk elke bestemming bereikt.
Die stromen worden geconfigureerd in plaats van per leverancier handmatig gebouwd, waarbij de Code Transformer beschikbaar is voor situaties waarin configuratie niet volstaat en het schrijven van code de voorkeur heeft. De honderdste leverancier wordt gekoppeld aan een patroon in plaats van aan een project.
Wat voorbereiding op het digitaal productpaspoort daadwerkelijk oplevert
Compliance-programma's worden gefinancierd op basis van de deadline en beoordeeld op de vraag of het product verzonden kon worden. Die insteek onderschat wat het werk oplevert, omdat dezelfde gegevens claims ondersteunen waar het marketingteam al jaren om vraagt, maar die ze nooit konden onderbouwen.
Een bedrijf dat de materiaalsamenstelling en herkomst per product kan aantonen, kan duurzaamheidsclaims maken die standhouden bij kritische controle. Het kan verkopen aan retailers die die gegevens nu contractueel eisen. Het kan een vraag van een klant over repareerbaarheid beantwoorden zonder een heel onderzoeksproject te hoeven starten.
De deadline is dan niet langer het hoofddoel. Een fabrikant die kan aantonen wat een product bevat, waar het vandaan komt en wie dit heeft bevestigd, heeft iets gebouwd waarvoor de nalevingsdatum slechts het eerste gebruiksmoment was.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
