Diagrama ilustrativo — o operador (exception handler) e a frota AMR alimentam um painel unico de KPIs do sistema, nao metricas isoladas.
❌ O erro classico: UPH individual com AMRs
A metrica legada mais comum em armazem e o Units Per Hour (UPH) individual: conta quantas unidades cada operador processa por hora. Em operacao manual fazia sentido. Com AMRs (robos moveis autonomos) na operacao, ela se torna ativamente nociva — penaliza exatamente quem faz o trabalho mais critico.
🎯 O incentivo perverso
O operador que para para resolver uma excecao do robo perde UPH — mas sem ele, a frota inteira para. A metrica premia quem ignora o problema e faz tarefa simples, e pune quem mantem o sistema de pe.
- •Mede a parte, ignora o todo
- •Penaliza o exception handler — o papel de maior valor
- •Cria competicao onde deveria haver colaboracao homem-frota
✓ O que a metrica DEVE recompensar
- ✓Manter a frota rodando sem parar
- ✓Resolver excecoes rapido e bem
- ✓Output total do sistema humano + robos
✗ O que o UPH individual faz
- ✗Conta unidades de UM operador isolado
- ✗Pune quem para para salvar a frota
- ✗Premia tarefa simples sobre trabalho critico
Conceitos-chave
📈 System Throughput: output do sistema inteiro
O System Throughput mede a producao total do sistema humano-robo como uma unidade integrada — nao a soma das partes individuais. O valor da operacao moderna nao esta no quanto cada pessoa carrega, esta na sinergia entre quem opera e a frota que ela mantem.
📊 O dado que muda a conversa
- •Um operador que mantem 10 AMRs rodando gera mais throughput que 10 operadores fazendo pick manual.
- •O ganho vem da sinergia humano-maquina, nao do esforco individual somado.
💡 Dica pratica
Antes de avaliar uma pessoa, pergunte: "qual era o output do sistema com ela presente vs ausente?" Se a frota cai sem o operador, o throughput dele e enorme — mesmo que o UPH individual seja baixo.
Conceitos-chave
🔧 Exception Rate: intervencoes por hora
O Exception Rate conta o numero de intervencoes humanas necessarias por hora de operacao robotica. E a metrica que mede a qualidade da integracao entre humano e robo — e a mais reveladora da maturidade do sistema.
🔍 O que uma exception rate alta esta te dizendo
Exception rate alta nao e culpa do operador — e sintoma. Ela aponta para problemas a montante:
- •Setup ruim: layout, sinalizacao ou docking mal configurados
- •Treinamento insuficiente: operador nao previne, so apaga incendio
- •Design do fluxo: rotas que geram colisao ou bloqueio recorrente
✓ Use a exception rate para
- ✓Fazer root cause de excecoes recorrentes
- ✓Medir a maturidade da integracao ao longo do tempo
- ✓Priorizar onde investir em setup e treino
✗ NAO use a exception rate para
- ✗Culpar o operador que resolve as excecoes
- ✗Ignorar a causa-raiz e so cobrar numero
- ✗Comparar areas com layouts diferentes sem contexto
Conceitos-chave
⏱️ Fleet Uptime e MTTR: responsabilidade do operador
Duas metricas que finalmente valorizam o papel humano: Fleet Uptime (% de tempo que a frota opera normalmente) e MTTR — Mean Time to Resolve (quanto tempo o operador leva para resolver cada excecao). Uptime e responsabilidade direta do operador; MTTR revela competencia — e e treinavel.
Fleet Uptime %
Percentual de tempo que a frota opera normalmente
Responsabilidade direta do operador: quanto mais rapido ele previne e resolve, mais a frota fica produtiva. E o KPI central do operador de frota.
MTTR de excecoes
Tempo medio para resolver cada excecao
Revela competencia na resolucao — e, ao contrario de "talento", e treinavel. Operador treinado baixa o MTTR e sobe o uptime simultaneamente.
💡 Dica pratica
Uptime e MTTR sao acopladas: quem reduz MTTR quase sempre eleva o uptime. Treine resolucao de excecao especifica (docking, bloqueio, leitura de codigo) e as duas metricas melhoram juntas — esse e o argumento concreto de que requalificacao tem retorno mensuravel.
Conceitos-chave
🎯 Zero erro em handoffs: transicoes criticas
Handoffs sao os pontos de transferencia entre humano e robo — e os momentos de maior risco em operacoes hibridas. A meta e zero falha (zero-defect target) nesses pontos especificos, porque e ali que acidentes e perdas se concentram.
⚠️ Por que o handoff e o ponto fragil
Acidentes e perdas ocorrem predominantemente nos handoffs — quando a responsabilidade passa de humano para robo ou vice-versa. Medir e treinar esses pontos especificos de transicao reduz risco drasticamente.
Identificar cada handoff critico
Mapear todo ponto onde controle/carga passa entre humano e robo. Cada transferencia e um ponto a medir.
Definir zero-defect target
Estabelecer meta de zero falha por handoff e contar desvios. Diferente de metrica de media — aqui qualquer falha conta.
Treinamento especifico de transicao
Treinar o gesto exato da transferencia — nao o trabalho em geral. Treino focado no ponto de risco reduz a falha onde ela mais custa.
Conceitos-chave
🧠 Framework 92.5%: reconhecimento de intencoes
A proxima geracao de metricas HRC (Human-Robot Collaboration) parte de robos que entendem a intencao humana. Um framework de pesquisa (arxiv, 2025) alcanca 92.5% de precisao no reconhecimento de intencoes humanas em ambientes colaborativos — e isso muda o que da pra medir.
📊 Dados de pesquisa
- •92.5% de accuracy no reconhecimento de intencao humana (arxiv 2025).
- •Robos que antecipam intencao reduzem excecoes antes que elas aconteçam.
- •Colaboracao mais natural e segura — menos handoffs falhos.
🚀 Por que isso e o futuro da metrica HRC
Quando o robo reconhece intencao, as metricas dos topicos anteriores melhoram em cascata: menos excecoes (topico 3), mais uptime (topico 4) e handoffs mais seguros (topico 5). O intent recognition e a alavanca a montante de quase tudo.
- •Reduz excecoes na origem, nao so na resolucao
- •Aumenta seguranca nos pontos de transicao
- •Torna a colaboracao humano-robo mais natural
💡 Dica pratica
Use o framework como horizonte, nao como pre-requisito. Comece medindo throughput, exception rate, uptime/MTTR e handoffs hoje. O intent recognition (92.5%) e o proximo degrau que torna essas metricas estruturalmente melhores.
Conceitos-chave
📌 Resumo do Modulo
Proximo Modulo:
3.3 - Business Case: Vendendo Requalificacao para Robotica