Seu Template de dados para gerenciamento de problemas

Template universal de Process Mining
Seu Template de dados para gerenciamento de problemas

Seu Template de dados para gerenciamento de problemas

Template universal de Process Mining

Este é nosso Template genérico de dados para Process Mining de Gestão de problemas. Use os Templates específicos de cada sistema para receber orientações mais detalhadas.

Selecione um sistema específico
  • Uma estrutura universal para qualquer sistema de gerenciamento de problemas.
  • Campos de dados e etapas do processo recomendados para uma análise completa.
  • Insights iniciais para começar a mineração de processos com eficiência.
Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Atributos do gerenciamento de problemas

A tabela de atributos abaixo apresenta os campos de dados recomendados para criar um Event Log completo e obter insights detalhados sobre o processo de gerenciamento de problemas.
5 Obrigatório 8 Recomendado 4 Opcional
Nome Descrição
Data e hora do evento
EventTime
A data e a hora exatas em que uma atividade específica ocorreu.
Descrição

A data e a hora do evento fornecem o contexto cronológico de cada atividade no ciclo de vida do problema. Elas são essenciais para ordenar os eventos corretamente e calcular a duração entre as diferentes etapas do processo.

Em Process Mining, esse atributo é usado para ordenar atividades, descobrir o modelo do processo e realizar todas as análises baseadas em tempo. Ele serve de base para calcular indicadores-chave de performance, como 'Tempo médio de investigação da causa raiz', e identificar atrasos entre etapas, como a transferência entre a identificação da causa raiz e o início de uma solicitação de mudança.

Por que isso importa

A data e a hora de cada atividade são fundamentais para ordenar os eventos e calcular todas as métricas baseadas em tempo, como tempos de ciclo e duração dos gargalos.

Onde encontrar

Essa data e hora geralmente ficam em uma tabela de Event Log ou de trilha de auditoria, junto com o nome da atividade e o identificador do caso.

Exemplos
2023-04-15T10:22:05Z2023-11-20T14:05:30Z2024-01-08T09:00:11Z
ID do registro de problema
ProblemRecordId
Identificador exclusivo de um registro de problema, que representa uma ocorrência individual do processo de gestão de problemas.
Descrição

O ID do registro de problema é a chave principal para acompanhar todo o ciclo de vida de um problema, desde a criação até a resolução final. Cada problema, que pode estar vinculado a vários incidentes, recebe um ID exclusivo para diferenciá-lo dos demais.

Em Process Mining, esse atributo é fundamental porque define o caso e permite que a ferramenta agrupe todas as atividades relacionadas em uma única instância do processo. A análise dos fluxos do processo, a identificação de gargalos e o cálculo da duração dos casos dependem da identificação correta de cada registro de problema.

Por que isso importa

Este é o ID do caso essencial para agrupar todos os eventos relacionados e acompanhar a jornada completa de cada investigação de problema.

Onde encontrar

Esse identificador geralmente fica na tabela principal de problemas ou chamados do sistema de Gerenciamento de Serviços de TI (ITSM).

Exemplos
PRB0040332PROB-1298778103PM-5501
Nome da atividade
ActivityName
Nome de um evento, uma tarefa ou uma mudança de status específica ocorrida durante o ciclo de vida da gestão de problemas.
Descrição

O nome da atividade descreve uma etapa do processo de gestão de problemas, como 'Registro de problema criado', 'Causa raiz identificada' ou 'Correção permanente implementada'. Essas atividades são registradas em ordem cronológica para mostrar como o problema foi tratado.

Em Process Mining, esse atributo é essencial para construir o mapa do processo, que representa visualmente o fluxo real do trabalho. Analisar a sequência, a frequência e os caminhos dessas atividades ajuda a revelar desvios, gargalos e ineficiências no processo de resolução de problemas.

Por que isso importa

Este atributo define as etapas do processo e permite visualizar e analisar o fluxo, incluindo os caminhos mais comuns e os desvios.

Onde encontrar

Os nomes das atividades geralmente vêm de registros de mudanças de status, trilhas de auditoria ou tabelas de eventos associadas ao registro principal do problema.

Exemplos
Investigação iniciadaPrioridade alteradaSolução alternativa fornecidaRegistro de problema encerrado
Sistema de origem
SourceSystem
Nome do aplicativo ou sistema de onde os dados foram extraídos.
Descrição

