Seu Template de Dados para Gestão de Problemas
Seu Template de Dados para 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 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
|
|||
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
|
|||
|
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
|
|||