Seu Template de dados de gerenciamento de problemas
Seu Template de dados de gerenciamento de problemas
- Atributos recomendados para uma análise aprofundada
- Marcos do processo para registrar no Event Log
- Orientações técnicas para extração de dados
Atributos de 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 registra o nome do evento ou da transição de estado que ocorre durante o ciclo de vida da gestão de problemas. Alguns exemplos são 'Problema registrado', 'Status alterado para em investigação' ou 'Causa raiz identificada'. 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 encontrar
Histórico de alterações do Jira ou transições de status do chamado
Exemplos
Registro de problema criadoInvestigação iniciadaCausa raiz identificadaSolução temporária atualizadaRegistro de problema encerrado
|
|||
|
Data e hora
EventTimestamp
|
A data e a hora exatas em que a atividade ocorreu. | ||
|
Descrição
Esse atributo registra o momento exato em que uma atividade aconteceu. Ele é usado para ordenar os eventos cronologicamente e calcular a duração entre as etapas. Datas e horas precisas são essenciais para calcular tempos de ciclo, como o intervalo entre 'Problema registrado' e 'Causa raiz identificada', e para analisar a produtividade ao longo do tempo.
Por que isso importa
Permite calcular todos os KPIs baseados em tempo e ordenar os eventos corretamente.
Onde encontrar
Data de criação do histórico de alterações 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
|
Identificador exclusivo atribuído ao registro de problema no Jira Service Management. | ||
|
Descrição
Esse atributo funciona como o identificador central do caso na análise de Process Mining. Ele representa a chave exclusiva, como 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 do processo de ponta a ponta. A análise desse atributo permite visualizar todo o ciclo de vida de um problema, desde a detecção inicial, passando pela investigação, até o encerramento final.
Por que isso importa
É a chave fundamental para reconstruir o fluxo do processo e acompanhar registros de problemas específicos.
Onde encontrar
Tabela de chamados, campo 'Key' ou 'Issue Key'
Exemplos
PM-1023PM-4099PRB-3321PM-5001
|
|||
|
Sistema de origem
SourceSystem
|
Nome do sistema de onde os dados vieram. | ||
|
Descrição
Identifica o sistema de software do qual os dados do processo foram extraídos. Neste contexto, o valor é sempre 'Jira Service Management'. Esse atributo é especialmente útil em ambientes com vários sistemas para diferenciar as fontes de dados. Nesta visualização específica, porém, ele funciona 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 gestão de serviços de TI.
Onde encontrar
Valor definido diretamente ou configuração do sistema
Exemplos
Jira Service ManagementJira CloudJSM-Prod
|
|||
|
Última atualização dos dados
LastDataUpdate
|
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. Assim, os analistas podem avaliar se os dados estão atualizados. Esse campo ajuda a confirmar se a análise reflete o estado mais recente do processo e a identificar possíveis atrasos na atualização dos dados.
Por que isso importa
Ajuda a manter os dados atualizados e a confiar nos resultados da análise.
Onde encontrar
Data e hora do ETL
Exemplos
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
|
|||
|
Categoria da causa raiz
RootCauseCategory
|
Classificação da causa subjacente do problema. | ||
|
Descrição
Classifica a falha técnica ou de processo que causou o problema, como 'Erro de software', 'Erro humano' ou 'Falha de hardware'. Esse costuma ser um campo personalizado no Jira Service Management. Esse atributo alimenta o Dashboard 'Distribuição por categoria da causa raiz' e ajuda a tomar decisões estratégicas sobre investimentos em infraestrutura ou treinamento para evitar que o problema se repita.
Por que isso importa
Fundamental para identificar problemas sistêmicos e orientar medidas preventivas.
Onde encontrar
Campo personalizado 'Root Cause' ou 'Root Cause Category'
Exemplos
Erro de softwareErro de configuraçãoProblema de capacidadeProblema com fornecedor
|
|||
|
Grupo de suporte atribuído
SupportGroup
|
Equipe técnica ou grupo responsável por investigar o problema no momento. | ||
|
Descrição
Identifica a equipe responsável pelo registro do problema no momento do evento. No Jira Service Management, esse dado costuma ser associado ao campo 'Component' ou a um campo personalizado, como 'Support Group'. Esse atributo é essencial para o Dashboard 'Gargalos nas transferências entre grupos de suporte', que permite visualizar como os problemas passam de uma equipe para outra e onde ficam por mais tempo.
Por que isso importa
Essencial para analisar a organização e identificar atritos entre equipes.
Onde encontrar
Campo 'Component' da solicitação ou campo personalizado 'Support Group'
Exemplos
Administração de banco de dadosOperações de redeSuporte a aplicações nível 2
|
|||
|
Prioridade
Priority
|
Nível de criticidade atribuído ao registro do problema. | ||
|
Descrição
Indica a urgência e o impacto do problema, geralmente classificados de 'Baixa' a 'Crítica'. Esse campo permite segmentar a análise e verificar se os problemas de alta prioridade estão sendo resolvidos dentro das metas de SLA. A análise desse atributo ajuda a verificar, no Dashboard 'Conformidade com o SLA e tendências das metas', se os riscos críticos para o negócio estão recebendo a prioridade adequada.
Por que isso importa
Permite segmentar a performance do processo de acordo com a criticidade para o negócio.
Onde encontrar
Campo 'Priority' da solicitação
Exemplos
Mais altaAltaMédiaBaixa
|
|||
|
Resumo do problema
ProblemSummary
|
Descrição breve ou título do registro do problema. | ||
|
Descrição
Apresenta um resumo do registro do problema. Embora seja principalmente textual, fornece contexto para os analistas que consultam casos individuais na ferramenta de Process Mining. Também permite pesquisar palavras-chave e analisar qualitativamente os tipos de problemas registrados.
Por que isso importa
Fornece um contexto legível para o identificador do caso.
Onde encontrar
Campo 'Summary' da solicitação
Exemplos
Tempo limite de conexão com o 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
|
Identificador exclusivo ou nome do usuário que realizou a atividade. | ||
|
Descrição
Registra a identidade da pessoa ou da conta de sistema responsável por realizar a atividade específica. Pode ser o responsável que atualizou o registro ou o autor de uma mudança de status. Esses dados ajudam a analisar a utilização de recursos, identificar gargalos nas transferências entre usuários e garantir a responsabilização no 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 encontrar
Campo 'author' do changelog do Jira ou campo 'assignee' da solicitação
Exemplos
j.smithsystem_automationm.doe
|
|||
|
Código de resolução
ResolutionCode
|
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 'Não foi possível reproduzir'. Esse campo permite separar os problemas resolvidos com sucesso daqueles encerrados por motivos administrativos e manter a precisão de indicadores como 'Tempo médio até a causa raiz'.
Por que isso importa
Diferencia correções eficazes de encerramentos administrativos.
Onde encontrar
Campo 'Resolution' da solicitação
Exemplos
ConcluídoNão será feitoDuplicadoNão foi possível reproduzir
|
|||
|
Data de criação
CreatedDate
|
Data em que o registro do problema foi criado. | ||
|
Descrição
Data e hora em que o problema foi registrado pela primeira vez no sistema. Embora a data e hora do evento indiquem quando cada atividade ocorreu, esse atributo costuma ser usado em filtros de alto nível, como 'Mostrar todos os problemas criados no primeiro trimestre'. Ele serve como referência para a análise de envelhecimento.
Por que isso importa
Data de referência para analisar o envelhecimento e o volume de entrada.
Onde encontrar
Campo 'Created' da solicitação
Exemplos
2023-01-012023-06-15
|
|||
|
Foi reaberto
IsReopened
|
Indicador de que o problema foi reaberto após o encerramento. | ||
|
Descrição
Indicador booleano definido como verdadeiro quando o registro do problema passa do estado fechado para o estado aberto. Esse dado alimenta a 'Análise da taxa de reabertura de problemas'. Uma taxa alta de reabertura pode indicar problemas de qualidade nas correções definitivas ou procedimentos de verificação insuficientes.
Por que isso importa
Indicador de qualidade da eficácia das correções.
Onde encontrar
Derivado das mudanças de status
Exemplos
truefalse
|
|||
|
Origem da detecção
DetectionSource
|
Como o problema foi identificado (por exemplo, de forma proativa ou reativa). | ||
|
Descrição
Indica como o problema foi identificado. Entre os valores comuns estão 'Monitoramento proativo', 'Incidente na Central de serviços' e 'Notificação do fornecedor'. Esse atributo é usado no Dashboard 'Identificação proativa versus reativa' 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 encontrar
Campo personalizado 'Source' ou 'Detection Source'
Exemplos
Monitoramento proativoEscalonamento de incidenteNotificação do fornecedor
|
|||
|
Quantidade de incidentes vinculados
LinkedIncidentCount
|
Quantidade de incidentes vinculados a este registro do problema. | ||
|
Descrição
Contagem de chamados de incidente associados ao registro do problema. Esse atributo quantifica o impacto do problema sobre os usuários. Ele é usado no KPI 'Profundidade do vínculo entre incidente e problema' para priorizar os problemas que geram o maior volume de chamados de suporte.
Por que isso importa
Quantifica o impacto no negócio com base no volume de incidentes.
Onde encontrar
Contagem de vínculos na tabela 'issuelinks' cujo tipo é 'Problem/Incident'
Exemplos
011550
|
|||
|
Revisão pós-implementação realizada
ReviewStatus
|
Indica se foi realizada uma revisão pós-implementação (PIR). | ||
|
Descrição
Registra se a atividade ou o indicador 'Revisão pós-implementação' está presente no caso. Esse dado é essencial para o Dashboard 'Conformidade com a revisão pós-implementação'. Ele ajuda a garantir que a organização cumpra os requisitos de governança para a melhoria contínua.
Por que isso importa
Métrica de conformidade para o aprendizado organizacional.
Onde encontrar
Campo personalizado 'PIR Status' ou existência da atividade 'PIR'
Exemplos
ConcluídoPendenteNão necessário
|
|||
|
Solicitação de mudança vinculada
LinkedChangeRequest
|
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 implementar a correção definitiva. Esse vínculo é essencial para o Dashboard 'Atraso na abertura de solicitações de mudança'. Ele conecta o processo de gerenciamento de problemas ao gerenciamento de mudanças e permite analisar os dois processos em conjunto.
Por que isso importa
Conecta a investigação à correção no processo de gerenciamento de mudanças.
Onde encontrar
Vínculos da solicitação cujo tipo é 'is fixed by' ou semelhante
Exemplos
CR-404CHG-1099CR-5512
|
|||
|
Solicitante
ReporterName
|
Usuário que registrou o problema originalmente. | ||
|
Descrição
Identifica quem criou o registro do problema. Essa pessoa não é necessariamente o responsável pelo caso. A análise dos solicitantes ajuda a entender onde os problemas são detectados, por exemplo, por agentes da Central de serviços ou administradores de sistema. Esse dado complementa a análise 'Proativa versus reativa'.
Por que isso importa
Identifica a origem da entrada do problema.
Onde encontrar
Campo 'Reporter' da solicitação
Exemplos
monitoring_servicehelpdesk_leadnetwork_admin
|
|||
|
Solução alternativa disponível
WorkaroundDetails
|
Indica se há uma solução alternativa documentada para o problema. | ||
|
Descrição
Registra se existe ou foi publicada uma descrição de solução temporária. Isso permite acompanhar a 'Velocidade de publicação de soluções alternativas'. A análise desse campo ajuda a avaliar com que rapidez a equipe consegue restabelecer a estabilidade do serviço, mesmo antes de encontrar uma correção definitiva.
Por que isso importa
Fundamental para medir a rapidez com que o negócio recebe um alívio temporário.
Onde encontrar
Campo personalizado 'Workaround'
Exemplos
Reiniciar o serviçoLimpar o cache do navegadorNenhuma solução informada
|
|||
|
Status de violação do SLA
SlaBreachStatus
|
Indica se o registro do problema ultrapassou o prazo acordado no contrato 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. Esse dado ajuda a alimentar o Dashboard 'Conformidade com o SLA e tendências das metas'. Ele 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 encontrar
Lógica do campo de SLA do Jira Service Management
Exemplos
CumpridoVioladoPausado
|
|||
Atividades de gerenciamento de problemas
| Atividade | Descrição | ||
|---|---|---|---|
|
Atribuído ao grupo de suporte
|
Atribuição do registro de problema a uma equipe técnica ou grupo de suporte específico. Isso é acompanhado pelas alterações no campo personalizado 'Support Group' ou no campo 'Assignee', caso não sejam usados grupos. | ||
|
Por que isso importa
Essencial para analisar transferências e gargalos entre equipes. Uma alta taxa de transferências pode indicar ineficiências no encaminhamento.
Onde encontrar
Histórico do chamado no Jira: campo 'Support Group' ou 'Assignee' alterado
Coleta
Registrado quando o campo de atribuição é alterado
Tipo de evento
explicit
|
|||
|
Causa raiz identificada
|
Momento em que a causa subjacente é registrada formalmente. Pode ser identificado pela mudança de status para 'Root Cause Identified' ou pelo preenchimento do campo 'Root Cause'. | ||
|
Por que isso importa
Marco importante que encerra a etapa de investigação. É essencial para calcular o 'Tempo médio até a descoberta da causa raiz'.
Onde encontrar
Histórico do chamado no Jira: status alterado para 'Root Cause Identified' OU campo 'Root Cause' preenchido
Coleta
Compare o campo de status ou verifique se o campo foi preenchido
Tipo de evento
inferred
|
|||
|
Incidente vinculado ao problema
|
Ação de vincular um chamado de incidente relacionado ao registro de problema. Esse evento fica registrado na tabela de vínculos entre 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 encontrar
Vínculos entre chamados do Jira: vínculo criado com o tipo 'causes' ou 'relates to'
Coleta
Registrado quando um vínculo entre chamados é criado
Tipo de evento
explicit
|
|||
|
Investigação iniciada
|
Transição do status do problema para um estado de investigação ativa, como 'Under Investigation' ou 'In Progress'. Marca o início da etapa de trabalho ativo. | ||
|
Por que isso importa
Inicia a contagem do tempo de ciclo da investigação. Ajuda a diferenciar o tempo de espera no backlog do tempo de análise ativa.
Onde encontrar
Histórico do chamado no Jira: status alterado para 'Under Investigation' ou 'In Progress'
Coleta
Compare as atualizações do campo de status
Tipo de evento
inferred
|
|||
|
Registro de problema criado
|
Evento inicial em que o chamado de problema é criado no sistema. Esse evento fica registrado explicitamente no histórico do chamado, com a data e hora da criação. | ||
|
Por que isso importa
Marca o início do ciclo de vida da gestão de problemas e permite analisar o volume. É essencial para calcular a produtividade e as taxas de entrada.
Onde encontrar
Tabela de chamados do Jira: data de criação ou aba de histórico: evento de criação do chamado
Coleta
Registrado quando a transação de criação do chamado é confirmada
Tipo de evento
explicit
|
|||
|
Registro de problema encerrado
|
Encerramento definitivo do ciclo de vida do problema. O evento é registrado explicitamente quando o status muda para 'Closed'. | ||
|
Por que isso importa
Marca o fim definitivo da instância do processo. É necessário para calcular o tempo total de ciclo e as taxas de encerramento.
Onde encontrar
Histórico do chamado no Jira: status alterado para 'Closed'
Coleta
Registrado quando o status muda para 'Closed'
Tipo de evento
explicit
|
|||
|
Resolução validada
|
Confirmação de que a correção resolveu o problema. Pode ser identificada pela transição de status para 'Resolved' ou para um estado específico de 'Verified'. | ||
|
Por que isso importa
Etapa de controle de qualidade que garante o funcionamento da correção. Atrasos nessa etapa indicam gargalos nos testes ou na aceitação do usuário.
Onde encontrar
Histórico do chamado no Jira: status alterado para 'Resolved' ou 'Verified'
Coleta
Compare as atualizações do campo de status
Tipo de evento
inferred
|
|||
|
Solução temporária atualizada
|
Preenchimento ou atualização do campo de texto 'Workaround'. Esse evento indica que uma correção temporária foi documentada. | ||
|
Por que isso importa
Mede a rapidez com que o negócio recebe uma solução provisória. É essencial para o KPI 'Tempo até a disponibilização da solução temporária'.
Onde encontrar
Histórico do chamado no Jira: campo 'Workaround' alterado (não nulo)
Coleta
Registrado quando o campo 'Workaround' é alterado
Tipo de evento
explicit
|
|||
|
Correção definitiva aplicada
|
Transição que indica que a solução foi implementada. Geralmente, pode ser identificada pela mudança de status para 'Implementing' ou 'Fixed'. | ||
|
Por que isso importa
Marca o fim do trabalho de correção técnica. Usado para medir o tempo de ciclo da implementação.
Onde encontrar
Histórico do chamado no Jira: status alterado para 'Implemented', 'Pending Verification' ou 'Fixed'
Coleta
Compare as atualizações do campo de status
Tipo de evento
inferred
|
|||
|
Prioridade do problema alterada
|
Atualização do campo de prioridade do registro de problema. Esse evento é capturado ao monitorar as alterações no campo 'Priority' da aba de histórico. | ||
|
Por que isso importa
Indica que o problema foi escalado ou teve sua prioridade reduzida. A análise ajuda a identificar a precisão da triagem inicial e o tempo de espera dos problemas de alta prioridade no backlog.
Onde encontrar
Histórico do chamado no Jira: campo 'Priority' alterado do valor anterior para o novo valor
Coleta
Registrado quando o campo de prioridade é atualizado
Tipo de evento
explicit
|
|||
|
Problema reaberto
|
Transição do problema de um 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 das principais métricas de qualidade. Uma alta taxa de reabertura indica uma análise de causa raiz ou testes ineficazes.
Onde encontrar
Histórico do chamado no Jira: status alterado de 'Closed'/'Resolved' para 'Open'/'In Progress'
Coleta
Compare a sequência do campo de status
Tipo de evento
inferred
|
|||
|
Revisão pós-implementação
|
Realização de uma revisão após a aplicação da correção. O evento é registrado pela mudança de status para 'In Review' ou por atualizações em campos específicos da revisão pós-implementação (PIR). | ||
|
Por que isso importa
Atividade de Conformidade que garante o registro das lições aprendidas. Contribui para a análise de 'Conformidade da revisão pós-implementação'.
Onde encontrar
Histórico do chamado no Jira: status alterado para 'In Review' OU campo 'PIR Notes' atualizado
Coleta
Compare o campo de status ou as atualizações dos campos da PIR
Tipo de evento
inferred
|
|||
|
SLA não cumprido
|
Evento que indica que o tempo de resolução do problema ultrapassou o prazo definido no acordo de nível de serviço. É calculado comparando a data-limite 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 mais frequentemente não cumprem os prazos.
Onde encontrar
Registros de SLA do Jira Service Management: 'Time to Resolution' acima da meta ou calculado
Coleta
Obtenha os 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
|
Vínculo de uma solicitação de mudança (RFC) ao registro de problema. Indica o início do processo de correção definitiva. | ||
|
Por que isso importa
Mede o intervalo entre a identificação da causa e o início da correção. Contribui para o KPI 'Atraso na transição para a gestão de mudanças'.
Onde encontrar
Vínculos entre chamados do Jira: vínculo criado com o tipo 'is fixed by' ou com um chamado do tipo 'Change'
Coleta
Registrado quando é criado um vínculo com um chamado do tipo 'Change'
Tipo de evento
explicit
|
|||
Guias de extração
Pronto para começar?
Transforme hoje os dados de gerenciamento de problemas em insights acionáveis. Baixe o guia ou entre em contato com nossa equipe de suporte para começar sua jornada com Process Mining.
Otimize hoje o fluxo de gerenciamento de problemas
Reduza o tempo de ciclo em 30% e estabilize seu ambiente de TI.
Não é necessário informar cartão de crédito. Configure em poucos minutos.