Seu Template de dados para gestão de solicitações de serviço

BMC Helix ITSM
Seu Template de dados para gestão de solicitações de serviço

Seu Template de dados para gestão de solicitações de serviço

Este Template apresenta os atributos de dados essenciais para coletar e as principais atividades para acompanhar no processo de gestão de solicitações de serviço. Ele também traz orientações práticas para extrair esses dados do BMC Helix ITSM com eficiência. Use este material para simplificar a preparação dos dados e iniciar suas iniciativas de Process Mining com segurança.
  • Atributos recomendados para coleta
  • Principais atividades para acompanhar
  • Orientações para extrair dados do BMC Helix ITSM
Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Atributos da gestão de solicitações de serviço

Esses campos de dados são essenciais para criar um Event Log completo e permitir uma análise aprofundada do processo de gestão de solicitações de serviço.
5 Obrigatório 6 Recomendado 9 Opcional
Nome Descrição
Atividade
ActivityName
Nome do evento ou da tarefa específica que ocorreu em determinado momento do ciclo de vida da solicitação de serviço.
Descrição

Este atributo descreve uma etapa específica ou uma mudança de status no processo de solicitação de serviço, como 'Solicitação em revisão', 'Atendimento em andamento' ou 'Solicitação de serviço resolvida'. Cada atividade representa um evento na jornada completa de uma solicitação de serviço.

Analisar a sequência e a frequência das atividades é a base do Process Mining. Isso permite descobrir mapas de processo, identificar gargalos e analisar variantes do processo. Entender quais atividades ocorrem, em que ordem e com que frequência é essencial para otimizar o processo.

Por que isso importa

As atividades são os elementos que compõem o mapa do processo. Acompanhar cada uma permite visualizar e analisar o fluxo do processo e entender como o trabalho é realizado na prática.

Onde encontrar

Em geral, este dado é derivado de mudanças nos campos 'Status' e 'Status Reason' do formulário 'SRM:Request' ou de logs de aplicativos relacionados ao atendimento, como Incident e Work Order.

Exemplos
Solicitação aguardando aprovaçãoAtendimento em andamentoSolicitação de serviço resolvidaSolicitação de serviço fechada
Hora de início
EventStartTime
Data e hora que indicam quando uma atividade ou um evento específico começou.
Descrição

Este atributo registra a data e a hora exatas em que uma atividade começou. Cada evento do log, do envio inicial ao fechamento final, precisa ter uma hora de início para estabelecer a sequência cronológica do processo.

Essa data e hora são essenciais para todas as análises de Process Mining baseadas em tempo. Elas são usadas para calcular tempos de ciclo, duração das atividades e tempos de espera entre etapas, além de verificar a conformidade com os SLAs. Também permitem identificar gargalos e analisar a performance do processo ao longo do tempo.

Por que isso importa

A hora de início estabelece a ordem cronológica dos eventos, essencial para calcular a duração do processo, identificar atrasos e entender sua linha do tempo.

Onde encontrar

Corresponde aos campos de data e hora nos logs de auditoria ou nas tabelas de histórico de status associadas ao formulário 'SRM:Request', como 'Submit Date' para o evento inicial.

Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
ID da solicitação de serviço
ServiceRequestId
Identificador exclusivo de cada solicitação de serviço, usado como chave principal para acompanhar todo o ciclo de vida.
Descrição

O ID da solicitação de serviço identifica exclusivamente cada solicitação enviada por um usuário ou sistema. Ele funciona como elo central entre todos os eventos seguintes, do registro inicial ao fechamento final, permitindo analisar toda a jornada de cada solicitação de serviço.

No Process Mining, esse ID é essencial para reconstruir a sequência de atividades de cada caso. Ele permite que a ferramenta agrupe todos os eventos relacionados, como 'Solicitação enviada', 'Solicitação atribuída' e 'Solicitação de serviço fechada', em uma única instância do processo, que serve de base para toda a análise.

Por que isso importa

Este é o identificador fundamental do caso. Sem ele, não é possível acompanhar toda a jornada da solicitação de serviço, o que inviabiliza a descoberta e a análise do processo.

Onde encontrar

