TRILHA ITSM · ADMINISTRAÇÃO SERVICENOW · INCIDENT, PROBLEM E CHANGE · 2026
Como Incident, Problem e Change Management se conectam no ServiceNow
Incident, Problem e Change Management são três práticas de ITSM que formam um único ciclo no ServiceNow: o Incident restaura o serviço, o Problem encontra e controla a causa raiz e o Change aplica a correção definitiva com risco controlado. Cada etapa gera um registro próprio (incident, problem e change_request), e os três ficam vinculados por campos de referência e related lists, o que permite rastrear de ponta a ponta por que uma falha aconteceu e como ela deixou de acontecer.
Na prática, o ciclo de Incident, Problem e Change Management começa no formulário do incidente: pelo menu de contexto, o analista cria o problem ou a change já vinculados, com campos copiados automaticamente. O valor não está em cada processo isolado, e sim na ligação entre eles. Sem o vínculo, a central resolve o mesmo incidente toda semana e ninguém enxerga o padrão.
- Incident Management restaura o serviço o mais rápido possível; não é o processo que investiga causa raiz.
- Problem Management identifica e controla a causa de um ou mais incidentes, gerenciando workarounds e known errors.
- Change Management autoriza e executa a correção definitiva, nos tipos standard, normal ou emergency.
- No ServiceNow, o incidente aponta para o problem (campo Problem), para a change que o resolve (Change Request) e para a change que o causou (Caused by Change).
- O CI do CMDB é o fio comum: quanto mais preciso o item de configuração, mais rápido incidente, problema e mudança se conectam.
Para quem está começando a navegar por esses módulos na plataforma, o curso Fundamentos de ServiceNow da Prática Academy é um ponto de partida estruturado.
O que é Incident, Problem e Change Management e por que a conexão importa
Incident, Problem e Change Management são práticas de gerenciamento de serviços descritas no ITIL 4 e implementadas nativamente no ServiceNow ITSM. Cada uma responde a uma pergunta diferente sobre a mesma falha, e confundir essas perguntas é a origem da maior parte dos processos que não funcionam.
| Prática | Pergunta que responde | Objetivo | Tabela | Estados no modelo base |
|---|---|---|---|---|
| Incident Management | Como o usuário volta a trabalhar agora? | Restaurar o serviço com o menor impacto possível | incident | New, In Progress, On Hold, Resolved, Closed, Canceled |
| Problem Management | Por que isso aconteceu e como evitar que se repita? | Reduzir a probabilidade e o impacto de incidentes, identificando causas e gerenciando workarounds e known errors | problem | New, Assess, Root Cause Analysis, Fix in Progress, Resolved, Closed |
| Change Management | Como corrigir sem quebrar outra coisa? | Implementar mudanças com risco avaliado e autorização adequada | change_request | New, Assess, Authorize, Scheduled, Implement, Review, Closed, Canceled |
O guia de processo do ServiceNow para Problem Management lista três consequências de operar sem essa prática: incidentes repetidos, tempo da equipe gasto corrigindo o mesmo tipo de falha e desgaste com usuários que convivem com o mesmo erro por semanas. A conexão com Change Management fecha a outra ponta, porque é a change que transforma o diagnóstico em correção definitiva.
Mapa de relacionamentos: como os registros se ligam na plataforma
O vínculo entre Incident, Problem e Change Management no ServiceNow é feito por campos de referência no formulário do incidente e por related lists nos formulários de problem e change. A tabela resume os caminhos do modelo base.
| Vínculo | Como criar | Onde aparece |
|---|---|---|
| Incident → Problem | Menu de contexto do incidente: Create Problem | Campo Problem no incidente; related list Incidents no problem |
| Incident → Change (correção) | Menu de contexto: Create Normal Change, Create Standard Change ou Create Emergency Change | Campo Change Request no incidente; related list Incidents Fixed By Change na change |
| Change → Incident (causa) | Incidente criado ou associado a partir da change de origem | Campo Caused by Change no incidente; related list Incidents Caused By Change na change |
| Problem → Change | Change criada a partir do problem | Problem listado em related list no formulário da change |
| Problem → Incidentes | Workaround e known error comunicados pelo problem | Work notes no activity stream de cada incidente associado |
Dois detalhes de configuração fazem diferença na operação. A propriedade com.snc.problem.create_from_incident.attributes define quais campos do incidente são copiados para o problem; no modelo base, a lista inclui descrição, CI, impacto, urgência, prioridade, serviço de negócio, categoria e subcategoria. Já os scripts de criação de change a partir do incidente copiam short description, description, CI, prioridade e company. Se o incidente já tem um problem ou uma change associados, a plataforma não permite criar outro registro do mesmo tipo a partir dele.
Roteiro do ciclo completo de Incident, Problem e Change Management
O roteiro mostra o caminho de uma falha real pelos três processos, na ordem em que os registros são criados no ServiceNow.
Etapa 1: o incidente restaura o serviço
O service desk registra o incidente, associa o CI afetado e usa o CMDB, as dependency views e a lista de incidentes do mesmo solicitante para diagnosticar. O objetivo é restaurar o serviço, mesmo que com uma solução de contorno. Se o impacto é amplo e a urgência é máxima, o incidente pode ser promovido a major incident.
Etapa 2: a recorrência vira problem
Quando a equipe identifica que a causa é um erro ou uma falha generalizada, o analista cria o problem direto do incidente com Create Problem. Incidentes semelhantes entram na related list Incidents do problem: quanto maior a lista, mais claro fica o impacto real e mais fácil justificar a correção definitiva. Com Major Incident Management instalado e o flow Create Problem from Major Incident ativado (ele vem inativo no modelo base), a promoção a major incident gera o problem automaticamente.
Etapa 3: o workaround volta para os incidentes
O problem passa por Assess e Root Cause Analysis. Se existe solução de contorno, ela é registrada no campo Workaround e enviada a todos os incidentes associados pelo link Communicate Workaround, que grava um work note com o resumo e o link para o problem. Ao vincular um artigo de known error ao problem, o mesmo tipo de registro aparece no activity stream dos incidentes.
Etapa 4: a correção definitiva vira change
Com a causa raiz identificada, o problem segue para Fix in Progress e a correção é solicitada como change request a partir do próprio problem. A change percorre o modelo de estados do seu tipo, e o problem aparece em related list no formulário da change, preservando a rastreabilidade.
Etapa 5: a change implementada fecha o ciclo
No Problem Management Best Practice, o problem coordinator é notificado quando todas as changes relacionadas estão concluídas ou canceladas. O problem é revisado e resolvido, e os incidentes associados a ele podem ser fechados automaticamente.
Etapa 6: quando a change é a causa do incidente
O ciclo também roda no sentido inverso. Se uma mudança implementada provoca uma falha, o incidente é criado ou associado a partir da change de origem e registrado no campo Caused by Change. Esse vínculo alimenta a related list Incidents Caused By Change e é a base para medir quantas mudanças geram incidentes, um indicador direto da qualidade do Change Management.
Os três tipos de change e onde cada um entra no ciclo
Change Management no ServiceNow trabalha com os três tipos descritos pelo ITIL: standard, normal e emergency. O tipo define o modelo de estados e o caminho de aprovação que a change vai percorrer.
| Tipo | Pré-aprovada | Exige CAB | Onde entra no ciclo |
|---|---|---|---|
| Standard | Sim | Não | Correções de baixo risco, repetíveis e com histórico de sucesso, disponíveis como templates |
| Normal | Não | Sim | Correção definitiva planejada a partir de um problem, com avaliação de risco e autorização |
| Emergency | Não | Sim, pelo grupo de aprovação CAB/ECAB no estado Authorize | Restaurar serviço em major incident ou aplicar patch de segurança urgente |
Pelo guia de processo do ServiceNow, a emergency change normalmente exige um incidente relacionado para comprovar a urgência que justifica pular prazos e etapas da change normal, vínculo feito pela related list Incidents Fixed By Change. Os três tipos também existem como change models, que permitem desenhar fluxos próprios para casos como provisionamento em nuvem ou changes de DevOps.
O papel do CMDB na conexão entre os três processos
O CMDB é o que conecta Incident, Problem e Change Management por dado, e não apenas por processo. Quando incidente, problem e change apontam para o mesmo CI, o ícone de outras tarefas ativas ao lado do campo Configuration item mostra tudo o que está aberto naquele item. Para o analista de problem, isso revela padrões de falha; para o change manager, revela o risco de mexer em um CI que já acumula incidentes. Se o tema é novo para você, vale entender como Discovery e Service Mapping alimentam o CMDB e a diferença entre Asset e CI no ITAM.
Erros comuns que quebram o ciclo ITSM
- Fechar incidente recorrente sem abrir problem. O serviço volta, a métrica de resolução melhora e a falha reaparece na semana seguinte. Recorrência sem problem é custo operacional escondido.
- Tratar problem como incidente grande. O problem não existe para restaurar serviço, e sim para eliminar a causa. Incidente de alto impacto é major incident: ele pode gerar um problem, mas não se transforma em um.
- Aplicar SLA ao problem inteiro. A documentação do ServiceNow não recomenda SLA sobre o problem como um todo, porque investigação e correção podem levar muito tempo. Para evitar problems esquecidos, use inactivity monitors.
- Criar a change fora do problem. Uma change aberta do zero, sem vínculo, faz o problem perder a referência da correção, e o problem coordinator não é notificado quando ela termina.
- Não registrar Caused by Change. Sem esse campo, a organização não sabe quantas mudanças geram incidentes e não consegue calibrar o risco das próximas changes.
- Usar emergency change como atalho. Emergency change existe para falha em andamento ou iminente. Para mudanças repetitivas de baixo risco, o caminho é transformar o procedimento em standard change. Montar o fluxo completo em uma PDI, criando incident, problem e change vinculados e observando o que aparece em cada formulário, é o exercício que mais evita esses erros, e é a lógica de laboratório que a Prática Academy aplica nos cursos.
Recursos oficiais
- ServiceNow Docs: documentação oficial de Incident Management, Problem Management e Change Management, incluindo propriedades e formulários.
- ServiceNow Developer Program: instância pessoal gratuita (PDI) para testar o ciclo completo.
- Guia completo de certificação ITIL: a base conceitual das três práticas no ITIL 4.
- CSA x CAD x CIS: onde a CIS-ITSM entra na sua trilha de certificações.
Perguntas frequentes sobre Incident, Problem e Change Management
Qual a diferença entre Incident, Problem e Change Management?
Incident Management restaura o serviço, Problem Management investiga e controla a causa de um ou mais incidentes e Change Management autoriza e implementa a correção com risco controlado. No ServiceNow, cada prática tem sua tabela (incident, problem e change_request), e os registros se ligam por campos de referência e related lists.
Quando abrir um problem a partir de um incidente no ServiceNow?
Quando a causa do incidente é um erro ou falha generalizada, quando o mesmo incidente se repete ou quando a solução aplicada foi apenas contorno. O problem é criado pelo menu de contexto do incidente (Create Problem), que já associa os dois registros e copia os campos definidos na propriedade com.snc.problem.create_from_incident.attributes.
Todo problem gera uma change?
Na maioria dos casos, sim, porque a correção definitiva ou até o workaround exigem alterar algum componente. Há problems que permanecem como known error documentado quando a organização decide não corrigir naquele momento. No ciclo de Incident, Problem e Change Management, a change é criada a partir do problem para manter a rastreabilidade.
O que é known error no Problem Management?
Known error é um problem que já teve a causa analisada, mas ainda não foi resolvido em definitivo. No ServiceNow, o known error pode ser publicado como artigo de conhecimento vinculado ao problem, e esse vínculo é registrado no activity stream dos incidentes associados.
Como registrar que uma change causou um incidente?
Preencha o campo Caused by Change no incidente ou crie o incidente a partir da change de origem. O registro passa a aparecer na related list Incidents Caused By Change, o que permite medir quantas mudanças geram falhas, um indicador central de Change Management.
Preciso dominar Incident, Problem e Change Management para trabalhar com ServiceNow?
Para atuar com ITSM, sim: são processos centrais do ServiceNow ITSM e base da certificação CIS-ITSM, voltada a quem implementa as aplicações de IT Service Management. Mesmo em administração ou desenvolvimento, entender Incident, Problem e Change Management evita customizações que quebram o vínculo entre os registros.
Incident, Problem e Change Management só entregam valor quando funcionam como ciclo, e isso se aprende operando os registros, não decorando definições. A Prática Academy é a escola de ServiceNow da 4MATT, com cursos em português focados na operação real da plataforma. Conheça as trilhas em pratica.academy: você sai daqui pronto para operar, não apenas para passar na prova.
PRÁTICA ACADEMY · pratica.academy · by 4MATT