Seu Template de Dados para Gestão de Problemas

Jira Service Management
Seu Template de Dados para Gestão de Problemas

Seu Template de Dados para Gestão de Problemas

Este template serve como um guia completo para analisar seus fluxos de gestão de serviços de TI, identificando dados e marcos essenciais no Jira Service Management. Ele oferece uma visão estruturada dos atributos e atividades necessários para ter visibilidade total de como sua equipe lida com causas raiz. Use estas diretrizes para otimizar sua coleta de dados e garantir insights práticos.
  • Atributos recomendados para análise profunda
  • Marcos do processo para capturar no seu Event Log
  • Orientação técnica para extração de dados
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gestão de Problemas

Estes são os campos de dados recomendados para incluir no seu Event Log para uma análise completa do ciclo de vida da gestão de problemas.
5 Obrigatório 5 Recomendado 11 Opcional
Nome Descrição
Atividade
ActivityName
A ação específica ou mudança de status ocorrida no registro do problema.
Descrição

Este atributo captura o nome do evento ou transição de estado no ciclo de vida do problema. Exemplos: 'Problema Registrado', 'Investigação Iniciada' ou 'Causa Raiz Identificada'.

É essencial para mapear o fluxo e identificar a sequência de passos para a resolução. No Process Mining, essas atividades formam os nós do mapa de processo.

Por que é importante

Define as etapas no mapa do processo e permite analisar as variantes do processo.

Onde obter

Changelog do Jira (Histórico) ou transições de Status do ticket

Exemplos
Registro de Problema CriadoInvestigação IniciadaCausa raiz identificadaWorkaround AtualizadoRegistro de Problema Fechado
Registro de Problema
ProblemKey
O identificador exclusivo atribuído ao registro de problema no Jira Service Management.
Descrição

Este atributo serve como o identificador central (Case ID) para a análise. Representa a chave única (ex: PM-1001) gerada pelo JSM.

Ele agrupa todas as atividades relacionadas em uma única instância de processo de ponta a ponta. Analisar esse atributo permite visualizar todo o ciclo de vida do problema, da detecção inicial ao fechamento final.

Por que é importante

É a chave fundamental para reconstruir o fluxo do processo e rastrear registros de problemas específicos.

Onde obter

Tabela de tickets, campo 'Key' ou 'Issue Key'

Exemplos
PM-1023PM-4099PRB-3321PM-5001
Sistema de Origem
SourceSystem
O nome do sistema de onde os dados se originaram.
Descrição

Identifica o sistema de onde os dados foram extraídos. Neste contexto, o valor é sempre 'Jira Service Management'.

Útil em ambientes multi-sistema para distinguir fontes de dados, servindo como um identificador estático para rastreabilidade dos dados.

Por que é importante

Fornece contexto sobre a origem dos dados, especialmente ao unificar com outros dados de Gerenciamento de Serviços de TI.

Onde obter

Configuração do Sistema ou Hardcoded

Exemplos
Jira Service ManagementJira CloudJSM-Prod
Timestamp
EventTimestamp
A data e hora exatas em que a atividade ocorreu.
Descrição

Este atributo registra o momento exato em que uma atividade ocorreu. É usado para sequenciar eventos e calcular a duração entre etapas.

Timestamps precisos são críticos para calcular tempos de ciclo, como do registro até a identificação da causa raiz, e para analisar a produtividade ao longo do tempo.

Por que é importante

Permite o cálculo de todos os KPIs temporais e a ordenação correta dos eventos.

Onde obter

Data de criação no Changelog do Jira ou Data de criação do ticket

Exemplos
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
Última Atualização de Dados
LastDataUpdate
O timestamp de quando os dados foram extraídos ou atualizados pela última vez.
Descrição

Indica quando os dados foram sincronizados pela última vez com o ambiente real do JSM.

Serve para validar se a análise reflete o estado mais atual do processo e identificar possíveis problemas de latência nos dados.

Por que é importante

Garante que os dados estejam atualizados e traz confiança aos resultados da análise.

Onde obter

Timestamp ETL

Exemplos
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
Categoria da causa raiz
RootCauseCategory
A classificação da causa subjacente do problema.
Descrição

Categoriza a falha técnica ou de processo (ex: 'Bug de Software', 'Erro Humano', 'Falha de Hardware'). Geralmente é um campo personalizado no JSM.