Em geral, este é o campo 'InstanceId' ou 'Request Number' do formulário 'SRM:Request' no BMC Helix ITSM.

Exemplos
SR000010572931SR000010572932SR000010572933
Sistema de origem
SourceSystem
Identifica o sistema de onde os dados foram extraídos.
Descrição

Este atributo especifica a origem dos dados do processo. Nesta visualização, o valor seria definido como 'BMC Helix ITSM' para indicar que todos os eventos relacionados às solicitações de serviço vieram desse sistema.

Em ambientes com vários sistemas integrados, este campo é essencial para entender a linhagem dos dados e separá-los conforme a origem. Ele garante clareza e rastreabilidade, principalmente quando dados de diferentes plataformas são combinados.

Por que isso importa

Este atributo informa a origem dos dados, algo importante para a governança de dados, a rastreabilidade e a solução de problemas em ambientes com vários sistemas.

Onde encontrar

Este é um valor estático adicionado durante a extração e a transformação dos dados, não um campo do próprio BMC Helix ITSM.

Exemplos
BMC Helix ITSM
Última atualização dos dados
LastDataUpdate
Data e hora da última atualização dos dados deste processo a partir do sistema de origem.
Descrição

Este atributo indica a data e a hora da extração mais recente de dados do BMC Helix ITSM. Ele informa quando os dados analisados foram atualizados e qual período a análise abrange.

Este é um metadado essencial para qualquer Dashboard ou análise de Process Mining. Ele ajuda a entender se os insights se baseiam em dados quase em tempo real ou em um recorte histórico, o que afeta a validade e a relevância das conclusões.

Por que isso importa

Este atributo informa se os dados estão atualizados, algo essencial para tomar decisões com base nas informações mais recentes disponíveis sobre a performance do processo.

Onde encontrar

Esta data e hora são geradas e adicionadas durante o processo de extração e carregamento dos dados.

Exemplos
2024-05-21T08:00:00Z
Agente responsável
AssignedAgent
Usuário atualmente responsável por trabalhar na solicitação de serviço.
Descrição

Este atributo identifica o agente de TI ou profissional de suporte responsável pela solicitação em determinado momento. Mudanças nesse campo ao longo do ciclo de vida de uma solicitação indicam um handoff ou uma reatribuição.

Esse atributo é essencial para analisar a performance dos agentes e a distribuição da carga de trabalho. Com ele, você acompanha quantas solicitações cada agente atende, o tempo médio de resolução e a frequência das reatribuições. Esses dados ajudam a gerenciar recursos e identificar oportunidades de treinamento.

Por que isso importa

Acompanhar o agente responsável é essencial para analisar handoffs, medir a performance individual e entender como a carga de trabalho está distribuída entre a equipe de suporte.

Onde encontrar

Corresponde ao campo 'Responsável' ou 'Atribuído a' no registro de atendimento (por exemplo, ordem de serviço ou incidente) associado à solicitação de serviço.

Exemplos
Bob SmithAlice JohnsonCharlie Brown
Equipe responsável
AssignedTeam
O grupo ou a equipe de suporte atualmente responsável pela solicitação de serviço.
Descrição

Este atributo identifica o grupo funcional responsável por atender à solicitação, como 'Central de serviços', 'Equipe de rede' ou 'Administração de banco de dados'. Uma mudança nesse campo indica a transferência de responsabilidade entre equipes.

A análise por equipe responsável ajuda a identificar gargalos em cada equipe, analisar handoffs entre equipes e avaliar a eficiência dos diferentes grupos de suporte. Esse atributo é essencial para os Dashboards de Análise de retrabalho e reatribuição de solicitações e de Eficiência da triagem, que revelam como o trabalho é encaminhado pela organização.

Por que isso importa

Ele permite analisar o fluxo do processo entre diferentes grupos funcionais, ajudando a identificar ineficiências no encaminhamento e a medir a performance de cada equipe.

Onde encontrar

Corresponde ao campo 'Grupo atribuído' no registro de atendimento (por exemplo, ordem de serviço ou incidente) associado à solicitação de serviço.

Exemplos
Central de serviçosSuporte de infraestruturaSuporte a aplicações, nível 2
Hora de término
EventEndTime
Data e hora que indicam quando uma atividade ou um evento específico foi concluído.
Descrição

