Seu Template de Dados de Gestão de Problemas
Seu Template de Dados de Gestão de Problemas
- Atributos recomendados para análise profunda
- Marcos do processo para capturar no seu Event Log
- Orientação técnica para extração de dados
Atributos de Gestão de Problemas
| 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 identificadaSolução de Contorno AtualizadaRegistro 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.doe
|
|||
|
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
2023-01-012023-06-15
|
|||
|
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
|
|||
|
Requisição de Mudança 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
|
|||
|
Solução de Contorno 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
|
|||
|
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
|
|||
Atividades de Gestão de Problemas
| 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
|
|||
|
Solução de Contorno Atualizada
|
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
|
|||
|
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
|
|||
|
Requisição de Mudança 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
|
|||
|
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
|
|||