A técnica dos 5 Porquês na prática: aplicando análise de causa raiz em chamados de help desk

O que é a técnica dos 5 Porquês (e por que ela cabe tão bem no help desk)

A técnica dos 5 Porquês nasceu na Toyota e é a ferramenta de análise de causa raiz (RCA) mais barata que existe: você não precisa de software, planilha nem reunião. Precisa de disciplina para, diante de um problema, perguntar “por quê?” e, para cada resposta, perguntar “por quê?” de novo — até parar de encontrar sintomas e bater na causa que, se corrigida, impede o problema de voltar.

O número cinco é uma referência prática, não um dogma. Às vezes a causa raiz aparece no terceiro porquê; às vezes você precisa de seis. A regra de parada não é contar perguntas — é reconhecer quando a resposta deixou de ser um evento isolado (“o disco encheu”) e virou um processo ausente ou falho (“ninguém monitora o disco”).

No help desk isso é precioso porque o sintoma reclamado pelo cliente quase nunca é o problema. “O sistema está lento”, “não consigo logar”, “o relatório veio errado” são portas de entrada. Quem fecha o chamado no sintoma resolve o dia; quem fecha na causa raiz resolve o mês.

• Sintoma: o que o cliente sente e descreve no chamado.
• Causa imediata: o evento técnico que disparou o sintoma.
• Causa raiz: o processo ausente ou falho que permitiu o evento — e que vai repeti-lo se não for tratado.
• Regra de parada: pare quando a resposta apontar para um processo a corrigir, não para uma pessoa a culpar.

Um exemplo ilustrativo: o chamado de “o sistema está lento”

