La concentración de flujos de envases industriales o comerciales en un grupo reducido de SCRAPs, similar a lo que sucedió con Ecoembes, podría tener consecuencias alarmantes.

Cuando fundé Container Loop, mi propósito era claro: utilizar mi experiencia de más de 30 años en el sector de los envases para mejorar el planeta, eliminando el uso de envases de un solo uso en la industria. Aunque sé que esta meta es ambiciosa o incluso imposible, como decía el anuncio de la Lotería de Navidad, no tenemos sueños baratos. Y aunque no alcance todos los objetivos, el recorrido valdrá la pena.

La idea era simple: demostrar a las empresas que es más económico utilizar un envase retornable, a 7,90 € por unidad y con 100 usos, que una caja de cartón de 0,50 € para un único uso. Aunque este cálculo sencillo debía tener en cuenta también el coste de retorno, lavado, plegado y manipulación, los números confirmaban la viabilidad del proyecto. Sin embargo, como buen empresario, reflexioné sobre los posibles riesgos que podrían entorpecer estos cálculos.

Uno de los riesgos era la pérdida de activos. Para evitarla, desarrollamos la aplicación Track Loop, que facilita el seguimiento de envases, les otorga valor al ubicarlos en un punto de la cadena y previene pérdidas significativas. Después de todo, es mucho más fácil recuperar 1,000 palets cuando están valorados en 10 € cada uno que perderlos sin siquiera saber su paradero o valor.

Cuando leí el Real Decreto 1055/2022 de envases y residuos de envases en un largo viaje de regreso en ferry desde Ibiza, me sorprendió gratamente: la normativa responsabiliza al envasador de los envases que pone en el mercado. Finalmente, el envasador no solo buscaría el envase más económico, sino que tendría que pensar en la vida útil del mismo, alineado con la visión de Container Loop.

Estamos a finales de 2024, y en enero de 2025 las empresas deberían empezar a asumir la RAP, pero hay amenazas latentes en el Real Decreto que podrían desviar este objetivo.

Siempre hemos defendido que los flujos de envases retornables deben gestionarse a través de sistemas individuales (SIRAPs), ya que es lógico que un flujo específico y no masificado sea gestionado directamente por la empresa que usa los envases o el fabricante que los produce. Delegar estos flujos en un SCRAP que desconoce el uso del envase y sus características específicas nos parece insensato.

Hace poco, en una conversación con un fabricante de IBCs que también es uno de nuestros proveedores, noté un inquietante cambio de enfoque. Planteaba gestionar los flujos de envases de sus clientes a través de un SCRAP, si este ofrecía tarifas bajas, en lugar de crear un SIRAP propio. Para mí, eso no tiene sentido. ¿Por qué un fabricante de envases delegaría en un SCRAP la gestión de sus propios productos?

La lógica de un super SCRAP parece clara: centralizar flujos, ganar poder y hacer más atractivas sus tarifas a los fabricantes. Sin embargo, esto plantea una pregunta fundamental: ¿cómo va a optimizar un tercero que no conoce el proceso de producción o el flujo del envase? Este enfoque parece descartar cualquier oportunidad de optimización real.

Imaginé un escenario distópico en el que un SCRAP todopoderoso controla los envases y se centra solo en cumplir objetivos burocráticos. En ese modelo, la prioridad ya no es la reducción de residuos o la durabilidad de los envases, sino el cumplimiento de estadísticas. Esto genera escalofríos y subraya la importancia de evitar que el poder recaiga en entidades sin una visión real de sostenibilidad. La misión de un SCRAP debería ser la de agrupar esfuerzos para optimizar la recogida separada, priorizando la reducción y reutilización por encima del reciclaje.

Desde Container Loop no decimos que los SCRAPs sean innecesarios. Son necesarios, pero deberían centrarse en gestionar flujos complejos donde la colaboración genera eficiencia. Los flujos de envases retornables, en cambio, deberían gestionarse por los propios fabricantes o usuarios de los envases, quienes pueden optimizar su ciclo de vida de manera más eficaz y sostenible.

[Este contenido procede de ContainerLoop]

8 de noviembre 2024