Seu Template de dados para gerenciamento de problemas
Seu Template de dados para gerenciamento de problemas
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.
Atributos do gerenciamento de problemas
| 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 | |||
Atividades do gerenciamento 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. 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 | |||
Guias de extração
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.
Não é necessário informar cartão de crédito. A configuração leva poucos minutos.