Seu Template de dados de gestão de problemas
Seu Template de dados de gestão de problemas
- Campos de dados essenciais para a análise da causa raiz
- Marcos de processo padronizados para acompanhamento
- Orientações específicas de extração para o BMC Helix ITSM
Atributos da gestão de problemas
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
Activity
|
A Task específica ou o evento de alteração de status que ocorreu. | ||
|
Descrição
Esse atributo representa a etapa específica executada no ciclo de vida de Problem Management, como 'Problem Record Logged', 'Root Cause Identified' ou 'Solution Database Updated'. No BMC Helix, esses dados geralmente são derivados do histórico de status, dos registros de auditoria ou de carimbos de data e hora de transações específicas no módulo Problem Investigation. Esse atributo é o núcleo da descoberta de processos. Ao analisar a sequência dessas atividades, a ferramenta de Process Mining constrói o mapa do processo, revelando o fluxo real de trabalho em comparação com o processo projetado. Ela destaca loops, retrabalho e desvios do procedimento operacional padrão. Nomes precisos de atividades são essenciais para entender o que realmente aconteceu durante o ciclo de vida. Esses dados permitem medir os tempos de transição entre etapas específicas, como o tempo entre a identificação de uma causa raiz e o início de uma solicitação de mudança.
Por que isso importa
Ele define os nós do mapa do processo e permite visualizar o Workflow.
Onde obter
Derivado do histórico de status de PBM:Problem Investigation ou PBM:AuditLogSystem
Exemplos
Registro de problema criadoAtribuído ao grupo de suporteInvestigação iniciadaCausa raiz identificada
|
|||
|
Horário do evento
EventTime
|
O carimbo de data e hora em que a atividade específica ocorreu. | ||
|
Descrição
Esse atributo registra a data e a hora exatas em que uma atividade ocorreu. No BMC Helix ITSM, corresponde a campos como 'Submit Date', 'Last Modified Date' ou a carimbos de data e hora específicos registrados nas tabelas de histórico relacionadas às alterações de status. Na análise, esse atributo é usado para ordenar os eventos cronologicamente e calcular durações. Ele permite medir os tempos de ciclo entre quaisquer dois pontos do processo, como 'Investigation Cycle Time' ou 'Workaround Publication Lead Time'. Carimbos de data e hora precisos são essenciais para identificar gargalos. Ao calcular a diferença de tempo entre eventos consecutivos, os analistas conseguem apontar exatamente onde os atrasos estão ocorrendo, seja durante a atribuição inicial ou na fase de revisão final.
Por que isso importa
Ele permite calcular todos os KPIs baseados em duração e ordenar os eventos.
Onde obter
Tabelas de histórico ou registros de auditoria associados a PBM:Problem Investigation
Exemplos
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
|
|||
|
Registro de problema
ProblemRecord
|
O identificador exclusivo do caso de investigação do problema. | ||
|
Descrição
Esse atributo funciona como o identificador central do caso no processo de Problem Management. No BMC Helix ITSM, normalmente corresponde ao campo 'Problem ID' (por exemplo, PBI00000012345), encontrado no formulário PBM:Problem Investigation. Ele conecta todas as atividades relacionadas, desde o registro inicial do problema até o encerramento final e a revisão pós-implementação. Na análise de Process Mining, esse atributo é usado para agrupar eventos individuais em uma única instância do processo. Ele permite que os analistas visualizem a jornada completa de uma investigação específica de problema. Sem esse identificador, seria impossível correlacionar a sequência de ações realizadas por diferentes grupos de suporte e coordenadores. Esse campo funciona como a chave primária do Event Log e é essencial para todas as agregações no nível do caso, como calcular o tempo total de ciclo por problema ou contar a quantidade de problemas por nível de prioridade.
Por que isso importa
É a chave fundamental necessária para construir a visão do processo e acompanhar o ciclo de vida de problemas específicos.
Onde obter
Formulário PBM:Problem Investigation, campo 'Problem ID'
Exemplos
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
Sistema de origem
SourceSystem
|
O sistema de onde os dados foram originados. | ||
|
Descrição
Esse atributo identifica o sistema de software do qual os dados do processo foram extraídos, neste caso, 'BMC Helix ITSM'. Ele é especialmente importante em ambientes com vários sistemas, nos quais o Process Mining pode agregar dados de diferentes ferramentas de ITSM, desenvolvimento ou fornecedores externos. Na análise, esse campo funciona como uma tag de metadados que valida a origem do registro. Se a visão de Process Mining combinar dados do BMC Helix para Problem Management com um sistema separado de desenvolvimento de software, como o Jira, esse atributo ajudará a segmentar a análise pela ferramenta de origem. Ele também ajuda na solução de problemas técnicos. Quando surgem problemas de qualidade dos dados, conhecer o sistema de origem permite que os engenheiros de dados rastreiem o problema até a rotina de extração ou o banco de dados de origem específico.
Por que isso importa
Ele oferece rastreabilidade e contexto, especialmente em visões de processos que envolvem vários sistemas.
Onde obter
Definido durante o processo de extração
Exemplos
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
|
|||
|
Última atualização dos dados
LastDataUpdate
|
O carimbo de data e hora em que os dados foram extraídos ou atualizados pela última vez. | ||
|
Descrição
Esse atributo indica quando os dados foram carregados pela última vez no aplicativo de Process Mining. Ele garante que os analistas saibam quão atuais são os dados que estão visualizando. Normalmente, é gerado pelo script de extração ou pela ferramenta de pipeline de dados. Na análise, isso ajuda a evitar decisões baseadas em dados desatualizados. Por exemplo, se um gestor estiver analisando 'Open Problem Records', saber que os dados foram atualizados há uma hora, e não há uma semana, muda significativamente a interpretação da carga de trabalho atual. Ele também é usado em cargas incrementais de dados. Ao acompanhar o horário da última atualização, o processo de ETL pode buscar apenas os registros alterados desde a extração anterior, otimizando a performance e reduzindo a carga no sistema.
Por que isso importa
Ele garante a atualização dos dados e ajuda nas estratégias de carregamento incremental.
Onde obter
Horário do sistema no momento da extração
Exemplos
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
|
|||
|
Categoria da causa raiz
RootCauseCategory
|
A classificação da causa subjacente do problema. | ||
|
Descrição
Esse atributo contém a categoria selecionada quando a causa raiz é identificada, como 'Software Error', 'Hardware Failure' ou 'Process Gap'. No BMC Helix, normalmente é selecionado nos menus 'Root Cause' ou 'Generic Categorization'. Esse atributo é essencial para a visão 'Fix Effectiveness and Quality'. Ele permite que a organização correlacione tipos específicos de causas raiz com taxas de retrabalho ou investigações longas. Por exemplo, pode revelar que problemas de 'Software Error' levam consistentemente o dobro do tempo para serem resolvidos em comparação com problemas de 'Hardware Failure'. Ele também é usado para calcular a 'Root Cause Categorization Rate'. Uma porcentagem alta de valores 'Unknown' ou 'Other' nesse campo sugere a necessidade de melhorar o treinamento técnico ou oferecer opções de categorização mais detalhadas.
Por que isso importa
Ele permite analisar tendências de problemas sistêmicos e dá suporte ao gerenciamento proativo de problemas.
Onde obter
Formulário PBM:Problem Investigation, campos das abas 'Root Cause' ou de categorização
Exemplos
Módulo de softwareInfraestrutura de redeErro humano
|
|||
|
CI do serviço
ServiceCI
|
O principal serviço de negócio ou item de configuração afetado. | ||
|
Descrição
Esse atributo identifica o Item de Configuração de Serviço (CI) relacionado ao problema, como 'Email Service', 'SAP ERP' ou 'Wi-Fi Network'. No BMC Helix, geralmente corresponde ao campo 'Service+' ou ao relacionamento com o CI principal. Na análise, ele permite segmentar os registros de problemas por produto ou serviço. Ajuda a liderança de TI a entender quais serviços são mais frágeis e geram mais investigações de problemas. Isso alimenta o Dashboard 'Throughput and Priority Volume' ao adicionar uma dimensão de produto. Correlacionar esse atributo com 'Investigation Cycle Time' pode mostrar se determinados serviços complexos, como um sistema bancário central, exigem naturalmente períodos de investigação mais longos do que serviços comuns, como impressão.
Por que isso importa
Ele conecta a performance do processo a produtos ou serviços específicos do negócio.
Onde obter
Formulário PBM:Problem Investigation, campo 'ServiceCI' ou 'CI Name'
Exemplos
Serviço de e-mailSistema de folha de pagamentoVPN corporativa
|
|||
|
Coordenador de problemas
ProblemCoordinator
|
O usuário individual responsável por coordenar a investigação. | ||
|
Descrição
Esse atributo identifica a pessoa responsável pelo registro de problema. No BMC Helix ITSM, corresponde ao campo 'Problem Coordinator'. Essa pessoa é responsável pelo ciclo de vida do problema, mesmo quando as Tasks são delegadas a outras pessoas. Esse atributo dá suporte ao Dashboard 'Support Group Workload Distribution'. Ele ajuda os gestores a identificar se determinadas pessoas estão sobrecarregadas com investigações enquanto outras têm capacidade disponível. Também permite analisar a performance individual, ajudando a identificar necessidades de treinamento ou profissionais de alto desempenho. No Process Mining, esse campo funciona como um atributo de recurso. Ele ajuda a visualizar como o trabalho flui entre as pessoas e pode destacar pontos únicos de falha, nos quais o processo depende demais de um especialista específico.
Por que isso importa
Ele permite analisar recursos e equilibrar a carga de trabalho no nível individual.
Onde obter
Formulário PBM:Problem Investigation, campo 'Problem Coordinator'
Exemplos
John DoeJane SmithAdministrador de sistemas
|
|||
|
Data de vencimento do SLA
SLADueDate
|
A data e a hora limite até as quais o problema deve ser resolvido. | ||
|
Descrição
Esse atributo contém o prazo para a resolução do problema com base no acordo de nível de serviço. No BMC Helix, geralmente corresponde a 'Target Resolution Date' ou a um carimbo de data e hora calculado de um marco do SLA. Esse atributo é a referência para o Dashboard 'SLA Compliance and Breach Trends'. Ao comparar esse carimbo de data e hora com o carimbo da atividade 'Resolution Verified', o sistema calcula se o SLA foi cumprido ou violado. Visualizar essa data permite que os analistas entendam quão perto do limite a equipe está concluindo o trabalho. Os problemas estão sendo resolvidos com dias de antecedência ou terminam consistentemente poucos minutos antes do descumprimento? Esse insight orienta o planejamento de capacidade.
Por que isso importa
É a referência para calcular todas as métricas de conformidade e pontualidade.
Onde obter
Formulário PBM:Problem Investigation, campo 'Target Resolution Date'
Exemplos
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
Grupo de suporte
SupportGroup
|
A equipe técnica atualmente responsável pela investigação do problema. | ||
|
Descrição
Esse atributo representa o grupo de suporte específico, como 'Server Admin' ou 'Database Support', responsável pelo registro de problema no momento do evento. No BMC Helix, corresponde ao campo 'Assigned Group'. Esse atributo é essencial para os Dashboards 'Support Group Workload Distribution' e 'Support Group Reassignment Analysis'. Ele permite que os analistas segmentem o mapa do processo por equipe, revelando quais grupos estão lidando com o maior volume e quais são gargalos no processo de investigação. Analisar as transferências entre grupos de suporte ajuda a identificar o comportamento de 'pingue-pongue', em que um chamado passa de uma equipe para outra sem ser resolvido. Isso geralmente aponta para responsabilidades pouco claras ou uma gestão do conhecimento inadequada na organização.
Por que isso importa
Ele permite analisar a organização e detectar gargalos no nível da equipe.
Onde obter
Formulário PBM:Problem Investigation, campo 'Assigned Group'
Exemplos
Service Desk Nível 1Suporte de back officeAdministração de redes
|
|||
|
Motivo da investigação
InvestigationDriver
|
O motivo pelo qual a investigação do problema foi iniciada. | ||
|
Descrição
Esse atributo classifica o gatilho do registro de problema, como 'Incident Volume', 'Major Incident', 'Vendor Notification' ou 'Proactive Trend Analysis'. No BMC Helix, corresponde ao campo 'Investigation Driver'. Esse atributo dá suporte ao Dashboard 'Proactive Identification Trends'. Ele permite que a organização meça a mudança de uma atuação reativa, respondendo a incidentes, para uma gestão proativa de problemas, identificando riscos antes que eles se manifestem. Analisar os fluxos do processo por 'Investigation Driver' pode revelar comportamentos diferentes. Por exemplo, problemas 'Proactive' podem permanecer mais tempo na fila porque não causam indisponibilidades imediatas, enquanto problemas motivados por 'Major Incident' avançam rapidamente pelo processo.
Por que isso importa
Ele diferencia o trabalho reativo do proativo, um indicador importante de maturidade.
Onde obter
Formulário PBM:Problem Investigation, campo 'Investigation Driver'
Exemplos
ReativoProativoIncidentes recorrentes
|
|||
|
Prioridade
Priority
|
A prioridade calculada do problema com base no impacto e na urgência. | ||
|
Descrição
Esse atributo indica o nível de prioridade do registro de problema, como Critical, High, Medium ou Low. No BMC Helix, normalmente é um campo calculado a partir das seleções de Impact e Urgency. Na análise, ele é usado para o Dashboard 'Throughput and Priority Volume'. Ele permite que as organizações verifiquem se os recursos estão alinhados corretamente às necessidades do negócio. Por exemplo, problemas 'Critical' teoricamente deveriam ter tempos de atribuição inicial mais rápidos e tempos totais de ciclo menores do que problemas de prioridade 'Low'. Filtrar por prioridade ajuda a direcionar os esforços de melhoria. Um gargalo em um processo de prioridade 'Low' pode ser aceitável, mas o mesmo atraso em um processo 'Critical' representa um risco significativo para a continuidade do negócio e a conformidade com o SLA.
Por que isso importa
Ele segmenta a análise por criticidade do negócio e dá suporte à análise de SLA.
Onde obter
Formulário PBM:Problem Investigation, campo 'Priority'
Exemplos
CríticoAltoMédioBaixo
|
|||
|
Quantidade de incidentes relacionados
RelatedIncidentCount
|
A quantidade de incidentes vinculados a esse registro de problema. | ||
|
Descrição
Esse atributo quantifica o impacto do problema contando a quantidade de incidentes associados a ele. No BMC Helix, normalmente corresponde à contagem de registros no formulário HPD:Help Desk relacionados ao registro PBM. Esse atributo alimenta o KPI 'Incident Linkage Density'. Uma quantidade alta indica um problema de grande impacto, gerando muito volume para a central de serviços. Correlacioná-lo com 'Priority' garante que problemas de alto volume sejam realmente tratados como críticos. Ele também ajuda a priorizar o backlog. Um registro de problema com 500 incidentes vinculados provavelmente deve ser priorizado em relação a um problema 'Critical' com apenas 1 incidente, pois resolver o primeiro liberará mais capacidade da central de serviços.
Por que isso importa
Ele quantifica o impacto operacional e o impacto para os usuários associados ao problema.
Onde obter
Calculado contando as linhas relacionadas em HPD:Associations ou HPD:Help Desk
Exemplos
15120
|
|||
|
SLA violado
IsSLABreached
|
Um indicador que mostra se a resolução do problema ultrapassou o tempo permitido. | ||
|
Descrição
Este atributo booleano indica se o registro do problema violou o acordo de nível de serviço. Ele é calculado comparando o carimbo de data e hora de 'Resolution Verified' com a 'SLA Due Date' ou é extraído diretamente do status do SLM. Este atributo é fundamental para o Dashboard 'SLA Compliance and Breach Trends'. Ele permite uma segmentação binária simples do processo: em conformidade ou fora de conformidade. Assim, fica fácil isolar as características dos processos que falharam, por exemplo: 'Os casos que violam o SLA sempre envolvem o Support Group X?'. Ele funciona como um filtro principal para a análise da causa raiz de falhas de processo. Os analistas podem filtrar por 'IsSLABreached = True' e examinar o mapa do processo para identificar onde o tempo foi perdido, como em longos tempos de espera pela aprovação do fornecedor.
Por que isso importa
Simplifica os relatórios de conformidade e a análise de falhas.
Onde obter
Formulário SLM:Measurement ou calculado
Exemplos
truefalse
|
|||
|
Contagem de reatribuições
ReassignmentCount
|
O número total de vezes que o grupo de suporte foi alterado. | ||
|
Descrição
Este atributo conta quantas vezes a atividade 'Assigned to Support Group' ocorre em um único caso. Ele mede diretamente o atrito do processo e a eficiência do roteamento. Este atributo alimenta o gráfico 'Support Group Reassignment Analysis'. Valores altos, indicando um efeito de pingue-pongue, mostram que a triagem inicial está falhando ou que não existe uma responsabilidade clara por problemas complexos. É um indicador antecedente do aumento do tempo de ciclo. Os gestores usam esse dado para identificar oportunidades de treinamento. Se o Service Desk reatribui consistentemente problemas de 'Database' primeiro para 'Network', e depois 'Network' os envia para 'Database', a contagem de reatribuições aumenta, destacando a necessidade de scripts melhores para o diagnóstico inicial.
Por que isso importa
Identifica desperdícios, atritos e falta de responsabilidade no processo.
Onde obter
Calculado com base no histórico de atividades
Exemplos
015
|
|||
|
ID da solicitação de mudança relacionada
RelatedChangeRequestId
|
O identificador da solicitação de mudança iniciada para corrigir o problema. | ||
|
Descrição
Esse atributo contém o ID da Change Request, como CRQ0000..., vinculada ao registro de problema. Ele representa a transição da investigação para a implementação de uma correção permanente. Esse atributo é necessário para o KPI 'Root Cause to Change Lead Time'. Ele permite que a ferramenta de Process Mining meça o atraso entre a descoberta da causa raiz e o início do processo de mudança. Esse é um ponto comum de transferência em que o ritmo se perde. Ele também ajuda a verificar a 'completude do processo'. Um registro de problema encerrado com status 'Completed', mas sem uma solicitação de mudança relacionada ou uma solução alternativa, pode indicar uma violação do processo, na qual a causa raiz foi encontrada, mas nunca foi realmente corrigida.
Por que isso importa
Ele conecta o processo de Problem Management ao processo de Change Management.
Onde obter
PBM:Investigation Associations ou aba Relationship
Exemplos
CRQ00000021345CRQ00000021346
|
|||
|
Região
Region
|
A região geográfica associada ao problema. | ||
|
Descrição
Esse atributo especifica a localização geográfica, como 'North America' ou 'EMEA', onde o problema se originou ou está sendo gerenciado. No BMC Helix, geralmente aparece nos campos 'Region' ou 'Site' associados ao solicitante ou ao ativo afetado. Na análise, ele dá suporte à segmentação geográfica. Ajuda a identificar se determinadas regiões apresentam volumes maiores de problemas ou tempos de resolução mais longos. Isso pode revelar diferenças na disponibilidade de equipes de suporte ou na qualidade da infraestrutura entre diferentes localidades. Ele é valioso para organizações globais que precisam garantir uma prestação de serviços consistente. Se o 'Investigation Cycle Time' em 'APAC' for o dobro do registrado em 'NAM', isso indica a necessidade de investigar a alocação de recursos ou a adesão ao processo nessa região.
Por que isso importa
Ele permite comparar a performance do processo entre regiões.
Onde obter
Formulário PBM:Problem Investigation, campo 'Region'
Exemplos
AméricasEMEAAPAC
|
|||
|
Status da solução alternativa
WorkaroundStatus
|
Indica se uma solução alternativa válida foi identificada e publicada. | ||
|
Descrição
Este atributo acompanha o estado da solução temporária (Workaround). Pode ser um simples valor booleano (Has Workaround) ou uma string de status. No BMC Helix, geralmente é derivado da presença de texto no campo 'Workaround' ou de um indicador de status específico. Este atributo é fundamental para o Dashboard 'Workaround Publication Performance'. Ele mostra com que eficiência a equipe reduz o impacto enquanto investiga a causa raiz. Uma visão do processo filtrada por 'No Workaround' destaca os casos em que o negócio está sofrendo o impacto total durante a investigação. Ele também apoia auditorias de qualidade. Encerrar um registro de problema sem uma correção permanente (Change Request) E sem uma solução alternativa geralmente indica uma falha de processo que precisa ser analisada.
Por que isso importa
Mede a eficácia da redução do impacto durante a investigação.
Onde obter
Formulário PBM:Problem Investigation, verificação do conteúdo do campo 'Workaround'
Exemplos
AtivoNenhumRetirado
|
|||
|
Tempo de ciclo da investigação
InvestigationCycleTime
|
O tempo entre o início da investigação e a identificação da causa raiz. | ||
|
Descrição
Este é um atributo de duração calculado que mede o tempo entre a atividade 'Investigation Commenced' e a atividade 'Root Cause Identified'. Ele representa o principal tempo que agrega valor no processo de gestão de problemas. Essa métrica alimenta o Dashboard 'Root Cause Investigation Cycle Time'. Ela ajuda os gestores a entender a complexidade técnica dos problemas e a eficiência das equipes de investigação. Anomalias aqui, como tempos extremamente curtos, podem indicar uma suposição, enquanto tempos muito longos indicam investigações paradas. Comparando essa métrica entre 'Support Groups' e 'Priorities', a organização consegue identificar quais equipes precisam de ferramentas, treinamento ou suporte de fornecedores para diagnosticar problemas mais rapidamente.
Por que isso importa
É a principal métrica de eficiência da fase de investigação técnica.
Onde obter
Calculado com base nos carimbos de data e hora das atividades
Exemplos
4500000120000
|
|||
Atividades da gestão de problemas
| Atividade | Descrição | ||
|---|---|---|---|
|
Atribuído ao grupo de suporte
|
A atribuição do registro de problema a uma equipe técnica específica. Capturada monitorando alterações no campo 'Assigned Group'. | ||
|
Por que isso importa
Essencial para medir transferências, efeitos de pingue-pongue e o KPI 'Mean Time to Initial Assignment'.
Onde obter
Formulário PBM:Problem Investigation, histórico do campo 'Assigned Group' ou registro de auditoria.
Captura
Comparar o campo 'Assigned Group' antes e depois da atualização
Tipo de evento
inferred
|
|||
|
Causa raiz identificada
|
O momento em que o registro de problema passa para um estado que indica que a causa é conhecida. Inferido quando o Status muda para 'Root Cause Identified'. | ||
|
Por que isso importa
Um marco crítico para o Dashboard 'Root Cause Investigation Cycle Time'. Sinaliza a passagem da análise para a definição da solução.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Root Cause Identified'.
Captura
Comparar o campo de status para identificar a transição para Root Cause Identified
Tipo de evento
inferred
|
|||
|
Investigação iniciada
|
A transição do registro de problema para uma fase ativa de análise. É inferida quando o campo Status muda para 'Under Investigation'. | ||
|
Por que isso importa
Marca o início da fase efetiva de trabalho e dá suporte ao KPI 'Investigation Cycle Time'.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Under Investigation'.
Captura
Comparar o campo de status para identificar a transição para Under Investigation
Tipo de evento
inferred
|
|||
|
Registro de problema cancelado
|
O encerramento de um registro de problema antes da resolução. Capturado quando o status se torna 'Cancelled' ou 'Rejected'. | ||
|
Por que isso importa
Identifica esforço desperdiçado ou duplicidades válidas. Representa um ponto final alternativo.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Cancelled' ou 'Rejected'.
Captura
Comparar o campo de status para identificar a transição para Cancelled
Tipo de evento
inferred
|
|||
|
Registro de problema criado
|
A criação inicial de um registro de investigação de problema no sistema. Esse evento é capturado explicitamente quando uma nova entrada é salva no formulário PBM:Problem Investigation. | ||
|
Por que isso importa
Marca o início da instância do processo. É essencial para calcular os tempos totais de ciclo e as métricas de resposta inicial.
Onde obter
Formulário PBM:Problem Investigation, carimbo de data e hora de 'Submit Date' ou registro de criação com 'Status' = 'Draft'.
Captura
Registrado quando o registro PBM:Problem Investigation é criado
Tipo de evento
explicit
|
|||
|
Registro de problema encerrado
|
O encerramento administrativo final do registro de problema. Esse evento encerra a instância do processo. | ||
|
Por que isso importa
O evento final padrão. Necessário para a análise completa do tempo de ciclo e o cálculo de 'Incident Linkage Density'.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Closed'.
Captura
Comparar o campo de status para identificar a transição para Closed
Tipo de evento
inferred
|
|||
|
Resolução verificada
|
O momento em que a correção permanente é confirmada como bem-sucedida. Inferido quando o Status muda para 'Solution Implemented' ou 'Completed'. | ||
|
Por que isso importa
Usado para a 'Problem SLA Adherence Rate'. Confirma que o trabalho técnico foi concluído.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Solution Implemented' ou 'Completed'.
Captura
Comparar o campo de status para identificar a transição para Solution Implemented
Tipo de evento
inferred
|
|||
|
Solicitação de mudança iniciada
|
A vinculação de uma Infrastructure Change Request à Problem Investigation. Isso sinaliza o início da fase de implementação. | ||
|
Por que isso importa
É essencial para o KPI 'Root Cause to Change Lead Time' e para identificar silos entre os processos de Problem Management e Change Management.
Onde obter
Tabela PBM:Investigation_Associations ou preenchimento do campo 'Infrastructure Change ID'.
Captura
Registrado quando a associação é criada em PBM:Investigation_Associations
Tipo de evento
explicit
|
|||
|
Solução alternativa definida
|
A inserção ou atualização de texto no campo Workaround do registro de problema. Esse evento indica que uma solução temporária foi documentada. | ||
|
Por que isso importa
Dá suporte ao KPI 'Workaround Publication Lead Time' e indica a mitigação do impacto do incidente.
Onde obter
Formulário PBM:Problem Investigation, alterações no campo de texto 'Workaround'.
Captura
Comparar o conteúdo do campo 'Workaround' para identificar atualizações não nulas
Tipo de evento
inferred
|
|||
|
Banco de soluções atualizado
|
A transição do registro para o status 'Solution Database', indicando que uma correção permanente foi proposta ou identificada. | ||
|
Por que isso importa
Acompanha o avanço da definição da solução antes da implementação.
Onde obter
Formulário PBM:Problem Investigation, campo 'Status' = 'Solution Database'.
Captura
Comparar o campo de status para identificar a transição para Solution Database
Tipo de evento
inferred
|
|||
|
Coordenador reatribuído
|
Uma alteração no Problem Coordinator individual dentro de um grupo de suporte. Capturada monitorando o campo 'Problem Coordinator'. | ||
|
Por que isso importa
Ajuda a analisar a distribuição da carga de trabalho e os gargalos de recursos individuais.
Onde obter
Formulário PBM:Problem Investigation, histórico do campo 'Problem Coordinator'.
Captura
Comparar o campo 'Problem Coordinator' antes e depois da atualização
Tipo de evento
inferred
|
|||
|
Erro conhecido promovido
|
A criação de um registro de Known Error vinculado à investigação do problema. Esse é um evento de criação de registro relacionado. | ||
|
Por que isso importa
Indica a formalização do problema para comunicação mais ampla e acompanhamento de longo prazo.
Onde obter
Criação de um registro em PBM:Known Error vinculado ao ID de PBM:Problem Investigation.
Captura
Registrado quando o registro PBM:Known Error é criado
Tipo de evento
explicit
|
|||
|
Revisão pós-implementação realizada
|
A conclusão da fase de PIR. Capturada por uma transição de status para fora de um estado de PIR ou pelo encerramento de uma Task de PIR vinculada. | ||
|
Por que isso importa
Dá suporte direto a 'Post Implementation Review Compliance' e às auditorias de qualidade do processo.
Onde obter
Formulário PBM:Problem Investigation, sinalizador específico 'PIR Required' ou conclusão de uma Task vinculada do tipo 'PIR'.
Captura
Derivado da conclusão do status de PIR ou do encerramento da Task de PIR
Tipo de evento
inferred
|
|||
Guias de extração
Pronto para começar?
Transforme a estabilidade dos seus serviços aplicando hoje este Template aos seus dados do BMC Helix ITSM. Nossa equipe está à disposição para ajudar se você tiver dúvidas sobre a configuração.
Elimine hoje os gargalos da gestão de problemas
Reduza os tempos de ciclo em 30% e melhore a estabilidade dos serviços.
Não é necessário cartão de crédito. Configure em poucos minutos.