Este atributo alimenta o dashboard de 'Distribuição de Categorias de Causa Raiz', auxiliando em decisões estratégicas sobre investimentos em infraestrutura ou treinamento para evitar reincidências.

Por que é importante

Chave para identificar problemas sistêmicos e orientar medidas preventivas.

Onde obter

Campo personalizado 'Root Cause' ou 'Root Cause Category'

Exemplos
Bug de softwareErro de configuraçãoProblema de CapacidadeProblema de Fornecedor
Grupo de suporte atribuído
SupportGroup
A equipe técnica ou grupo atualmente designado para investigar o problema.
Descrição

Identifica a equipe responsável pelo problema no momento do evento. No JSM, costuma ser mapeado para 'Componente' ou um campo personalizado como 'Grupo de Suporte'.

Atributo vital para o dashboard de 'Gargalos de Repasse entre Grupos de Suporte', permitindo visualizar como os problemas circulam e onde ficam parados por mais tempo.

Por que é importante

Essencial para mining organizacional e para identificar atritos entre equipes.

Onde obter

Campo de ticket 'Component' ou campo personalizado 'Support Group'

Exemplos
Administração de Banco de DadosOp. de RedeSuporte de Aplicação Nível 2
Prioridade
Priority
O nível de criticidade atribuído ao registro do problema.
Descrição

Indica a urgência e o impacto (geralmente de 'Baixo' a 'Crítico'). Segmenta a análise para garantir que problemas de alta prioridade sejam resolvidos no prazo.

Ajuda no dashboard de 'Conformidade de SLA e Tendências de Metas' a verificar se os riscos críticos estão sendo priorizados corretamente.

Por que é importante

Permite segmentar o desempenho do processo pela criticidade do negócio.

Onde obter

Campo de ticket 'Priority'

Exemplos
Mais altaAltoMédioBaixo
Resumo do Problema
ProblemSummary
A descrição breve ou o título do registro de problema.
Descrição

Contém o resumo (headline) do registro de problema. Embora seja textual, fornece contexto para os analistas dentro da ferramenta de Process Mining.

Permite buscas por palavras-chave e análise qualitativa dos tipos de problemas registrados.

Por que é importante

Fornece um contexto legível para o identificador do caso.

Onde obter

Campo de ticket 'Summary'

Exemplos
Timeout de conexão com banco de dados na região EUPico de latência no serviço de e-mailFila de processamento de pedidos travada
Utilizador
UserKey
O identificador único ou nome do usuário que realizou a atividade.
Descrição

Captura a identidade da pessoa ou conta de sistema que executou a atividade. Pode ser o 'Responsável' atualizando o ticket ou o 'Autor' de uma mudança de status.

Estes dados são usados para analisar a utilização de recursos, identificar gargalos de repasse entre usuários e garantir a responsabilidade no processo de gestão de problemas.

Por que é importante

Fundamental para analisar repasses, segregação de funções e carga de trabalho.

Onde obter

Campo 'author' no changelog do Jira ou campo 'assignee' no ticket

Exemplos
j.smithsystem_automationm.silva
Change Request Vinculada
LinkedChangeRequest
O identificador da solicitação de mudança vinculada a este problema.
Descrição

Armazena o ID da Solicitação de Mudança (RFC) criada para aplicar a correção definitiva. Este vínculo é vital para o dashboard de atraso na abertura de mudanças.

Ele conecta a Gestão de Problemas à Gestão de Mudanças, permitindo análises entre diferentes processos.

Por que é importante

Conecta a investigação à remediação no processo de Gestão de Mudanças.

Onde obter

Links de ticket onde o tipo é 'é corrigido por' ou similar

Exemplos
CR-404CHG-1099CR-5512
Código de resolução
ResolutionCode
O código que indica como o problema foi resolvido.
Descrição

Especifica o resultado final do registro do problema, como 'Corrigido', 'Não será corrigido', 'Duplicado' ou 'Incapaz de reproduzir'.

Isso é usado para filtrar problemas resolvidos com sucesso daqueles fechados por motivos administrativos, garantindo que os cálculos de KPI, como o 'Tempo Médio para Causa Raiz', sejam precisos.

Por que é importante

Distingue entre correções eficazes e fechamentos administrativos.

Onde obter

Campo de ticket 'Resolution'

