Do defeito na peça à ordem de serviço no ERP

Pense numa tarde comum numa fábrica de autopeças.

O operador da linha L2 vê uma peça defeituosa sair da prensa. No tablet da linha, abre o formulário de ocorrência e fotografa a peça com a etiqueta da ordem de fabricação. A IA lê a foto e preenche a ficha: OF 4471, linha L2, setor montagem. Ele completa por voz:

“Problema no rolamento, parece o 6204.”

O agente de IA responde no próprio tablet:

“Ocorrência registrada: OF 4471 · linha L2 · setor montagem. Sintoma: rolamento 6204. Posso abrir a OS de manutenção corretiva no ERP e acionar o Cassio, mecânico do turno?”

Operador: “Confirmado.”

“OS de manutenção corretiva nº 8839 aberta no ERP. Cassio avisado no Teams. Aviso aqui assim que ele assumir.”

Trilha · registro #45219.

Foto, relato, ordem de serviço aberta dentro do ERP que a fábrica já usa, mecânico do turno avisado — e cada passo registrado numa trilha à prova de adulteração.

Antes desse “aberta no ERP”, o que acontecia é o que ainda acontece em quase toda planta da região: o operador anotava no caderno ou mandava uma foto no grupo do celular, contava no almoço pro supervisor, e o supervisor abria a OS manualmente à tarde — quando lembrava. Entre o “vi o defeito” e o “OS aberta”, passavam horas. Às vezes a OF inteira passava antes de a OS sair.

Por que isso não é chatbot

A diferença entre o que o agente faz e o que um chatbot faz é de natureza — mas é fácil de confundir, porque a conversa parece a mesma.

Chatbot lê texto e responde texto. O ciclo termina dentro da conversa.

O agente do F7 KORE recebe o relato — formulário, foto, voz — e age dentro do ERP. Abre a OS de verdade, com número de OS verdadeiro, atribuída a mecânico verdadeiro, vinculada à OF verdadeira. O ciclo termina dentro da operação real, não dentro de uma janela de conversa.

Três coisas precisam acontecer pra isso funcionar:

• Registrar o fato na fonte, do jeito que ele acontece. Foto da peça lida pela IA para preencher os campos da ficha, relato por voz em português coloquial, número da OF tirado da etiqueta em vez de digitado de memória. O dado entra uma vez, por quem está com a peça na mão.
• Conhecer a empresa. “A OF 4471 está rodando na L2” não é dado que um chatbot tem — é dado que mora no ERP, na fila de produção do turno, no histórico do equipamento. O F7 KORE está integrado a esses sistemas e enxerga esse contexto.
• Agir com permissão. O operador da L2 pode abrir OS de manutenção corretiva sem aprovação? Depende das regras de acesso da empresa. O agente executa com a permissão de quem confirmou — e não vai além dela.

Essa é a diferença entre uma IA que conversa e execução operacional auditável: a ação acontece no sistema de registro, e fica provado quem a autorizou.

O canal é onde a pessoa já está

Na linha, o operador usa o tablet da bancada, porque o chão de fábrica nem sempre libera celular pessoal. O supervisor está no Teams, porque a TI padronizou o Teams. O gerente de manutenção acompanha pelo e-mail ou pelo próprio F7 KORE.

Em todos esses lugares, o agente é o mesmo e a ação é a mesma. O que muda é só por onde a pessoa fala com ele.

O que importa, então, não é por onde o relato entra. É:

• O que a plataforma sabe sobre a sua operação (o dado do ERP, o cadastro de equipamentos, o histórico de ocorrências e manutenções).
• Quais regras a empresa definiu (procedimento padrão, política de aprovação, escalonamento por turno).
• Qual a integração real com o sistema onde a ação acontece — não “uma API exposta pelo ERP”, mas “OS aberta com os campos certos, no módulo certo, atribuída ao recurso certo”, com monitoramento de cada chamada.

Quando esses três estão de pé, o canal deixa de ser o problema. O ciclo de execução é o mesmo no tablet, no Teams ou no e-mail.

Permissão como desenho, não como opção

Aqui mora a diferença entre IA agindo dentro da operação e um assistente que só sugere coisas.

O agente só executa dentro das permissões do usuário que o acionou. Não herda permissão de administrador. Não tem permissão própria. Se o operador da L2 não pode abrir OS de manutenção corretiva sem aprovação do supervisor, o agente também não abre — cria o pedido de aprovação, avisa o supervisor e espera o “OK” dele chegar pelo canal dele.

E cada confirmação fica registrada — não como log de depuração, mas numa trilha à prova de adulteração, em que qualquer alteração fica detectável e que qualquer auditor verifica sem depender da F7:

• Quem registrou a ocorrência.
• O que a IA leu da foto e o que o operador corrigiu.
• Que ação foi sugerida.
• Quem confirmou, e com qual permissão.
• Que ação foi executada de fato, em qual sistema, com qual número.

Esse registro é o que separa IA aplicada à operação industrial de experimento de demonstração. Sem ele, qualquer ação automática vira passivo no primeiro dia de auditoria.

O que muda na operação

Três efeitos diretos:

• A OS sai enquanto o defeito ainda está na linha. O intervalo entre “vi o defeito” e “OS aberta” deixa de depender de alguém lembrar à tarde. Em manutenção corretiva, isso é margem direta — máquina parada custa a cada minuto.
• Coordenação informal recua. Caderno, almoço, foto perdida no grupo, “te falo depois” — todo o trânsito de informação de boca em boca vira registro com dono e com rastro.
• Operador ganha alavanca. Em vez de esperar o supervisor, ele aciona o sistema diretamente — dentro do que a permissão dele permite. Quando precisa de aprovação, o pedido chega ao supervisor com o contexto pronto: a foto, a OF, o sintoma.

E nenhum desses ganhos exige trocar o ERP — seja qual for o fornecedor. Exige só que a ação real, dentro do sistema que a fábrica já usa, possa ser disparada por um agente com contexto, regra e a permissão certa.

---

O F7 KORE é desenvolvido pela F7 KORE SOFTWARE LTDA, parceira da InterSystems — incluindo integração com ERP em casos como Degraus (aluguel de equipamentos) e Quinabra (química regulada). Detalhes do funcionamento na página de FAQ.

Se você opera indústria de médio ou grande porte, tem ERP estabelecido, e quer ver o defeito na peça virar OS aberta no seu sistema — fale com a gente.