Seu Template de dados de Problem Management
Seu Template de dados de Problem Management
- Atributos recomendados para uma análise aprofundada
- Marcos do processo a capturar no seu Event Log
- Orientações técnicas para extração de dados
Atributos do gerenciamento de problemas
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
A ação específica ou a mudança de status ocorrida no registro de problema. | ||
|
Descrição
Esse atributo captura o nome do evento ou da transição de estado que ocorre durante o ciclo de vida do gerenciamento de problemas. Os exemplos incluem 'Problem Logged', 'Status Changed to Investigating' ou 'Root Cause Identified'. Ele é essencial para mapear o fluxo do processo e identificar a sequência de etapas realizadas para resolver um problema. No process mining, essas atividades formam os nós do mapa do processo.
Por que isso importa
Define as etapas do mapa do processo e permite analisar as variantes do processo.
Onde obter
Changelog do Jira (Histórico) ou transições de status do chamado
Exemplos
Registro de problema criadoInvestigação iniciadaCausa raiz identificadaSolução alternativa atualizadaRegistro de problema encerrado
|
|||
|
Registro de data e hora
EventTimestamp
|
A data e a hora exatas em que a atividade ocorreu. | ||
|
Descrição
Esse atributo registra o momento preciso em que uma atividade ocorreu. Ele é usado para ordenar os eventos cronologicamente e calcular as durações entre as etapas. Registros de data e hora precisos são essenciais para calcular tempos de ciclo, como o tempo entre 'Problem Logged' e 'Root Cause Identified', e para analisar o throughput ao longo do tempo.
Por que isso importa
Permite calcular todos os KPIs baseados em tempo e ordenar corretamente os eventos.
Onde obter
Data de criação do Changelog do Jira ou data de criação do chamado
Exemplos
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
|
|||
|
Registro de problema
ProblemKey
|
O identificador exclusivo atribuído ao registro de problema no Jira Service Management. | ||
|
Descrição
Esse atributo funciona como o identificador central do caso para a análise de process mining. Ele representa a chave exclusiva, por exemplo, PM-1001, gerada pelo Jira Service Management quando um novo registro de problema é criado. Ele é usado para agrupar todas as atividades, mudanças de status e atualizações relacionadas em uma única instância de processo de ponta a ponta. Analisar esse atributo permite visualizar o ciclo de vida completo de um problema, desde a detecção inicial, passando pela investigação, até o encerramento final.
Por que isso importa
É a chave fundamental necessária para reconstruir o fluxo do processo e acompanhar registros de problemas específicos.
Onde obter
Tabela de chamados, campo 'Key' ou 'Issue Key'
Exemplos
PM-1023PM-4099PRB-3321PM-5001
|
|||
|
Sistema de origem
SourceSystem
|
O nome do sistema de onde os dados foram originados. | ||
|
Descrição
Identifica o sistema de software do qual os dados do processo foram extraídos. Nesse contexto, o valor é sempre 'Jira Service Management'. Esse atributo é especialmente útil em ambientes com vários sistemas para distinguir as fontes de dados. Nesta visualização específica, porém, ele serve principalmente como um identificador estático da linhagem dos dados.
Por que isso importa
Fornece contexto sobre a origem dos dados, especialmente quando eles são combinados com outros dados de IT Service Management.
Onde obter
Definido no código ou na configuração do sistema
Exemplos
Jira Service ManagementJira CloudJSM-Prod
|
|||
|
Última atualização dos dados
LastDataUpdate
|
O registro de data e hora em que os dados foram extraídos ou atualizados pela última vez. | ||
|
Descrição
Indica quando o conjunto de dados foi sincronizado pela última vez com o ambiente ativo do Jira Service Management. Isso garante que os analistas entendam o nível de atualização dos dados. Ele é usado para validar se a análise reflete o estado mais atual do processo e para identificar possíveis problemas de latência dos dados.
Por que isso importa
Garante a atualização dos dados e ajuda a aumentar a confiança nos resultados da análise.
Onde obter
Registro de data e hora do 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 que causou o problema, como 'Software Bug', 'Human Error' ou 'Hardware Failure'. Geralmente, esse é um campo personalizado no Jira Service Management. Esse atributo dá suporte ao Dashboard 'Root Cause Category Distribution', permitindo decisões estratégicas sobre onde investir em infraestrutura ou treinamento para evitar recorrências.
Por que isso importa
Fundamental 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 com fornecedor
|
|||
|
Grupo de suporte atribuído
SupportGroup
|
A equipe técnica ou o grupo atualmente responsável por investigar o problema. | ||
|
Descrição
Identifica a equipe específica responsável pelo registro do problema no momento do evento. No Jira Service Management, geralmente é mapeado para 'Component' ou para um campo personalizado, como 'Support Group'. Esse atributo é essencial para o Dashboard 'Support Group Handover Bottlenecks', permitindo que os analistas visualizem como os problemas passam de uma equipe para outra e onde permanecem por mais tempo.
Por que isso importa
Essencial para o organizational mining e para identificar atritos entre equipes.
Onde obter
Campo 'Component' da issue ou campo personalizado 'Support Group'
Exemplos
Administração de banco de dadosOperações de redeSuporte de aplicações 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 do problema, geralmente variando de 'Low' a 'Critical'. Esse campo é usado para segmentar a análise e garantir que os problemas de alta prioridade sejam resolvidos dentro das metas de SLA. A análise desse atributo ajuda no Dashboard 'SLA Compliance and Target Trends' a verificar se os riscos críticos para o negócio estão sendo priorizados corretamente.
Por que isso importa
Permite segmentar a performance do processo de acordo com a criticidade para o negócio.
Onde obter
Campo 'Priority' da issue
Exemplos
Mais altoAltoMédioBaixo
|
|||
|
Resumo do problema
ProblemSummary
|
A descrição curta ou o título do registro do problema. | ||
|
Descrição
Contém o resumo principal do registro do problema. Embora seja predominantemente textual, fornece contexto para os analistas que revisam casos individuais na ferramenta de Process Mining. Permite pesquisar por palavras-chave e fazer uma análise qualitativa dos tipos de problemas registrados.
Por que isso importa
Fornece um contexto legível para o identificador do caso.
Onde obter
Campo 'Summary' da issue
Exemplos
Tempo limite de conexão do banco de dados na região da UEPico de latência no serviço de e-mailFila de processamento de pedidos travada
|
|||
|
Usuário
UserKey
|
O identificador exclusivo ou o nome do usuário que executou a atividade. | ||
|
Descrição
Captura a identidade da pessoa ou da conta de sistema responsável por executar a atividade específica. Pode ser o 'Assignee' que atualizou o registro ou o 'Author' de uma mudança de status. Esses dados são usados para analisar a utilização dos recursos, identificar gargalos nas transferências entre usuários e garantir a responsabilização dentro do processo de gerenciamento de problemas.
Por que isso importa
Essencial para analisar transferências, segregação de funções e carga de trabalho dos recursos.
Onde obter
Campo 'author' do Jira no changelog ou campo 'assignee' na issue
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 'Fixed', 'Won't Fix', 'Duplicate' ou 'Cannot Reproduce'. É usado para filtrar problemas resolvidos com sucesso daqueles encerrados por motivos administrativos, garantindo que os cálculos de KPI, como 'Mean Time to Root Cause', sejam precisos.
Por que isso importa
Diferencia correções efetivas de encerramentos administrativos.
Onde obter
Campo 'Resolution' da issue
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 dos tickets de incidente associados ao registro do problema. Esse atributo quantifica o impacto do problema sobre a base de usuários. É usado no KPI 'Incident to Problem Linkage Depth' para priorizar os problemas que estão gerando o maior volume de tickets de suporte.
Por que isso importa
Quantifica o impacto no negócio com base no volume de incidentes.
Onde obter
Contagem de links na tabela 'issuelinks' cujo tipo é 'Problem/Incident'
Exemplos
011550
|
|||
|
Data de criação
CreatedDate
|
A data em que o registro do problema foi criado. | ||
|
Descrição
O timestamp em que o problema foi registrado pela primeira vez no sistema. Embora o timestamp do evento controle o momento da atividade, esse atributo específico costuma ser usado para filtros de alto nível, como 'Mostrar todos os problemas criados no primeiro trimestre'. Serve como ponto de referência para a análise de envelhecimento.
Por que isso importa
Data de referência para análises de envelhecimento e volume de entradas.
Onde obter
Campo 'Created' da issue
Exemplos
2023-01-012023-06-15
|
|||
|
Foi reaberto
IsReopened
|
Indicador que informa se o problema foi reaberto após o encerramento. | ||
|
Descrição
Indicador booleano definido como true quando o registro do problema passa de um estado fechado novamente para um estado aberto. Dá suporte à 'Problem Reopened Rate Analysis'. Taxas altas de reabertura indicam problemas de qualidade nas correções permanentes ou procedimentos de verificação insuficientes.
Por que isso importa
Indicador de qualidade da eficácia das correções.
Onde obter
Derivado das transições de status
Exemplos
truefalse
|
|||
|
Fonte de detecção
DetectionSource
|
Como o problema foi identificado, por exemplo, de forma proativa ou reativa. | ||
|
Descrição
Indica a origem da identificação do problema. Os valores comuns incluem 'Proactive Monitoring', 'Service Desk Incident' ou 'Vendor Notification'. Esse atributo é usado no Dashboard 'Proactive vs Reactive Identification' para medir a maturidade do processo de gerenciamento de problemas.
Por que isso importa
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 ao fornecedor
|
|||
|
PIR realizada
ReviewStatus
|
Indica se foi realizada uma Post Implementation Review (PIR). | ||
|
Descrição
Acompanha se a atividade ou o indicador 'Post Implementation Review' está presente no caso. É essencial para o Dashboard 'Post Implementation Review Compliance'. Garante que a organização esteja cumprindo os requisitos de governança para a melhoria contínua.
Por que isso importa
Métrica de conformidade para o aprendizado organizacional.
Onde obter
Campo personalizado 'PIR Status' ou existência da atividade 'PIR'
Exemplos
ConcluídoPendenteNão necessário
|
|||
|
Relator
ReporterName
|
O usuário que registrou originalmente o problema. | ||
|
Descrição
Identifica a pessoa que criou o registro do problema. É diferente do responsável atribuído. A análise dos relatores ajuda a entender onde os problemas estão sendo detectados, por exemplo, por agentes do Service Desk ou administradores de sistemas. Isso acrescenta contexto à análise 'Proactive vs Reactive'.
Por que isso importa
Identifica a origem da entrada do problema.
Onde obter
Campo 'Reporter' da issue
Exemplos
monitoring_servicehelpdesk_leadnetwork_admin
|
|||
|
Solicitação de mudança vinculada
LinkedChangeRequest
|
O identificador da solicitação de mudança vinculada a este problema. | ||
|
Descrição
Armazena o ID da Change Request (RFC) criada para implementar a correção permanente. Esse vínculo é essencial para o Dashboard 'Change Request Initiation Lag'. Conecta o processo de Problem Management ao Change Management, permitindo uma análise entre processos.
Por que isso importa
Conecta a investigação à correção no processo de Change Management.
Onde obter
Links da issue cujo tipo é 'is fixed by' ou semelhante
Exemplos
CR-404CHG-1099CR-5512
|
|||
|
Solução alternativa disponível
WorkaroundDetails
|
Indica se uma solução alternativa foi documentada para o problema. | ||
|
Descrição
Registra se existe ou foi publicado um texto com uma solução alternativa temporária. Isso permite acompanhar a 'Workaround Publication Speed'. A análise desse campo ajuda a determinar com que rapidez a equipe consegue restabelecer a estabilidade do serviço, mesmo antes de encontrar uma correção permanente.
Por que isso importa
Fundamental para medir a velocidade do alívio temporário oferecido ao negócio.
Onde obter
Campo personalizado 'Workaround'
Exemplos
Reiniciar o serviçoLimpar o cache do navegadorNenhuma informação fornecida
|
|||
|
Status de violação do SLA
SlaBreachStatus
|
Indica se o registro do problema violou o acordo de nível de serviço. | ||
|
Descrição
Campo booleano ou de status que indica se o tempo de resolução ultrapassou a meta acordada. Ele ajuda no Dashboard 'SLA Compliance and Target Trends'. Destaca os casos que expõem a organização a riscos de conformidade ou penalidades.
Por que isso importa
Essencial para monitorar a conformidade e a performance.
Onde obter
Lógica do campo de SLA do Jira Service Management
Exemplos
Dentro do prazoFora do prazoPausado
|
|||
Atividades de gerenciamento de problemas
| Atividade | Descrição | ||
|---|---|---|---|
|
Atribuído ao grupo de suporte
|
A atribuição do registro de problema a uma equipe técnica ou grupo de suporte específico. Isso é acompanhado por meio de alterações no campo personalizado 'Support Group' ou no campo 'Assignee', caso grupos não sejam usados. | ||
|
Por que isso importa
É essencial para analisar transferências e gargalos entre equipes. Taxas elevadas de transferência podem indicar ineficiências no roteamento.
Onde obter
Histórico do chamado no 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 a partir de uma mudança de status para 'Root Cause Identified' ou do preenchimento do campo 'Root Cause'. | ||
|
Por que isso importa
Um marco importante que encerra a fase de investigação. É essencial para calcular o 'Tempo médio até a descoberta da causa raiz'.
Onde obter
Histórico do chamado no Jira: status alterado para 'Root Cause Identified' OU campo 'Root Cause' preenchido
Captura
Compare o campo de status ou verifique se o campo foi preenchido
Tipo de evento
inferred
|
|||
|
Incidente vinculado ao problema
|
A ação de vincular um chamado de incidente relacionado ao registro de problema. Isso é capturado na tabela de links de chamados ou no histórico. | ||
|
Por que isso importa
Determina o impacto e o escopo do problema. É essencial para o KPI 'Profundidade do vínculo entre incidente e problema' e para priorizar com base no impacto no negócio.
Onde obter
Links de chamados do Jira: link criado com o tipo 'causes' ou 'relates to'
Captura
Registrado quando um link de chamado é criado
Tipo de evento
explicit
|
|||
|
Investigação iniciada
|
A transição do status do problema para um estado de investigação ativa, como 'Under Investigation' ou 'In Progress'. Isso marca o início da fase de trabalho ativo. | ||
|
Por que isso importa
Inicia a contagem do tempo do ciclo de investigação. Ajuda a distinguir o tempo de espera no backlog do tempo de análise efetivamente ativo.
Onde obter
Histórico do chamado no Jira: status alterado para 'Under Investigation' ou 'In Progress'
Captura
Compare as atualizações do campo de status
Tipo de evento
inferred
|
|||
|
Registro de problema criado
|
O evento inicial em que o chamado de problema é criado no sistema. Ele é capturado explicitamente no histórico do chamado como o registro de data e hora da criação. | ||
|
Por que isso importa
Marca o início do ciclo de vida do gerenciamento de problemas e permite analisar o volume. É essencial para calcular o throughput e as taxas de entrada.
Onde obter
Tabela de chamados do Jira: registro de data e hora da data de criação ou aba Histórico: evento de chamado criado
Captura
Registrado quando a transação de criação do chamado é confirmada
Tipo de evento
explicit
|
|||
|
Registro de problema encerrado
|
A finalização do ciclo de vida do problema. É capturada explicitamente quando o status muda para 'Closed'. | ||
|
Por que isso importa
O fim definitivo da instância do processo. É necessário para calcular o tempo total do ciclo e as taxas de encerramento.
Onde obter
Histórico do chamado no Jira: status alterado para 'Closed'
Captura
Registrado quando o status muda para Closed
Tipo de evento
explicit
|
|||
|
Resolução verificada
|
A confirmação de que a correção resolveu o problema de forma eficaz. É inferida a partir de uma transição de status para 'Resolved' ou para um estado específico de 'Verified'. | ||
|
Por que isso importa
Uma etapa de controle de qualidade que garante o funcionamento da correção. Atrasos aqui indicam gargalos nos testes ou na aceitação do usuário.
Onde obter
Histórico do chamado no Jira: status alterado para 'Resolved' ou 'Verified'
Captura
Compare as atualizações do campo de status
Tipo de evento
inferred
|
|||
|
Solução alternativa atualizada
|
O preenchimento ou a atualização do campo de texto 'Workaround'. Esse evento indica que uma correção temporária foi documentada. | ||
|
Por que isso importa
Mede a velocidade com que o negócio recebe alívio. É essencial para o KPI 'Lead time de disponibilidade da solução alternativa'.
Onde obter
Histórico do chamado no Jira: campo 'Workaround' alterado (não nulo)
Captura
Registrado quando o campo Workaround é modificado
Tipo de evento
explicit
|
|||
|
Correção permanente aplicada
|
A transição que indica que a solução foi implementada. Normalmente, ela é inferida a partir de uma mudança de status para 'Implementing' ou 'Fixed'. | ||
|
Por que isso importa
Marca o fim do trabalho de remediação técnica. É usada para medir o tempo do ciclo de implementação.
Onde obter
Histórico do chamado no Jira: status alterado para 'Implemented', 'Pending Verification' ou 'Fixed'
Captura
Compare as atualizações do campo de status
Tipo de evento
inferred
|
|||
|
Prioridade do problema alterada
|
Uma atualização no campo Prioridade do registro de problema. Isso é capturado monitorando a aba de histórico em busca de alterações no campo 'Priority'. | ||
|
Por que isso importa
Indica a escalação ou desescalação do problema. Analisar esse evento ajuda a identificar a precisão da triagem inicial e o envelhecimento do backlog de alta prioridade.
Onde obter
Histórico do chamado no Jira: campo 'Priority' alterado de valor antigo para valor novo
Captura
Registrado quando o campo Priority é atualizado
Tipo de evento
explicit
|
|||
|
Problema reaberto
|
A transição de um problema do status 'Resolved' ou 'Closed' de volta para um status ativo. Indica uma correção malsucedida ou uma resolução rejeitada. | ||
|
Por que isso importa
Uma métrica de qualidade essencial. Taxas elevadas de reabertura indicam análise de causa raiz ou testes ineficazes.
Onde obter
Histórico do chamado no Jira: status alterado de 'Closed'/'Resolved' para 'Open'/'In Progress'
Captura
Compare a sequência do campo 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 por meio de uma mudança de status para 'In Review' ou de atualizações em campos específicos da PIR. | ||
|
Por que isso importa
Atividade de conformidade que garante o registro das lições aprendidas. Apoia a análise de 'Conformidade da revisão pós-implementação'.
Onde obter
Histórico do chamado no Jira: status alterado para 'In Review' OU campo 'PIR Notes' atualizado
Captura
Compare o campo de status ou as atualizações dos campos da PIR
Tipo de evento
inferred
|
|||
|
SLA violado
|
Um evento que indica que o tempo de resolução do problema excedeu o Acordo de Nível de Serviço definido. Isso é calculado comparando a data-alvo do SLA com a data de resolução. | ||
|
Por que isso importa
É essencial para os relatórios de conformidade. Ajuda a identificar quais prioridades ou categorias deixam de cumprir as metas com mais frequência.
Onde obter
Logs de SLA do Jira Service Management: 'Time to Resolution' > meta, ou calculado
Captura
Derive dos dados do campo de SLA ou compare a data de vencimento com a data de resolução
Tipo de evento
calculated
|
|||
|
Solicitação de mudança vinculada
|
A vinculação de uma Request for Change (RFC) ao registro de problema. Isso indica o início do processo de correção permanente. | ||
|
Por que isso importa
Mede o intervalo entre a identificação da causa e o início da remediação. Apoia o KPI 'Atraso na transição do gerenciamento de mudanças'.
Onde obter
Links de chamados do Jira: link criado com o tipo 'is fixed by' ou vinculado ao tipo de chamado 'Change'
Captura
Registrado quando um link para um tipo de chamado Change é criado
Tipo de evento
explicit
|
|||
Guias de extração
Pronto para começar?
Transforme hoje seus dados de Problem Management em insights acionáveis. Baixe o guia ou entre em contato com nossa equipe de suporte para começar sua jornada de Process Mining.
Otimize hoje seu fluxo de Problem Management
Reduza os tempos de ciclo em 30% e estabilize seu ambiente de TI.
Não é necessário cartão de crédito. Configuração em minutos.