Exemplos
ConcluídoNão será feitoDuplicadoNão é possível reproduzir
Contagem de Incidentes Vinculados
LinkedIncidentCount
O número de incidentes vinculados a este registro de problema.
Descrição

Contagem de tickets de incidentes associados ao registro de problema. Atributo que quantifica o impacto do problema na base de usuários.

É usado no KPI de 'Profundidade de Vínculo entre Incidente e Problema' para priorizar problemas que geram maior volume de chamados.

Por que é importante

Quantifica o impacto no negócio com base no volume de incidentes.

Onde obter

Contagem de links na tabela 'issuelinks' onde o tipo é 'Problema/Incidente'

Exemplos
011550
Data de Criação
CreatedDate
A data em que o registro do problema foi criado.
Descrição

O timestamp de quando o problema foi registrado no sistema. Enquanto o timestamp do evento cuida do tempo das atividades, este atributo é usado para filtros de alto nível (ex: 'problemas criados no 1º trimestre').

Ele serve como âncora para análises de envelhecimento (aging).

Por que é importante

Data de referência para análise de envelhecimento (aging) e volume de entrada.

Onde obter

Campo de ticket 'Created'

Exemplos
01/01/20232023-06-15
Duração da Investigação
InvestigationDuration
Tempo decorrido do registro do problema até a identificação da causa raiz.
Descrição

Calcula o tempo entre a criação do registro e o momento da 'Causa Raiz Identificada'. É a principal métrica do dashboard de 'Análise do Tempo de Ciclo de Investigação'.

Ajuda gestores a identificar problemas complexos que travaram a equipe ou falta de recursos na fase de diagnóstico.

Por que é importante

Métrica principal para medir a eficiência da fase de análise de causa raiz.

Onde obter

Calculado a partir dos timestamps dos eventos

Exemplos
48 horas5 dias30 minutos
Origem da Detecção
DetectionSource
Como o problema foi identificado (ex: Proativo, Reativo).
Descrição

Indica a origem da identificação do problema (ex: 'Monitoramento Proativo', 'Incidente de Service Desk', 'Notificação de Fornecedor').

Usado no dashboard 'Identificação Proativa vs Reativa' para medir a maturidade da gestão de problemas.

Por que é importante

Mede a maturidade do processo e a eficácia dos sistemas de monitoramento.

Onde obter

Campo personalizado 'Source' ou 'Detection Source'

Exemplos
Monitoramento ProativoEscalonamento de IncidenteNotificação de Fornecedor
PIR Realizada
ReviewStatus
Indica se uma Revisão Pós-Implementação (PIR) foi realizada.
Descrição

Verifica se a atividade ou flag de 'Revisão Pós-Implementação' está presente no caso. Essencial para o dashboard de conformidade de PIR.

Garante que a organização esteja seguindo os requisitos de governança para melhoria contínua.

Por que é importante

Métrica de conformidade para o aprendizado organizacional.

Onde obter

Campo personalizado 'PIR Status' ou existência da atividade 'PIR'

Exemplos
ConcluídoPendenteNão Requerido
Reaberto
IsReopened
Sinalizador que indica se o problema foi reaberto após o fechamento.
Descrição

Um sinalizador booleano definido como verdadeiro se o registro de problema voltou de um estado fechado para um aberto. Isso alimenta a 'Análise da Taxa de Reabertura de Problemas'.

Altas taxas de reabertura indicam problemas de qualidade nas correções definitivas ou procedimentos de verificação ineficazes.

Por que é importante

Indicador de qualidade para a eficácia das correções.

Onde obter

Derivado de transições de status

Exemplos
verdadeirofalse
Reportante
ReporterName
O usuário que registrou originalmente o problema.
Descrição

Identifica quem criou o registro do problema. É diferente do responsável técnico. Analisar o relator ajuda a entender onde os problemas estão sendo detectados (ex: Agentes de Service Desk vs. Admins de Sistema).

Isso adiciona contexto para a análise 'Proativo vs Reativo'.

Por que é importante

Identifica a fonte de entrada do problema.

Onde obter

Campo de ticket 'Reporter'

Exemplos
servico_monitoramentolider_helpdeskadmin_rede
Status de Violação de SLA
SlaBreachStatus
Indica se o registro de problema violou seu SLA.
Descrição

