Seu Template de Dados para Gerenciamento de Problemas

Gerenciamento de Problemas do ServiceNow
Seu Template de Dados para Gerenciamento de Problemas

Seu Template de Dados para Gerenciamento de Problemas

Este template oferece um roteiro completo para analisar o ciclo de vida do seu gerenciamento de problemas ITIL no ServiceNow. Você encontrará os atributos necessários para coleta, as atividades críticas para rastreio e um guia de extração passo a passo. Essa estrutura garante a visibilidade necessária para reduzir o tempo médio de resolução e eliminar incidentes recorrentes.
  • Atributos recomendados para análise de causa raiz
  • Principais marcos e atividades do processo
  • Guia passo a passo para extração do ServiceNow
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gerenciamento de Problemas

Estes são os campos de dados recomendados para incluir no seu event log para uma análise completa do seu processo de gerenciamento de problemas ITIL.
5 Obrigatório 7 Recomendado 10 Opcional
Nome Descrição
Atividade
Activity
O evento ou ação específica realizada no registro do problema.
Descrição

Representa as etapas distintas ou mudanças de status que ocorrem durante o ciclo de vida de um registro de problema. Exemplos incluem 'Registro de Problema Criado', 'Causa Raiz Identificada' ou 'Atribuído ao Grupo de Suporte'. Este atributo é crucial para construir o mapa do processo e visualizar a sequência de eventos.

Por que é importante

Define os nós no mapa do processo, permitindo visualizar o workflow e as variantes do processo.

Onde obter

Derivado das tabelas 'sys_audit', 'sys_history_line' ou mudanças de estado na tabela 'problem'

Exemplos
Registro de Problema CriadoAnálise ConcluídaEstado alterado para Fechado
Event Timestamp
EventTime
A data e hora exatas em que uma atividade ocorreu.
Descrição

Registra o timestamp exato de quando uma alteração ou ação foi logada no sistema. Este dado é fundamental para ordenar as atividades cronologicamente e calcular métricas de duração, como tempos de ciclo e lead times entre as etapas do processo.

Por que é importante

Essencial para ordenar eventos e calcular todos os KPIs baseados em tempo.

Onde obter

Campo 'sys_created_on' do ServiceNow em tabelas de auditoria/histórico

Exemplos
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
Registro do Problema
ProblemNumber
O identificador exclusivo para o registro do problema.
Descrição

A chave alfanumérica única atribuída a um registro de problema no ServiceNow (ex: PRB000123). Este identificador serve como o fio condutor que liga todas as atividades do processo, desde o registro inicial até o fechamento final. Na análise de Process Mining, este atributo funciona como o Case ID, permitindo reconstruir a jornada de ponta a ponta da resolução do problema.

Por que é importante

É a chave primária para diferenciar casos únicos e agrupar eventos relacionados no gráfico do processo.

Onde obter

Tabela 'problem' do ServiceNow, campo 'number'

Exemplos
PRB004512PRB009823PRB001122
Sistema de Origem
SourceSystem
O nome do sistema de onde os dados se originaram.
Descrição

Identifica a instância ou ambiente específico do ServiceNow de onde os dados foram extraídos. Útil em cenários de múltiplos sistemas para rastrear a origem dos dados e lidar com as nuances de cada sistema.

Por que é importante

Fornece contexto sobre a origem dos dados, especialmente ao consolidar informações de várias ferramentas de ITSM.

Onde obter

Fixado durante a extração (ex: 'ServiceNow Production')

Exemplos
ServiceNow ProdServiceNow EMEA
Última Atualização de Dados
LastDataUpdate
O timestamp de quando os dados foram extraídos ou atualizados pela última vez.
Descrição

Indica o quão recente é o conjunto de dados. Ajuda analistas a entenderem se olham para dados em tempo real ou uma foto histórica, algo vital para interpretar status de casos abertos.

Por que é importante

Garante que os usuários saibam o quão atualizados estão os dados para relatórios operacionais precisos.

Onde obter

Hora do sistema no momento da execução do ETL

Exemplos
2023-11-01T12:00:00Z
Categoria da causa raiz
RootCauseCategory
A classificação da causa raiz identificada.
Descrição