A hora de término marca a conclusão de uma atividade. Embora muitas atividades em sistemas ITSM sejam mudanças de status instantâneas, algumas têm duração mensurável. Registrar a hora de término permite calcular essa duração com precisão.

Na análise, a hora de término é usada junto com a hora de início para calcular o tempo de processamento de cada atividade. Isso ajuda a identificar quais tarefas específicas, e não apenas o tempo de espera entre elas, consomem mais tempo no processo.

Por que isso importa

Este atributo permite calcular o tempo de processamento das atividades, essencial para identificar etapas ineficientes e entender onde os recursos estão gastando tempo.

Onde encontrar

Este dado pode ser derivado. A hora de término de uma atividade costuma ser a hora de início da próxima atividade sequencial do mesmo caso. Para a atividade final, corresponde à data e hora da resolução ou do fechamento.

Exemplos
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
Prioridade
Priority
Nível de prioridade atribuído à solicitação de serviço, que indica seu impacto nos negócios e sua urgência.
Descrição

A prioridade determina a ordem e a rapidez com que as solicitações devem ser atendidas. Os valores comuns incluem 'Crítico', 'Alto', 'Médio' e 'Baixo'. Em geral, a prioridade é definida com base no impacto da solicitação nos negócios e em sua urgência.

Analisar os dados por prioridade é essencial para avaliar se as solicitações de alta prioridade são processadas mais rapidamente do que as de baixa prioridade. É uma dimensão importante nos Dashboards de tempo de resolução e conformidade com os SLAs, pois ajuda a garantir que os recursos sejam alocados de acordo com as necessidades mais críticas dos negócios.

Por que isso importa

Este atributo ajuda a avaliar se o processo prioriza o trabalho corretamente e cumpre os níveis de serviço esperados para solicitações com diferentes níveis de impacto nos negócios.

Onde encontrar

Este é o campo 'Priority' do formulário 'SRM:Request'.

Exemplos
CríticoAltoMédioBaixo
Status da solicitação
RequestStatus
Status da solicitação de serviço no momento do evento, como 'In Progress', 'Pending' ou 'Closed'.
Descrição

Este atributo registra o estado da solicitação de serviço em diferentes momentos do ciclo de vida. O status dá contexto a cada atividade e muitas vezes é a fonte usada para derivar o próprio atributo 'Atividade'.

Analisar os dados por status ajuda a entender quanto tempo as solicitações permanecem em determinados estados, como 'Pending Customer' ou 'Waiting for Approval'. Isso é essencial para identificar gargalos e atrasos causados por dependências externas ou filas internas. O atributo também dá suporte direto ao Dashboard de identificação de gargalos.

Por que isso importa

Este atributo mostra o estado da solicitação em determinado momento e permite comparar o tempo em estados de espera com o tempo em estados ativos, algo essencial para identificar gargalos.

Onde encontrar

Este é o campo 'Status' do formulário 'SRM:Request'. Os valores históricos podem ser encontrados no log de auditoria.

Exemplos
PlanejamentoEm andamentoPendenteResolvidaFechada
Tipo de serviço
ServiceType
Categoria ou tipo de serviço solicitado pelo usuário.
Descrição

O tipo de serviço classifica a natureza da solicitação, por exemplo, 'Solicitar novo software', 'Redefinir senha' ou 'Integrar novo funcionário'. É uma dimensão fundamental para filtrar e segmentar os dados do processo.

Na análise de processos, este atributo permite comparar a performance de diferentes tipos de solicitação. Ele ajuda a responder perguntas como 'Quais tipos de serviço demoram mais para ser resolvidos?' ou 'Quais tipos de serviço geram mais retrabalho?'. É essencial para os Dashboards de tempo de resolução e conformidade com os SLAs.

Por que isso importa

Este atributo permite segmentar as solicitações de serviço para comparar fluxos de processo, identificar problemas específicos de cada tipo e direcionar as iniciativas de otimização.

Onde encontrar

Em geral, estes dados estão no campo 'Title' ou em um campo de categorização do formulário 'SRM:Request', com base no serviço selecionado no catálogo.

