KNOWLEDGE BASE · PRODUCT DATA

What PPWR asks of you

Collecting packaging data is a data question before it is a legal one. This piece is about the collecting.

WHAT WE DO AND DO NOT DO HERE

First the limits of this piece

PPWR is the European packaging regulation. It asks companies to be able to show data about their packaging. What we can say about that regulation stops there: we are not legal advisers, so we are not going to explain here which obligation applies to which kind of company from which date. Anyone who needs certainty on that gets it from somebody who signs for it.

What we do have something to say about is the practical part: the collecting. Because before an obligation becomes a legal question, it is a data question. You have to get packaging data out of your suppliers, make it complete, keep it current and be able to find it again. That is precisely the same problem as collecting product data, and it goes wrong in precisely the same way.

THE CORE

A data question before it is a legal question

In practice such a project looks the same almost everywhere. An email goes out to the suppliers asking for packaging data, certificates and specifications. Some reply, some do not, some reply with a file that is not what you asked for. Somebody keeps the state of play in a spreadsheet. Two months later nobody knows which version is the latest.

The fault is not with those people. The fault is that the data belongs to the other party while the filling in sits with you. Every time you enter something somebody else knows, you build a copy that ages. So the solution is not to chase harder but to reverse the direction: the party who knows fills it in, in one place, where you can see it.

WHERE EMAIL BREAKS DOWN

Three things a mailbox cannot do

An exchange of emails is an excellent way to ask for something and a poor way to collect something. You notice that difference around the third round. Below are the three points where it goes wrong in practice, and why no agreement about “please attach it in this format” solves them.

A mailbox has no versions

Two attachments with the same name, two weeks apart. Which is the latest? And more importantly: which one did your colleague use when he built the overview? As long as the file goes round instead of sitting in one place, that question cannot be answered without phoning somebody.

A mailbox has no empty fields

A form knows what it is missing; an email does not. If a supplier delivers four out of six pieces of data, you only see that when you transfer it yourself. In a portal the person filling it in sees it straight away, and that saves you the round where you have to ask for the last two.

A mailbox has no counter

In projects like this the question is never “can it be done” but “where are we”. How many parties are finished, how many have started, how many have done nothing? Without that counter it is impossible to plan, and with it the job is a workload like any other.

THE OTHER DIRECTION

Let the other party fill it in

A portal is a closed environment for one party. On the sales side you know it already: a customer or a dealer logs in and sees their own prices, their own range, their own orders and their own documents, and nothing else. On the purchasing side the same mechanism works the other way round: there your supplier fills in their own data — packaging data, certificates and specifications — instead of your team gathering it by email.

What that gives you is less spectacular than it sounds, and usable for exactly that reason. You get a complete set instead of a mailbox full of attachments. There is no more discussion about who had which version, because there is only one. Rights are fixed per user: who may fill in, who may only look, who may approve. And the portal sits at its own address in the branding of the party using it, so it does not feel like an appendix to a system of yours but like a place where they belong.

WHAT WE ARE BUILDING TODAY

A supplier portal in practice

For Spranz we are building a supplier portal in which their suppliers fill in their own data, among other things for the packaging regulation. That is part of a wider project at that customer — Magic Logo, the PIM with the DAM, the consumer environment and the agent — and the portal is precisely the part that is about collecting rather than selling.

A portal runs on the same catalogue from the PIM and the same order flow as the ERP module. That is not a technical detail: it means the packaging data your supplier enters ends up on the same item as the print data, the prices and the photos. One source, and therefore one place where a mistake is made and one place where it is fixed.

HOW TO START

Start with what you now collect by email

The first step is not software but a list. Which data do you request by email today, from how many parties, how often, and who keeps the state of play? Those four answers say exactly whether a portal is worth it for you. Collecting two fields from three suppliers? An email is fine. Collecting ten fields plus documents from thirty parties, yearly? A portal wins in the first round.

Send us that list and we will put up a portal for it, so you see what the person filling it in sees. What we will not do is promise that this makes you compliant — that is a question for your lawyer. What we will do is make sure the data is complete, current and findable at the moment somebody asks for it.

READ ON

What this is about

The portal in this piece is the product Portals; if you want to offer the same mechanism under your customer's brand, that is Brand Sites. The industry page for manufacturers and importers describes where this fits in the chain.

What are you collecting by email today?

Send us the list of data you currently request from your suppliers, and from how many parties. We will put up a portal for it and you see what the person filling it in sees.

Rather see the whole picture first? Book a demo in your own branding.

Ask your question Book a demo