Vamos a um exemplo concreto, no mesmo tipo de chamado que o Copilot da Service Up analisa todo dia dentro do Znuny. Ele é uma reconstrução didática inspirada em um caso real (o #2685787), montada para mostrar a técnica em ação — não a transcrição literal de um único ticket. A abertura é a mais comum do help desk: o cliente registra que “o sistema está lento” e pede prioridade. O agente que pega o chamado tem duas saídas possíveis.

A saída rápida: confirmar que o servidor está com carga alta, reiniciar o serviço, ver a lentidão sumir e fechar o chamado como resolvido. Tempo investido: 20 minutos. Problema: na semana seguinte, outro chamado igual entra na fila. E outro.

A saída de causa raiz: aplicar os 5 Porquês antes de fechar. É aqui que o chamado deixa de ser um caso de infraestrutura e revela uma possível falha de processo. No caso real que inspira o exemplo (#2685787), a linha do tempo trouxe um detalhe revelador: entre uma interação e outra, o chamado ficou cerca de 29 dias parado sem ninguém tocar nele.

A investigação, pergunta por pergunta

Acompanhe a cadeia exatamente como ela se desenrola neste exemplo. Cada resposta vira a pergunta seguinte — esse encadeamento é o coração da técnica.

• 1º Porquê — Por que o sistema está lento? Porque um job de processamento em lote estava consumindo quase toda a CPU do servidor no horário comercial.
• 2º Porquê — Por que o job rodou no horário comercial? Porque ficou acumulado na fila e disparou junto com outros jobs antigos que nunca foram concluídos nem cancelados.
• 3º Porquê — Por que havia jobs antigos acumulados na fila? Porque um chamado anterior, que pedia o ajuste do agendamento desses jobs, ficou parado muito tempo e nunca foi tratado.
• 4º Porquê — Por que o chamado ficou tanto tempo parado? Porque caiu numa zona cega da fila, sem alerta de estouro de prazo — exatamente o tipo de intervalo que apareceu como gap de ~29 dias na linha do tempo do #2685787.
• 5º Porquê — Por que ele caiu nessa zona cega? Porque não havia um passo obrigatório de triagem que vinculasse o chamado a um serviço e a um SLA na abertura. Essa é a causa raiz: uma falha de processo, não de infraestrutura.

Onde o sintoma termina e a causa raiz começa

Repare na virada entre o 2º e o 5º porquê. Os dois primeiros são técnicos e tentadores: dá para resolver com um reinício ou um reagendamento e seguir a vida. Mas eles tratam o sintoma. Se o agente parasse no 2º porquê, a lentidão voltaria assim que a fila acumulasse de novo.

É só a partir do 3º porquê que o problema sai da máquina e entra no processo: existe um buraco na triagem que deixa chamados sem serviço e sem SLA, e esses chamados envelhecem invisíveis até virarem incidentes. Corrigir isso — tornar a triagem com vínculo de serviço um passo obrigatório — não conserta só um chamado. Previne toda a categoria.

Esse é o teste prático de que você chegou à causa raiz: a correção que você propõe deixa de ser “resolver este chamado” e passa a ser “impedir que chamados como este aconteçam”. Quando a recomendação muda de escopo assim, pode parar de perguntar.

• Correção do sintoma (1º–2º porquê): reiniciar serviço / reagendar o job → o problema volta.
• Correção da causa imediata (3º–4º porquê): tratar o chamado parado e revisar a fila → ajuda, mas o buraco continua.
• Correção da causa raiz (5º porquê): triagem obrigatória com vínculo de serviço e SLA → mata a recorrência.
• Sinal de número real: em 30 dias, 182 chamados estavam “No linked service” — a mesma zona cega que costuma deixar chamados envelhecerem invisíveis na fila.

De exercício manual a relatório automático: a causa raiz no Copilot da Service Up

Fazer isso à mão, chamado por chamado, é o problema da técnica dos 5 Porquês: ela é boa, mas ninguém tem tempo de aplicá-la em centenas de tickets por mês. É exatamente o gargalo que o módulo Relatório de Causa-Raiz da Service Up ataca, dentro do próprio Znuny.

O Copilot lê toda a thread do chamado — abertura, respostas, notas internas, tempos entre interações — e entrega uma análise de causa raiz na seção de Análise de Gaps e Causa Raiz do relatório RCA (são 8 seções no total: resumo executivo, linha do tempo, gaps e causa raiz, sentimento, status técnico, recomendações, métricas e conclusão). Gaps longos como o de ~29 dias do #2685787 aparecem destacados na linha do tempo — um intervalo que um humano levaria minutos para encontrar manualmente.

O motor por trás é o DeepSeek (modelo deepseek-chat). E o ponto que insistimos: a IA não substitui o analista. Ela acelera o “por quê?” e entrega a primeira versão da análise; quem decide se a causa raiz está certa, e qual processo mudar, continua sendo a pessoa. A IA acelera; o humano decide.

• Por chamado: relatório RCA em PDF com a análise de causa raiz na seção de Gaps e Causa Raiz.
• Painel agregado: chamados do período agrupados por serviço vinculado, com a causa raiz da IA como detalhe de cada grupo.
• Processamento: botão “Processar agora” na interface ou, em lote, o console bin/znuny.Console.pl Maint::AICopilot::RCAScan.
• Cobertura real (30 dias): 647 de 974 chamados analisados (66%), com 84% de cobertura de RCA e 85 serviços mapeados.

Como aplicar os 5 Porquês no seu help desk ainda hoje

Você não precisa do módulo para começar — a técnica é de graça. Mas precisa de método para não cair na armadilha mais comum: confundir o último porquê que você teve paciência de fazer com a causa raiz de verdade.

Use o checklist abaixo no próximo chamado recorrente da sua fila. Quando a quantidade de chamados crescer a ponto de a análise manual virar gargalo, é aí que faz sentido deixar o Copilot acelerar a investigação por você e usar o tempo do time para o que a IA não faz: decidir.

• Comece pelo sintoma exato que o cliente escreveu, não pela sua suposição do que aconteceu.
• A cada resposta, pergunte “por quê?” sobre a resposta — nunca pule para uma nova linha de raciocínio.
• Pare quando a resposta for um processo ausente/falho, não uma pessoa ou um evento isolado.
• Valide a causa raiz com o teste reverso: “se eu corrigir isto, o problema deixa de poder acontecer?” Se não, continue.
• Documente a cadeia no próprio chamado — ela vira treinamento para o time e base de FAQ para os próximos.