Exemplos
Solicitação de novo hardwareSolicitação de acesso a softwareConfiguração de acesso à VPN
Canal de envio
SubmissionChannel
O método ou canal usado para enviar a solicitação de serviço.
Descrição

Este atributo registra como a solicitação de serviço foi iniciada, por exemplo, pelo portal de autoatendimento, por e-mail, por telefone para a central de serviços ou por um alerta automatizado do sistema. Cada canal pode levar a diferentes variantes do processo e tempos de resolução.

Analisar o processo por canal de envio pode revelar ineficiências ou boas práticas associadas a métodos específicos de entrada. Por exemplo, solicitações enviadas pelo portal de autoatendimento podem ser resolvidas mais rapidamente graças à melhor qualidade inicial dos dados, enquanto as recebidas por e-mail podem exigir mais triagem manual.

Por que isso importa

Ele ajuda a entender como o método de entrada afeta a eficiência do processo, a qualidade dos dados e o tempo de ciclo geral, permitindo direcionar melhorias para canais específicos.

Onde encontrar

Muitas vezes, é possível inferir essa informação a partir de campos como 'Tipo de cliente' ou 'Origem informada' no formulário 'SRM:Request' ou nos chamados de atendimento associados.

Exemplos
Portal de autoatendimentoE-mailTelefoneGerado pelo sistema
Categoria de resolução
ResolutionCategory
A classificação da solução fornecida para resolver a solicitação.
Descrição

Este atributo classifica de forma estruturada como uma solicitação foi resolvida, por exemplo, com 'Correção de software', 'Treinamento do usuário' ou 'Correção de dados'. Ele vai além de um simples código de encerramento e descreve a natureza da resolução.

Esse atributo é essencial para o Dashboard de Precisão da categoria de resolução, que permite comparar a categoria com o tipo de serviço inicial e verificar se são consistentes. Analisar as categorias de resolução ajuda a identificar tendências nos problemas e orienta a gestão proativa de problemas. Por exemplo, se muitas solicitações forem resolvidas com treinamento dos usuários.

Por que isso importa

Ele oferece insights sobre a natureza das soluções, ajudando a identificar tendências em problemas recorrentes e oportunidades para a gestão proativa de problemas ou o treinamento de usuários.

Onde encontrar

Essa informação faz parte dos campos de categorização operacional e de produto do chamado de atendimento, geralmente identificados como 'Categoria de resolução'.

Exemplos
Administração de contasFalha de hardwareAtualização de softwareInformações fornecidas
Código de encerramento
CloseCode
Código que indica o resultado final ou o motivo do encerramento da solicitação de serviço.
Descrição

O código de encerramento oferece uma forma padronizada de classificar a resolução de uma solicitação de serviço. Alguns exemplos são 'Resolvida pela central de serviços', 'Cancelada pelo usuário' e 'Solicitação duplicada'.

Analisar os códigos de encerramento ajuda a entender os resultados mais comuns das solicitações. Isso pode destacar problemas como muitas solicitações canceladas pelos usuários, o que talvez indique um processo demorado, ou um grande número de duplicatas, que pode apontar para problemas no sistema ou na comunicação. Esse atributo dá suporte ao Dashboard de Precisão da categoria de resolução.

Por que isso importa

Ele fornece dados estruturados sobre os resultados das solicitações, permitindo analisar a eficácia das resoluções e os motivos de não conclusão ou cancelamento.

Onde encontrar

Em geral, essa informação aparece no campo 'Resolução' ou 'Código de encerramento' do chamado de atendimento associado à solicitação de serviço.

Exemplos
Concluída com sucessoCancelada pelo usuárioNão é mais necessáriaResolução automatizada
Contagem de handoffs
HandoffCount
O número total de vezes que uma solicitação de serviço foi reatribuída entre diferentes agentes ou equipes.
Descrição

Essa métrica calculada conta quantas vezes o 'AssignedAgent' ou o 'AssignedTeam' muda para uma mesma solicitação de serviço. Uma contagem alta de handoffs pode indicar fragmentação do processo, baixa resolução no primeiro contato ou encaminhamento ineficiente.