Este atributo identifica a origem dos dados de gestão de problemas, como ServiceNow, Jira ou uma ferramenta de ITSM desenvolvida internamente. Ele é especialmente importante quando dados de vários sistemas são combinados para uma análise abrangente.

Em Process Mining, o sistema de origem pode ser usado como filtro para comparar a performance e as variações do processo entre diferentes unidades de negócio ou plataformas. Ele também ajuda na validação dos dados e na resolução de problemas, pois informa de onde eles vieram.

Por que isso importa

Identifica a origem dos dados, algo fundamental para validá-los e comparar processos entre diferentes sistemas ou unidades organizacionais.

Onde encontrar

Normalmente, esse é um valor estático adicionado durante a extração dos dados para identificar registros de um sistema de origem específico.

Exemplos
ServiceNowJira Service ManagementBMC Helix ITSMFreshservice
Última atualização dos dados
LastDataUpdate
Data e hora da última extração ou atualização dos dados do sistema de origem.
Descrição

Este atributo registra a data e a hora da extração mais recente dos dados. Ele mostra o quanto os dados analisados estão atualizados e ajuda as partes interessadas a entender o período coberto pela análise.

Em Dashboards e relatórios, essa informação é fundamental para dar contexto. Ela ajuda a saber se os dados são em tempo real ou representam um instantâneo de um momento específico, o que influencia a interpretação de métricas como 'Backlog de problemas antigos'.

Por que isso importa

Fornece contexto essencial sobre a atualização dos dados e ajuda a interpretar corretamente as análises e os Dashboards com base na última atualização.

Onde encontrar

Essa data e hora geralmente são geradas e armazenadas pela ferramenta ou pelo script de extração, transformação e carregamento de dados (ETL) durante a ingestão.

Exemplos
2023-10-01T06:00:00Z2024-02-20T08:00:00Z2024-03-15T05:30:00Z
Categoria da causa raiz
RootCauseCategory
Classificação final da causa subjacente que levou ao problema.
Descrição

Após a conclusão da investigação, a categoria da causa raiz classifica o motivo fundamental do problema, como 'Falha de software', 'Falha de hardware' ou 'Erro de configuração'. Essa classificação é essencial para promover melhorias estratégicas.

Este atributo é a base do Dashboard 'Performance da investigação da causa raiz'. Ao analisar a frequência das diferentes categorias, as organizações podem identificar problemas sistêmicos recorrentes e priorizar correções de longo prazo. Isso ajuda a mudar o foco da resolução reativa de problemas para a prevenção proativa.

Por que isso importa

É fundamental para a análise estratégica, pois ajuda a identificar problemas sistêmicos e tendências nas causas dos problemas em toda a organização.

Onde encontrar

Essas informações geralmente são registradas em um campo específico do registro do problema, preenchido antes ou durante o encerramento.

Exemplos
Erro de configuraçãoFalha de softwareFalha de hardwareProblema de treinamento do usuário
Grupo de suporte
SupportGroup
Equipe técnica ou departamento responsável por investigar e resolver o problema em determinado momento.
Descrição

O grupo de suporte indica qual equipe está responsável pelo problema. À medida que o problema avança, ele pode ser transferido entre diferentes grupos, por exemplo, de uma equipe de suporte de nível 2 para uma equipe especializada em engenharia de redes.

Este atributo é essencial para analisar a performance das equipes e as transferências entre elas. Process Mining pode destacar atrasos causados por reatribuições, medir quanto tempo os problemas ficam com cada grupo e identificar quais equipes são mais eficazes na resolução de determinados tipos de problema. Ele também dá suporte direto a Dashboards como 'Análise de transferências entre grupos de suporte'.

Por que isso importa

É fundamental para analisar a performance das equipes, identificar gargalos causados por transferências e entender como a carga de trabalho se distribui entre elas.

Onde encontrar

Essas informações geralmente ficam no histórico de atribuições do registro do problema ou na tabela de detalhes principais do sistema de ITSM.

Exemplos
Operações de redeAdministração de banco de dadosSuporte a aplicações nível 3Equipe de segurança
Prazo do SLA
SlaDueDate
Data e hora limite para a resolução do registro do problema, conforme o acordo de nível de serviço.
Descrição

O prazo do SLA define uma meta formal para a resolução do problema. Em geral, essa meta é determinada pela prioridade do problema e pelas condições definidas no acordo de nível de serviço (SLA).

