PLM y ERP: ¿quién gestiona cada dato de producto?
El PLM acompaña el diseño y el desarrollo del producto, mientras que el ERP se encarga de su gestión operativa, en particular las compras, la producción y las existencias. Ambos sistemas deben poder intercambiar sus datos para evitar dobles registros e incoherencias.
Dos sistemas para dos etapas de la vida del producto
Un producto alimentario o cosmético existe mucho antes de su primera fabricación. Durante semanas, I+D formula ensayos, calidad verifica la conformidad y marketing aprueba la etiqueta y el envase. Ese trabajo de definición corresponde al PLM (gestión del ciclo de vida del producto): fórmulas, especificaciones, datos regulatorios, etiquetado, envases, versiones y proyectos.
El ERP interviene en la gestión operativa del producto: compras, fabricación, existencias y ventas. Gestiona los proveedores homologados, los precios de compra, las órdenes de fabricación, los lotes, las existencias y los pedidos de venta. El ERP conoce los costes reales; el PLM conoce el coste teórico de la receta.
¿Qué sistema es la referencia de cada dato?
Para evitar incoherencias, conviene definir qué sistema es la referencia para cada dato. Este reparto puede variar según la organización y las herramientas existentes.
| Dato | Sistema de referencia | Cuándo se transmite |
|---|---|---|
| Receta o fórmula, ensayos | PLM | Al aprobar la versión, hacia el ERP |
| Lista de materiales de fabricación y de envase | PLM | Al aprobarla, hacia el ERP |
| Especificaciones, alérgenos, nutrición | PLM | Hacia fichas técnicas, ERP y catálogos GS1 |
| Contenido de la etiqueta, lista de ingredientes o lista INCI | PLM | Hacia artes finales y catálogos |
| Datos regulatorios de materias primas | PLM | Los usa calidad, rara vez el ERP |
| Código de artículo | ERP o PLM, a elegir | Al crear el artículo, en ambos sentidos |
| Precios de compra y costes reales | ERP | Periódicamente, hacia el PLM para el escandallo |
| Existencias, lotes, órdenes de fabricación | ERP | No vuelven, salvo para una investigación de calidad |
| Pedidos de venta y ventas | ERP | Hacia la inteligencia de negocio |
Tres patrones de integración habituales
Liberar la receta aprobada
Cuando se aprueba en el PLM una versión de receta o de lista de materiales, se libera al ERP. Los ensayos y las versiones de trabajo se quedan en el PLM. La planta solo recibe lo aprobado.
Crear el artículo
Un producto nuevo debe existir en el ERP antes del primer pedido de compra o de venta. O bien el PLM crea el artículo y el ERP le asigna el código, o bien el ERP crea el código y el PLM lo recoge. Es importante definir qué sistema crea los códigos de artículo y mantener una correspondencia fiable entre ambos programas.
Devolver los costes
El PLM calcula el coste teórico de una receta. Para que sea exacto, necesita los precios reales de compra de ingredientes y envases, que están en el ERP. Ese flujo va periódicamente del ERP al PLM.
Errores frecuentes
- Doble entrada: la receta se vuelve a teclear en el ERP, con errores de cantidad o de unidad.
- Una hoja de cálculo por medio: una exportación a Excel retocada a mano que nadie controla del todo.
- Cambios sin control: una lista de materiales corregida directamente en el ERP que ya no coincide con la receta ni con la etiqueta.
- Dos maestros para el mismo dato: alérgenos o pesos introducidos en ambos sistemas, sin una única fuente fiable.
Cuando el PLM es el sistema de referencia para las recetas, los cambios deben aprobarse en él antes de transmitirse al ERP.
Lista de comprobación antes de conectar
Antes de construir cualquier interfaz, responda a cinco preguntas con I+D, calidad, compras e informática:
- ¿Qué sistema es la referencia de cada dato de la tabla anterior?
- ¿Qué evento dispara la liberación: aprobación, cambio de estado, fecha?
- ¿Quién crea el código de artículo y dónde se guarda la correspondencia?
- ¿Cómo se detecta que una transferencia ha fallado y quién la corrige?
- ¿Con qué frecuencia deben volver los costes?
Lo que aporta beCPG
beCPG es el sistema de referencia de los datos de producto: en cuanto un producto se aprueba, se modifica o se archiva, el cambio queda disponible para su ERP, directamente o a través de su ESB o su ETL. Su API REST (documentación en inglés) importa y exporta cualquier entidad en JSON y admite la sincronización en ambos sentidos: sale un registro aprobado, vuelven los costes. El conector SAP envía materiales, listas de materiales y hojas de ruta a SAP S/4HANA, en OData o IDoc. Un conector CSV configurable alimenta otros ERP.
Cada conector está ligado a un canal de publicación, que selecciona los productos que se envían y registra los éxitos y los fallos en la ficha del producto. Los intercambios pasan por HTTPS y aplican los permisos del usuario que llama. Más información en nuestro artículo en inglés sobre el intercambio de datos entre el PLM, el ERP y otros sistemas y en nuestra página de la plataforma PLM. Para hablar de su propio caso, póngase en contacto con nosotros.
Preguntas frecuentes
¿Puede un ERP sustituir a un PLM?
El ERP guarda una lista de materiales, pero no calcula el etiquetado, los alérgenos ni la conformidad a partir de la receta, ni gestiona los ensayos. En alimentación y cosmética, esos cálculos siguen siendo tarea del PLM.
¿Hay que enviar los ensayos al ERP?
No. Solo la versión aprobada va al ERP. Los ensayos se quedan en el PLM, donde se comparan antes de la aprobación.
¿Qué sistema debe crear el código de artículo?
Los dos patrones funcionan. Lo importante es elegir un único creador y mantener la correspondencia entre el código del PLM y el del ERP, para que cada artículo siga siendo único.
¿Cómo obtiene el PLM los costes reales?
Mediante un flujo de retorno desde el ERP: los precios de compra de ingredientes y envases se envían periódicamente y el PLM recalcula el coste de las recetas.
¿Hace falta un bus de servicios para conectar PLM y ERP?
No necesariamente. A menudo basta con una API o un conector. Si su sistema de información ya tiene un ESB o una herramienta ETL, el PLM se integra en ella.
