Ir al contenido
BASE DE CONOCIMIENTO · DATOS DE PRODUCTO

Lo que el PPWR le exige

Reunir datos de envase es una cuestión de datos antes de ser una cuestión jurídica. Este texto trata del reunir.

LO QUE AQUÍ HACEMOS Y NO HACEMOS

Primero el límite de este texto

El PPWR es el reglamento europeo de envases. Exige de las empresas que puedan mostrar datos sobre sus envases. Lo que podemos decir de ese reglamento termina ahí: no somos asesores jurídicos y por tanto no vamos a explicar aquí qué obligación rige en qué fecha para qué tipo de empresa. Quien necesite certeza sobre eso la obtiene de alguien que responda por ella.

Donde sí tenemos algo que decir es en la parte práctica: el reunir. Porque antes de que una obligación se convierta en una cuestión jurídica, es una cuestión de datos. Tiene que conseguir datos sobre envases de sus proveedores, completarlos, mantenerlos al día y poder volver a encontrarlos. Es exactamente el mismo problema que reunir datos de producto, y falla exactamente de la misma manera.

EL NÚCLEO

Una cuestión de datos antes de ser una cuestión jurídica

En la práctica, un proyecto así tiene el mismo aspecto en casi todo el mundo. Sale un correo a los proveedores con la petición de datos de envase, certificados y especificaciones. Una parte responde, otra no, otra responde con un archivo que no es lo que pedía. Alguien lleva la situación en una hoja de cálculo. Dos meses después nadie sabe ya qué versión es la última.

El error no está en esas personas. El error está en que los datos son del otro, mientras que el rellenar le toca a usted. Cada vez que rellena algo que sabe otra persona, construye una copia que envejece. La solución no es, por tanto, insistir mejor sino invertir el sentido: la parte que lo sabe lo rellena ella misma, en un único lugar, donde usted lo puede ver.

DONDE EL CORREO FRACASA

Tres cosas que un buzón no puede hacer

Un intercambio de correos es una manera excelente de pedir algo y una mala manera de reunir algo. Esa diferencia no se nota hasta la tercera ronda. Abajo los tres puntos en los que falla en la práctica, y por qué ningún acuerdo sobre «por favor como adjunto en este formato» los resuelve.

Un buzón no conoce versiones

Dos adjuntos con el mismo nombre, con dos semanas de diferencia. ¿Cuál es el último? Y más importante: ¿cuál usó su colega cuando hizo el resumen? Mientras el archivo circule en lugar de estar en un único lugar, esa pregunta no se puede responder sin llamar a alguien.

Un buzón no conoce campos vacíos

Un formulario sabe lo que le falta; un correo no. Si un proveedor entrega cuatro de los seis datos, usted lo ve solo cuando lo traspasa él mismo. En un portal, quien rellena lo ve al momento, y eso le ahorra la ronda en la que aún tiene que pedirle los dos últimos.

Un buzón no tiene contador

La pregunta en este tipo de proyectos nunca es «¿se puede?» sino «¿dónde estamos?». ¿Cuántas partes han acabado, cuántas han empezado, cuántas no han hecho nada todavía? Sin ese contador es imposible planificar, y con ese contador es una reserva de trabajo como cualquier otra.

EL SENTIDO INVERSO

Deje que el otro lo rellene él mismo

Un portal es un entorno aislado para una sola parte. En el lado de la venta ya lo conoce: un cliente o un distribuidor entra y ve sus propios precios, su propio surtido, sus propios pedidos y sus propios documentos, y nada más. En el lado de la compra, el mismo mecanismo funciona justo al revés: allí su proveedor rellena él mismo sus datos — datos de envase, certificados y especificaciones — en lugar de que su equipo los reúna por correo.

Lo que eso produce es menos espectacular de lo que suena y precisamente por eso utilizable. Obtiene un conjunto completo en lugar de un buzón lleno de adjuntos. Ya no hay discusión sobre quién tenía qué versión, porque hay una. Los permisos están fijados por usuario: quién puede rellenar, quién puede solo mirar, quién puede aprobar. Y el portal está en una dirección propia, con la identidad visual de la parte que lo usa, de modo que no parece un anexo a un sistema suyo sino un lugar donde esos datos deben estar.

LO QUE CONSTRUIMOS HOY

Un portal de proveedores en la práctica

Para Spranz construimos un portal de proveedores en el que los proveedores rellenan sus datos ellos mismos, entre otras cosas para la normativa de envases. Forma parte de un proyecto más amplio en ese cliente — Magic Logo, el PIM con el DAM, el entorno de consumidor y el agente — y el portal es allí precisamente la parte que trata de reunir y no de vender.

Un portal funciona además sobre el mismo catálogo del PIM y el mismo flujo de pedidos que el módulo ERP. No es un detalle técnico: significa que los datos de envase que rellena su proveedor pasan a estar junto al mismo artículo que los datos de impresión, los precios y las fotos. Una fuente, y por tanto un único lugar donde se comete un error y un único lugar donde se resuelve.

CÓMO EMPEZAR

Empiece por lo que hoy reúne por correo

El primer paso no es software sino una lista. Qué datos pide hoy por correo, a cuántas partes, con qué frecuencia, y quién lleva la situación. Esas cuatro respuestas dicen exactamente si un portal le aporta algo. Si reúne dos campos en tres proveedores, un correo está perfecto. Si reúne diez campos más documentos en treinta partes, y eso tiene que repetirse cada año, entonces un portal gana ya en la primera ronda.

Si nos envía esa lista, le dejamos un portal en pie y ve lo que ve quien rellena. Lo que no hacemos es prometer que con eso cumple una obligación — eso es una pregunta para su abogado. Lo que sí hacemos es procurar que los datos estén completos, al día y encontrables en el momento en que alguien los pida.

¿Qué reúne hoy por correo?

Envíenos la lista de datos que hoy pide a sus proveedores, y a cuántas partes. Le dejamos un portal en pie y ve lo que ve quien rellena.

¿Prefiere ver primero el conjunto? Solicite una demo en su propia identidad visual.