Este atributo é essencial para o Dashboard 'Visão geral da conformidade com o SLA'. Ao comparar o tempo real de resolução com o prazo do SLA, as organizações podem calcular as taxas de cumprimento do SLA. Process Mining também permite detalhar a análise para identificar quais etapas do processo ou equipes mais contribuem para as violações de SLA.

Por que isso importa

Define a meta de resolução e serve de base para medir e relatar o cumprimento do SLA.

Onde encontrar

Essa data geralmente é calculada e armazenada no registro do problema com base na data de criação e na prioridade.

Exemplos
2023-05-20T17:00:00Z2024-01-10T09:30:00Z2024-03-01T12:00:00Z
Prioridade
Priority
Nível de prioridade atribuído ao problema, que determina a urgência da investigação e da resolução.
Descrição

A prioridade é um atributo-chave para classificar problemas de acordo com o impacto no negócio e a urgência. Ela ajuda as equipes a concentrar esforços primeiro nos problemas mais críticos. Os níveis de prioridade costumam ser padronizados, como Crítico, Alto, Médio e Baixo.

Na análise de processos, a prioridade é uma dimensão importante para filtrar e comparar dados. Os analistas podem comparar o fluxo de problemas de alta prioridade com o de problemas de baixa prioridade para verificar se são tratados de outra forma ou com mais eficiência. Ela também é fundamental para analisar a conformidade com o SLA, já que os SLAs costumam estar vinculados aos níveis de prioridade.

Por que isso importa

Permite segmentar a análise para comparar o tratamento de problemas críticos e rotineiros, além de ser essencial para medir o cumprimento do SLA.

Onde encontrar

Este é um campo padrão na tabela principal de registros de problemas da maioria das plataformas de ITSM.

Exemplos
1 - Crítico2 - Alto3 - Médio4 - Baixo
Quantidade de incidentes relacionados
RelatedIncidentCount
Número total de registros de incidentes individuais vinculados ao problema.
Descrição

Este atributo quantifica o impacto de um problema mostrando quantos incidentes que afetam os usuários ele causou. Em geral, um problema relacionado a muitos incidentes causa mais transtornos ao negócio.

Essa métrica é uma ferramenta importante para priorização e análise de impacto. Em Process Mining, ela pode ser usada para relacionar a quantidade de incidentes ao tempo de investigação ou à prioridade de resolução. Ela ajuda as organizações a entender a dimensão dos problemas e justifica os recursos dedicados à gestão de problemas, mostrando quantos incidentes uma única correção pode evitar.

Por que isso importa

Quantifica o impacto do problema no negócio, ajudando a priorizar investigações e medir a eficácia da resolução.

Onde encontrar

Esse valor costuma ser calculado no registro do problema e corresponde à quantidade de registros de incidentes vinculados.

Exemplos
5281501
Quantidade de reatribuições
ReassignmentCount
Número de vezes que o registro do problema foi reatribuído entre diferentes grupos de suporte ou pessoas.
Descrição

Esta métrica conta quantas vezes a responsabilidade por um problema foi transferida. Uma quantidade alta de reatribuições costuma indicar ineficiência no processo, como encaminhamento inicial incorreto ou falta de clareza nas responsabilidades das equipes.

Em Process Mining, esse é um indicador-chave de atrito no processo. Ele pode revelar situações de 'pingue-pongue', em que o problema passa repetidamente de uma equipe para outra. Analisar casos com muitas reatribuições pode revelar lacunas de conhecimento ou falhas no processo que causam atrasos significativos e desperdício de esforço.

Por que isso importa

Ajuda a quantificar a ineficiência do processo ao acompanhar transferências excessivas, que muitas vezes indicam encaminhamento incorreto, lacunas de conhecimento ou responsabilidades pouco claras.

Onde encontrar

Esse campo costuma ser um contador incrementado no registro do problema a cada mudança de atribuição. Também pode ser calculado a partir do Event Log.

Exemplos
0135
Serviço afetado
AffectedService
Principal serviço de negócio, aplicativo ou item de configuração (CI) afetado pelo problema.
Descrição

Este atributo vincula um problema a um componente ou serviço específico da infraestrutura de TI, como 'Serviços de e-mail' ou 'Plataforma de gestão de relacionamento com clientes'. Ele fornece contexto de negócio essencial para a questão técnica.