Um campo booleano ou de status que indica se o tempo de resolução excedeu a meta acordada. Útil para o dashboard de 'Conformidade de SLA e Tendências de Metas'.

Destaca casos que expõem a empresa a riscos de conformidade ou penalidades.

Por que é importante

Essencial para monitoramento de desempenho e conformidade.

Onde obter

Lógica do campo de SLA do Jira Service Management

Exemplos
AtingidoVioladoPausado
Workaround Disponível
WorkaroundDetails
Indica se uma solução de contorno foi documentada para o problema.
Descrição

Captura se existe ou foi publicada uma solução de contorno (workaround). Isso permite que a empresa acompanhe a 'Velocidade de Publicação de Solução de Contorno'.

A análise deste campo ajuda a determinar a rapidez com que a equipe consegue restabelecer a estabilidade, mesmo antes de uma correção definitiva.

Por que é importante

Chave para medir a velocidade do alívio temporário fornecido ao negócio.

Onde obter

Campo personalizado 'Workaround'

Exemplos
Reiniciar o serviçoLimpar cache do navegadorNenhum fornecido
Obrigatório Recomendado Opcional

Atividades de Gestão de Problemas

Estes são os principais passos e marcos do processo para capturar no seu Event Log para uma descoberta precisa dos seus workflows de resolução.
8 Recomendado 6 Opcional
Atividade Descrição
Atribuído ao Grupo de Suporte
A atribuição do registro do problema a uma equipe técnica ou grupo de suporte específico. Isso é monitorado por alterações no campo customizado 'Grupo de Suporte' ou no campo 'Responsável'.
Por que é importante

Crítico para analisar repasses e gargalos entre times. Altas taxas de transferência podem indicar ineficiência no roteamento.

Onde obter

Histórico do Jira: Campo 'Support Group' ou 'Assignee' alterado

Captura

Registrado quando o campo de atribuição é alterado

Tipo de evento explicit
Causa raiz identificada
O momento em que a causa subjacente é registrada formalmente. Isso é inferido por uma mudança para 'Causa Raiz Identificada' ou pelo preenchimento do campo 'Causa Raiz'.
Por que é importante

Um marco importante que encerra a fase de investigação. Essencial para calcular o 'Tempo Médio para Descoberta da Causa Raiz'.

Onde obter

Histórico do Jira: Status alterado para 'Root Cause Identified' OU campo 'Root Cause' preenchido

Captura

Comparar campo de status ou verificar preenchimento de campo

Tipo de evento inferred
Incidente Vinculado ao Problema
A ação de vincular um ticket de Incidente relacionado ao registro de Problema. Isso é capturado na tabela de links ou no histórico do ticket.
Por que é importante

Determina o impacto e o escopo do problema. Essencial para o KPI de 'Profundidade de Vínculo entre Incidente e Problema' e para a priorização baseada em impacto.

Onde obter

Links do Jira: Link criado com tipo 'causes' ou 'relates to'

Captura

Registrado quando um link de ticket é criado

Tipo de evento explicit
Investigação Iniciada
A mudança do status do problema para um estado de investigação ativa (ex: 'Sob Investigação' ou 'Em Andamento'). Isso marca o início da fase de trabalho ativo.
Por que é importante

Inicia o cronômetro para o tempo de ciclo da investigação. Ajuda a distinguir entre o tempo de espera no backlog e o tempo de análise ativa de fato.

Onde obter

Histórico do Jira: Status alterado para 'Under Investigation' ou 'In Progress'

Captura

Comparar atualizações de campos de status

Tipo de evento inferred
Registro de Problema Criado
O evento inicial onde o ticket de Problema é criado no sistema. Isso é capturado explicitamente no histórico do ticket como o timestamp de criação.
Por que é importante

Marca o início do ciclo de vida da gestão de problemas e permite análise de volume. Essencial para calcular a vazão (throughput) e as taxas de entrada.

Onde obter

Tabela de tickets do Jira: Timestamp da Created Date ou aba de Histórico: evento Issue Created

Captura

Registrado quando a transação de criação do ticket é confirmada

Tipo de evento explicit
Registro de Problema Fechado
O encerramento final do ciclo de vida do problema. Capturado explicitamente quando o status muda para 'Fechado'.
Por que é importante

O encerramento definitivo da instância do processo. Necessário para calcular o tempo de ciclo total e as taxas de fechamento.