Esse atributo é a base do KPI de Média de handoffs por solicitação e é usado no Dashboard de Análise de retrabalho e reatribuição de solicitações. Analisar casos com muitos handoffs pode revelar oportunidades para melhorar a triagem, oferecer treinamento mais adequado ou simplificar o processo de resolução, reduzindo atrasos e aumentando a satisfação dos clientes.

Por que isso importa

Ele mede a fragmentação do processo e o esforço de comunicação. Uma contagem alta de handoffs costuma estar associada a tempos de resolução mais longos e menor eficiência do processo.

Onde encontrar

Essa métrica calculada é obtida contando os valores distintos do atributo 'AssignedAgent' ou 'AssignedTeam' para cada ID exclusivo de solicitação de serviço.

Exemplos
0135
Data-limite do SLA
SlaTargetDate
A data e a hora em que se espera que a solicitação de serviço seja resolvida, conforme o Acordo de Nível de Serviço (SLA).
Descrição

A data-limite do SLA é um registro calculado de data e hora que representa o prazo para concluir a solicitação de serviço. Ela é determinada pelas regras do acordo de serviço, que geralmente consideram fatores como a prioridade e o tipo da solicitação.

Esse atributo é fundamental para o Dashboard de Visão geral da conformidade com o SLA. Ele serve como referência para comparar o tempo real de resolução. Ao comparar o 'EventEndTime' da atividade final de resolução com essa data-limite, é possível determinar se o compromisso de serviço foi cumprido.

Por que isso importa

Essa é a principal referência para medir a performance do serviço em relação aos compromissos assumidos, por isso é essencial para monitorar e reportar a conformidade com o SLA.

Onde encontrar

Essa data é calculada e armazenada pelo módulo de Gerenciamento de Nível de Serviço (SLM) e pode ser encontrada nos formulários SLM relacionados à solicitação de serviço.

Exemplos
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
Departamento solicitante
RequestorDepartment
O departamento ou a unidade de negócio da pessoa que enviou a solicitação.
Descrição

Este atributo identifica o departamento da pessoa que solicitou o serviço, como 'Finanças', 'Recursos Humanos' ou 'TI'. Em geral, essa informação vem do perfil da pessoa no sistema.

Segmentar a análise do processo por departamento ajuda a identificar necessidades e padrões de solicitação específicos, além de possíveis oportunidades para oferecer treinamento direcionado ou melhorar o serviço. Também permite responder a perguntas como: 'O departamento de Finanças espera mais tempo pelas solicitações?'

Por que isso importa

Ele permite analisar o consumo de serviços e a performance do processo por unidade de negócio, destacando problemas ou tendências específicos de cada departamento.

Onde encontrar

Em geral, essa informação é obtida no perfil da pessoa associada ao usuário 'Solicitado para' no formulário 'SRM:Request'.

Exemplos
FinançasVendasRecursos HumanosTecnologia da Informação
Foi escalada
IsEscalated
Indicador booleano que informa se a solicitação de serviço foi escalada.
Descrição

Este indicador recebe o valor verdadeiro quando uma solicitação de serviço passa por um escalonamento funcional ou hierárquico. Em geral, o escalonamento ocorre quando a solicitação não avança como esperado, está prestes a descumprir o SLA ou precisa de aprovação ou ação de uma autoridade superior.

Esse atributo é essencial para o Dashboard de Análise de eficiência do escalonamento de solicitações. Ele permite filtrar e analisar os caminhos do processo das solicitações escaladas para entender o que as desencadeia, quanto tempo levam para ser resolvidas após o escalonamento e qual é a eficácia desse processo.

Por que isso importa

Ele permite isolar e analisar as solicitações que precisaram ser escaladas, ajudando a identificar pontos fracos no processo padrão ou fatores que desencadeiam problemas complexos.

Onde encontrar

Em geral, essa informação não está em um único campo. Ela é derivada da verificação de atividades específicas de escalonamento no log de auditoria ou de mudanças de prioridade ou atribuição feitas conforme um protocolo de escalonamento.

Exemplos
truefalse
Houve retrabalho
IsRework
Indicador booleano que informa se a solicitação de serviço passou por retrabalho, como o retorno a uma etapa anterior.
Descrição