Categoriza o motivo subjacente do problema, como Bug de Software, Erro Humano ou Falha de Hardware. Este atributo alimenta o dashboard de 'Precisão da Categoria de Causa Raiz' e ajuda a identificar padrões sistêmicos de falha.

Por que é importante

Permite a análise de padrões de falha para impulsionar melhorias estratégicas.

Onde obter

Tabela 'problem' do ServiceNow, campo 'rca_category' ou 'u_root_cause_category'

Exemplos
Defeito de SoftwareErro de configuraçãoProblema de Fornecedor
Contagem de Incidentes Relacionados
RelatedIncidentCount
O número de incidentes vinculados a este registro de problema.
Descrição

Quantifica o impacto do problema contando o número de incidentes associados a ele. Valores altos neste campo, especialmente para Erros Conhecidos, alimentam o dashboard de 'Recorrência de Erros Conhecidos e Incidentes'.

Por que é importante

Mede a magnitude do impacto causado aos usuários pelo problema.

Onde obter

Tabela 'problem' do ServiceNow, campo 'related_incidents' (o nome varia) ou contagem de registros vinculados

Exemplos
1501200
Estado do Problema
ProblemState
O status do ciclo de vida do registro do problema.
Descrição

Reflete a etapa atual do registro de problema, como Aberto, Análise de Causa Raiz, Correção em Andamento ou Fechado. É o principal filtro para entender a composição do backlog na 'Análise de Envelhecimento de Registros de Problemas Antigos'.

Por que é importante

O indicador de status principal usado para filtrar casos abertos vs. fechados.

Onde obter

Tabela 'problem' do ServiceNow, campo 'state'

Exemplos
NovoAvaliaçãoAnálise de causa raizResolvido
Grupo de suporte
AssignmentGroup
A equipe técnica responsável pela resolução do problema.
Descrição

Designa o grupo ou equipe de suporte atribuído ao problema. Vital para o dashboard de 'Análise de Reatribuição de Grupos de Suporte' para rastrear transferências e identificar silos organizacionais.

Por que é importante

Crucial para identificar gargalos entre departamentos e analisar a eficiência das transferências (handovers).

Onde obter

Tabela 'problem' do ServiceNow, campo 'assignment_group'

Exemplos
Ops de RedeDBAsService Desk
Número de reatribuições
ReassignmentCount
O número de vezes que o problema foi reatribuído entre grupos.
Descrição

Um contador que rastreia a frequência com que o grupo de atribuição mudou. É a fonte direta para o KPI 'Contagem de Reatribuição de Problemas' e ajuda a identificar o efeito pingue-pongue entre equipes.

Por que é importante

Indicador direto de atrito no processo e falta de clareza de propriedade (ownership).

Onde obter

Tabela 'problem' do ServiceNow, campo 'reassignment_count'

Exemplos
0312
Prioridade
Priority
O nível de prioridade atribuído ao registro do problema.
Descrição

Indica a importância e urgência do problema. Este atributo permite segmentar a análise por criticidade, alimentando o dashboard de 'Monitoramento de SLA e Prioridade'.

Por que é importante

Permite segmentar a performance do processo por criticidade de negócio.

Onde obter

Tabela 'problem' do ServiceNow, campo 'priority'

Exemplos
1 - Crítico2 - Alto3 - Moderada
Usuário Atribuído
AssignedTo
O indivíduo específico atribuído para trabalhar no problema.
Descrição

Identifica o usuário responsável pelo problema. Analisar este atributo ajuda a entender a distribuição de carga de trabalho, performance individual e possíveis gargalos em nível de recurso.

Por que é importante

Chave para analisar a eficiência dos recursos e a carga de trabalho individual.

Onde obter

Tabela 'problem' do ServiceNow, campo 'assigned_to'

Exemplos
Alice SmithBob JonesAdministrador do sistema
Data de vencimento do SLA
SlaDueDate
A data/hora limite para a resolução do problema conforme o SLA.
Descrição

O timestamp indicando quando o problema deve ser resolvido para cumprir os SLAs. É a base para o dashboard de 'Monitoramento de Violação de SLA e Prioridade' e para o cálculo das taxas de conformidade.

Por que é importante

Base de comparação para calcular o status de violação de SLA.

Onde obter

Tabela 'task_sla' do ServiceNow vinculada ao problema

