Máquina parada: replanear a produção com dados do ERP
«A máquina está parada. Para onde passam as ordens de hoje?»
Precisas de uma resposta que permita trabalhar: quais as operações afetadas, que centro as pode receber e o que acontece aos prazos. Uma mensagem a dizer «indisponibilidade registada» não resolve nenhuma dessas perguntas. Pode estar correta e, mesmo assim, deixar o plano de produção exatamente como estava.
É aqui que se distingue um assistente que explica procedimentos de uma integração que consulta o teu ERP, prepara uma alteração concreta e permite verificar o resultado. Não pela simpatia da resposta. Pelo estado das ordens depois da intervenção.
Registar a paragem não é mudar o planeamento
Um centro de trabalho é o recurso onde uma operação é executada: uma linha de montagem, uma máquina ou um posto com determinada capacidade. Quando fica indisponível, há pelo menos três questões diferentes: o intervalo da paragem, a existência de uma alternativa adequada e a atribuição das operações a essa alternativa.
A documentação do Odoo 19 torna a diferença visível. No procedimento descrito, configuras um centro alternativo e registas a indisponibilidade do centro principal. Depois crias e confirmas uma nova ordem de fabrico cuja operação usa o centro indisponível. Nesse momento, a coluna do centro de trabalho ainda apresenta o centro original. A mudança para o alternativo acontece após a ação Plan, ou planear.
Portanto, a existência de uma paragem registada não prova que a produção já tenha sido desviada. Falta uma ação de planeamento e falta observar o resultado.
Há outro limite importante: esse exemplo documenta uma nova ordem de fabrico. Não demonstra que todas as ordens anteriormente planeadas sejam redistribuídas, nem fornece nesse procedimento uma sequência para as replanear. Se tens trabalho já agendado, essa situação tem de ser testada na tua versão e configuração. Um assistente não deve transformar um exemplo da documentação numa garantia sobre toda a fábrica.
O centro alternativo tem de existir antes da promessa
O procedimento do Odoo pressupõe pelo menos dois centros e a configuração do substituto no campo de centros alternativos do principal. Sem essa alternativa, a documentação avisa que as ordens não podem ser redirecionadas e se acumulam no centro indisponível.
Mas um nome num campo não chega para demonstrar viabilidade operacional. Antes de propor uma mudança, a integração deve consultar o que estiver efetivamente registado: operações previstas, calendários, carga atribuída e parâmetros relevantes de capacidade e duração. Onde os dados não chegam, a resposta deve dizer o que falta validar.
Num posto de montagem, a alternativa pode exigir uma preparação diferente. Num laboratório de calibração, uma bancada livre pode não ter o equipamento necessário para aquele trabalho. Não se deve tratar «está livre» como sinónimo de «pode executar». Estes são requisitos de validação do projeto, não uma promessa de que o ERP deteta sozinho todas as incompatibilidades físicas.
A distinção interessa também ao armazém: mudar uma operação pode deslocar a disponibilidade do produto acabado. Sem consultar o plano resultante, não há fundamento para assegurar à expedição que o prazo se mantém.
Um exemplo: há alternativa, mas não cabe tudo
Considera este cenário ilustrativo, com valores escolhidos para explicar a decisão. Não é um caso de cliente nem um resultado medido.
O centro A fica indisponível das 08h00 às 12h00. O centro B está configurado como alternativa, mas só tem uma janela livre das 10h00 às 12h00. Estão por planear duas novas ordens: a OF-204 precisa de 90 minutos e a OF-205 de 60. Para este exemplo, assumes ainda 30 minutos de preparação no centro B, feitos uma única vez antes das duas operações, e execução sequencial.
A conta é simples: 90 + 60 + 30 = 180 minutos de trabalho para 120 minutos livres. Falta uma hora de capacidade nessa janela. Ter uma alternativa configurada não elimina essa diferença.
Uma proposta possível, sujeita às regras reais do planeador, seria preparar o posto das 10h00 às 10h30 e executar a OF-204 até às 12h00. A OF-205 teria de esperar por outra janela. Se a prioridade comercial for diferente, a decisão também pode mudar. O assistente deve apresentar esse compromisso, não escondê-lo numa resposta como «produção reorganizada».
Existe ainda uma OF-203 já planeada no centro A antes da paragem. Essa ordem fica identificada para análise separada: o procedimento documental referido acima não basta para garantir a sua reatribuição.
Uma resposta útil seria: «O centro B é a alternativa configurada. Nesta hipótese, a OF-204 cabe até às 12h00; a OF-205 precisa de outra janela. A OF-203 já estava planeada e exige validação do procedimento de replaneamento. Ainda não alterei ordens.»
Isto já permite decidir. Não é uma confirmação de execução.
Consulta read-only; escrita só num circuito separado
O acesso conversacional ao ERP pode começar por ser apenas de leitura, ou read-only. Nesse modo, o assistente consulta a indisponibilidade, identifica a alternativa e reúne as ordens relevantes. Pode preparar uma proposta, mas não tem permissão para mudar o plano.
A pergunta em linguagem natural — no WhatsApp ou numa consola — serve para pedir a análise. Não substitui a identidade do utilizador, os seus acessos nem as regras de planeamento. A consulta deve usar operações autorizadas e devolver a origem dos dados: que ordens foram lidas, de que empresa e em que momento.
Se o projeto incluir execução, a escrita pertence a outro circuito, com permissões próprias e aprovação explícita. A proposta tem de identificar as ordens e operações abrangidas, o centro de origem, o destino, as alterações previstas e as incertezas. «Passa tudo para B» é demasiado vago: tudo o que estava planeado, tudo o que está por começar ou apenas as novas ordens do turno?
A aprovação deve ter um âmbito concreto. Antes de executar, o sistema volta a consultar o estado relevante. Se entretanto alguém ocupou o centro B ou iniciou uma operação, a proposta pode ter deixado de ser válida. Nesse caso, precisa de revisão; a aprovação antiga não deve justificar uma alteração diferente.
O mecanismo técnico para desencadear o planeamento também tem de ser validado na instalação. A documentação da interface do Odoo demonstra uma ação funcional. Não prova que exista, em qualquer versão ou personalização, um conector pronto com o comportamento de que precisas.
Esta é uma arquitetura proposta para uma integração, não a descrição de um agente já instalado pela Leiritech neste cenário.
A confirmação vem das ordens, não da conversa
Depois da ação autorizada, a integração deve voltar a ler os registos. É essa leitura que permite confirmar o centro atribuído, as datas planeadas e os estados das operações. Uma chamada técnica sem erro não chega para afirmar que o resultado operacional pretendido ficou registado.
O histórico auditável deve ligar o pedido à consulta, à proposta, à aprovação, à execução e ao resultado observado. Se apenas parte do pedido foi concluída, a resposta precisa de separar o que mudou do que ficou pendente. Se não for possível confirmar o estado final, o sistema deve declarar essa falta de confirmação, em vez de repetir a ação sem verificar o que aconteceu.
Mesmo uma atribuição corretamente registada não prova que o trabalho físico começou. No exemplo, verificar a OF-204 no centro B confirma o planeamento no ERP. O início efetivo depende do registo operacional correspondente e do que está a acontecer no posto.
«Mas o Odoo já faz isso. Para quê a IA?»
Para escolher um centro alternativo, podes não precisar de IA. Se o planeador resolve o problema com os ecrãs existentes, essa pode ser a solução certa.
A camada conversacional justifica-se quando reduz o trabalho de reunir contexto: encontrar as ordens afetadas, distinguir as novas das já planeadas, consultar a alternativa e explicar o impacto de uma proposta. O cálculo e as regras devem continuar nos mecanismos adequados do ERP. O modelo de linguagem não deve inventar capacidade nem substituir o planeador por uma estimativa plausível.
É isto que significa uma resposta fundamentada nos teus dados: não apenas conhecer o manual, mas consultar o estado autorizado da tua instalação e distinguir factos de hipóteses. «O manual permite um centro alternativo» e «esta operação ficou atribuída ao centro B» são afirmações diferentes e exigem provas diferentes.
O preço do bot não demonstra integração
Na oferta da 3HASH consultada em outubro de 2026, o site era anunciado por 15 €/mês e o WhatsApp por mais 10 €/mês, com IVA incluído e 100 € de configuração. Essa descrição não documentava um conector ERP incluído nos 25 €. Isso delimita a oferta consultada; não demonstra incapacidade do fornecedor para desenvolver integrações.
Também não seria rigoroso dizer que todos os agentes de atendimento apenas respondem a perguntas frequentes. A Meta já apresenta conectores e ações. A pergunta de compra tem de ser mais exigente: consegue executar este procedimento na tua instalação, com este âmbito e esta prova de resultado?
Para atendimento informativo, uma solução económica pode chegar. Para gerir a consequência de uma paragem na produção, estás a avaliar outro trabalho: acesso ao ERP, interpretação dos estados, regras de aprovação, execução controlada e verificação. Uma mensalidade maior, por si só, também não garante nada disso.
Começa por uma paragem, não por uma promessa de autonomia
O primeiro teste deve caber num ambiente de ensaio: um centro indisponível, uma alternativa válida, uma nova ordem e outra já planeada. Inclui uma situação em que a capacidade alternativa não chega. A demonstração tem de mostrar a consulta inicial, o que exige aprovação e os registos depois da ação.
Envia à Leiritech, para hello@leiritech.com, um exemplo anonimizado de uma paragem, indicando a versão do ERP, o centro alternativo e as ordens afetadas. O próximo passo é delimitar o que se consegue consultar e testar no teu sistema — antes de alguém escrever «produção replaneada» numa conversa.
