Ir para o conteúdo
BASE DE CONHECIMENTO · DADOS DE PRODUTO

O que o PPWR lhe exige

Reunir dados de embalagem é uma questão de dados antes de ser uma questão jurídica. Este texto é sobre o reunir.

O QUE AQUI FAZEMOS E NÃO FAZEMOS

Primeiro o limite deste texto

O PPWR é o regulamento europeu das embalagens. Exige das empresas que consigam mostrar dados sobre as suas embalagens. O que podemos dizer desse regulamento acaba aí: não somos consultores jurídicos e não vamos por isso explicar aqui que obrigação vale a que data para que tipo de empresa. Quem precisa de certeza sobre isso vai buscá-la a quem responde por ela.

Onde temos, sim, algo a dizer é na parte prática: o reunir. Porque antes de uma obrigação se tornar uma questão jurídica, é uma questão de dados. Tem de obter dados sobre embalagens junto dos seus fornecedores, torná-los completos, mantê-los atuais e conseguir reencontrá-los. É exatamente o mesmo problema que reunir dados de produto, e corre mal exatamente da mesma maneira.

O NÚCLEO

Uma questão de dados antes de ser uma questão jurídica

Na prática, um percurso desses tem o mesmo aspeto em quase todos. Sai um e-mail para os fornecedores com o pedido de dados de embalagem, certificados e especificações. Uma parte responde, uma parte não, uma parte responde com um ficheiro que não é o que pediu. Alguém mantém a situação numa folha de cálculo. Dois meses depois ninguém sabe já que versão é a última.

O erro não está nessas pessoas. O erro está em que os dados são do outro, enquanto o preenchimento cabe a você. Cada vez que preenche algo que outra pessoa sabe, constrói uma cópia que envelhece. A solução não é, portanto, insistir melhor mas inverter o sentido: a parte que sabe preenche-o ela mesma, num único lugar, onde você o pode ver.

ONDE O E-MAIL FALHA

Três coisas que uma caixa de correio não consegue fazer

Uma troca de e-mails é uma maneira excelente de pedir algo e uma má maneira de reunir algo. Essa diferença só se nota à terceira volta. Abaixo os três pontos em que na prática corre mal, e porque nenhum acordo sobre «por favor em anexo neste formato» os resolve.

Uma caixa de correio não conhece versões

Dois anexos com o mesmo nome, com duas semanas de intervalo. Qual é o último? E mais importante: qual usou a sua colega quando fez o resumo? Enquanto o ficheiro circula em vez de estar num único lugar, essa pergunta não se consegue responder sem telefonar a alguém.

Uma caixa de correio não conhece campos vazios

Um formulário sabe o que lhe falta; um e-mail não. Se um fornecedor entrega quatro dos seis dados, você só o vê quando os passa a limpo. Num portal, quem preenche vê-o logo, e isso poupa-lhe a volta em que ainda lhe tem de pedir os dois últimos.

Uma caixa de correio não tem contador

A pergunta em percursos deste género nunca é «é possível» mas «onde estamos». Quantas partes acabaram, quantas começaram, quantas não fizeram ainda nada? Sem esse contador é impossível planear, e com esse contador é uma reserva de trabalho como qualquer outra.

O SENTIDO INVERSO

Deixe o outro preencher ele mesmo

Um portal é um ambiente isolado para uma só parte. Do lado da venda já conhece isso: um cliente ou um revendedor entra e vê os seus próprios preços, o seu próprio sortido, as suas próprias encomendas e os seus próprios documentos, e mais nada. Do lado da compra o mesmo mecanismo funciona exatamente ao contrário: aí o seu fornecedor preenche ele mesmo os seus dados — dados de embalagem, certificados e especificações — em vez de a sua equipa os juntar por e-mail.

O que isso rende é menos espetacular do que soa e é justamente por isso utilizável. Recebe um conjunto completo em vez de uma caixa de correio cheia de anexos. Já não há discussão sobre quem tinha que versão, porque há uma. Os direitos estão fixados por utilizador: quem pode preencher, quem pode só ver, quem pode aprovar. E o portal está num endereço próprio, na identidade visual da parte que o usa, para que não pareça um anexo a um sistema seu mas um lugar onde esses dados devem estar.

O QUE CONSTRUÍMOS HOJE

Um portal de fornecedores na prática

Para a Spranz construímos um portal de fornecedores em que os fornecedores preenchem eles mesmos os seus dados, entre outras coisas para a regulamentação das embalagens. Faz parte de um percurso mais amplo nesse cliente — Magic Logo, o PIM com o DAM, o ambiente de consumidor e o agente — e o portal é aí precisamente a parte que trata de reunir e não de vender.

Um portal corre, além disso, sobre o mesmo catálogo do PIM e o mesmo fluxo de encomendas que o módulo ERP. Não é um detalhe técnico: significa que os dados de embalagem que o seu fornecedor preenche vão ficar junto do mesmo artigo que os dados de impressão, os preços e as fotografias. Uma fonte, e por isso um único lugar onde um erro é cometido e um único lugar onde é resolvido.

COMO COMEÇAR

Comece por aquilo que hoje reúne por e-mail

O primeiro passo não é software mas uma lista. Que dados pede hoje por e-mail, a quantas partes, com que frequência, e quem mantém a situação? Essas quatro respostas dizem exatamente se um portal lhe rende algo. Se reúne dois campos junto de três fornecedores, um e-mail serve muito bem. Se reúne dez campos mais documentos junto de trinta partes, e isso tem de se repetir todos os anos, um portal ganha já à primeira volta.

Se nos enviar essa lista, colocamos de pé um portal para isso e vê o que vê quem preenche. O que não fazemos é prometer que com isso cumpre uma obrigação — essa é uma pergunta para o seu jurista. O que fazemos é assegurar que os dados estejam completos, atuais e reencontráveis no momento em que alguém os pedir.

O que reúne hoje por e-mail?

Envie-nos a lista de dados que hoje pede aos seus fornecedores, e a quantas partes. Colocamos de pé um portal para isso e vê o que vê quem preenche.

Prefere ver primeiro o conjunto? Marque uma demo na sua própria identidade visual.