Exemplos
2023-12-31T17:00:00Z
Duração do RCA
RootCauseAnalysisDuration
Tempo levado desde a criação do problema até a identificação da causa raiz.
Descrição

Uma duração calculada que mede a eficiência da fase de investigação. Suporta diretamente o KPI 'Tempo Médio para Causa Raiz' e ajuda a identificar lacunas de habilidades técnicas ou problemas de complexidade.

Por que é importante

Métrica chave de eficiência para a fase de investigação.

Onde obter

Calculado: Timestamp da atividade 'Causa Raiz Identificada' menos a hora de 'Criação do Registro do Problema'

Exemplos
3 dias e 4 horas12 horas
Duração Pendente
PendingDuration
Tempo total que o problema passou em estado suspenso ou pendente.
Descrição

Soma o tempo gasto em estados como 'Pendente com Fornecedor' ou 'Em Espera'. Esta métrica é usada na 'Análise de Estados Pendentes e Tempo de Espera' para separar o tempo de processamento interno dos atrasos externos.

Por que é importante

Diferencia ineficiência da equipe de dependências externas.

Onde obter

Calculado: Soma da duração dos intervalos onde o Estado = Pendente/Em Espera

Exemplos
5 dias0 minutos
É Erro Conhecido
IsKnownError
Sinalizador indicando se o problema foi classificado como Erro Conhecido.
Descrição

Identifica se o problema foi convertido ou marcado como Erro Conhecido. Essencial para a análise de 'Erro Conhecido e Recorrência de Incidentes' para verificar a eficácia da gestão de conhecimento.

Por que é importante

Distingue investigações ativas de defeitos aceitos com soluções de contorno.

Onde obter

Tabela 'problem' do ServiceNow, campo 'known_error'

Exemplos
verdadeirofalse
Item de Configuração
ConfigurationItem
O ativo ou serviço específico afetado pelo problema.
Descrição

Identifica o Item de Configuração (CI) vinculado ao problema. Analisar isso ajuda a correlacionar problemas com hardwares, softwares ou serviços específicos, alimentando o dashboard de 'Precisão da Categoria de Causa Raiz'.

Por que é importante

Vincula problemas de processo a ativos físicos ou lógicos específicos.

Onde obter

Tabela 'problem' do ServiceNow, campo 'cmdb_ci'

Exemplos
Servidor SAP ERP 01Serviço de E-mail ExchangeOracle DB Prod
Número da Change Request
ChangeRequestNumber
O identificador da requisição de mudança iniciada para corrigir o problema.
Descrição

Vincula o problema a um registro de Gestão de Mudanças (RFC). Esta conexão é vital para o dashboard de 'Eficiência da Transição para Change Request' para medir a velocidade entre o diagnóstico e a execução da mudança.

Por que é importante

Rastreia a transição do gerenciamento de problemas para o gerenciamento de mudanças.

Onde obter

Tabela 'problem' do ServiceNow, campo 'rfc'

Exemplos
CHG003001CHG004552
Resultado do PIR
PostImplementationReviewResult
O resultado ou status de conclusão da Revisão Pós-Implementação.
Descrição

Armazena o resultado ou status do PIR (ex: Concluído, Não Necessário, Pendente). Este atributo é necessário para o dashboard de 'Conformidade de Revisão Pós-Implementação' para garantir que problemas graves sejam revisados.

Por que é importante

Métrica de controle de qualidade que garante o aprendizado com incidentes graves.

Onde obter

Tabela 'problem' do ServiceNow, campo 'pir_state' ou campo personalizado similar

Exemplos
ConcluídoDispensadoPendente
Serviço de Negócio
BusinessService
O serviço de negócio de alto nível impactado pelo problema.
Descrição

Representa o serviço voltado ao negócio (ex: 'Serviço de Folha de Pagamento', 'Portal do Cliente') em vez do componente técnico. Isso oferece uma visão centrada no negócio para relatórios aos stakeholders.

Por que é importante

Conecta problemas técnicos aos fluxos de valor de negócio.

Onde obter

Tabela 'problem' do ServiceNow, campo 'business_service'

Exemplos
Internet BankingE-mail Interno
Tempo de Elaboração da Solução
SolutionDraftingTime
Tempo entre a identificação da causa raiz e a proposta de solução.
Descrição