Na análise com Process Mining, o serviço afetado permite analisar o processo pela perspectiva do negócio. Ele ajuda a responder perguntas como 'Quais serviços geram mais problemas?' ou 'Qual é o tempo médio de resolução dos problemas que afetam sistemas financeiros críticos?'. Esse contexto é fundamental para priorizar melhorias de acordo com o impacto no negócio.

Por que isso importa

Fornece contexto de negócio ao vincular problemas técnicos aos serviços afetados e permite priorizar com base na importância desses serviços para o negócio.

Onde encontrar

Normalmente, esse dado vem de um Banco de Dados de Gerenciamento de Configuração (CMDB) e fica no campo 'Item de configuração' ou 'Serviço' do registro do problema.

Exemplos
Serviços de e-mail e colaboraçãoFinanças do SAP ERPVPN corporativaSite principal da empresa
SLA violado
SlaBreached
Sinalizador que indica se a resolução do problema ultrapassou o prazo do SLA atribuído.
Descrição

Este atributo booleano indica de forma simples e direta se o Acordo de Nível de Serviço foi cumprido. Em geral, ele recebe o valor verdadeiro quando a data e a hora da resolução do problema são posteriores ao prazo do SLA.

Como medida direta do resultado, esse sinalizador é muito útil para Dashboards e relatórios de alto nível. Em Process Mining, ele pode ser usado para criar verificações de conformidade ou filtrar todos os casos com violação. Comparar os mapas de processo dos problemas com e sem violação pode revelar padrões, gargalos ou atividades específicas que costumam causar o não cumprimento do SLA.

Por que isso importa

Indica claramente se o SLA foi cumprido, facilitando a filtragem e a análise dos caminhos do processo que levam a violações.

Onde encontrar

Esse campo costuma ser derivado ou calculado pela comparação entre a data e a hora da resolução e o prazo do SLA.

Exemplos
truefalse
ID da solicitação de mudança relacionada
RelatedChangeRequestId
Identificador da solicitação de mudança iniciada para implementar a correção permanente do problema.
Descrição

Este atributo cria um vínculo direto entre o processo de gestão de problemas e o processo de gestão de mudanças. Ele é usado quando é necessário alterar o código, substituir hardware ou fazer outra modificação para resolver a causa raiz do problema.

Analisar esse vínculo é essencial para entender o 'Atraso na transferência para a gestão de mudanças'. Process Mining pode medir o tempo entre a identificação da causa raiz e a criação da solicitação de mudança, bem como entre a implementação da mudança e o encerramento do problema. Isso ajuda a identificar ineficiências na interação entre os dois processos.

Por que isso importa

Vincula o problema à solução na gestão de mudanças e permite analisar atrasos nas transferências e todo o ciclo de vida da resolução.

Onde encontrar

Normalmente, esse é um campo de referência no registro do problema que aponta para o registro correspondente no sistema ou módulo de gestão de mudanças.

Exemplos
CHG0030219CR-8812CHANGE-401
Solução alternativa fornecida
WorkaroundProvided
Sinalizador que indica se uma solução temporária foi identificada e comunicada para o problema.
Descrição

Este atributo acompanha se uma solução temporária foi disponibilizada para reduzir o impacto do problema enquanto uma correção permanente está sendo desenvolvida. Esse é um marco importante no ciclo de vida da gestão de problemas.

Este atributo é essencial para o Dashboard 'Eficácia e rapidez da solução temporária'. Process Mining pode calcular o tempo médio para disponibilizar uma solução temporária e, em seguida, relacionar essa disponibilização à redução de novos incidentes relacionados. Isso ajuda a medir a capacidade da equipe de restabelecer o serviço rapidamente, mesmo antes da correção da causa raiz.

Por que isso importa

Indica se o serviço foi restabelecido temporariamente e permite analisar a rapidez com que a equipe consegue reduzir o impacto no negócio.

Onde encontrar

Pode ser um sinalizador booleano ('WorkaroundPublished') ou ser derivado da existência de texto em um campo de detalhes da solução temporária.

Exemplos
truefalse
Status do problema
ProblemStatus
Estado atual do ciclo de vida do registro do problema, como Aberto, Em investigação ou Encerrado.
Descrição

O status do problema indica a etapa atual do problema no fluxo de trabalho. Ele mostra em que ponto o problema está, desde o registro inicial até a resolução final.

Enquanto o nome da atividade registra o evento de mudança de status, o status do problema é útil para analisar o backlog atual. Ele permite criar Dashboards que mostram quantos problemas abertos há em cada estado, ajudando a gerenciar a carga de trabalho e identificar registros parados por muito tempo em uma determinada etapa.

