Integração ERP & Digitalização de Processos

SAP, Dynamics, NetSuite, Odoo e muitos ERPs regionais via conectores padrão; qualquer outro via API REST ou troca de arquivos.

A camada de integração mapeia campos e lógica personalizados, porque a personalização é normal.

A MSF complementa o ERP sem o substituir. As finanças e a área comercial ficam onde estão, e a fábrica ganha uma camada de produção de nível mundial.

Do ERP para a fábrica seguem normalmente ordens de produção, dados mestre de itens, listas de materiais, roteiros e estoques. No sentido inverso, confirmações de ordem e de operação, quantidades produzidas e refugadas, consumos de material e resultados de qualidade. A discussão nunca é sobre essa lista, é sobre que sistema é dono de cada campo e o que acontece quando ambos são alterados. Defina essa propriedade campo a campo antes de alguém escrever um mapeamento, porque é uma decisão cara de reverter.

Precisa, se as confirmações tiverem de ser lançadas no ERP. Tudo o que registra um movimento de mercadoria ou fecha uma operação é uma escrita, e a sua equipe de ERP vai querer que seja feita por interfaces homologadas, como BAPIs, serviços OData ou uma tabela de staging, e não por acesso direto ao banco de dados. Uma primeira fase só de leitura é razoável: puxar as ordens, mostrá-las na fábrica e continuar a lançar à mão até os números baterem.

Semanas quando já existe um responsável identificado do lado do ERP, um ambiente de testes semelhante ao produtivo, interfaces acordadas e dados mestre em geral corretos; mais tempo quando não existem. O trabalho do conector raramente é o que atrasa; o que atrasa é esperar por janelas de alteração, por aprovações de transportes e por alguém que diga qual dos quatro códigos de item é o verdadeiro. Se hoje não conseguir dizer quem é o interlocutor do ERP, planeje em meses e não em semanas.

Com arquivos CSV ou XML colocados por agendamento em SFTP, com uma tabela de staging do lado do ERP, ou com uma view de banco de dados que o fornecedor do ERP ou a sua própria equipe de ERP cria e mantém; ler diretamente as tabelas da aplicação é normalmente recusado e pode quebrar numa atualização. O que se perde é o tempo real, e o atraso passa a ser o intervalo que agendar, tipicamente por turno ou durante a noite. O sentido inverso exige um job de importação do lado do ERP, com um responsável e uma regra para os registros que forem rejeitados.

Vão divergir, e nenhuma integração decide quem tem razão. As diferenças vêm de lançamentos feitos em momentos diferentes, de refugo registrado na fábrica mas ainda não lançado e de movimentos feitos fora dos dois sistemas. O que fica é um rastro de eventos, e uma diferença pode ser seguida até um turno e uma ordem. Sem ele, apareceria só como um valor global no inventário. Defina um responsável pela reconciliação e uma periodicidade antes da entrada em produção.

Se o ERP estiver inacessível mas o servidor local e a rede da fábrica estiverem funcionando, as ordens já liberadas continuam nos painéis e os operadores continuam confirmando. Essas confirmações ficam gravadas no banco de dados local, por isso sobrevivem a um reinício e são enviadas assim que o ERP responder. O limite prático são as ordens que nunca chegaram a ser transferidas, que não podem ser iniciadas. Pergunte se os lançamentos reenviados podem cair num período que a sua contabilidade já fechou.

Não. O modelador de fluxos de processo digitaliza formulários, aprovações e o encaminhamento do trabalho entre pessoas, por isso os processos de desvio e de alteração de engenharia em papel passam bem para lá, mas não muda a forma como o seu ERP calcula preços, planeja ou lança, e qualquer passo que tenha de atualizar um registro do ERP continua precisando de uma interface por trás. A lógica que é de fato cálculo, como as regras de custeio, pertence ao lugar onde esses dados vivem.