Rastreia a duração da fase de design onde uma correção é desenvolvida após a causa ser conhecida. Suporta o dashboard de 'Elaboração de Solução e Aplicação de Correção'.

Por que é importante

Isola a performance da fase de 'design da correção'.

Onde obter

Calculado: Timestamp de 'Solução Proposta Elaborada' menos 'Causa Raiz Identificada'

Exemplos
2 dias4 horas
Workaround Publicado
WorkaroundPublished
Indica se um contorno foi documentado e compartilhado.
Descrição

Um sinalizador booleano ou de status que indica se uma solução temporária foi identificada e publicada na Base de Conhecimento ou no Banco de Dados de Erros Conhecidos. Alimenta o dashboard de 'Desempenho da Publicação de Contornos'.

Por que é importante

Crítico para medir a rapidez com que o impacto no negócio é mitigado antes da correção final.

Onde obter

Tabela 'problem' do ServiceNow, campo 'work_around' (presença de texto) ou status específico

Exemplos
verdadeirofalse
Obrigatório Recomendado Opcional

Atividades de Gerenciamento de Problemas

Estas são as principais etapas e marcos do ciclo de vida que devem ser capturados no seu event log para uma descoberta precisa dos seus workflows de problemas.
8 Recomendado 6 Opcional
Atividade Descrição
Atribuído ao Grupo de Suporte
O roteamento do registro do problema para uma equipe técnica específica para investigação. Esta atividade rastreia o fluxo de responsabilidade e é crítica para analisar as passagens de bastão.
Por que é importante

Essencial para o dashboard de Análise de Reatribuição de Grupos de Suporte para identificar efeitos pingue-pongue e gargalos entre equipes.

Onde obter

Tabela 'sys_audit' ou 'sys_history_line' do ServiceNow rastreando mudanças no campo 'assignment_group'.

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Causa raiz identificada
O ponto em que os códigos de 'Causa Raiz' são preenchidos ou o estado muda para 'Correção em Andamento'. Representa o sucesso no diagnóstico do problema.
Por que é importante

Calcula o Tempo Médio para Causa Raiz e alimenta o dashboard de Ciclo de Investigação. É um marco principal do processo.

Onde obter

Tabela 'sys_audit' do ServiceNow rastreando mudanças no campo de categoria 'root_cause' ou transição para o estado 'Fix in Progress'.

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Change Request Iniciada
A associação de uma Requisição de Mudança (RFC) ao registro do problema. Isso sinaliza a passagem do Gerenciamento de Problemas para o Gerenciamento de Mudanças para implementação.
Por que é importante

Vital para o dashboard de Eficiência na Transição de Mudanças. Identifica atrasos entre encontrar uma correção e iniciar o processo de mudança.

Onde obter

Tabela 'sys_audit' do ServiceNow rastreando o preenchimento do campo de referência 'rfc' na tabela 'problem'.

Captura

Registrado quando a transação de Criar Mudança Normal é executada

Tipo de evento explicit
Correção Permanente Aplicada
O momento em que o problema é marcado como Resolvido, geralmente acionado pelo fechamento da Mudança associada. Indica que o trabalho técnico está concluído.
Por que é importante

Determina o fim do ciclo de correção ativo. Usado para calcular o tempo total de resolução em relação ao SLA.

Onde obter

Tabela 'sys_audit' do ServiceNow, transição do campo 'state' para 'Resolved' (valor típico 106).

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Investigação Iniciada
A transição do estado do registro de 'Novo' para 'Avaliação' ou 'Análise de Causa Raiz'. Significa que um analista começou a trabalhar ativamente no problema.
Por que é importante

Marca o fim do tempo de espera inicial na fila e o início da investigação ativa, auxiliando na análise de Estados Pendentes.

Onde obter

Tabela 'sys_audit' do ServiceNow rastreando mudanças no campo 'state' (ex: valor mudando para 102 ou 103, dependendo da configuração).

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Registro de Problema Criado
A criação inicial de um registro de problema no ServiceNow. Isso marca o início do ciclo de vida do gerenciamento de problemas e define o timestamp base para métricas de envelhecimento.
Por que é importante

Estabelece o horário de início para todos os cálculos de tempo de ciclo e medidas de SLA. É a âncora principal para identificar o volume de investigações de problemas recebidas.

Onde obter