Este indicador identifica solicitações de serviço que passaram por um loop ou retrabalho no fluxo do processo. Por exemplo, uma solicitação que passa de 'Atendimento em andamento' de volta para 'Solicitação em análise' é considerada retrabalho. A definição exata depende da lógica do processo de negócio.

Esse atributo dá suporte direto ao Dashboard de Análise de retrabalho e reatribuição de solicitações e ao KPI de Taxa de retrabalho de solicitações. Ele permite quantificar a frequência do retrabalho e analisar suas causas comuns, como uma avaliação inicial incorreta ou informações incompletas, que geram ineficiências no processo.

Por que isso importa

Ele quantifica as ineficiências do processo ao sinalizar casos que se desviam do caminho ideal, ajudando a identificar as causas raiz de loops e trabalho repetido.

Onde encontrar

Este é um atributo calculado a partir da sequência de atividades no Event Log. É preciso definir uma lógica para detectar movimentos de retorno no fluxo do processo.

Exemplos
truefalse
O SLA foi descumprido
IsSlaBreached
Indicador booleano que informa se a solicitação de serviço foi resolvida após a data-limite do SLA.
Descrição

Este indicador calculado recebe o valor verdadeiro quando o registro de data e hora da resolução final da solicitação de serviço é posterior à 'Data-limite do SLA'. Ele fornece um resultado simples, sim ou não, sobre a performance do SLA para cada solicitação.

Esse atributo é essencial para o Dashboard de Visão geral da conformidade com o SLA e para o KPI de Taxa de cumprimento do SLA. Ele facilita a agregação dos dados para calcular as taxas gerais de conformidade e permite filtrar as solicitações que descumpriram o SLA para comparar suas características de processo com as das solicitações em conformidade. Assim, ajuda a identificar as causas raiz dos descumprimentos.

Por que isso importa

Ele simplifica a análise da performance do SLA ao transformar a comparação entre registros de data e hora em um indicador booleano, facilitando a medição e a visualização das taxas de conformidade.

Onde encontrar

Este é um campo calculado. A lógica é: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false.

Exemplos
truefalse
Obrigatório Recomendado Opcional

Atividades de gestão de solicitações de serviço

Registre no Event Log estas etapas e marcos importantes do processo para descobrir e visualizar o processo com precisão.
6 Recomendado 8 Opcional
Atividade Descrição
Atendimento em andamento
O agente ou a equipe responsável começou a trabalhar ativamente na solicitação de serviço. Isso indica que a solicitação saiu da fila e passou para um estado de trabalho ativo.
Por que isso importa

Marca o início do trabalho de atendimento que agrega valor. Analisar o tempo nesta etapa ajuda a entender a produtividade dos recursos e a complexidade do atendimento.

Onde encontrar

Inferido a partir de uma mudança de status no formulário SRM:Request para 'In Progress'.

Coleta

Data e hora do evento de atualização em que o campo 'Status' de SRM:Request muda para 'In Progress'.

Tipo de evento inferred
Solicitação atribuída
A solicitação de serviço foi atribuída a um agente ou equipe responsável por concluir o trabalho. Isso marca o fim da etapa de triagem.
Por que isso importa

Este marco é essencial para medir o tempo de triagem e analisar a carga de trabalho dos agentes. Reatribuições frequentes podem indicar problemas de encaminhamento ou lacunas de habilidades.

Onde encontrar

Este evento pode ser registrado diretamente no log de auditoria dos campos 'Assigned Group' ou 'Assignee' do SRM:Request ou de formulários relacionados ao atendimento, como WOI:WorkOrder.

Coleta

Data e hora do log de auditoria em que um valor não nulo é definido pela primeira vez no campo 'Assignee'.

Tipo de evento explicit
Solicitação de serviço cancelada
O solicitante ou a Central de serviços retirou a solicitação de serviço antes da conclusão do atendimento. Esse é um estado final da solicitação.
Por que isso importa

Acompanhar os cancelamentos ajuda a identificar padrões, como usuários enviando solicitações incorretas ou serviços que deixaram de ser necessários. Essas informações podem orientar melhorias no catálogo de serviços.