Por que isso importa

Indica a etapa atual do problema, informação essencial para analisar o backlog e identificar problemas parados em uma fase específica.

Onde encontrar

Este é um campo padrão na tabela principal de registros de problemas, atualizado à medida que o problema avança no ciclo de vida.

Exemplos
AbertoAnálise de causa raizAguardando mudançaResolvidoEncerrado
Usuário atribuído
AssignedUser
Usuário ou coordenador responsável atualmente pela gestão do registro do problema.
Descrição

Este atributo identifica a pessoa responsável pelo problema em determinado momento. Enquanto o grupo de suporte indica a equipe, o usuário atribuído identifica o agente, engenheiro ou coordenador que conduz a investigação.

Analisar os dados por usuário atribuído ajuda a entender a carga de trabalho, a performance e as necessidades de treinamento de cada pessoa. Isso pode revelar se alguém está se tornando um gargalo ou se o trabalho não está bem distribuído na equipe. Essa análise complementa a análise por grupo de suporte.

Por que isso importa

Permite analisar a carga de trabalho e a performance individuais, ajudando a identificar quem tem os melhores resultados e quem pode precisar de mais apoio ou treinamento.

Onde encontrar

Esse campo geralmente fica na tabela principal de registros de problemas e pode aparecer como 'Responsável', 'Atribuído a' ou 'Coordenador'.

Exemplos
Alice JohnsonajohnsonBob Smithbsmith
Obrigatório Recomendado Opcional

Atividades do gerenciamento de problemas

Esta seção detalha as principais etapas do processo e os marcos importantes que você deve registrar para descobrir o processo com precisão e entender claramente o Workflow de gerenciamento de problemas.
7 Recomendado 8 Opcional
Atividade Descrição
Causa raiz identificada
Esta atividade marca o momento em que a causa subjacente do problema foi diagnosticada e documentada com sucesso. Ela representa a conclusão da etapa de investigação.
Por que isso importa

Este é um marco essencial para medir a eficiência do diagnóstico. O tempo entre o início da investigação e a identificação da causa raiz é um indicador importante da performance da análise de problemas.

Onde encontrar

Muitas vezes, este evento é identificado por uma mudança de status para “Root Cause Identified” ou pelo primeiro preenchimento do campo “Root Cause”.

Coleta

Registre a data e a hora da mudança de status ou da primeira atualização do campo de texto “Root Cause”.

Tipo de evento inferred
Investigação iniciada
Este evento marca a transição do registro de problema de um estado novo ou pendente para uma investigação ativa. Ele indica que um analista começou formalmente a diagnosticar o problema.
Por que isso importa

Esta atividade ajuda a medir o tempo de resposta inicial e a velocidade de processamento do backlog. O tempo entre a criação e o início da investigação é um indicador importante da capacidade de resposta da equipe.

Onde encontrar

Muitas vezes, este evento é identificado por uma mudança de status no histórico do registro, como a transição de “New” para “In Progress” ou “Under Investigation”.

Coleta

Registre a data e a hora em que o status mudar pela primeira vez para um estado de investigação ativa.

Tipo de evento inferred
Registro de problema criado
Este é o momento em que um registro de problema é criado. Ele marca o início formal do processo de gerenciamento de problemas e define o registro de data e hora de referência para as análises seguintes.
Por que isso importa

Esta atividade é o ponto de partida de cada instância do processo. Analisar o tempo entre este evento e os demais é essencial para entender a duração total do processo e os atrasos iniciais.

Onde encontrar

Em geral, este dado vem do registro de data e hora de criação do registro principal do problema ou da tabela de chamados. Quase sempre há um campo explícito para isso nos dados de origem.

Coleta

Use o campo “Created On” ou um registro de data e hora equivalente da tabela principal de problemas.

Tipo de evento explicit
Registro de problema encerrado
Esta é a atividade final do ciclo de vida. Ela indica que o registro de problema foi encerrado administrativamente e que nenhuma outra ação é esperada. O caso é considerado concluído e arquivado.
Por que isso importa

Esta atividade é o ponto final da maioria das instâncias do processo. Ela é essencial para calcular a duração total, de ponta a ponta, do processo de gerenciamento de problemas.

Onde encontrar

Quase sempre, este é um evento explícito, registrado quando o status muda para “Closed” no log de histórico do registro.

Coleta

