Como este tema funciona na sua empresa
Sem diferença prática. Tudo é tratado como incidente (urgência). Se impressora abre ticket toda semana, é resolvida toda semana (restart, limpeza de fila de impressão). Ninguém nota que é recorrente; ninguém investe em solução permanente. Desafio: desperdício de tempo em workarounds. Abordagem recomendada: técnico deve identificar padrão ("vimos isto 3x no mês") e alertar gerente. Desencadeia investigação de causa raiz simples.
Diferença conceitual existe mas não é formal. Help desk entende que há "problemas recorrentes" mas sem processo estruturado de identificação ou análise. Quando problema é muito óbvio (VPN cai todo mês), às vezes há reunião para investigar. Desafio: oportunidades de solução permanente são perdidas. Abordagem recomendada: agregar incidentes recorrentes, analisar após 3 ocorrências, investir em RCA e solução permanente.
Problem Management é processo formal. Há comitê de problemas que revisa incidentes semanalmente para detectar padrões. RCA estruturado com técnicas documentadas. Solução permanente é rastreada e testada. Desafio: balanço entre velocidade (incidente) e qualidade (problema). Abordagem: automação de detecção de padrões, priorizaçãode RCA por impacto, integração com change management.
Incidente é qualquer serviço degradado ou interrompido que exige resposta rápida. Problema é causa raiz subjacente de um ou mais incidentes recorrentes que exige investigação e solução permanente. A diferença chave: incidente é urgente (resolver agora), problema é estrutural (resolver de verdade)[1].
Incidente vs. Problema: clareza conceitual
Exemplo prático: impressora do 5º andar trava todo mês.
Abordagem de incidente: chamada chega "impressora não imprime", técnico vai lá, reinicia impressora, problema "resolvido". Próximo mês, repetição. Técnico frustrado, usuário frustrado. Investimento contínuo em tempo de técnico para "conserto" que não resolve.
Abordagem de problema: após terceira ocorrência no mês, estoura alerta. Comitê reúne: "impressora trava todo mês. Por quê?" RCA: driver de impressora desatualizado + conflito de memória. Ação: atualizar driver + aumentar memória. Solução permanente. Problema resolvido de verdade.
Incidente: trata sintoma. Problema: trata doença.
Identificando quando é problema
Como saber quando incidente virou problema? Critérios:
- Frequência: se mesmo incidente ocorre 2-3x em 30 dias, é candidato a problema
- Impacto cumulativo: 5 ocorrências de 30 min cada = 2.5h de downtime. Vale investigar causa
- Incerteza de causa: se incidente é resolvido sempre por workaround mas nunca se sabe por quê, é problema
- Risco: se workaround não funciona 100% das vezes, causa impacto maior
Métrica prática: "5 porquês". Se responder à pergunta "por que" 5 vezes, chegou a causa raiz. Se não conseguir, é problema que merece análise estruturada.
RCA (Root Cause Analysis): como investigar de verdade
RCA é processo de encontrar causa raiz. Três técnicas simples:
Cinco Porquês: fazer "por quê" até chegar a causa. Exemplo: "Não estou vendendo online" ? "Por quê? Site está lento" ? "Por quê? BD está sobrecarregada" ? "Por quê? Query em produção não tem índice" ? "Por quê? Deploy não foi validado em staging" ? "Por quê? Processo de QA foi pulado".
Fishbone (Ishikawa Diagram): desenhar diagrama com causa raiz central e ramos de potenciais causas (pessoa, processo, sistema, ambiente). Brainstorm quais são relevantes. Mais visual que 5 porquês.
Timeline e Correlação: mapear eventos. Às 14:00 aplicação foi deployada. Às 14:15 erros começaram. Conclusão: deploy causou. Procura: qual mudança no deploy? Qual código novo? Qual config? Isolação de causa.
Workaround vs. solução: quando usar cada um
Para incidente crítico, workaround é necessário: restaurar serviço em 30 min. Mas deve ser temporário.
Workaround: "Reinicia o servidor" (restaura serviço), "Limpa cache" (alivia problema), "Redireciona tráfego" (contorna falha). Rápido, efetivo curto-prazo. Mas não resolve causa.
Solução permanente: "Corrige leak de memória no código", "Aumenta capacidade de BD", "Muda algoritmo de matching". Resolve causa. Demorado (dias/semanas), mas duradouro.
Estratégia: P1 usa workaround para restaurar, depois investigação de problema em background. P3/P4 pode esperar solução permanente.
Processo de Problem Management
Não é improviso. Tem etapas:
- Detecção: padrão de incidentes recorrentes é detectado (manual ou automático)
- Investigação: RCA estruturada com técnicas (5 porquês, fishbone). Documentar achados
- Solução proposta: qual é fix permanente? Qual esforço? Qual risco? Qual custo?
- Aprovação: decisor aprova ou nega. Se aprovado, vira Change Request
- Implementação: solução é codificada, testada, deployada (como qualquer mudança formal)
- Validação: problema recorrente para? Incidentes somem ou diminuem? Sucesso ou falha?
Cada problema deve ser rastreado de ponta a ponta. Falta disso = perda de aprendizado.
Integração com Change Management
Solução de problema deve passar por Change Management. Não é patch rápido; é mudança formal.
Exemplo: problema de vazamento de memória em app X. RCA confirma causa. Solução: deploy de nova versão. Essa mudança segue processo de change: planejamento, teste, agendamento, comunicação, rollback plan.
Evita: deploy de fix sem testes, que causa problema pior ainda.
RCA simples: técnico sênior reúne com técnico que resolveu, faz "5 porquês" rapidamente, documenta em Slack. Se envolve código, passa para developer. Sem processo formal mas com disciplina.
Comitê técnico reunindo semanalmente revisa incidentes de alta frequência. Para cada, executa RCA estruturado. Documenta em sistema de problemas. Solução passa por change management.
Automação detecta padrões de incidentes. Problem Management cria ticket automático quando limiares são atingidos. RCA é feito com dados (logs, traces, métricas), documentado em sistema. Integração automática com change management e KPIs de sucesso rastreados.
Sinais de que você precisa de gestão de problemas estruturada
Se você se reconhece em três ou mais cenários, há oportunidade de problema management.
- Mesma coisa quebra toda semana (ou mês) e é resolvida do mesmo jeito
- Técnicos sabem "o truque" de como resolver mas ninguém sabe por quê funciona
- Quando técnico responsável sai, novo técnico não sabe como resolver (conhecimento em cabeça)
- Workarounds viraram "padrão de operação"; ninguém tira tempo para solução permanente
- Help desk gasta 20%+ do tempo em "tickets recorrentes"
- Não há documentação de causa raiz em ticket (quando finalmente alguém investiga)
- Investimento em infraestrutura não reduz incidentes (porque causa raiz nunca foi encontrada)
Caminhos para implementar Problem Management
Começar com processo simples e evoluir.
Você estrutura processo de detecção de problemas e RCA com equipe interna.
- Perfil necessário: técnico sênior + gestor de TI que entende ITIL, facilidade com RCA
- Tempo estimado: 1-2 semanas para desenhar, 1 mês para implementar
- Faz sentido quando: você tem people disponível, quer baixo custo inicial
- Risco principal: falta de consistência, RCA superficial, ações não são implementadas
Consultoria ITIL desenha processo, treina equipe, acompanha primeiros RCAs.
- Tipo de fornecedor: consultoria ITIL especializada, ou MSP com expertise em problem management
- Vantagem: templates, best practices, treinamento estruturado
- Faz sentido quando: operação é complexa, quer garantir rigor em RCA
- Resultado típico: processo em 2 semanas, implementação em 2-3 meses, equipe preparada para manter
Precisa estruturar Problem Management para resolver problemas recorrentes?
Se reduzir incidentes recorrentes via análise de causa raiz é prioridade, o oHub conecta você gratuitamente com consultores ITIL e especialistas em problem management. Em menos de 3 minutos, descreva sua situação e receba propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Qual é a diferença entre incidente e problema ITIL?
Incidente é interrupção urgente de serviço (resolver agora). Problema é causa raiz de incidentes recorrentes (investigar e resolver de verdade). Incidente é a febre; problema é a infecção que causa a febre.
Como identificar quando um incidente virou problema?
Quando mesmo incidente ocorre 2-3x em 30 dias. Quando cumulativamente consome tempo significativo. Quando é resolvido por workaround mas nunca se investiga causa. Nesses casos, time deve parar e investigar.
O que é análise de causa raiz (RCA) e como fazer?
Técnica de investigação estruturada. Três abordagens: "5 porquês" (perguntar por quê 5 vezes), Fishbone (desenhar diagrama de causas potenciais), Timeline (correlacionar problema com evento recente que o causou).
Qual é o limite entre workaround e solução permanente?
Workaround é rápido (horas) e temporário (problema pode repetir). Solução permanente é demorada (dias/semanas) mas dura (problema não repete). Para P1 crítico, use workaround para restaurar, depois solução permanente. Para P3/P4, vá direto à solução.
Como documentar causa raiz de problema?
Registrar em sistema de problemas (ou ticket com tag "problem"): descrição do problema, frequência/impacto, RCA (causa raiz identificada), solução proposta, ações (implementação, validação, comunicação). Sem documentação, aprendizado se perde.
Qual é a conexão entre problema resolvido e change management?
Quando solução permanente é identificada, deve vir Change Request formal. Solução passa por testes, agendamento, comunicação, validação pós-implementação. Evita: deploy sem rigor que causa problema pior ainda.