O peso de um produto encontra-se na gestão de materiais. A percentagem de material reciclado encontra-se no sistema de fórmulas. O certificado do fornecedor está disponível em formato PDF numa unidade de rede. A ficha técnica do produto necessita destas três informações num único registo de dados, e é precisamente aí que reside o projeto de integração, e não na ligação entre dois sistemas.
A «integração perfeita do ERP» é uma promessa padrão que, na prática, dá lugar a um projeto de três meses. Publicamos o nosso guia para que o seu departamento de TI possa verificar, antes da assinatura do contrato, quais são, de facto, os dados solicitados. Este artigo mostra quais os dados que o Passaporte necessita dos seus sistemas, as três formas através das quais nos são transmitidos e por que razão isso pode ser feito em duas semanas.
O que o seu ERP tem, na verdade, de fornecer
Para que um DPP seja criado, necessitamos, por produto:
- Dados de base - número de artigo, designação, variantes, pesos, dimensões, imagens
- Dados da lista de peças - componentes com quantidades e percentagens de material reciclado
- Dados de origem - local de produção, número de lote, data de produção
- Dados ambientais - CO₂eq por unidade, consumo de água, consumo de energia
- Dados de fornecedores - quem fornece cada componente (para o cumprimento das obrigações de diligência)
No seu ERP, estes dados estão, teoricamente, todos disponíveis. Na prática, encontram-se distribuídos por 4 a 7 módulos: gestão de materiais, produção, qualidade, base de dados de fornecedores, por vezes um módulo separado para dados ambientais, por vezes um sistema próprio para fórmulas e listas de peças.
A questão da integração não é: «O seu ERP fornece dados a um DPP?» É sim: «Como é que reúne os dados de 5 subsistemas num conjunto de dados coerente?»
Três formas comprovadas
Forma 1: Obter os dados do ERP
Funciona bem com ERPs modernos (SAP S/4HANA Cloud, Dynamics 365, Odoo). O fornecedor do DPP obtém os dados através da interface do ERP (tecnicamente, OData ou REST). Apenas as alterações, de acordo com um calendário ou desencadeadas por um evento.
Vantagens: pouco trabalho de desenvolvimento da sua parte; concede um acesso de leitura e o fornecedor desenvolve a conversão.
Desvantagens: não funciona com instalações mais antigas do SAP ECC sem uma camada de interface adicional. São necessárias regras claras sobre quem pode aceder a quais dados.
Método 2: Encaminhar alterações
O seu ERP comunica cada alteração como um evento (através do SAP Event Mesh, Apache Kafka ou RabbitMQ), e o fornecedor de DPP recebe-as.
Vantagens: quase em tempo real, adapta-se à evolução, os sistemas não dependem uns dos outros.
Desvantagens: a configuração é complexa e requer infraestrutura que nem todos os departamentos de TI possuem. Para empresas de menor dimensão, é geralmente excessivo.
Opção 3: Utilizar a camada de integração existente
Já dispõe de uma ### camada de integração(Mulesoft, Boomi, Informatica, Azure Data Factory) entre o ERP e os sistemas externos. Esta camada funciona como um intermediário: o fornecedor de DPP comunica com ela, nunca diretamente com o ERP.
Vantagens: os investimentos existentes podem ser aproveitados, as regras permanecem estáveis, não há acesso direto ao ERP por parte de terceiros.
Desvantagens: os seus custos com a camada de integração aumentam em conformidade.
O que fazemos de forma diferente em projetos concretos
Muitos fornecedores pretendem ligar-se diretamente ao seu ERP. Nós incorporamos, por princípio, um passo intermédio: a nossa interface aceita um formato de dados neutro (um esquema JSON), que pode preencher com uma ferramenta à sua escolha. Isto significa que:
- Pode tratar do processamento dos dados por conta própria, com as ferramentas que a sua equipa conhece
- Podem substituir-nos - o formato neutro é portátil
- Podem recuperar todo o seu inventário a qualquer momento - em CSV, XLSX, JSON-LD e SQL, bem como através da API REST
- Fornecemos um validador de importação que verifica os vossos dados antes do upload
O formato completo e todas as consultas estão descritos publicamente na Documentação da API, como uma descrição da interface de acordo com a OpenAPI. O seu departamento de TI pode verificar a interface antes da assinatura de um contrato - incluindo exemplos de consultas, respostas de erro e detalhes de autenticação.
Prazo de execução desta abordagem na prática:
- Dia 1 a 2: Workshop de mapeamento. Qual campo do ERP corresponde a qual campo do DPP?
- Dia 3 a 5: Primeiras exportações em JSON a partir do ERP, através do nosso validador.
- Dia 6 a 8: Resolução de erros (campos em falta, codificações inconsistentes).
- Dia 9 a 10: Os primeiros DPPs estão ativos.
Duas semanas, e não três meses. O ponto crucial é o workshop de mapeamento - é aí que se decide a qualidade dos dados.
O que pode correr mal: as armadilhas mais frequentes
Dados de base de produtos em vários sistemas: o SAP tem o número de artigo, o PIM tem as imagens e os textos de marketing, o PLM tem a lista de peças. Ninguém tem uma visão coerente. Solução: defina, antes do projeto, qual o sistema que é de referência para cada campo.
Certificados em PDF: os fornecedores enviam certificados GOTS, OEKO-TEX ou REACH como digitalizações em PDF. Esta não é uma fonte de dados estruturada. Solução: as entidades certificadoras oferecem, cada vez mais, a possibilidade de consulta através de uma interface (a OEKO-TEX está na vanguarda, a GOTS fica para trás). Ou então: registe manualmente, mas com a data de validade, para que não surjam certificados caducados no DPP.
Confidencialidade da fórmula: especialmente nos setores da cosmética, alimentar e farmacêutico: a fórmula completa constitui um segredo comercial. O DPP deve torná-la pública? Solução: o modelo de três níveis da ESPR. A categoria do produto é pública; as autoridades têm acesso à fórmula completa. Quase nunca constitui um obstáculo, mas deve ser esclarecido numa fase inicial.
Dados de CO₂ com base nos fornecedores: o seu fornecedor fornece um valor médio para todo o seu portfólio, e não por lote. Solução: aceitar temporariamente e, a longo prazo, ajustar os contratos com os fornecedores. O ESPR exige valores específicos por produto a partir de uma data de referência, mas a prática atual constitui um compromisso.
Versões linguísticas locais: o seu ERP contém apenas a designação do produto em alemão e inglês. Para os 27 países da UE, necessita de mais. Solução: tradução automática com base de dados terminológica; dispomos de um artigo específico sobre este tema.
As questões que deve colocar antes do projeto
Antes de enviar um pedido de proposta (RFP) a três fornecedores, responda internamente às seguintes questões:
- Quantos produtos/códigos de artigo devem ter DPPs? (10, 10 000, 1 milhão?)
- Que sistemas contêm atualmente dados relevantes para os DPPs?
- Que departamento gere cada um dos sistemas?
- Dispõe de uma camada de integração que deva ser utilizada?
- Existe já uma interface em funcionamento através do seu ERP?
As respostas determinam qual das três vias é a mais adequada para si.
As respostas determinam se um projeto demora duas semanas ou seis meses.
Perguntas sobre este artigo
A interface REST é suficiente, ou precisamos de um middleware?
A interface é suficiente. Os três modelos diferem na localização onde a transformação ocorre, e não no que recebemos - a nossa interface aceita um esquema JSON neutro, independentemente da forma como o tenha gerado. Uma consulta a um ERP moderno, um fluxo de eventos e uma camada de integração existente terminam todos no mesmo ponto final. Vale a pena utilizar um middleware se já tiver um em funcionamento e se pretender que este continue a constituir o contrato perante terceiros. Se ainda não existir nenhum, não adquira nenhum para o «Product Pass».
O que é que se decide no workshop de mapeamento?
Qual campo do ERP corresponde a qual campo de referência - e qual sistema é a fonte principal, caso vários sistemas contenham o mesmo valor. O workshop decorre no 1.º e no 2.º dia e constitui o ponto crucial de todo o projeto, pois é aí que se decidem as questões relativas à qualidade dos dados e não posteriormente no código. Traga consigo as pessoas que se encarregam da manutenção dos sistemas, e não apenas os responsáveis pelo projeto - os departamentos de dados mestre, produção, qualidade e compras raramente se encontram num único departamento. Tudo o que se segue, ou seja, exportações, validação e correção de erros, é uma questão de execução prática.
Os nossos certificados só estão disponíveis em formato PDF digitalizado. O que devemos fazer com eles?
Uma digitalização não constitui uma fonte de dados estruturada e, como tal, é inutilizável para o passaporte. Existem duas formas de proceder: os operadores de certificação oferecem, cada vez mais, consultas via API e, nos casos em que estas não estão disponíveis, deve introduzir os valores manualmente, mas sempre com a data de validade, para que nenhum certificado caducado permaneça num passaporte publicado. Planeie o método manual como uma tarefa recorrente, e não como uma tarefa pontual.
O nosso departamento de TI pode verificar a interface antes de assinarmos alguma coisa?
Sim. O esquema completo e todos os pontos de extremidade estão disponíveis como especificação OpenAPI em Documentação da API, com exemplos de pedidos, respostas de erro e detalhes de autenticação. Nada disto está sujeito a uma negociação comercial, pelo que a sua equipa de integração pode avaliar o esforço necessário antes mesmo de existir um contrato. Se um fornecedor não revelar a sua interface nesta fase, isso também constitui uma resposta.
O que acontece aos nossos dados quando mudamos de prestador de serviços?
Eles acompanham-no. A interface aceita um esquema JSON neutro em vez de um formato proprietário, e todo o seu inventário é exportado nos formatos CSV, XLSX, JSON-LD e SQL ou através da API REST. Isto é intencional - o formato que preenche é portátil, pelo que uma mudança implica apenas uma exportação e não a criação de um novo modelo. Faça a mesma pergunta a cada fornecedor antes do workshop de mapeamento, pois, a seguir, os nomes dos seus campos passarão a constar no modelo desse fornecedor.
Quanto tempo demora realmente uma ligação?
Nos projetos que acompanhamos, duas semanas - dois dias de mapeamento, três dias até às primeiras exportações através do nosso validador, três dias de correção de erros, dois dias até à publicação dos primeiros passaportes. O processo mais demorado nunca é o código, mas sim o que o validador deteta - campos em falta, codificações inconsistentes, valores pelos quais ninguém se sente responsável. Planeie estes dias, em vez de os reduzir. Um projeto que os ignore acaba por publicar as lacunas juntamente com o conteúdo.
Temos de integrar todos os produtos de uma só vez?
Não. Comece pelos produtos que necessitam de um passe em primeiro lugar e por um sistema de origem - o esquema neutro aceita tanto um catálogo parcial como um catálogo completo, e as importações são repetíveis, pelo que as execuções posteriores atualizam o inventário. Isto também mantém o workshop de mapeamento suficientemente curto para ser concluído em dois dias. A expansão posterior é uma tarefa de mapeamento, não um novo projeto.