Use o registro de data e hora em que o status do registro muda para “Closed”.

Tipo de evento explicit
Solicitação de mudança iniciada
Este evento registra a criação ou vinculação de uma solicitação formal de mudança ao registro de problema. Ele marca a transferência do gerenciamento de problemas para o gerenciamento de mudanças, com o objetivo de implementar uma solução definitiva.
Por que isso importa

Esta atividade é essencial para analisar o atraso entre o diagnóstico do problema e o início da correção. Ela ajuda a identificar gargalos na integração entre o gerenciamento de problemas e o gerenciamento de mudanças.

Onde encontrar

Em geral, este é um evento explícito no histórico de relacionamentos ou vínculos do registro, que mostra a associação a um registro de mudança.

Coleta

Identifique o evento em que um registro de mudança é vinculado ao registro de problema.

Tipo de evento explicit
Solução alternativa fornecida
Este evento indica que uma solução temporária foi documentada e disponibilizada. Essa ação ajuda a reduzir o impacto para os usuários finais enquanto uma solução definitiva é desenvolvida.
Por que isso importa

O tempo para fornecer uma solução alternativa é um KPI importante para medir a capacidade da equipe de restabelecer o serviço rapidamente. Esta atividade ajuda a analisar a rapidez e a eficácia das soluções temporárias.

Onde encontrar

Este evento pode ser identificado pelo primeiro registro de texto no campo “Workaround”, pelo registro da ação “Communicate Workaround” ou pela ativação de um indicador específico “Workaround Available”.

Coleta

Identifique o primeiro preenchimento de um campo de solução alternativa ou um evento relacionado à publicação.

Tipo de evento explicit
Solução definitiva implementada
Este evento indica que a solução técnica definitiva, geralmente gerenciada por meio de uma solicitação de mudança, foi implantada com sucesso. Ele marca a conclusão do trabalho de correção.
Por que isso importa

Esta atividade encerra a etapa de implementação da solução. O tempo entre o início da mudança e este momento mede a eficiência do processo de gerenciamento de mudanças na resolução de problemas.

Onde encontrar

Em geral, este evento é identificado quando o status do registro de problema muda para “Resolved” ou “Solution Implemented”, muitas vezes após o encerramento da solicitação de mudança vinculada.

Coleta

Identifique a mudança de status do problema para “Resolved” ou use o registro de data e hora de conclusão do registro de mudança associado.

Tipo de evento inferred
Aguardando implementação da mudança
Esta atividade representa o estado em que o registro de problema fica suspenso, aguardando a conclusão de uma solicitação de mudança associada. A equipe de problemas aguarda a implantação da correção pela equipe de mudanças.
Por que isso importa

Isolar esse período de espera ajuda a medir com precisão o tempo gasto no processo de gerenciamento de mudanças em comparação com o processo de gerenciamento de problemas, aumentando a responsabilização.

Onde encontrar

Em geral, este evento é identificado por uma mudança de status para “Pending Change” ou “Fix in Progress” no histórico do registro de problema.

Coleta

Registre a data e a hora em que o status do registro de problema mudar para indicar que ele está aguardando uma mudança.

Tipo de evento inferred
Grupo de suporte atribuído
Esta atividade representa a atribuição ou reatribuição do registro de problema a um grupo de suporte ou equipe específica. Ela registra a transferência da responsabilidade pela investigação.
Por que isso importa

Acompanhar as atribuições é essencial para analisar atrasos nas transferências, identificar gargalos entre equipes e entender a performance dos grupos. Um número elevado de reatribuições costuma indicar ineficiência no processo.

Onde encontrar

Em geral, essas informações estão em um log de auditoria ou tabela de histórico que registra mudanças no campo “Assignment Group” ou “Support Team” do registro de problema.

Coleta

Identifique todas as mudanças no campo de grupo de atribuição no log de histórico do registro.

Tipo de evento explicit
Prioridade alterada
Esta atividade registra qualquer atualização da prioridade, do impacto ou da urgência do problema após sua criação. Ela reflete uma nova avaliação da importância do problema para o negócio.
Por que isso importa

Analisar as mudanças de prioridade ajuda a identificar problemas que são escalados ou têm sua prioridade reduzida com frequência, o que pode afetar a alocação de recursos e a conformidade com o SLA.

Onde encontrar

Em geral, essa informação é registrada em um log de auditoria ou tabela de histórico de mudanças que acompanha as alterações no campo “Priority”.

Coleta

