"Deu erro": o catálogo que explica o motivo e o que fazer

Quarta-feira, 21h30, célula de usinagem de uma fábrica de componentes. O operador terminou a troca de inserto, apontou o tempo e vai fechar a O.S. no terminal do posto. A tela mostra uma caixa vermelha: “Erro ao salvar. Tente novamente.” Ele tenta. Mesma mensagem. Tenta pela terceira vez, com uma fila de peças esperando.

Desiste. Anota no verso da folha de programação: “O.S. 4471 fechada 21h30, inserto trocado”. Segue trabalhando. A folha vai para a pasta do supervisor, que só olha na sexta.

Na quinta, a O.S. aparece como aberta para o PCM, que liga para o supervisor, que não sabe de nada. O sistema registrou o erro, mas em um log que só o T.I. acessa — e o T.I. não foi avisado. A causa era simples: o campo de tempo tinha um valor fora do formato. Ninguém disse isso ao operador.

O que isso custa de verdade

Num cenário ilustrativo: três dias de uma O.S. aberta que estava fechada. O indicador de backlog sobe sem motivo. A peça trocada não baixa do estoque no dia certo. O planejador gasta uma manhã caçando o que aconteceu. E o operador, na próxima vez que vir uma tela vermelha, nem vai tentar: vai direto para o papel.

O custo real de uma mensagem de erro sem explicação não é o erro. É a perda de confiança no sistema por parte de quem mais precisa usar. Cada “deu erro” sem resposta empurra o chão de fábrica de volta para a prancheta, e todo o esforço de digitalizar o apontamento vai embora.

Some o custo do suporte: o chamado que chega ao T.I. diz “deu erro no terminal”. Sem código, sem contexto, sem horário. O técnico precisa reproduzir, perguntar, adivinhar.

Por que acontece

A maioria dos sistemas foi projetada para funcionar, não para falhar bem. A mensagem de erro é um detalhe deixado para o fim, escrita por quem programou e não por quem vai ler. “Erro ao salvar” descreve o que aconteceu do ponto de vista do código, não do ponto de vista de quem está com a luva na mão e a fila de peças atrás.

O erro não fica registrado de um jeito que o suporte consiga usar. Ou fica em um log técnico, sem ligação com o usuário e a tela, ou não fica em lugar nenhum. E quem está no posto não tem como saber se o problema é dele, do terminal, da rede ou do sistema.

Sem explicação, o operador faz a única coisa razoável: contorna.

O que fazer a partir de segunda-feira

1. Reúna os erros mais frequentes dos últimos 30 dias. Pergunte aos operadores e ao T.I. Liste as dez mensagens que mais aparecem.
2. Para cada uma, escreva em linguagem de fábrica o motivo provável e a ação. “O tempo apontado está fora do formato. Digite horas e minutos, ex.: 01:30.”
3. Cole essa lista nos terminais, num cartão, até o sistema fazer isso sozinho. É feio, mas funciona.
4. Defina o caminho de escalada. Se a ação sugerida não resolve, para quem o operador liga, e o que ele informa.
5. Exija que todo erro tenha um código. Um chamado com “erro E-2031 às 21h30 no terminal 4” resolve em minutos; “deu erro” resolve em dias.
6. Combine com o fornecedor do sistema uma revisão das mensagens. Se ele não consegue explicar o erro, o problema não é seu.

Como fica no ArkhiX

O Catálogo de Erros do Hub parte de uma regra simples: todo erro do ArkhiX explica o motivo provável, diz o que fazer e fica no log, com código para o suporte. A tela do terminal não diz “Erro ao salvar”. Diz o que estava errado, sugere a correção e mostra o código. O operador corrige na hora e fecha a O.S. sem sair do posto.

O mesmo erro fica registrado no Registro de Logs, com usuário, terminal, tela e horário. Quando o operador ou o supervisor abre um chamado no Chamados T.I., o código já diz ao suporte onde olhar. O técnico não precisa reproduzir: o contexto veio junto.

O catálogo também serve para o gestor. Um erro que se repete em vários terminais não é um problema de operador; é um sinal de que algo no processo, no cadastro ou na configuração precisa de ajuste. Como cada ocorrência tem código e fica no log, esse padrão aparece sem ninguém contar no dedo.

Checklist

• Quando o terminal mostra um erro, o operador sabe o que fazer sem ligar para ninguém?
• Os erros mais frequentes do último mês estão listados com motivo e ação?
• Todo erro tem um código que o suporte consegue rastrear?
• O chamado de T.I. chega com contexto ou com “deu erro”?
• Você sabe quais erros se repetem em quais postos?
• O operador ainda confia no sistema depois de uma tela vermelha?

Se “deu erro” ainda manda o seu chão de fábrica de volta para o papel, vale ver como fica uma tela que explica o motivo e o que fazer, nos terminais da sua própria planta.