Seu Template de dados de gerenciamento de problemas
Seu Template de dados de gerenciamento de problemas
Este é nosso Template genérico de dados para Process Mining para Gestão de problemas. Use nossos Templates específicos de sistemas para obter orientações mais detalhadas.
Selecione um sistema específico- Uma estrutura universal aplicável a qualquer sistema de gerenciamento de problemas.
- Campos de dados e etapas do processo recomendados para uma análise completa.
- Insights fundamentais para começar sua jornada de Process Mining com eficiência.
Atributos da gestão de problemas
| Nome | Descrição | ||
|---|---|---|---|
| Horário do evento EventTime | A data e a hora exatas em que uma atividade específica ocorreu. | ||
| Descrição O horário do evento, ou timestamp, fornece o contexto cronológico de cada atividade no ciclo de vida do problema. Ele é essencial para ordenar os eventos corretamente e calcular as durações entre diferentes etapas do processo. No Process Mining, esse atributo é usado para ordenar atividades, descobrir o modelo do processo e realizar todas as análises baseadas em tempo. Ele é a 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 O timestamp de cada atividade é fundamental para ordenar os eventos e calcular todas as métricas baseadas em tempo, como tempos de ciclo e durações de gargalos. Onde obter Esse timestamp geralmente está localizado em uma tabela de Event Log ou de trilha de auditoria, junto ao nome da atividade e ao identificador do caso. Exemplos 2023-04-15T10:22:05Z2023-11-20T14:05:30Z2024-01-08T09:00:11Z | |||
| ID do registro do problema ProblemRecordId | O identificador exclusivo de um registro de problema, que representa uma única instância do processo de gerenciamento de problemas. | ||
| Descrição O ID do registro do problema funciona como chave primária para acompanhar todo o ciclo de vida de um problema, desde sua criação até a resolução final. Cada problema, que pode estar vinculado a vários incidentes, recebe um ID exclusivo para diferenciá-lo de todos os outros problemas. No 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 das durações dos casos dependem da identificação correta de cada registro de problema exclusivo. Por que isso importa Este é o Case ID essencial que agrupa todos os eventos relacionados, permitindo rastrear a jornada completa de cada investigação de problema. Onde obter Esse identificador geralmente é encontrado na tabela principal de problemas ou tickets do sistema de Gerenciamento de Serviços de TI (ITSM). Exemplos PRB0040332PROB-1298778103PM-5501 | |||
| Nome da atividade ActivityName | O nome de um evento, tarefa ou mudança de status específica que ocorreu durante o ciclo de vida do gerenciamento de problemas. | ||
| Descrição O nome da atividade descreve uma única etapa do processo de gerenciamento de problemas, como 'Registro do problema criado', 'Causa raiz identificada' ou 'Correção permanente implementada'. Essas atividades são registradas em ordem cronológica para contar como o problema foi tratado. No Process Mining, esse atributo é essencial para construir o mapa do processo, que representa visualmente o fluxo real do trabalho. A análise da sequência, da frequência e dos caminhos dessas atividades ajuda a revelar desvios, gargalos e ineficiências no processo de resolução de problemas. Por que isso importa Esse atributo define as etapas do processo, permitindo visualizar e analisar o fluxo do processo, incluindo caminhos comuns e desvios. Onde obter Os nomes das atividades geralmente são derivados de registros de mudança 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 fechado | |||
| Sistema de origem SourceSystem | O nome do aplicativo ou sistema do qual os dados foram extraídos. | ||
| Descrição Esse atributo identifica a origem dos dados de gerenciamento de problemas, como ServiceNow, Jira ou uma ferramenta de ITSM desenvolvida internamente. Ele é especialmente importante em ambientes nos quais dados de vários sistemas são combinados para uma análise abrangente. No contexto de 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 solução de problemas, fornecendo contexto sobre a origem dos dados. Por que isso importa Identifica a origem dos dados, o que é fundamental para validar os dados e comparar processos entre diferentes sistemas ou unidades organizacionais. Onde obter Normalmente, este é 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 | O timestamp que indica quando os dados foram extraídos ou atualizados pela última vez a partir do sistema de origem. | ||
| Descrição Esse atributo registra a data e a hora da extração mais recente dos dados. Ele dá transparência sobre a atualidade dos dados analisados, garantindo que as partes interessadas entendam o período abrangido pela análise. Em Dashboards e relatórios, essas informações são essenciais para dar contexto. Elas ajudam você a saber se está consultando informações em tempo real ou um retrato de um momento específico, o que afeta a interpretação de métricas como 'Backlog de problemas antigos'. Por que isso importa Fornece um contexto essencial sobre a atualidade dos dados, garantindo que as análises e os Dashboards sejam interpretados corretamente com base na última atualização. Onde obter Esse timestamp geralmente é gerado e armazenado pela ferramenta ou pelo script de extração, transformação e carregamento (ETL) durante a ingestão dos dados. Exemplos 2023-10-01T06:00:00Z2024-02-20T08:00:00Z2024-03-15T05:30:00Z | |||
| Categoria da causa raiz RootCauseCategory | A classificação final da causa subjacente que levou ao problema. | ||
| Descrição Depois que uma investigação é concluída, a categoria da causa raiz é usada para classificar o motivo fundamental do problema, como 'Defeito de software', 'Falha de hardware' ou 'Erro de configuração'. Essa categorização é essencial para a melhoria estratégica. Esse atributo é a base do Dashboard 'Performance da investigação da causa raiz'. Ao analisar a frequência das diferentes categorias de causa raiz, as organizações podem identificar problemas sistêmicos recorrentes e priorizar correções de longo prazo. Ele 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, ajudando a identificar problemas sistêmicos e tendências nas causas dos problemas em toda a organização. Onde obter Essas informações geralmente são registradas em um campo específico do registro do problema, muitas vezes preenchido antes ou durante a etapa de encerramento. Exemplos Erro de configuraçãoDefeito de softwareFalha de hardwareProblema de treinamento do usuário | |||
| Data limite do SLA SlaDueDate | A data e a hora-alvo até as quais se espera que o registro do problema seja resolvido, de acordo com o acordo de nível de serviço. | ||
| Descrição A data limite do SLA define uma meta formal para a resolução do problema. Essa meta geralmente é determinada com base na prioridade do problema e nos termos definidos no acordo de nível de serviço (SLA). Esse atributo é essencial para o Dashboard 'Visão geral da conformidade com o SLA'. Ao comparar o tempo real de resolução com a data limite do SLA, as organizações podem calcular as taxas de cumprimento do SLA. O Process Mining pode detalhar ainda mais essa análise para identificar quais etapas do processo ou equipes mais contribuem para o não cumprimento do SLA. Por que isso importa Define a meta de resolução e serve de base para todas as medições e todos os relatórios de conformidade com o SLA. Onde obter Essa data geralmente é calculada e armazenada no registro do problema com base no horário de criação e na prioridade. Exemplos 2023-05-20T17:00:00Z2024-01-10T09:30:00Z2024-03-01T12:00:00Z | |||
| Grupo de suporte SupportGroup | A equipe técnica ou o 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. Conforme o problema avança, ele pode ser transferido entre diferentes grupos, como uma equipe de suporte de Nível 2 e uma equipe especializada em Engenharia de Redes. Esse atributo é essencial para analisar a performance das equipes e as transferências entre elas. O Process Mining pode destacar atrasos causados por transferências, medir quanto tempo os problemas permanecem com cada grupo e identificar quais equipes são mais eficazes na resolução de determinados tipos de problemas. Ele 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 a distribuição da carga de trabalho entre diferentes equipes. Onde obter Essas informações geralmente ficam armazenadas no histórico de atribuições do registro do problema ou na tabela principal de detalhes do sistema de ITSM. Exemplos Operações de redeAdministração de banco de dadosSuporte de aplicações L3Equipe de segurança | |||
| Prioridade Priority | O 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 essencial para classificar problemas com base no impacto e na urgência para o negócio. Ela ajuda as equipes a concentrarem seus esforços primeiro nos problemas mais críticos. Os níveis de prioridade costumam ser padronizados, como Crítica, Alta, Média e Baixa. Na análise de processos, a prioridade é uma dimensão poderosa para filtrar e comparar dados. Os analistas podem comparar o fluxo do processo de problemas de alta prioridade com o de problemas de baixa prioridade para verificar se eles são tratados de forma diferente ou mais eficiente. Ela também é fundamental para a análise de conformidade com o SLA, pois os SLAs geralmente estão vinculados aos níveis de prioridade. Por que isso importa Permite segmentar a análise para comparar como problemas críticos são tratados em relação aos problemas rotineiros e é essencial para medir a conformidade com o SLA. Onde obter 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 | O número total de registros de incidentes individuais vinculados ao problema. | ||
| Descrição Esse atributo quantifica o impacto de um problema ao mostrar quantos incidentes voltados aos usuários ele causou. Um problema com muitos incidentes relacionados normalmente é mais prejudicial para o negócio. Essa métrica é uma ferramenta poderosa para priorização e análise de impacto. No Process Mining, ela pode ser usada para correlacionar o número de incidentes com o tempo de investigação ou a prioridade de resolução. Ela ajuda as organizações a entender a dimensão dos problemas e justificar os recursos investidos no gerenciamento de problemas, mostrando quantos incidentes são evitados por uma única correção. Por que isso importa Quantifica o impacto de um problema para o negócio, ajudando a priorizar investigações e medir a eficácia da resolução. Onde obter Esse valor geralmente é um campo calculado no registro do problema que contabiliza o número de registros de incidentes vinculados. Exemplos 5281501 | |||
| Quantidade de reatribuições ReassignmentCount | O número de vezes que o registro do problema foi reatribuído entre diferentes grupos de suporte ou pessoas. | ||
| Descrição Essa métrica contabiliza quantas vezes a responsabilidade por um problema foi transferida. Uma quantidade alta de reatribuições geralmente indica ineficiência no processo, como roteamento inicial incorreto ou falta de clareza sobre as responsabilidades das equipes. No Process Mining, esse é um indicador importante de atrito no processo. Ele pode ser usado para identificar cenários de 'pingue-pongue', nos quais um problema fica indo e voltando entre equipes. A análise de 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 geralmente indicam roteamento incorreto, lacunas de conhecimento ou responsabilidades pouco claras. Onde obter Geralmente, este é um campo contador incrementado no registro do problema a cada mudança de atribuição. Ele também pode ser calculado a partir do Event Log. Exemplos 0135 | |||
| Serviço afetado AffectedService | O principal serviço de negócio, aplicativo ou item de configuração (CI) afetado pelo problema. | ||
| Descrição Esse atributo vincula um problema a um componente ou serviço específico da infraestrutura de TI, como 'Serviço de e-mail' ou 'Plataforma de gestão do relacionamento com clientes'. Ele fornece um contexto de negócio essencial para o problema técnico. Na análise de Process Mining, o serviço afetado permite uma visão do processo orientada ao negócio. Ele ajuda a responder perguntas como 'Quais serviços geram mais problemas?' ou 'Qual é nosso tempo médio de resolução para problemas que afetam sistemas financeiros críticos?'. Esse contexto é fundamental para priorizar iniciativas de melhoria com base no impacto para o negócio. Por que isso importa Fornece contexto de negócio ao vincular problemas técnicos aos serviços afetados, permitindo priorizar ações com base na criticidade para o negócio. Onde obter Normalmente, ele é vinculado a partir de um Banco de Dados de Gerenciamento de Configuração (CMDB) e armazenado em um campo 'Item de configuração' ou 'Serviço' do registro do problema. Exemplos Serviços de e-mail e colaboraçãoSAP ERP FinancialsVPN corporativaSite principal do cliente | |||
| SLA não cumprido SlaBreached | Um indicador que mostra se a resolução do problema ultrapassou a data limite do SLA atribuído. | ||
| Descrição Esse atributo booleano fornece uma indicação simples e direta de que um acordo de nível de serviço foi ou não cumprido. Normalmente, ele recebe o valor true quando o timestamp da resolução do problema é posterior à data limite do SLA. Como medida direta de resultado, esse indicador é extremamente útil para Dashboards e relatórios de alto nível. No Process Mining, ele pode ser usado para criar verificações de conformidade ou filtrar todos os casos em que o SLA não foi cumprido. A análise dos mapas de processo de 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 Fornece um resultado claro de sucesso ou falha na conformidade com o SLA, facilitando a filtragem e a análise dos caminhos do processo que levam ao não cumprimento. Onde obter Geralmente, este é um campo derivado ou calculado, determinado pela comparação entre o timestamp da resolução e a data limite do SLA. Exemplos truefalse | |||
| ID da solicitação de mudança relacionada RelatedChangeRequestId | O identificador da solicitação de mudança iniciada para implementar a correção permanente do problema. | ||
| Descrição Esse atributo cria um vínculo direto entre o processo de gerenciamento de problemas e o processo de gerenciamento de mudanças. Ele é usado quando uma alteração de código, substituição de hardware ou outra modificação é necessária para resolver a causa raiz do problema. A análise desse vínculo é essencial para entender o 'Atraso na transferência para o gerenciamento de mudanças'. O Process Mining pode medir o tempo entre a identificação da causa raiz e a criação de uma solicitação de mudança, além do tempo 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 no gerenciamento de mudanças, permitindo analisar atrasos nas transferências e o ciclo de vida completo da resolução. Onde obter Normalmente, este é um campo de referência no registro do problema que aponta para o registro correspondente no sistema ou módulo de gerenciamento de mudanças. Exemplos CHG0030219CR-8812CHANGE-401 | |||
| Solução alternativa fornecida WorkaroundProvided | Um indicador que mostra se uma solução temporária foi identificada e comunicada para o problema. | ||
| Descrição Esse 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 do gerenciamento de problemas. Esse atributo é fundamental para o Dashboard 'Eficácia e velocidade da solução temporária'. O Process Mining pode ser usado para calcular o tempo médio até a disponibilização de uma solução temporária. Em seguida, a análise pode correlacionar essa disponibilização com a redução de novos incidentes relacionados. Isso ajuda a medir a capacidade da equipe de restaurar rapidamente o serviço, mesmo antes da correção da causa raiz. Por que isso importa Indica se o serviço foi restaurado temporariamente, permitindo analisar a rapidez com que a equipe consegue reduzir o impacto para o negócio. Onde obter Pode ser um indicador booleano ('WorkaroundPublished') ou ser derivado da presença de texto em um campo de detalhes da solução temporária. Exemplos truefalse | |||
| Status do problema ProblemStatus | O 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 Workflow. Ele mostra em que ponto o problema está em determinado momento, 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 o número de problemas abertos em cada estado, ajudando a gerenciar a carga de trabalho e identificar registros que permanecem tempo demais em uma determinada etapa. Por que isso importa Indica a etapa atual de um problema, o que é essencial para analisar o backlog e identificar problemas parados em uma fase específica. Onde obter Este é um campo padrão da tabela principal de registros de problemas, atualizado conforme o problema avança pelo ciclo de vida. Exemplos AbertoAnálise de causa raizAguardando alteraçãoResolvidoFechado | |||
| Usuário atribuído AssignedUser | O usuário ou coordenador atualmente responsável por gerenciar o registro do problema. | ||
| Descrição Esse atributo identifica a pessoa responsável pelo problema em determinado momento. Enquanto o grupo de suporte define a equipe, o usuário atribuído indica o agente, engenheiro ou coordenador responsável pela investigação. A análise por usuário atribuído ajuda a entender a carga de trabalho individual, a performance e as necessidades de treinamento. Ela pode mostrar se determinadas pessoas estão se tornando gargalos ou se o trabalho não está sendo distribuído de maneira equilibrada dentro da equipe. Essa visão complementa a análise do grupo de suporte. Por que isso importa Permite analisar a carga de trabalho e a performance individuais, ajudando a identificar os profissionais de melhor desempenho ou aqueles que podem precisar de suporte ou treinamento adicional. Onde obter Esse campo geralmente é encontrado na tabela principal de registros de problemas, muitas vezes com os nomes 'Responsável', 'Atribuído a' ou 'Coordenador'. Exemplos Alice JohnsonajohnsonBob Smithbsmith | |||
Atividades da gestão de problemas
| 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. A duração 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 obter Isso geralmente é inferido a partir de uma mudança de status para "Root Cause Identified" ou capturado quando um campo "Root Cause" é preenchido pela primeira vez. Captura Capture o registro de data e hora da mudança de status ou da primeira atualização de um campo de texto "Root Cause". Tipo de evento inferred | |||
| Correção permanente implementada | Este evento indica que a solução técnica permanente, geralmente gerenciada por meio de uma solicitação de mudança, foi implementada com sucesso. Ele marca a conclusão do trabalho de correção. | ||
| Por que isso importa Esta atividade conclui 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 gestão de mudanças na resolução dos problemas. Onde obter Normalmente, isso é inferido quando o status do registro de problema muda para "Resolved" ou "Solution Implemented", geralmente após o fechamento da solicitação de mudança vinculada. Captura Infira a partir de uma mudança de status do problema para "Resolved" ou do registro de data e hora de conclusão do registro de mudança associado. Tipo de evento inferred | |||
| Investigação iniciada | Este evento marca a transição do registro de problema de um estado novo ou pendente para um estado de investigação ativa. Ele indica que um analista começou formalmente a trabalhar no diagnóstico do problema. | ||
| Por que isso importa Esta atividade ajuda a medir o tempo de resposta inicial e a velocidade de processamento do backlog. A duração entre a criação e o início da investigação é um indicador importante da capacidade de resposta da equipe. Onde obter Isso geralmente é inferido a partir de uma mudança de status no histórico do registro, como a transição de "New" para "In Progress" ou "Under Investigation". Captura Capture o registro de data e hora em que o status muda pela primeira vez para um estado de investigação ativa. Tipo de evento inferred | |||
| Registro de problema criado | Esta é a criação inicial de um registro de problema. Ela marca o início formal do processo de gestão de problemas e estabelece o registro de data e hora de referência para todas as análises posteriores. | ||
| Por que isso importa Esta atividade é o principal ponto de início de cada instância do processo. Analisar o tempo entre esse evento e os demais é essencial para entender a duração geral do processo e os atrasos iniciais. Onde obter Normalmente, isso é capturado a partir do registro de data e hora de criação do registro de problema principal ou da tabela de tickets. Quase sempre existe um campo explícito para isso nos dados de origem. Captura Use o registro de data e hora "Created On" ou equivalente na tabela principal de problemas. Tipo de evento explicit | |||
| Registro de problema fechado | Esta é a atividade final do ciclo de vida, indicando que o registro de problema foi fechado administrativamente e que nenhuma ação adicional é esperada. O caso é considerado concluído e arquivado. | ||
| Por que isso importa Esta atividade é o principal ponto final da maioria das instâncias do processo. Ela é essencial para calcular a duração total de ponta a ponta do processo de gestão de problemas. Onde obter Quase sempre, este é um evento explícito capturado a partir de uma mudança de status para "Closed" no log de histórico do registro. Captura Use o registro de data e hora em que o status do registro é definido como "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 representa a transferência do processo de gestão de problemas para o processo de gestão de mudanças, com o objetivo de implementar uma correção permanente. | ||
| 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 interseção entre a gestão de problemas e a gestão de mudanças. Onde obter Normalmente, este é um evento explícito encontrado no histórico de relacionamentos ou links do registro, mostrando uma associação com um registro de mudança. Captura 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 ou alternativa foi documentada e disponibilizada. Essa ação ajuda a reduzir o impacto sobre os usuários finais enquanto uma correção permanente é desenvolvida. | ||
| Por que isso importa O tempo necessário para fornecer uma solução alternativa é um KPI importante para medir a capacidade da equipe de restaurar o serviço rapidamente. Esta atividade ajuda a analisar a velocidade e a eficácia das soluções temporárias. Onde obter Isso pode ser capturado pelo primeiro registro de data e hora em que um campo de texto "Workaround" é preenchido, uma ação "Communicate Workaround" é registrada ou um indicador específico "Workaround Available" é definido. Captura Detecte o primeiro preenchimento de um campo de solução alternativa ou um evento de publicação relacionado. Tipo de evento explicit | |||
| Aguardando implementação da mudança | Esta atividade representa um estado em que o registro de problema está suspenso, aguardando a conclusão de uma solicitação de mudança associada. A equipe de problemas está esperando que a equipe de mudanças implemente a correção. | ||
| Por que isso importa Isolar esse período de espera ajuda a medir com precisão o tempo gasto no processo de gestão de mudanças em comparação com o processo de gestão de problemas, aumentando a responsabilização. Onde obter Isso geralmente é inferido a partir de uma mudança de status para "Pending Change" ou "Fix in Progress" no histórico do registro de problema. Captura Capture o registro de data e hora em que o status do registro de problema muda 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 ou equipe de suporte específico. Ela registra a transferência da propriedade e 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 geralmente indica ineficiência no processo. Onde obter Essas informações geralmente estão em um log de auditoria ou em uma tabela de histórico que registra alterações no campo "Assignment Group" ou "Support Team" do registro de problema. Captura Identifique todas as alterações 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 na prioridade, no impacto ou na urgência do registro de problema após sua criação inicial. Ela reflete uma reavaliação da importância do problema para a empresa. | ||
| Por que isso importa Analisar mudanças de prioridade ajuda a identificar problemas que são frequentemente escalados ou rebaixados, o que pode afetar a alocação de recursos e a conformidade com o SLA. Onde obter Normalmente, isso é registrado em um log de auditoria ou em uma tabela de histórico de alterações que acompanha modificações no campo "Priority". Captura Acompanhe todas as atualizações no campo "Priority" no histórico de alterações do registro. Tipo de evento explicit | |||
| Registro de problema cancelado | Esta atividade representa o encerramento de um registro de problema antes que uma resolução seja alcançada. Isso pode acontecer se o registro tiver sido criado por engano, for duplicado ou não for mais relevante. | ||
| Por que isso importa Analisar cancelamentos ajuda a entender a qualidade dos registros de problemas recebidos. Uma taxa elevada de cancelamento pode indicar a necessidade de melhorar o treinamento ou os critérios de qualificação. Onde obter Isso é capturado a partir de uma mudança de status para "Cancelled", "Rejected" ou "Withdrawn" no histórico do registro. Captura Identifique o registro de data e 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 anteriormente resolvido ou fechado retorna a um estado ativo. Normalmente, 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 da resolução. Acompanhar esta atividade é essencial para medir as taxas de resolução na primeira tentativa e identificar soluções ineficazes. Onde obter Este evento é capturado monitorando o histórico de status do registro em busca de uma transição de um estado fechado ou resolvido de volta para um estado aberto ou em andamento. Captura Identifique mudanças de status de "Resolved" ou "Closed" de volta 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 efetivamente o problema subjacente e que o serviço normal foi restaurado. É a etapa final de validação antes do fechamento. | ||
| Por que isso importa Esta etapa funciona como uma verificação de qualidade da resolução. Analisar o tempo necessário para a verificação pode destacar atrasos na confirmação do sucesso de uma correção. Onde obter Isso pode ser um status explícito, como "Verification", ou ser inferido a partir da transição para um estado "Resolved" ou "Solved". Captura Capture o registro de data e hora em que o status muda para um estado que indica 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 melhorias no processo. | ||
| Por que isso importa Acompanhar a conclusão da PIR é importante para a conformidade do processo e a melhoria contínua. Isso garante que insights valiosos de problemas importantes sejam registrados e transformados em ações. Onde obter Isso geralmente é capturado pela conclusão de uma subtarefa de PIR, por uma mudança de status para "Review Complete" ou pelo preenchimento de um campo de data de conclusão da PIR. Captura 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 necessário para alcançar uma resolução ou um marco de resposta excedeu a meta predefinida do Acordo de Nível de Serviço (SLA). É um evento gerado pelo sistema ou calculado. | ||
| Por que isso importa Acompanhar violações de SLA é fundamental para a gestão da 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 obter Isso pode ser um indicador ou evento específico registrado pelo sistema, ou pode ser calculado comparando o registro de data e hora da resolução com a data de vencimento do SLA. Captura Calcule comparando os registros de data e hora da resolução ou resposta com os registros de data e hora das metas de SLA, ou capture um evento de violação gerado pelo sistema. Tipo de evento calculated | |||
Guias de extração
Os métodos de extração variam conforme o sistema. Para obter instruções detalhadas,
Pronto para começar?
Escolha um guia específico do sistema para obter instruções personalizadas ou use este Template genérico para iniciar hoje mesmo a análise do seu processo de gerenciamento de problemas.
Eleve seu gerenciamento de problemas. Comece agora
Descubra ineficiências e resolva problemas mais rapidamente com insights orientados por dados.
Não é necessário cartão de crédito. Configure em poucos minutos.