Onde encontrar

Inferido a partir de uma mudança de status no formulário SRM:Request para 'Canceled'.

Coleta

Data e hora do evento de atualização em que o campo 'Status' de SRM:Request muda para 'Canceled'.

Tipo de evento inferred
Solicitação de serviço enviada
Esta atividade marca a criação e o envio de uma nova solicitação de serviço por um usuário. Ela é registrada quando uma nova entrada é criada no formulário SRM:Request com um status inicial, geralmente 'Submitted'.
Por que isso importa

Este é o ponto de partida de cada caso de solicitação de serviço. Ele é essencial para medir a duração total do ciclo de vida e analisar o volume de solicitações recebidas.

Onde encontrar

Este evento é inferido a partir da data e hora de criação e do status inicial (por exemplo, 'Submitted') de um registro no formulário SRM:Request.

Coleta

Identifique a data e hora de criação de um novo ID de solicitação de serviço no formulário SRM:Request quando o status for 'Submitted'.

Tipo de evento inferred
Solicitação de serviço fechada
A solicitação de serviço é fechada formalmente e passa para um estado arquivado, somente para leitura. Isso ocorre após a resolução e o fim de qualquer período de confirmação.
Por que isso importa

Esta atividade representa o fim definitivo do processo. O tempo entre 'Resolved' e 'Closed' pode revelar ineficiências no procedimento de fechamento.

Onde encontrar

Inferido a partir da mudança final de status no formulário SRM:Request para 'Closed'.

Coleta

Data e hora do evento de atualização em que o campo 'Status' de SRM:Request muda para 'Closed'.

Tipo de evento inferred
Solicitação de serviço resolvida
O atendimento da solicitação de serviço foi concluído e a solução foi comunicada ao solicitante. A solicitação aguarda a confirmação final ou será fechada automaticamente após um período definido.
Por que isso importa

Um marco essencial que indica o fim do ciclo de prestação do serviço. É o principal ponto final para medir o tempo de resolução e o cumprimento dos SLAs.

Onde encontrar

Inferido a partir de uma mudança de status no formulário SRM:Request para 'Resolved' ou 'Completed'.

Coleta

Data e hora do evento de atualização em que o campo 'Status' de SRM:Request muda para 'Resolved' ou 'Completed'.

Tipo de evento inferred
Informações solicitadas ao usuário
O agente responsável pelo atendimento precisa de informações adicionais do solicitante para dar continuidade ao trabalho. Em geral, a solicitação passa para o estado 'Pending'.
Por que isso importa

Esta atividade é essencial para calcular o 'Tempo de espera por informações externas' e identificar com que frequência as solicitações ficam paradas por falta de informações.

Onde encontrar

Inferido a partir de uma mudança de status no formulário SRM:Request para 'Pending', com um motivo como 'Customer Hold' ou 'Awaiting Information'.

Coleta

Data e hora da mudança para o status 'Pending', combinada com um motivo de status específico.

Tipo de evento inferred
Resolução confirmada pelo usuário
O solicitante confirmou que o serviço foi prestado de forma satisfatória e que a solicitação está resolvida. Muitas vezes, isso inicia o fechamento final da solicitação.
Por que isso importa

Indica claramente a satisfação do cliente e encerra formalmente a interação de serviço. Também diferencia a resolução do processo da aceitação pelo cliente.

Onde encontrar

Este evento pode ser registrado nos logs de trabalho ou nas notas de atividade de SRM:Request quando o usuário confirma pelo portal ou por e-mail. Nem sempre corresponde a um status específico.

Coleta

Pesquise nos logs de trabalho (SRM:WorkInfo) entradas específicas que indiquem a confirmação do usuário ou a conclusão de uma pesquisa.

Tipo de evento explicit
Solicitação aguardando aprovação
A solicitação de serviço foi encaminhada a um aprovador ou grupo de aprovação designado e aguarda uma decisão antes do início do atendimento. Essa etapa é comum em solicitações que envolvem custos ou direitos de acesso.
Por que isso importa

Esta atividade isola os atrasos relacionados à aprovação, permitindo analisar os tempos do ciclo de aprovação e identificar gargalos na cadeia de aprovação.