Tabela 'problem' do ServiceNow, campo 'sys_created_on'.

Captura

Registrado quando a transação de Novo Registro é executada

Tipo de evento explicit
Registro de Problema Fechado
O evento final do ciclo de vida onde o registro torna-se inativo. Nenhum trabalho adicional é esperado.
Por que é importante

O ponto final definitivo para a instância do processo. Necessário para calcular o tempo total de ciclo.

Onde obter

Tabela 'problem' do ServiceNow, campo 'closed_at' ou transição de estado para 'Closed'.

Captura

Registrado quando a transação de Fechar Problema é executada

Tipo de evento explicit
Workaround Identificado
O ato de inserir texto no campo 'Workaround' no registro do problema. Isso captura o momento em que uma solução temporária é documentada pelo analista.
Por que é importante

Suporta o dashboard de Desempenho de Publicação de Workaround ao estabelecer quando a solução técnica foi conhecida pela primeira vez.

Onde obter

Tabela 'sys_audit' do ServiceNow onde 'fieldname' é 'workaround'.

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Avaliação Rejeitada
O registro do problema volta a um estado anterior ou é cancelado durante a fase de avaliação por não ser um problema válido.
Por que é importante

Identifica desperdícios no processo onde incidentes são promovidos incorretamente a problemas.

Onde obter

Tabela 'sys_audit' do ServiceNow, transição do campo 'state' para 'Closed/Cancelled' ou 'New' a partir de 'Assess'.

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Esboço da Solução Proposta Criado
A entrada de dados nos campos 'Fix Notes' ou 'Resolution Code'. Indica que o analista passou do entendimento da causa para o design da correção definitiva.
Por que é importante

Suporta o dashboard de Elaboração de Solução e Aplicação de Correção ao isolar a duração da fase de design.

Onde obter

Tabela 'sys_audit' do ServiceNow rastreando atualizações no campo 'fix_notes'.

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Estado alterado para Correção em Andamento
O registro muda para um estado indicando que uma correção está sendo construída ou implantada (geralmente aguardando o Gerenciamento de Mudanças).
Por que é importante

Diferencia o tempo de investigação ativa do tempo de 'espera por mudança', refinando a análise de gargalos.

Onde obter

Tabela 'sys_audit' do ServiceNow, transição do campo 'state' para 'Fix in Progress' (valor típico 104).

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Resolução Verificada
Uma etapa de validação onde se confirma que a resolução foi eficaz. Pode ser um estado específico ou um campo de seleção, dependendo da maturidade do processo.
Por que é importante

Garante o controle de qualidade antes do fechamento. Pular esta etapa permite a análise de Desvio de Processo.

Onde obter

Tabela 'sys_audit' do ServiceNow. Pode ser uma mudança de estado (Resolved -> Closed) ou um campo específico 'u_resolution_verified', se configurado.

Captura

Comparar campo de status antes/depois

Tipo de evento inferred
Revisão Pós-Implementação Concluída
A conclusão da tarefa de PIR ou a definição de um flag de PIR. Isso confirma que uma análise retrospectiva foi realizada para problemas graves.
Por que é importante

Suporta diretamente o dashboard de Conformidade da Revisão Pós-Implementação. A ausência desta atividade em problemas de alta prioridade indica falha de conformidade.

Onde obter

Fechamento da tabela 'problem_task' do ServiceNow (tipo=PIR), ou alteração no campo 'pir_state' da tabela 'problem'.

Captura

Derivado da comparação entre os campos X e Y

Tipo de evento inferred
Workaround Publicado
A execução da ação 'Comunicar Workaround', que envia a solução para incidentes relacionados ou cria um artigo de Erro Conhecido. Isso é diferente de apenas digitar o workaround.
Por que é importante

Crítico para medir a velocidade do compartilhamento de conhecimento. Atrasos aqui impactam diretamente o volume de incidentes recorrentes.

Onde obter

Tabela 'sys_journal_field' do ServiceNow ou logs específicos de UI Action; também pode ser inferido se um registro 'kb_knowledge' do tipo 'Known Error' for criado.

Captura

Registrado quando a transação de Comunicar Contorno é executada

Tipo de evento explicit
Recomendado Opcional

Guias de Extração

Como extrair seus dados do Gerenciamento de Problemas do ServiceNow