SLA, lead time e gargalo: como medir um processo de verdade

“Quanto tempo leva uma solicitação de compra, em média?” É a pergunta que qualquer diretor faz numa reunião de operações — e raramente alguém responde com um número que resista à segunda pergunta: “e o pior caso, quanto leva?”. A maioria das empresas mede processo com sensação, não com dado: alguém lembra de um caso que travou por semanas, outro garante que “normalmente é rápido”, e a conversa termina em opinião, não em decisão.

Este texto cobre os indicadores de processo que sustentam uma conversa que não termina em opinião: lead time e cycle time — e por que a diferença entre os dois é literalmente o gargalo —, WIP e a Lei de Little, throughput, taxa de retrabalho, e como transformar histórico em um SLA que alguém consegue cumprir, em vez de um número inventado em reunião. Tudo com fórmula e exemplo numérico, para quem vai medir o processo — não para quem vai só aprovar o relatório.

Lead time e cycle time: a diferença entre os dois é o gargalo

Lead time e cycle time são os dois indicadores mais citados e mais confundidos da gestão de processos. A diferença entre eles não é acadêmica — é o jeito de mostrar para onde vai o tempo do seu processo.

• Lead time: tempo total do ponto de vista de quem pediu. Conta da abertura da solicitação até a conclusão, com tudo dentro — trabalho e espera.
• Cycle time: tempo de trabalho efetivo. Conta só as horas em que alguém realmente mexeu no caso.
• Wait time: o resto. O tempo em que o caso existia, mas ninguém estava fazendo nada com ele — parado numa fila, esperando um responsável agir.

A relação entre os três é uma soma simples:

Lead Time = Cycle Time + Wait Time

Um exemplo com números reais deixa isso concreto. Uma solicitação de compra passa por quatro fases — Abertura, Triagem, Aprovação do gestor e Execução — e o tempo de trabalho (touch time) e o tempo de espera (wait time) de cada uma ficam assim:

Fase	Touch time	Wait time
Abertura	0,5h	0h
Triagem	1h	4h
Aprovação do gestor	0,25h	68h
Execução (compra)	3h	6h
Total	4,75h	78h

Lead time = 4,75h + 78h = 82,75h, cerca de 3,5 dias corridos. Cycle time é 4,75h — menos de meio dia de trabalho real. A diferença, 78 horas, é 94% do tempo total: é o gargalo, e não está em nenhuma etapa de execução — está no tempo em que o caso ficou parado esperando alguém.

Medir só o lead time (“o processo demora 3,5 dias”) ou só o cycle time (“o trabalho leva 5 horas”) esconde o diagnóstico — é preciso dos dois lado a lado. E isso só é possível com fases claras e nomeadas, o que pressupõe o trabalho descrito em como mapear processos passo a passo: sem fase definida, não há onde carimbar entrada e saída, e touch time e wait time viram estimativa, não medição. Esse par de indicadores é o que dá conteúdo real à fase de Monitorar do ciclo de gestão de processos.

WIP e a Lei de Little: por que processo lotado demora mais

WIP (work in progress, trabalho em andamento) é o número de casos abertos e ainda não concluídos, em qualquer fase, num dado momento. Throughput é quantos casos são concluídos por período.

A Lei de Little relaciona os três:

Lead Time = WIP ÷ Throughput

Com 40 solicitações em andamento e throughput de 8 concluídas por dia, o lead time esperado é 40 ÷ 8 = 5 dias. É fórmula de fila, não opinião: mais WIP para a mesma capacidade de concluir significa mais tempo por caso.

O efeito colateral é o que mais gente erra na prática: abrir mais solicitações ao mesmo tempo não acelera nada — piora. Se o WIP sobe para 60 sem limite de entrada, e o throughput cai para 5 por dia porque a equipe está espalhada em mais casos simultâneos, o lead time vira 60 ÷ 5 = 12 dias — mais que o dobro, com cada pessoa trabalhando na mesma velocidade de antes. Só existem duas alavancas para reduzir lead time: baixar o WIP ou subir o throughput. Tudo o mais é cosmético.

Throughput: quanto sai, não quanto entra