Onde encontrar

Inferido a partir de uma mudança de status no formulário SRM:Request para um valor como 'Waiting Approval'.

Coleta

Data e hora do evento de atualização em que o campo 'Status' de SRM:Request muda para 'Waiting Approval'.

Tipo de evento inferred
Solicitação aprovada
A solicitação de serviço foi aprovada formalmente pela parte responsável, permitindo que o atendimento prossiga. Em geral, este evento ocorre após o status 'Waiting for Approval'.
Por que isso importa

Marca o fim do subprocesso de aprovação e é um marco importante para acompanhar a duração das aprovações e seu impacto no tempo total de resolução.

Onde encontrar

Inferido a partir de uma mudança de status no formulário SRM:Request de 'Waiting Approval' para um status seguinte, como 'Planning' ou 'In Progress'. A decisão de aprovação é registrada nos formulários de aprovação relacionados.

Coleta

Data e hora da mudança de status após 'Waiting Approval', quando a aprovação é concedida.

Tipo de evento inferred
Solicitação em revisão
A Central de serviços está fazendo a revisão inicial e a triagem da solicitação para determinar sua natureza, prioridade e equipe responsável pelo atendimento. Em geral, isso é representado por uma mudança de status no registro da solicitação.
Por que isso importa

Acompanhar esta atividade ajuda a medir a eficiência da triagem e identificar atrasos entre o envio e a atribuição, algo essencial para o KPI 'Tempo médio de triagem'.

Onde encontrar

Inferido a partir de uma mudança de status no formulário SRM:Request para um valor como 'In Review' ou 'Planning'.

Coleta

Data e hora do evento de atualização em que o campo 'Status' de SRM:Request muda para 'In Review'.

Tipo de evento inferred
Solicitação rejeitada
A solicitação de serviço foi negada durante a etapa de aprovação. Esse é um estado final que interrompe o processo antes do início do atendimento.
Por que isso importa

Analisar as solicitações rejeitadas pode revelar problemas nas justificativas, nos critérios de elegibilidade ou nas políticas de aprovação.

Onde encontrar

Inferido a partir de uma mudança de status no formulário SRM:Request para 'Rejected'.

Coleta

Data e hora do evento de atualização em que o campo 'Status' de SRM:Request muda para 'Rejected'.

Tipo de evento inferred
Solicitação retomada
A solicitação de serviço saiu de um estado pendente ou de espera, geralmente após o usuário fornecer as informações necessárias. O agente responsável retoma o trabalho na solicitação.
Por que isso importa

Marca o fim de um período de espera, permitindo medir com precisão o tempo de espera por informações externas e seu impacto na conformidade com os SLAs.

Onde encontrar

Inferido quando o status de SRM:Request muda de 'Pending' para 'In Progress'.

Coleta

Data e hora do evento de atualização em que o campo 'Status' de SRM:Request muda de 'Pending' para 'In Progress'.

Tipo de evento inferred
Solução implementada
O agente concluiu o trabalho técnico necessário para atender à solicitação de serviço. Agora, a solução está pronta para ser confirmada pelo usuário antes da resolução formal.
Por que isso importa

Esta atividade separa a conclusão técnica da resolução formal, ajudando a identificar atrasos entre o fim do trabalho e a confirmação do usuário.

Onde encontrar

Este evento pode ser inferido a partir de uma mudança de status em um chamado de atendimento no back-end (por exemplo, o status da ordem de serviço muda para 'Completed') antes de a solicitação principal em SRM:Request ser marcada como 'Resolved'.

Coleta

Data e hora em que um chamado de back-end (ordem de serviço, incidente etc.) vinculado a SRM:Request é marcado como concluído.

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como obter seus dados do BMC Helix ITSM

Pronto para começar?

Use este Template para simplificar a coleta de dados e começar a fazer Process Mining com confiança. Comece hoje a otimizar a gestão de solicitações de serviço.

Ganhe eficiência: otimize hoje a gestão de solicitações de serviço

Alcance 70% de automação, elimine atrasos no atendimento e ofereça uma experiência melhor aos usuários.

Comece seu teste grátis

Não é necessário informar cartão de crédito. Comece em poucos minutos.