«Integração ERP sem interrupções» é uma promessa padrão que, na prática, dá lugar a um projeto de três meses. Publicamos o nosso Manual de API para que o seu departamento de TI possa verificar, antes da assinatura do contrato, quais são, de facto, os dados solicitados. Eis o que deve saber antes de iniciar um projeto de integração.
O que o seu ERP tem, na verdade, de fornecer
Para criar um DPP, precisamos, 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 due diligence)
Teoricamente, todos estes dados estão disponíveis no seu ERP. Na prática, estão distribuídos por 4 a 7 módulos: Gestão de Materiais (MM), Produção (PP), Qualidade (QM), Fornecedores (LFA1), por vezes um módulo EHS separado para dados ambientais, por vezes um sistema PLM para fórmulas.
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 modelos de integração comprovados
Modelo 1: OData / REST-Pull
Funciona bem com ERPs modernos (SAP S/4HANA Cloud, Dynamics 365, Odoo). O fornecedor do DPP extrai os dados através de OData ou REST. De forma incremental, planeada ou acionada por eventos.
Vantagens: pouco trabalho de desenvolvimento da sua parte; fornece as credenciais de leitura e o fornecedor desenvolve a transformação.
Desvantagens: não funciona com instalações mais antigas do SAP ECC sem uma camada de API adicional. É necessária uma governança sobre os pedidos de acesso aos dados.
Modelo 2: Integração baseada em eventos
SAP Event Mesh, Apache Kafka, RabbitMQ. O seu ERP publica eventos de alteração, o fornecedor de DPP consome-os.
Vantagens: quase em tempo real, elegantemente escalável, desacoplado.
Desvantagens: a configuração é complexa e requer infraestrutura que nem todos os departamentos de TI possuem. Para empresas mais pequenas, é geralmente exagerado.
Modelo 3: Middleware / ETL
Dispõe de uma camada de integração (Mulesoft, Boomi, Informatica, Azure Data Factory) entre o ERP e os sistemas externos. O middleware é o intermediário - o fornecedor de DPP comunica com o middleware, nunca diretamente com o ERP.
Vantagens: os investimentos existentes podem ser aproveitados, a governação é estável, não há acesso direto ao ERP por parte de terceiros.
Desvantagens: os seus custos com o middleware aumentam proporcionalmente.
O que fazemos de 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 API aceita um esquema JSON neutro, que pode preencher com uma ferramenta à sua escolha. Isto significa que:
- Pode tratar da preparação dos dados por conta própria, com as ferramentas com que a sua equipa está familiarizada
- Pode substituir-nos - o formato neutro é portátil
- Pode 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 seus dados antes do upload
O esquema completo e todos os endpoints estão documentados publicamente em /apidocs como especificação OpenAPI. O seu departamento de TI pode testar a interface antes da assinatura de um contrato - incluindo pedidos de exemplo, respostas de erro e detalhes de autenticação.
Cronograma prático com esta abordagem:
- Dia 1 a 2: Workshop de mapeamento. Qual campo do ERP corresponde a qual campo do DPP?
- Dia 3 a 5: Primeiras exportações 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, 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 comuns
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 constitui a «fonte de verdade» para cada campo.
Certificados em PDF: os fornecedores entregam certificados GOTS, OEKO-TEX ou REACH como digitalizações em PDF. Isso não constitui uma fonte de dados estruturada. Solução: as entidades certificadoras oferecem cada vez mais consultas via API (a OEKO-TEX está na vanguarda, a GOTS fica para trás). Ou então: registar manualmente, mas com data de validade, para que não apareçam certificados caducados no DPP.
Confidencialidade da fórmula: especialmente nos setores da cosmética, alimentar e farmacêutico: a fórmula completa é 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 é 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, precisa de mais. Solução: tradução automática com base de dados terminológica; temos um artigo separado sobre este tema.
As perguntas que deve colocar antes do projeto
Antes de enviar um pedido de proposta (RFP) a três fornecedores, responda internamente:
- Quantos produtos/números 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 algum investimento em middleware que deva ser aproveitado?
- Existe já uma camada de API em funcionamento sobre o seu ERP?
As respostas determinam qual dos três modelos se adequa melhor à sua situação. E definem se um projeto demora duas semanas ou seis meses.