El peso de un producto figura en la gestión de materiales. El porcentaje de material reciclado se encuentra en el sistema de fórmulas. El certificado del proveedor está disponible en formato PDF en una unidad de red. La ficha técnica del producto necesita estos tres datos en un único registro, y ahí radica precisamente el proyecto de integración, no en la conexión entre dos sistemas.
La «integración perfecta con el ERP» es una promesa habitual que, en la práctica, suele ir seguida de un proyecto de tres meses. Publicamos nuestra guía para que su departamento de TI pueda comprobar, antes de firmar el contrato, qué datos se solicitan realmente. Este artículo muestra qué datos necesita el pasaporte de sus sistemas, las tres vías por las que nos llegan y por qué esto se puede llevar a cabo en dos semanas.
Lo que su ERP debe proporcionar realmente
Para crear un DPP, necesitamos por cada producto:
- Datos maestros: número de artículo, denominación, variantes, pesos, dimensiones, imágenes
- Datos de la lista de materiales: componentes con cantidades y porcentajes de material reciclado
- Datos de origen: lugar de producción, número de lote, fecha de producción
- Datos medioambientales: CO₂eq por unidad, consumo de agua, consumo de energía
- Datos de proveedores: quién suministra cada componente (para cumplir con las obligaciones de diligencia debida)
En teoría, todos estos datos están disponibles en su sistema ERP. En la práctica, se distribuyen entre 4 y 7 módulos: gestión de materiales, producción, calidad, base de datos de proveedores; a veces, un módulo independiente para datos medioambientales; y, en ocasiones, un sistema propio para fórmulas y listas de piezas.
La cuestión de la integración no es: «¿Proporciona su ERP datos a un DPP?», sino: «¿Cómo se fusionan los datos de cinco subsistemas en un conjunto de datos coherente?».
Tres métodos probados
Método 1: Recopilar los datos del ERP
Funciona bien con los ERP modernos (SAP S/4HANA Cloud, Dynamics 365, Odoo). El proveedor del DPP extrae los datos a través de la interfaz del ERP (técnicamente, OData o REST). Solo los cambios, ya sea según un calendario o activados por un evento.
Ventajas: requiere poco desarrollo por su parte; usted proporciona un acceso de lectura y el proveedor se encarga de la conversión.
Desventajas: no funciona con instalaciones antiguas de SAP ECC sin una capa de interfaz adicional. Se necesitan normas claras sobre quién puede leer qué datos.
Opción 2: reenviar los cambios
Su ERP notifica cada cambio como un evento (a través de SAP Event Mesh, Apache Kafka o RabbitMQ), y el proveedor de DPP los recibe.
Ventajas: casi en tiempo real, se adapta al crecimiento y los sistemas no dependen unos de otros.
Desventajas: la configuración es compleja y requiere una infraestructura de la que no dispone todo departamento de TI. Suele resultar excesivo para empresas más pequeñas.
Opción 3: Utilizar la capa de integración existente
Ya dispone de una ### capa de integración(Mulesoft, Boomi, Informatica, Azure Data Factory) entre el ERP y los sistemas externos. Esta capa actúa como intermediario: el proveedor de DPP se comunica con ella, nunca directamente con el ERP.
Ventajas: se pueden aprovechar las inversiones existentes, las reglas se mantienen estables y no hay acceso directo al ERP por parte de terceros.
Desventajas: sus costes relacionados con la capa de integración aumentan proporcionalmente.
Lo que hacemos de forma diferente en proyectos concretos
Muchos proveedores desean conectarse directamente a su ERP. Nosotros incorporamos siempre un paso intermedio: nuestra interfaz acepta un formato de datos neutro (un esquema JSON) que usted puede rellenar con la herramienta que elija. Esto significa que:
- Puede encargarse usted mismo del procesamiento de los datos, con las herramientas con las que su equipo está familiarizado
- Puede sustituirnos: el formato neutro es portátil
- Puede recuperar todo su inventario en cualquier momento, en formato CSV, XLSX, JSON-LD y SQL, así como a través de la API REST
- Le proporcionamos un validador de importación que comprueba sus datos antes de la carga
El formato completo y todas las consultas se describen públicamente en Documentación de la API, como una especificación de interfaz según OpenAPI. Su departamento de TI puede comprobar la interfaz antes de firmar un contrato, incluyendo consultas de ejemplo, respuestas de error y detalles de autenticación.
Plazos con este enfoque en la práctica:
- Días 1 a 2: taller de mapeo. ¿Qué campo del ERP se corresponde con qué campo del DPP?
- Días 3 a 5: primeras exportaciones en formato JSON desde el ERP, sometidas a nuestro validador.
- Días 6 a 8: corrección de errores (campos que faltan, codificaciones incoherentes).
- Días 9 a 10: los primeros DPP están operativos.
Dos semanas, no tres meses. El punto clave es el taller de mapeo: ahí es donde se decide la calidad de los datos.
Lo que suele salir mal: las trampas más habituales
Datos maestros de productos en varios sistemas: SAP tiene el número de artículo, el PIM tiene las imágenes y los textos de marketing, y el PLM tiene la lista de piezas. Nadie tiene una visión coherente. Solución: defina antes del proyecto qué sistema es el principal para cada campo.
Certificados en formato PDF: los proveedores entregan los certificados GOTS, OEKO-TEX o REACH como escaneos en PDF. Esto no constituye una fuente de datos estructurada. Solución: los organismos de certificación ofrecen cada vez más la posibilidad de realizar consultas a través de una interfaz (OEKO-TEX va por delante, GOTS va a la zaga). O bien: introducirlos manualmente, pero con la fecha de validez, para que no aparezcan certificados caducados en el DPP.
Confidencialidad de la fórmula: especialmente en los sectores de la cosmética, la alimentación y el sector farmacéutico, la fórmula completa constituye un secreto comercial. ¿Debe el DPP hacerla pública? Solución: el modelo de tres niveles de la ESPR. La categoría del producto es pública; las autoridades ven la fórmula completa. Casi nunca supone un obstáculo, pero debe aclararse con antelación.
Datos de CO₂ basados en los proveedores: su proveedor facilita un valor medio para toda su cartera, no por lote. Solución: aceptarlo temporalmente y, a largo plazo, adaptar los contratos con los proveedores. El ESPR exige valores específicos por producto a partir de una fecha de referencia, pero la práctica actual es un compromiso.
Versiones lingüísticas locales: su sistema ERP solo contiene la denominación del producto en alemán e inglés. Para los 27 países de la UE, necesitará más. Solución: traducción automática con base de datos terminológica; disponemos de un artículo específico al respecto.
Las preguntas que debe plantearse antes del proyecto
Antes de enviar una solicitud de propuesta (RFP) a tres proveedores, responda internamente a lo siguiente:
- ¿Cuántos productos o números de artículo deben tener DPP? (¿10, 10 000, 1 millón?)
- ¿Qué sistemas contienen actualmente datos relevantes para los DPP?
- ¿Qué departamento gestiona cada uno de los sistemas?
- ¿Dispone de una capa de integración que deba utilizarse?
- ¿Existe ya una interfaz operativa a través de su ERP?
Las respuestas determinarán cuál de las tres vías es la más adecuada para usted.
Las respuestas determinarán si un proyecto dura dos semanas o seis meses.
Preguntas sobre esta publicación
¿Es suficiente la interfaz REST o necesitamos un middleware?
La interfaz es suficiente. Las tres plantillas se diferencian en dónde tiene lugar la transformación, no en lo que recibimos: nuestra interfaz admite un esquema JSON neutro, independientemente de con qué lo haya generado. Una extracción de un ERP moderno, un flujo de eventos y una capa de integración ya existente terminan todos en el mismo punto final. Merece la pena utilizar un middleware si ya dispone de uno y si desea que este siga constituyendo el contrato frente a terceros. Si actualmente no dispone de ninguno, no adquiera ninguno para el «Product Pass».
¿Qué se decide en el taller de mapeo?
Qué campo del ERP se convierte en qué campo de correspondencia, y qué sistema es la fuente principal cuando varios contienen el mismo valor. El taller tiene lugar los días 1 y 2 y constituye el punto crucial de todo el proyecto, ya que es allí donde se toman las decisiones sobre la calidad de los datos y no más adelante, en el código. Traiga a las personas que se encargan del mantenimiento de los sistemas, no solo a los responsables del proyecto: los departamentos de datos maestros, producción, calidad y compras rara vez se encuentran en un mismo departamento. Todo lo que viene después - es decir, las exportaciones, la validación y la corrección de errores - es cuestión de destreza técnica.
Nuestros certificados solo están disponibles en formato PDF escaneado. ¿Qué hacemos con ellos?
Un escaneo no es una fuente de datos estructurada y, por lo tanto, no es válido para el pase. Hay dos formas de proceder: los operadores de certificación ofrecen cada vez más consultas a través de API y, cuando no existan, introduzca los valores manualmente, pero siempre indicando la fecha de validez, para que no quede ningún certificado caducado en un pase publicado. Planifique el método manual como una tarea recurrente, no como una tarea puntual.
¿Podría nuestro departamento de TI comprobar la interfaz antes de que firmemos nada?
Sí. El esquema completo y todos los puntos finales están disponibles como especificación OpenAPI en Documentación de la API, junto con solicitudes de ejemplo, respuestas de error y detalles de autenticación. Nada de esto está sujeto a una negociación comercial, por lo que su equipo de integración puede evaluar el esfuerzo necesario antes de que exista un contrato. Si un proveedor no muestra su interfaz en esta fase, eso también es una respuesta.
¿Qué ocurre con nuestros datos cuando cambiamos de proveedor?
Se adaptan a sus necesidades. La interfaz acepta un esquema JSON neutro en lugar de un formato propietario, y todo su inventario se exporta en formatos CSV, XLSX, JSON-LD y SQL, o a través de la API REST. Esto es intencionado: el formato que usted rellena es portátil, por lo que un cambio solo requiere una exportación y no es necesario crear uno nuevo. Plantee la misma pregunta a cada proveedor antes del taller de mapeo, ya que, una vez finalizado, los nombres de sus campos figurarán en el modelo de dicho proveedor.
¿Cuánto tiempo dura realmente una conexión?
En los proyectos que supervisamos, dos semanas: dos días de mapeo, tres días hasta las primeras exportaciones a través de nuestro validador, tres días de corrección de errores y dos días hasta la publicación de los primeros pasaportes. El proceso más largo nunca es el código, sino lo que detecta el validador: campos que faltan, codificaciones inconsistentes, valores de los que nadie se hace responsable. Prevea estos días en su planificación, en lugar de reducirlos. Un proyecto que se salte esta fase publicará también las lagunas.
¿Tenemos que dar de alta todos los productos a la vez?
No. Empiece por los productos que requieren una ficha primero y utilice un sistema fuente: el esquema neutro admite tanto un catálogo parcial como uno completo, y las importaciones son repetibles, por lo que las ejecuciones posteriores actualizan el inventario. Esto también permite que el taller de mapeo sea lo suficientemente breve como para completarlo en dos días. La ampliación posterior es una tarea de mapeo, no un nuevo proyecto.