Acompanhe todas as atualizações do campo “Priority” no histórico de mudanças do registro.

Tipo de evento explicit
Registro de problema cancelado
Esta atividade representa o encerramento de um registro de problema antes que uma solução seja encontrada. Isso pode acontecer quando o registro é criado por engano, é duplicado ou deixa de ser relevante.
Por que isso importa

Analisar os cancelamentos ajuda a entender a qualidade dos registros de problema recebidos. Uma taxa alta de cancelamento pode indicar a necessidade de melhorar o treinamento ou os critérios de qualificação.

Onde encontrar

Esse evento é registrado quando o status muda para 'Cancelado', 'Rejeitado' ou 'Retirado' no histórico do registro.

Coleta

Identifique a data e a hora em que o status muda para um estado final de cancelamento.

Tipo de evento explicit
Registro de problema reaberto
Esta atividade ocorre quando um registro de problema resolvido ou encerrado volta a um estado ativo. Em geral, isso indica que a correção implementada não funcionou ou que o problema voltou a ocorrer.
Por que isso importa

Uma taxa elevada de reabertura é um indicador importante de baixa qualidade na resolução. Acompanhar esta atividade é essencial para medir a taxa de resolução na primeira tentativa e identificar soluções ineficazes.

Onde encontrar

Este evento é identificado ao acompanhar o histórico de status do registro e detectar a transição de um estado encerrado ou resolvido para um estado aberto ou em andamento.

Coleta

Identifique mudanças de status de “Resolved” ou “Closed” para um estado ativo, como “Open”.

Tipo de evento explicit
Resolução verificada
Esta atividade representa a confirmação de que a correção implementada resolveu o problema subjacente e restabeleceu o serviço normal. É a etapa final de validação antes do encerramento.
Por que isso importa

Esta etapa verifica a qualidade da resolução. Analisar o tempo necessário para a verificação pode revelar atrasos na confirmação do sucesso de uma correção.

Onde encontrar

Este evento pode ser registrado explicitamente com um status como “Verification” ou identificado pela transição para um estado “Resolved” ou “Solved”.

Coleta

Registre a data e a hora em que o status mudar para indicar que a correção foi confirmada.

Tipo de evento inferred
Revisão pós-implementação concluída
Este evento marca a conclusão de uma revisão pós-implementação (PIR). Esse processo formal analisa como o problema foi tratado para identificar lições aprendidas e oportunidades de melhoria no processo.
Por que isso importa

Acompanhar a conclusão das PIRs é importante para a conformidade do processo e a melhoria contínua. Isso garante que insights valiosos sobre problemas importantes sejam registrados e colocados em prática.

Onde encontrar

Muitas vezes, este evento é registrado pela conclusão de uma subtarefa de PIR, por uma mudança de status para “Review Complete” ou pelo preenchimento de um campo com a data de conclusão da PIR.

Coleta

Identifique a conclusão de uma tarefa relacionada à PIR ou uma atualização de status específica.

Tipo de evento explicit
Violação de SLA detectada
Este evento indica que o tempo para alcançar uma resolução ou um marco de resposta ultrapassou a meta predefinida do Acordo de Nível de Serviço (SLA). Ele é gerado pelo sistema ou calculado.
Por que isso importa

Acompanhar as violações de SLA é fundamental para a gestão de performance e os relatórios de conformidade. Isso destaca diretamente os casos que não cumpriram os compromissos de nível de serviço.

Onde encontrar

Pode ser um sinalizador específico ou um evento registrado pelo sistema, ou pode ser calculado comparando a data e a hora da resolução com o prazo do SLA.

Coleta

Calcule comparando as datas e horas de resolução ou resposta com as datas e horas das metas do SLA, ou registre um evento de violação gerado pelo sistema.

Tipo de evento calculated
Recomendado Opcional

Guias de extração

Como obter seus dados para Process Mining.

Os métodos de extração variam conforme o sistema. Para ver instruções detalhadas,

consulte nosso guia de ETL   ou   selecione um processo e um sistema específicos.

Pronto para começar?

Escolha um guia específico para o seu sistema ou use este Template Genérico para começar hoje mesmo a analisar o processo de gerenciamento de problemas.

Melhore o gerenciamento de problemas. Comece agora.

Encontre ineficiências e resolva problemas mais rápido com insights baseados em dados.

Começar o teste grátis

Não é necessário informar cartão de crédito. A configuração leva poucos minutos.