Throughput mede o que conclui, não o que entra. A distinção importa porque, se a taxa de entrada for maior que o throughput por tempo suficiente, o WIP cresce sem parar — e pela Lei de Little, o lead time cresce junto, sem que ninguém tenha ficado mais lento.

Um exemplo: um processo recebe 10 solicitações por dia e conclui 8 — o WIP cresce 2 por dia. Em 20 dias, são 40 casos a mais sobre o WIP de 40 do exemplo anterior. Com WIP em 80 e o mesmo throughput de 8/dia, o lead time dobra de 5 para 10 dias, sem que uma etapa tenha ficado mais lenta: o processo está recebendo mais do que entrega, e isso vira fila. A mesma dinâmica de entrada versus saída aparece em qualquer funil, incluindo o de contratação, com métricas próprias em tempo de contratação e custo por contratação.

Taxa de retrabalho: o indicador que esconde os outros

Retrabalho é quando um caso volta para uma etapa anterior — reprovado, devolvido, corrigido — em vez de seguir adiante. A fórmula:

Taxa de Retrabalho = (Casos que Retornaram ÷ Total de Casos Concluídos) × 100

Em 120 solicitações concluídas no mês, se 18 precisaram de pelo menos uma reprovação ou devolução antes de fechar, a taxa de retrabalho é 18 ÷ 120 × 100 = 15%.

Esse indicador importa porque se esconde dentro dos outros. Um caso que vai e volta duas vezes entre “Aprovação” e “Execução” conta, no tempo médio da fase, como se fosse trabalho normal — mas é o mesmo caso passando duas vezes pela mesma fila. Sem medir retrabalho à parte, uma fase “lenta” pode ser uma fase normal sendo revisitada pelos mesmos casos problemáticos. Por isso toda reprovação precisa de motivo registrado e rastro auditável — só assim dá para separar “essa fase é difícil” de “esse tipo de caso volta sempre pelo mesmo motivo”.

Como definir um SLA interno que signifique algo

SLA (service level agreement) é o compromisso de prazo máximo aceitável para um processo ou uma fase. O erro mais comum é defini-lo do jeito mais rápido possível: alguém sugere um número em reunião (“vamos dizer que é 2 dias”), todo mundo concorda porque soa razoável, e o número vira meta oficial sem nunca ter sido confrontado com um dado real. O jeito certo é o oposto: o SLA nasce do histórico, não da intuição.

Por que a média é a pior estatística para prazo

Tempo de processo quase nunca segue uma distribuição simétrica. A maioria dos casos termina rápido, e uma minoria — por exceção, por complexidade, por alguém esquecer um card numa fila — demora muito mais. Essa cauda longa distorce a média para cima sem representar o caso típico, e ao mesmo tempo não protege contra os casos realmente fora da curva.

Um exemplo com os últimos 20 casos concluídos de um processo, lead time em dias, ordenados:

Casos (ordenados)	Valores (dias)
1º ao 4º	1, 2, 2, 2
5º ao 8º	3, 3, 3, 3
9º ao 12º	4, 4, 4, 4
13º ao 16º	5, 5, 6, 7
17º ao 20º	9, 12, 18, 25

A média é 6,1 dias. A mediana (o valor central) é 4 dias. O percentil 85 — o valor abaixo do qual ficam 85% dos casos — é 9 dias.

Com o SLA fixado em 6 dias (a média arredondada), cinco dos vinte casos ultrapassam o prazo: 25% de estouro todo mês, com um número que parecia sólido. Com o SLA no percentil 85, 9 dias, só três casos ultrapassam: 15% de estouro — coerente com a própria definição do percentil. A média mente porque é puxada pelos outliers sem, em troca, garantir nada sobre eles. O percentil diz exatamente que fatia dos casos cobre.

O passo a passo

1. Deixe o processo rodar sem SLA imposto, ou use o histórico que já existe, para gerar dados reais em vez de estimativa.
2. Extraia os lead times de todos os casos concluídos no período, do ponto de vista de quem pediu.
3. Ordene os valores e calcule o percentil 85 (ou 90, para baixa tolerância a atraso): pegue o valor na posição 0,85 × número de casos.
4. Configure esse número como o SLA — total do processo ou por fase.
5. Revise o SLA a cada trimestre. Se a taxa de estouro mudar de forma consistente, o processo mudou — de volume, de equipe, de complexidade — e o SLA antigo já não descreve a realidade atual.