Onde obter

Histórico do Jira: Status alterado para 'Closed'

Captura

Registrado quando o status transita para Closed

Tipo de evento explicit
Resolução Verificada
A confirmação de que a correção resolveu o problema de forma eficaz. Inferido a partir de uma transição para 'Resolvido' ou um estado específico de 'Verificado'.
Por que é importante

Portão de qualidade para garantir que a correção funciona. Atrasos nesta fase indicam gargalos em testes ou aceitação do usuário.

Onde obter

Histórico do Jira: Status alterado para 'Resolved' ou 'Verified'

Captura

Comparar atualizações de campos de status

Tipo de evento inferred
Workaround Atualizado
O preenchimento ou atualização do campo de texto 'Workaround'. Este evento indica que uma correção temporária foi documentada.
Por que é importante

Mede a velocidade em fornecer alívio ao negócio. Crítico para o KPI de 'Lead Time de Disponibilidade de Solução de Contorno'.

Onde obter

Histórico do Jira: Campo 'Workaround' alterado (não nulo)

Captura

Registrado quando o campo Workaround é modificado

Tipo de evento explicit
Change Request Vinculada
A vinculação de uma Solicitação de Mudança (RFC) ao registro de Problema. Isso indica o início do processo de correção definitiva.
Por que é importante

Mede o atraso entre identificar a causa e iniciar a remediação. Alimenta o KPI de 'Atraso na Transição para Gestão de Mudanças'.

Onde obter

Links do Jira: Link criado com tipo 'is fixed by' ou vinculando ao tipo de ticket 'Change'

Captura

Registrado quando um link para um ticket do tipo Change é criado

Tipo de evento explicit
Correção Definitiva Aplicada
A transição que indica que a solução foi implementada. Geralmente inferida por uma mudança de status para 'Implementando' ou 'Corrigido'.
Por que é importante

Marca o fim do trabalho técnico de remediação. Usado para medir o tempo do ciclo de implementação.

Onde obter

Histórico do Jira: Status alterado para 'Implemented', 'Pending Verification' ou 'Fixed'

Captura

Comparar atualizações de campos de status

Tipo de evento inferred
Prioridade do Problema Alterada
Uma atualização no campo de Prioridade do registro de problema. É capturada monitorando as mudanças no campo 'Prioridade' na aba de histórico.
Por que é importante

Indica escalonamento ou desescalonamento do ticket. Ajuda a identificar a precisão da triagem inicial e o envelhecimento (aging) do backlog de alta prioridade.

Onde obter

Histórico do Jira: Campo 'Priority' alterado de Valor Antigo para Novo Valor

Captura

Registrado quando o campo Priority é atualizado

Tipo de evento explicit
Problema Reaberto
A transição de um problema de 'Resolvido' ou 'Fechado' de volta para um status ativo. Indica uma correção que falhou ou uma resolução rejeitada.
Por que é importante

Uma métrica de qualidade primária. Altas taxas de reabertura indicam testes ou análises de causa raiz ineficazes.

Onde obter

Histórico do Jira: Status alterado de 'Closed'/'Resolved' para 'Open'/'In Progress'

Captura

Comparar sequência de campos de status

Tipo de evento inferred
Revisão Pós-Implementação
A execução de uma revisão após a aplicação da correção. Capturada via mudança de status para 'Em Revisão' ou atualizações em campos específicos de PIR.
Por que é importante

Atividade de conformidade que garante a captura de lições aprendidas. Apoia a análise de 'Conformidade de Revisão Pós-Implementação'.

Onde obter

Histórico do Jira: Status alterado para 'In Review' OU campo 'PIR Notes' atualizado

Captura

Comparar campo de status ou atualizações de campos de PIR

Tipo de evento inferred
SLA Violado
Um evento que indica que o tempo de resolução do problema excedeu o SLA definido. É calculado comparando a data limite do SLA com a data de resolução real.
Por que é importante

Vital para relatórios de compliance. Ajuda a identificar quais prioridades ou categorias perdem prazos com mais frequência.

Onde obter

Logs de SLA do JSM: 'Time to Resolution' > Target, ou calculado

Captura

Derivar de dados do campo de SLA ou comparar Data Limite com Data de Resolução

Tipo de evento calculated
Recomendado Opcional

Guias de Extração

Como obter seus dados do Jira Service Management