Cada projeto começa com uma dor operacional concreta e termina com números que o gestor consegue verificar na própria rotina. Sem case genérico, sem métrica inflada.
O almoxarifado de manutenção de uma indústria operava com dois ERPs que não se comunicavam: um para manutenção (gestão de ativos, ordens de serviço, peças) e outro para compras (requisições, cotações, aprovações). Cada pedido de compra exigia digitação manual entre os dois sistemas — um trabalho repetitivo, lento e propenso a erros de padronização.
O time de manutenção identificava a necessidade de uma peça no ERP de gestão de ativos. Para solicitar a compra, era necessário abrir o ERP de procurement, localizar o item equivalente (muitas vezes com código diferente), preencher manualmente a requisição e garantir que as especificações estivessem alinhadas entre os dois sistemas.
Na prática, cada pedido consumia um tempo desproporcional para o que deveria ser um fluxo padrão. Erros de digitação geravam retrabalho, e a falta de padronização entre cadastros criava inconsistências que só apareciam no recebimento — quando já era tarde.
Desenvolvemos uma automação em Python que conecta os dois ERPs via API. O fluxo captura a demanda de compra direto do sistema de manutenção, faz o de-para dos códigos e especificações para o sistema de procurement, gera a requisição padronizada e envia para o fluxo de aprovação — tudo sem intervenção manual.
O mapeamento entre cadastros foi construído em conjunto com o time de manutenção para cobrir exceções e variações de nomenclatura. A automação também valida dados antes do envio, eliminando a principal fonte de erros.
Redução de mais de 60% no tempo necessário para realizar pedidos de compra do almoxarifado de manutenção. Além do ganho de tempo, a padronização eliminou os erros de cadastro cruzado e deu ao time de planejamento uma base de dados confiável para análise de consumo e reposição.
O almoxarifado de manutenção de uma indústria funcionava como um supermercado interno de peças e spare parts. Mas o registro de entradas e saídas era feito em papel, depois digitado manualmente no ERP — um por um. O resultado era um atraso sistêmico entre o que acontecia no físico e o que o sistema refletia, com margem de erro em cada etapa.
O fluxo era simples no conceito, mas caótico na execução: um técnico retirava uma peça, anotava em papel, e no final do dia (ou da semana) alguém digitava tudo no ERP. A cada etapa, informação se perdia: código errado, quantidade trocada, item sem registro. O estoque no sistema nunca batia com a realidade.
Além da imprecisão, o tempo gasto na digitação manual era significativo. E quando havia divergência, a investigação consumia ainda mais horas — sem garantia de encontrar a causa.
Desenvolvemos um aplicativo em Flutter para tablets Android, instalado diretamente no almoxarifado. O fluxo é direto: o técnico escaneia o QR Code da peça, confirma a quantidade e o sistema lança automaticamente no ERP de manutenção via API — em tempo real, 100% padronizado.
A interface foi desenhada para o contexto de campo: botões grandes, fluxo de no máximo 3 toques, feedback visual claro. O app funciona como um ponto de venda otimizado para a realidade de um almoxarifado industrial — sem treinamento longo, sem etapas desnecessárias.
Redução de 80% no tempo necessário para lançamento de spare parts e itens de manutenção. Aumento de 20% na confiança dos dados do sistema (antes comprometida pela cadeia papel → digitação manual → correções retroativas). O time de planejamento de manutenção passou a trabalhar com dados que refletem a realidade, não uma aproximação dela.
Uma máquina de mistura industrial operava com dezenas de receitas de preparo, cada uma com múltiplos parâmetros de controle. O gerenciamento era feito pela aplicação nativa da IHM: funcional, mas com uma UX confusa, sem validação de regras e sem padronização. O resultado era um cenário onde erros de configuração passavam despercebidos — e geravam perdas significativas no processo.
A aplicação nativa da IHM permitia criar e editar receitas, mas sem nenhuma camada de validação. Cada receita tinha dezenas de valores padrão que deveriam seguir regras específicas — faixas de temperatura, tempos de mistura, proporções de componentes. Só que a interface não alertava quando um valor estava fora do padrão. O operador precisava saber as regras de cabeça — ou consultar documentos que nem sempre estavam atualizados.
A UX da aplicação original era confusa: muitos campos por tela, navegação pouco intuitiva, sem hierarquia visual. Isso aumentava a chance de erro e tornava o processo de criação de novas receitas desnecessariamente lento. Era um gargalo que ninguém classificava como tal — até olhar para as perdas acumuladas.
Desenvolvemos uma aplicação Python que se conecta diretamente ao SQL Server da máquina e substitui a interface de gerenciamento de receitas. A aplicação foi buildada como executável e instalada na própria IHM — sem dependência de rede externa, sem servidor adicional.
As regras de cada receita foram mapeadas e codificadas: limites de parâmetros, interdependências entre campos, valores padrão por tipo de mistura. A interface valida em tempo real — se um valor foge da faixa, o operador vê imediatamente, antes de salvar. A UX foi redesenhada para o contexto de chão de fábrica: campos agrupados por etapa, fluxo linear, feedback visual claro.
Redução de aproximadamente 80% no tempo de edição e criação de receitas. Correção de mais de 20% das receitas em produção que continham erros ocultos. O impacto financeiro da redução de perdas de processo está sendo calculado, mas a eliminação das receitas incorretas por si só representa um ganho operacional relevante — receitas que geravam retrabalho, desperdício de material e paradas não planejadas.