Como encontrar o gargalo: a etapa com a maior fila, não a mais lenta

O erro mais comum ao caçar gargalo é abrir o relatório de tempo médio por fase e apontar a etapa com o número mais alto. Isso identifica a etapa mais lenta para executar — não necessariamente a que mais atrasa o processo.

Volte ao exemplo da solicitação de compra. A etapa “Aprovação do gestor” tem o menor touch time de todas — 15 minutos para clicar em aprovar. Mas tem, disparado, o maior wait time: 68 das 78 horas de espera do processo inteiro. É essa etapa que segura o caso, não porque o trabalho nela é difícil, mas porque a fila na frente dela é grande. Se alguém “otimizasse” a Execução — reduzindo touch time de 3h para 1h — o lead time do processo praticamente não mudaria, porque o gargalo nunca esteve lá.

O jeito de achar o gargalo de verdade é olhar para onde os casos se acumulam, não para quanto tempo cada etapa registra de trabalho: qual fase tem mais casos parados nela agora, relativo à sua capacidade normal de vazão. Fila crescente é a definição prática de gargalo — a mesma lógica por trás do WIP na Lei de Little. Depois de identificar o gargalo real, a resposta não é automaticamente “automatizar” — o critério para decidir isso está em o que automatizar primeiro; às vezes a solução é redistribuir responsáveis, não tecnologia.

Onde isso dá errado

• SLA de gaveta. Definido numa reunião, sem olhar um dado histórico, quase sempre otimista demais. Vira decoração porque ninguém o cumpre e ninguém o revisa — todo mundo sabe que é ficção e segue ignorando.
• Medir só a média. Um painel com “tempo médio: 3 dias” tranquiliza a diretoria enquanto 20% dos casos levam três semanas. A média some com a variabilidade que mais importa: a dos piores casos, que são os que geram reclamação.
• Otimizar a etapa errada. Acelerar a etapa com maior tempo médio de execução quando o gargalo real está em outra, com fila grande e touch time pequeno. O esforço é real, o ganho no lead time percebido é zero.
• Perseguir a meta em vez do resultado. Quando o SLA vira indicador de avaliação individual, o comportamento muda para bater o número, não para entregar o resultado — as pessoas fecham o card antes do trabalho estar pronto, empurrando o problema para um retrabalho disfarçado de caso novo. É a mesma armadilha de toda meta mal desenhada, o motivo pelo qual vale entender OKR e KPI antes de transformar indicador de processo em meta de desempenho.

Como a TAI resolve

Na TAI Processos, a tela de Métricas de cada fluxo mostra, sem planilha, os números deste texto: total de solicitações, concluídos, em andamento, taxa de SLA, a distribuição entre cards dentro do prazo e vencidos, o throughput por dia, semana ou mês, a comparação entre solicitações criadas e concluídas nos últimos 30 dias, e o tempo médio por fase.

O SLA não é um campo decorativo: é configurado como SLA Total (em dias) para o processo inteiro e, se fizer sentido, como SLA em horas por fase — o número que este texto recomenda calcular a partir do percentil 85 do histórico, não inventar em reunião. Quando um card estoura o prazo, ele aparece contado na tela de Métricas e na lista de fluxos, com atalho direto para abrir o board já filtrado pelos cards vencidos.

Para achar o gargalo — a etapa com a maior fila, não a mais lenta — o board mostra, em cada coluna, o contador de cards parados ali e o limite de WIP configurado para a fase — e, se você marcar a opção de bloquear cards acima do limite, a fase para de aceitar entrada quando enche, o que torna a fila visível antes de virar um problema de prazo. Cruzar essa contagem por coluna com o tempo médio por fase da tela de Métricas é o mesmo diagnóstico descrito acima, com os dados já prontos.

Retrabalho também fica rastreável: toda reprovação exige motivo registrado, o card permanece na fase até ser corrigido e reenviado, e a aba Histórico guarda cada movimentação — a base para calcular a taxa de retrabalho por processo ou por fase, em vez de deixá-la escondida dentro do tempo médio de execução.