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 nuestro manual de API para que su departamento de TI pueda comprobar, antes de firmar el contrato, qué datos se solicitan realmente. Esto es lo que debe saber antes de emprender un proyecto de integración.
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 piezas: 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 la diligencia debida)
En teoría, todos estos datos están disponibles en su ERP. En la práctica, se encuentran repartidos entre 4 y 7 módulos: Gestión de materiales (MM), Producción (PP), Calidad (QM), Proveedores (LFA1), a veces un módulo EHS independiente para los datos medioambientales y, en ocasiones, un sistema PLM para las fórmulas.
La cuestión de la integración no es: «¿Proporciona su ERP datos a un DPP?», sino: «¿Cómo se recopilan los datos de cinco subsistemas para formar un conjunto de datos coherente?».
Tres patrones de integración probados
Patrón 1: OData / REST-Pull
Funciona bien con los ERP modernos (SAP S/4HANA Cloud, Dynamics 365, Odoo). El proveedor de la DPP extrae los datos a través de OData o REST. De forma incremental, programada o basada en eventos.
Ventajas: requiere poco desarrollo por su parte; usted proporciona las credenciales de lectura y el proveedor se encarga de la transformación.
Desventajas: no funciona con instalaciones antiguas de SAP ECC sin una capa de API adicional. Se necesita un control de las solicitudes de acceso a los datos.
Modelo 2: Integración basada en eventos
SAP Event Mesh, Apache Kafka, RabbitMQ. Su ERP publica eventos de cambio y el proveedor de DPP los consume.
Ventajas: casi en tiempo real, escalabilidad elegante, desacoplado.
Desventajas: la configuración es compleja y requiere una infraestructura de la que no dispone cualquier departamento de TI. Suele ser excesivo para empresas más pequeñas.
Modelo 3: Middleware / ETL
Dispone de una capa de integración (Mulesoft, Boomi, Informatica, Azure Data Factory) entre el ERP y los sistemas externos. El middleware es el enlace: el proveedor de DPP se comunica con el middleware, nunca directamente con el ERP.
Ventajas: se pueden aprovechar las inversiones existentes, la gobernanza es estable y no hay acceso directo al ERP por parte de terceros.
Desventajas: sus costes de middleware aumentan proporcionalmente.
Qué hacemos de forma diferente en proyectos concretos
Muchos proveedores quieren conectarse directamente a su ERP. Nosotros incorporamos siempre un paso intermedio: nuestra API acepta un esquema JSON neutro que usted puede rellenar con la herramienta que elija. Esto significa que:
- Puede encargarse usted mismo del procesamiento de los datos, con las herramientas que su equipo ya conoce
- Puede cambiarnos de proveedor: 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
- Proporcionamos un validador de importación que comprueba sus datos antes de la carga
El esquema completo y todos los puntos de conexión están documentados públicamente en /apidocs como especificación OpenAPI. Su departamento de TI puede comprobar la interfaz antes de firmar el contrato, incluyendo solicitudes de ejemplo, respuestas de error y detalles de autenticación.
Plazos con este enfoque en la práctica:
- Días 1 y 2: taller de mapeo. ¿Qué campo del ERP se corresponde con qué campo de DPP?
- Días 3 a 5: primeras exportaciones JSON desde el ERP, mediante 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. La clave está en el taller de mapeo: ahí es donde se decide la calidad de los datos.
Lo que puede salir mal: las trampas más comunes
Datos maestros de productos en varios sistemas: SAP tiene el número de artículo, PIM tiene las imágenes y los textos de marketing, PLM tiene la lista de piezas. Nadie tiene una visión coherente. Solución: define antes del proyecto qué sistema es la «fuente de verdad» para cada campo.
Certificados en formato PDF: los proveedores envían 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 consultas a través de API (OEKO-TEX va por delante, GOTS se queda atrás). O bien: introducir los datos manualmente, pero con la fecha de validez, para que no aparezcan certificados caducados en el DPP.
Confidencialidad de la fórmula: especialmente en cosmética, alimentación y productos farmacéuticos: la fórmula completa es un secreto comercial. ¿Debe el DPP hacerla pública? Solución: el modelo de tres niveles del 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 desde el principio.
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 determinada, pero la práctica actual es un compromiso.
Versiones lingüísticas locales: su ERP solo contiene la denominación del producto en alemán e inglés. Para los 27 países de la UE necesita más. Solución: traducción automática con base de datos terminológica; tenemos un artículo específico sobre este tema.
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 referencias 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 alguna inversión en middleware que deba aprovecharse?
- ¿Existe ya una capa de API operativa sobre su ERP?
Las respuestas determinarán cuál de los tres modelos se adapta mejor a sus necesidades. Y determinarán si un proyecto durará dos semanas o seis meses.