Você já resolveu um incidente hoje que sua equipe resolveu semana passada?
Se a resposta for sim, você não tem um problema de capacidade técnica. Você tem um problema de processo, e ele tem nome: ausência de Gestão de Problemas.
A Gestão de Incidentes restaura o serviço. Isso é essencial. Mas ela, sozinha, não impede que o serviço precise ser restaurado de novo amanhã, e depois de amanhã, e na semana que vem. Quem fecha esse ciclo é a Gestão de Problemas, e a diferença entre as duas é precisamente essa: uma apaga o incêndio, a outra descobre por que o prédio continua pegando fogo.
Neste post, você vai entender o que é a Gestão de Problemas no contexto do ITIL, por que ela é frequentemente negligenciada mesmo em times maduros, e como estruturá-la do zero em 30 dias, com um plano prático, as técnicas de análise que realmente funcionam e um template para download.
O que você vai encontrar aqui
- Gestão de Incidentes vs. Gestão de Problemas: a distinção que muda tudo
- Por que a Gestão de Problemas é sempre adiada
- O que é um Problema, um Known Error e a KEDB
- As técnicas de análise de causa raiz que funcionam na prática
- O plano de 30 dias
- Os indicadores que provam que o processo está funcionando
- Gestão de Problemas proativa: o próximo nível
- Resumo: Gestão de Incidentes vs. Gestão de Problemas
- Baixe o Template de Gestão de Problemas
Gestão de Incidentes vs. Gestão de Problemas: a distinção que muda tudo
Essa confusão é mais comum do que parece, e ela tem consequências diretas na operação.
A Gestão de Incidentes tem um objetivo claro e urgente: restaurar o serviço o mais rápido possível, minimizando o impacto para o usuário. Ela não precisa saber por quê o servidor caiu, só precisa fazê-lo voltar.
A Gestão de Problemas tem um objetivo diferente e complementar: encontrar a causa raiz do que gerou o incidente e eliminar a possibilidade de recorrência. Ela não age sob pressão de SLA de restauração, ela age com método, investigação e tempo.
O problema surge quando as equipes tentam fazer os dois ao mesmo tempo, no mesmo chamado, com o mesmo analista. O resultado é previsível: a urgência do incidente sempre vence, a análise de causa raiz fica para depois, e “depois” nunca chega.
Por que a Gestão de Problemas é sempre adiada
Não é falta de intenção. Em quase todos os times de TI que já analisei, a Gestão de Problemas está no roadmap, na apresentação para a diretoria, no plano de maturidade. Só não está no dia a dia.
As razões são sempre parecidas. O volume de incidentes é alto demais para “sobrar tempo” para análise. Os analistas mais experientes, os únicos com conhecimento técnico para investigar causa raiz, são os mesmos que estão no front de incidentes críticos. E quando um incidente se resolve, a pressão para fechar o chamado é maior do que a pressão para entender o que aconteceu.
Isso cria um ciclo perverso: quanto mais incidentes recorrentes, menos tempo para Gestão de Problemas. Quanto menos Gestão de Problemas, mais incidentes recorrentes. É uma armadilha que só se quebra com estrutura, não com esforço individual.
O que é um Problema, tecnicamente falando
No ITIL, um Problema é a causa raiz de um ou mais incidentes. Ele pode ser identificado de duas formas: de forma reativa, quando surge a partir da análise de um incidente já ocorrido; ou de forma proativa, quando a equipe identifica uma condição de risco antes que ela gere impacto.
Um conceito que vale destacar aqui é o de Known Error (Erro Conhecido): quando a causa raiz de um Problema já foi identificada, mas a solução definitiva ainda não foi implementada, o Problema passa a ser registrado como Erro Conhecido. Isso é importante porque permite que o Service Desk aplique uma solução de contorno documentada enquanto a correção permanente não está disponível, reduzindo o tempo de resolução dos incidentes associados sem precisar reinvestigar do zero a cada ocorrência.
A base onde esses registros ficam armazenados é a KEDB — Known Error Database (Base de Erros Conhecidos). Uma boa KEDB vale mais do que qualquer ferramenta cara: ela é a memória operacional da sua equipe.
As técnicas de análise de causa raiz que funcionam na prática
Existem dezenas de técnicas de RCA (Root Cause Analysis ou Análise de Causa Raiz) documentadas. Na prática, três funcionam bem para equipes de TI e ITSM, e podem ser usadas de forma complementar dependendo da complexidade do Problema.
Os 5 Porquês
A técnica mais simples e mais subestimada. A ideia é perguntar “por quê?” de forma encadeada até chegar à causa raiz, normalmente em cinco níveis, mas o número exato varia. O risco é parar cedo demais, quando a equipe encontra uma causa técnica superficial e não investiga o que a gerou. A disciplina está em continuar perguntando mesmo quando a resposta já parece suficiente.
Exemplo direto: o servidor caiu. Por quê? Porque o disco ficou cheio. Por quê? Porque os logs não estavam sendo rotacionados. Por quê? Porque a política de retenção não estava configurada. Por quê? Porque não existe um processo de revisão periódica de configurações críticas. Aí está a causa raiz. Ela não é técnica, é de processo.
Diagrama de Ishikawa (Espinha de Peixe)
Útil quando o Problema tem múltiplas causas potenciais e a equipe precisa mapear todas antes de investigar. O diagrama organiza as hipóteses em categorias (pessoas, processos, tecnologia, fornecedores), e ajuda a estruturar a investigação sem descartar prematuramente nenhuma linha de análise. É especialmente útil em Problemas complexos que afetam múltiplos sistemas ou equipes.
Análise de Timeline
Constrói uma linha do tempo dos eventos que antecederam o incidente: mudanças realizadas, alertas disparados, comportamentos anômalos registrados em logs. É a técnica mais poderosa para Problemas relacionados a mudanças mal planejadas ou a falhas em cascata, porque frequentemente a causa raiz está num evento que aconteceu horas ou dias antes do incidente visível.
O plano de 30 dias
A estruturação da Gestão de Problemas não precisa ser um projeto de seis meses. Com foco e prioridade, quatro semanas são suficientes para ter um processo funcionando. Simples, rastreável e com os primeiros resultados visíveis. O segredo é resistir à tentação de fazer tudo de uma vez.
Semana 1 — Diagnóstico: entenda onde os problemas realmente estão
Antes de criar qualquer processo, você precisa de dados. Na primeira semana, o trabalho é investigativo: identificar os incidentes mais frequentes dos últimos 90 dias, agrupar os que têm o mesmo sintoma ou a mesma origem, e mapear quais deles nunca tiveram uma análise de causa raiz documentada.
Esse levantamento normalmente surpreende. Em operações sem Gestão de Problemas, é comum descobrir que 20% dos incidentes são responsáveis por 60% a 70% do volume total. O famoso Pareto aplicado à operação de TI. Esses são os seus primeiros Problemas candidatos.
Nessa semana também vale mapear o conhecimento informal que já existe na equipe: os analistas mais experientes frequentemente sabem de cor quais são as causas recorrentes. Esse conhecimento precisa sair das cabeças e entrar num registro estruturado.
Semana 2 — Estrutura: processo, registro e a primeira KEDB
Com os Problemas prioritários identificados, a segunda semana é sobre estrutura. Você vai definir o fluxo do processo de Gestão de Problemas, como um Problema é aberto, quem é responsável pela investigação, quais critérios definem prioridade, e o que precisa ser registrado em cada etapa.
O ponto central dessa semana é a criação da KEDB. Ela não precisa ser sofisticada: uma planilha bem estruturada com ID do Problema, sintomas, causa raiz identificada, solução de contorno disponível e status da solução definitiva já resolve para a maioria das operações. O que importa é que ela exista, esteja acessível para o Service Desk e seja atualizada de forma consistente.
Também é aqui que se define o Problema Owner (ou seja, o Dono do Problema): a pessoa responsável por conduzir cada investigação. Sem responsável nominado, o Problema existe no papel mas não avança na prática.
Semana 3 — Investigação: os primeiros RCAs documentados
A terceira semana é onde o processo sai do papel e entra em operação. Você vai conduzir as primeiras análises de causa raiz formais. Escolha de dois a três Problemas prioritários, não mais do que isso. O objetivo não é resolver tudo de uma vez, mas criar os primeiros registros bem documentados que vão servir de referência para a equipe.
Cada RCA deve seguir uma estrutura mínima: descrição do Problema, incidentes associados, linha do tempo dos eventos, análise de causa raiz com a técnica escolhida, causa raiz identificada, solução de contorno disponível e plano de solução definitiva com responsável e prazo.
Esse é também o momento de conectar a Gestão de Problemas à Gestão de Mudanças: quando a solução definitiva exige uma alteração no ambiente, ela entra no processo de Gestão de Mudanças, e não pode ficar num e-mail esquecido.
Semana 4 — Medição e revisão: os indicadores que revelam se está funcionando
Na quarta semana, você ativa os indicadores e faz a primeira revisão formal do processo. O objetivo é simples: ver o que funcionou, o que travou e o que precisa ser ajustado antes que o processo se consolide como rotina.
Também é nessa semana que a Gestão de Problemas proativa começa a ganhar espaço: com a estrutura no lugar, a equipe já pode olhar para alertas e tendências antes que eles virem incidentes. Esse é o salto de maturidade mais significativa, e o que mais impressiona lideranças que acompanham indicadores de operação.
Os indicadores que provam que o processo está funcionando
Métricas são o argumento mais poderoso para manter o processo vivo quando a pressão do dia a dia tenta engoli-lo. Três indicadores são suficientes para o início:
| Indicador | O que mede | Meta inicial sugerida |
|---|---|---|
| Taxa de Recorrência de Incidentes | % de incidentes que se repetem no mês com a mesma origem | Redução de 30% em 60 dias |
| Tempo Médio de Investigação (MTTI) | Tempo médio entre abertura do Problema e identificação da causa raiz | Definir baseline no primeiro mês |
| Cobertura da KEDB | % dos Problemas identificados com causa raiz documentada na KEDB | Acima de 80% dos Problemas abertos |
Um aviso importante sobre o MTTI: no primeiro mês, ele será alto, e isso é normal. O que importa é ter o baseline. A tendência de queda nos meses seguintes é o que demonstra maturidade do processo.
Gestão de Problemas proativa: o próximo nível
A maioria das equipes começa com a Gestão de Problemas reativa, e não tem nada de errado nisso. Você precisa ter o processo básico funcionando antes de avançar. Mas vale entender onde o processo pode chegar.
Na Gestão de Problemas proativa, a equipe não espera o incidente acontecer para investigar. Ela analisa tendências, monitora indicadores de degradação, revisa configurações críticas e avalia riscos em mudanças planejadas, tudo com o objetivo de identificar e eliminar Problemas antes que eles causem impacto visível para o usuário.
É aqui que a Gestão de Problemas conversa diretamente com as práticas de Monitoramento, Gestão de Mudanças e Melhoria Contínua. E é aqui também que ela gera o maior valor estratégico, não como processo de TI, mas como contribuição direta para a resiliência e confiabilidade dos serviços digitais que o negócio depende.
Resumo: Gestão de Incidentes vs. Gestão de Problemas
| Dimensão | Gestão de Incidentes | Gestão de Problemas |
|---|---|---|
| Objetivo | Restaurar o serviço o mais rápido possível | Eliminar a causa raiz e evitar recorrência |
| Gatilho | Interrupção ou degradação de serviço | Incidentes recorrentes ou análise proativa |
| Tempo de resposta | Imediato — regido por SLA de restauração | Investigativo — sem urgência de restauração |
| Resultado esperado | Serviço restaurado, usuário atendido | Causa raiz documentada, solução implementada |
| Principal artefato | Registro de incidente com histórico de atendimento | Registro de Problema com RCA e entrada na KEDB |
| Conexão com outras práticas | Service Desk, Monitoramento, Service Request | Change Enablement, Melhoria Contínua, Monitoramento |
Baixe o Template de Gestão de Problemas
Para facilitar a implementação, preparei um template completo para download com tudo que você precisa para começar:
- Política de Gestão de Problemas
- Fluxo do processo com papéis e responsabilidades (RACI simplificado)
- Formulário de abertura e investigação de Problema
- Template de RCA com 5 Porquês e linha do tempo
- Modelo de KEDB (Known Error Database)
- Dashboard com os 3 KPIs principais
- Checklist de implementação — semana a semana
Então, qual é o próximo incidente que não deveria existir?
Toda operação tem pelo menos um. Aquele incidente que todo mundo já conhece de cor, que tem um nome informal na equipe, que aparece no relatório mensal todo mês sem que ninguém questione por quê ele ainda está ali.
Esse incidente é o seu ponto de partida. Não porque ele é necessariamente o mais crítico, mas porque ele já tem algo que a maioria dos Problemas não tem no início: o engajamento da equipe. Todo mundo já está cansado dele. Isso é motivação suficiente para a primeira investigação real.
Estruturar a Gestão de Problemas não é um projeto de maturidade para o futuro. É uma decisão de hoje que vai liberar a sua equipe do ciclo de retrabalho e devolver tempo para o que realmente importa: melhorar, inovar e criar valor, em vez de restaurar o mesmo serviço pela décima vez no mês.
Quer construir isso com acompanhamento personalizado?
Deixe sua dúvida nos comentários ou me encontre no LinkedIn. Boa parte das melhores conversas começa por lá.