Seu Template de dados para gerenciamento de solicitações de serviço
Seu Template de dados para gerenciamento de solicitações de serviço
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações para extração no BMC Helix ITSM
Atributos da gestão de solicitações de serviço
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
O 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 alteração de status no processo de solicitação de serviço, como 'Request In Review', 'Fulfillment In Progress' ou 'Service Request Resolved'. Cada atividade representa um único evento na jornada de ponta a ponta de uma solicitação de serviço. Analisar a sequência e a frequência das atividades é o núcleo 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 formam os blocos de construção do mapa de processo. Acompanhar essas atividades permite visualizar e analisar o fluxo do processo, revelando como o trabalho é realmente executado.
Onde obter
Normalmente, isso é derivado de alterações nos campos 'Status' e 'Status Reason' do formulário 'SRM:Request' ou dos logs de aplicações relacionadas 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
|
O carimbo de data e hora que indica quando uma atividade ou 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, desde o envio inicial até o fechamento final, precisa ter uma hora de início para estabelecer a sequência cronológica do processo. Esse carimbo de data e hora é fundamental para todas as análises de Process Mining baseadas em tempo. Ele é usado para calcular tempos de ciclo, durações de atividades, tempos de espera entre etapas e conformidade com o SLA. Também permite descobrir gargalos e analisar a performance do processo ao longo do tempo.
Por que isso importa
A hora de início fornece a ordem cronológica dos eventos, essencial para calcular as durações do processo, identificar atrasos e entender a linha do tempo do processo.
Onde obter
Isso corresponde aos campos de carimbo 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
|
O identificador exclusivo de cada solicitação de serviço, usado como chave primária para acompanhar todo o ciclo de vida. | ||
|
Descrição
O ID da solicitação de serviço identifica exclusivamente cada solicitação individual enviada por um usuário ou sistema. Ele funciona como o fio condutor central que conecta todos os eventos seguintes, desde o registro inicial até o fechamento final, permitindo uma análise completa, de ponta a ponta, da 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 'Request Submitted', 'Request Assigned' e 'Service Request Closed', em uma única instância de processo, formando a base de toda a análise do processo.
Por que isso importa
Este é o identificador fundamental do caso. Sem ele, não é possível rastrear a jornada de ponta a ponta de uma solicitação de serviço, o que inviabiliza a descoberta e a análise do processo.
Onde obter
Normalmente, este é o campo 'InstanceId' ou 'Request Number' no formulário 'SRM:Request' do BMC Helix ITSM.
Exemplos
SR000010572931SR000010572932SR000010572933
|
|||
|
Sistema de origem
SourceSystem
|
Identifica o sistema do qual os dados foram extraídos. | ||
|
Descrição
Este atributo especifica a origem dos dados do processo. Nesta visualização, ele seria definido estaticamente como 'BMC Helix ITSM' para indicar que todos os eventos relacionados às solicitações de serviço foram obtidos desse sistema. Em ambientes com vários sistemas integrados, este campo é fundamental para entender a linhagem dos dados e particioná-los com base na origem. Ele garante clareza e rastreabilidade, especialmente quando dados de diferentes plataformas são combinados.
Por que isso importa
Ele fornece contexto sobre 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 obter
Este é um valor estático adicionado durante o processo de extração e transformação dos dados, não um campo do próprio BMC Helix ITSM.
Exemplos
BMC Helix ITSM
|
|||
|
Última atualização dos dados
LastDataUpdate
|
O carimbo de data e hora em que os dados deste processo foram atualizados pela última vez 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 fornece contexto sobre a atualidade dos dados analisados, garantindo que os usuários saibam qual período está coberto pela análise. Este é um atributo de metadados fundamental para qualquer Dashboard ou análise de Process Mining. Ele permite entender se os insights se baseiam em dados quase em tempo real ou em um retrato histórico, o que afeta a validade e a relevância das conclusões obtidas.
Por que isso importa
Ele informa aos usuários o quão atuais são os dados, algo essencial para tomar decisões com base nas informações mais recentes disponíveis sobre a performance do processo.
Onde obter
Este carimbo de data e hora é gerado e adicionado durante o processo de extração e carregamento dos dados.
Exemplos
2024-05-21T08:00:00Z
|
|||
|
Agente atribuído
AssignedAgent
|
O usuário individual atualmente responsável por trabalhar na solicitação de serviço. | ||
|
Descrição
Este atributo identifica o agente de TI ou membro da equipe de suporte responsável pela solicitação em determinado momento. Alterações nesse campo ao longo do ciclo de vida de uma única solicitação indicam uma transferência ou reatribuição. Este atributo é fundamental para analisar a performance e a carga de trabalho dos agentes. Ele permite acompanhar quantas solicitações cada agente trata, seu tempo médio de resolução e a frequência das reatribuições. Esses dados apoiam a gestão de recursos e a identificação de oportunidades de treinamento.
Por que isso importa
Acompanhar o agente atribuído é essencial para analisar transferências, medir a performance individual e entender a distribuição da carga de trabalho na equipe de suporte.
Onde obter
Isso corresponde ao campo 'Assignee' ou 'Assigned To' do registro de atendimento, como Work Order ou Incident, associado à solicitação de serviço.
Exemplos
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
Equipe atribuída
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 tratar a solicitação, como 'Help Desk', 'Network Team' ou 'Database Administration'. Uma alteração nesse campo indica uma transferência de responsabilidade entre equipes. A análise com base na equipe atribuída ajuda a identificar gargalos no nível da equipe, analisar transferências entre equipes e avaliar a eficiência de diferentes grupos de suporte. Ela é fundamental para os Dashboards de retrabalho e reatribuição de solicitações e de eficiência da triagem, revelando padrões de roteamento do trabalho na organização.
Por que isso importa
Ele permite analisar o fluxo do processo entre diferentes grupos funcionais, ajudando a identificar ineficiências de roteamento e medir a performance no nível da equipe.
Onde obter
Isso corresponde ao campo 'Assigned Group' do registro de atendimento, como Work Order ou Incident, associado à solicitação de serviço.
Exemplos
Service DeskSuporte de infraestruturaSuporte de aplicações, nível 2
|
|||
|
Hora de término
EventEndTime
|
O carimbo de data e hora que indica quando uma atividade ou 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 alterações instantâneas de status, algumas têm uma duração mensurável. Ter uma hora de término permite calcular essa duração com precisão. Na análise, a hora de término é usada em conjunto com a hora de início para calcular o tempo de processamento de atividades individuais. Isso ajuda a identificar quais tarefas específicas, e não apenas o tempo de espera entre elas, estão consumindo mais tempo no processo.
Por que isso importa
Ela permite calcular os tempos de processamento das atividades, algo fundamental para identificar etapas ineficientes e entender onde os recursos estão gastando seu tempo.
Onde obter
Isso pode ser derivado. A hora de término de uma atividade geralmente é a hora de início da próxima atividade sequencial do mesmo caso. Para a atividade final, seria o carimbo de 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
|
O nível de prioridade atribuído à solicitação de serviço, indicando seu impacto no negócio e sua urgência. | ||
|
Descrição
A prioridade determina a ordem e a velocidade com que as solicitações devem ser tratadas. Os valores comuns incluem 'Critical', 'High', 'Medium' e 'Low'. Essa atribuição geralmente se baseia em uma combinação do impacto da solicitação no negócio e de sua urgência. Analisar por prioridade é essencial para avaliar se as solicitações de alta prioridade estão sendo processadas mais rapidamente que as de baixa prioridade. Essa é uma dimensão importante nos Dashboards de tempo de resolução e conformidade com o SLA, ajudando a garantir que os recursos sejam alocados adequadamente às necessidades mais críticas do negócio.
Por que isso importa
Ele ajuda a avaliar se o processo prioriza o trabalho corretamente e atende aos níveis de serviço esperados para solicitações com diferentes níveis de impacto no negócio.
Onde obter
Este é o campo 'Priority' do formulário 'SRM:Request'.
Exemplos
CríticoAltoMédioBaixo
|
|||
|
Status da solicitação
RequestStatus
|
O status da solicitação de serviço no momento do evento, como 'In Progress', 'Pending' ou 'Closed'. | ||
|
Descrição
Este atributo captura o estado da solicitação de serviço em diferentes pontos do seu ciclo de vida. O status fornece contexto para cada atividade e geralmente é a fonte da qual o próprio atributo 'Activity' é derivado. Analisar 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 dá suporte direto ao Dashboard de identificação de gargalos.
Por que isso importa
Ele fornece um retrato do estado da solicitação, permitindo analisar o tempo gasto em estados de espera em comparação com estados ativos, algo essencial para identificar gargalos.
Onde obter
Este é o campo 'Status' do formulário 'SRM:Request'. Os valores históricos podem ser encontrados no log de auditoria.
Exemplos
PlanejamentoEm andamentoPendenteResolvidoFechado
|
|||
|
Tipo de serviço
ServiceType
|
A categoria ou o tipo de serviço solicitado pelo usuário. | ||
|
Descrição
O tipo de serviço classifica a natureza da solicitação, por exemplo, 'Request New Software', 'Password Reset' ou 'Onboard New Employee'. Ele é uma dimensão fundamental para filtrar e segmentar os dados do processo. Na análise do processo, este atributo é usado para 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 têm mais retrabalho?'. Isso é fundamental para os Dashboards de tempo de resolução e conformidade com o SLA.
Por que isso importa
Ele permite segmentar as solicitações de serviço para comparar fluxos de processo, identificar problemas específicos de cada tipo e direcionar os esforços de otimização de forma eficaz.
Onde obter
Esses dados geralmente são encontrados no campo 'Title' ou em um campo de categorização do formulário 'SRM:Request', derivados do 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 pelo qual a solicitação de serviço foi enviada. | ||
|
Descrição
Este atributo registra como a solicitação de serviço foi iniciada, por exemplo, por um portal de autoatendimento, e-mail, ligação telefônica para a central de serviços ou alerta automatizado do sistema. Diferentes canais podem levar a variantes de processo e tempos de resolução distintos. 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 devido à 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 total de ciclo, permitindo melhorias direcionadas em canais específicos.
Onde obter
Isso geralmente pode ser inferido a partir de campos como 'Client Type' ou 'Reported Source' no formulário 'SRM:Request' ou em tickets de atendimento associados.
Exemplos
Portal de autoatendimentoE-mailTelefoneGerado pelo sistema
|
|||
|
Categoria da resolução
ResolutionCategory
|
A classificação da solução fornecida para resolver a solicitação. | ||
|
Descrição
Este atributo oferece uma categorização estruturada de como uma solicitação foi resolvida, como 'Software Fix', 'User Training' ou 'Data Correction'. Ele vai além de um simples código de fechamento ao descrever a natureza da resolução. Isso é essencial para o Dashboard de precisão da categoria de resolução, no qual pode ser comparado ao tipo de serviço inicial para verificar a consistência. Analisar as categorias de resolução ajuda a identificar tendências nos problemas e orienta o gerenciamento proativo de problemas, por exemplo, quando muitas solicitações são resolvidas por meio de treinamento do usuário.
Por que isso importa
Oferece insights sobre a natureza das soluções, ajudando a identificar tendências em problemas recorrentes e oportunidades para o gerenciamento proativo de problemas ou o treinamento de usuários.
Onde obter
Essas informações fazem parte dos campos de categorização operacional e de produto do ticket de atendimento, geralmente identificados como 'Categoria da Resolução'.
Exemplos
Administração de contasFalha de hardwareAtualização de softwareInformações fornecidas
|
|||
|
Código de fechamento
CloseCode
|
Um código que indica o resultado final ou o motivo do fechamento da solicitação de serviço. | ||
|
Descrição
O código de fechamento oferece uma forma padronizada de classificar a resolução de uma solicitação de serviço. Os exemplos incluem 'Resolved by Service Desk', 'Canceled by User' ou 'Duplicate Request'. Analisar os códigos de fechamento ajuda a entender os resultados mais comuns das solicitações. Isso pode revelar problemas como um número elevado de solicitações canceladas pelos usuários, o que pode indicar um processo demorado, ou muitas solicitações duplicadas, o que pode apontar para um problema de sistema ou comunicação. Este 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 da resolução e os motivos da não conclusão ou do cancelamento.
Onde obter
Essas informações normalmente são encontradas em um campo 'Resolution' ou 'Closure Code' do ticket de atendimento associado à solicitação de serviço.
Exemplos
Concluído com sucessoCancelado pelo usuárioNão é mais necessárioResolução automatizada
|
|||
|
Contagem de transferências
HandoffCount
|
O número total de vezes que uma solicitação de serviço foi reatribuída entre diferentes agentes ou times. | ||
|
Descrição
Essa métrica calculada conta quantas vezes 'AssignedAgent' ou 'AssignedTeam' muda para uma única solicitação de serviço. Uma contagem alta de transferências pode indicar fragmentação do processo, baixa resolução no primeiro contato ou roteamento ineficiente. Esse atributo é a base do KPI de Média de Transferências entre Agentes por Solicitação e é usado no Dashboard de Retrabalho e Reatribuição de Solicitações. A análise de casos com muitas transferências pode revelar oportunidades para melhorar a triagem, oferecer treinamentos mais adequados ou simplificar o processo de resolução, reduzindo atrasos e aumentando a satisfação dos clientes.
Por que isso importa
Mede a fragmentação do processo e o esforço adicional de comunicação. Contagens altas de transferências geralmente estão associadas a tempos de resolução mais longos e menor eficiência do processo.
Onde obter
Esta é uma métrica calculada, derivada da contagem dos valores distintos do atributo 'AssignedAgent' ou 'AssignedTeam' para cada ID exclusivo de solicitação de serviço.
Exemplos
0135
|
|||
|
Data-alvo do SLA
SlaTargetDate
|
A data e a hora até as quais se espera que a solicitação de serviço seja resolvida, de acordo com seu Acordo de Nível de Serviço (SLA). | ||
|
Descrição
A data-alvo do SLA é um carimbo de data e hora calculado 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. Este atributo é fundamental para o Dashboard de visão geral da conformidade com o SLA. Ele serve como referência para medir o tempo real de resolução. Ao comparar o 'EventEndTime' da atividade final de resolução com essa data-alvo, é possível determinar se o compromisso de serviço foi cumprido.
Por que isso importa
Esta é a principal referência para medir a performance do serviço em relação aos compromissos assumidos, sendo essencial para monitorar e reportar a conformidade com o SLA.
Onde obter
Essa data é calculada e armazenada pelo módulo de Service Level Management (SLM) e pode ser encontrada nos formulários relacionados do SLM vinculados à solicitação de serviço.
Exemplos
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
|
|||
|
Departamento do solicitante
RequestorDepartment
|
O departamento ou a unidade de negócio do usuário que enviou a solicitação. | ||
|
Descrição
Este atributo identifica o departamento organizacional da pessoa que solicitou o serviço, como 'Finance', 'Human Resources' ou 'IT'. Essas informações geralmente vêm do perfil do usuário no sistema. Segmentar a análise do processo por departamento permite identificar necessidades específicas, padrões de solicitação e possíveis oportunidades de treinamento ou melhorias no serviço. Também ajuda a responder perguntas como: 'O departamento Financeiro enfrenta tempos de espera maiores para suas 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 obter
Essas informações normalmente são obtidas do perfil do usuário associado ao usuário 'Requested For' no formulário 'SRM:Request'.
Exemplos
FinançasVendasRecursos HumanosTecnologia da Informação
|
|||
|
É retrabalho
IsRework
|
Um indicador booleano que mostra se uma solicitação de serviço passou por retrabalho, como retornar a uma etapa anterior. | ||
|
Descrição
Esse 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' seria 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 mais comuns, como uma avaliação inicial incorreta ou informações incompletas, que geram ineficiências no processo.
Por que isso importa
Quantifica a ineficiência do processo ao sinalizar casos que se desviam do 'caminho ideal', ajudando a identificar as causas-raiz de loops e trabalhos repetidos.
Onde obter
Este é um atributo calculado, derivado da sequência de atividades no Event Log. É necessário usar uma lógica que detecte movimentos para trás no fluxo do processo.
Exemplos
truefalse
|
|||
|
Foi escalado
IsEscalated
|
Um indicador booleano que mostra se a solicitação de serviço foi escalada. | ||
|
Descrição
Esse indicador recebe o valor true quando uma solicitação de serviço passa por uma escalada funcional ou hierárquica. Normalmente, uma escalada ocorre quando uma solicitação não avança conforme o esperado, está prestes a violar um SLA ou precisa de uma autoridade superior para aprovação ou ação. Esse atributo é essencial para o Dashboard de Análise da Eficiência de Escaladas 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 a escalada e qual é a eficácia do processo de escalada.
Por que isso importa
Permite isolar e analisar o conjunto de solicitações que exigiram escalada, ajudando a identificar fragilidades no processo padrão ou gatilhos relacionados a problemas complexos.
Onde obter
Normalmente, não se trata de um único campo. Esse indicador é derivado da verificação de atividades específicas relacionadas à escalada no log de auditoria ou de alterações de prioridade ou atribuição que seguem um protocolo de escalada.
Exemplos
truefalse
|
|||
|
SLA violado
IsSlaBreached
|
Um indicador booleano que mostra se a solicitação de serviço foi resolvida após a data-alvo do SLA. | ||
|
Descrição
Esse indicador calculado recebe o valor true quando o timestamp final da resolução da solicitação de serviço é posterior à sua 'Data-alvo do SLA'. Ele fornece um resultado binário simples para a performance do SLA em 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 permite agregar os dados facilmente para calcular as taxas gerais de conformidade e filtrar as características do processo, comparando solicitações que violaram o SLA com as que cumpriram o prazo. Assim, ajuda a identificar as causas-raiz das falhas de SLA.
Por que isso importa
Simplifica a análise da performance do SLA ao transformar uma comparação de timestamps em um indicador booleano simples, facilitando a medição e a visualização das taxas de conformidade.
Onde obter
Este é um campo calculado. A lógica é: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false.
Exemplos
truefalse
|
|||
Atividades da gestão de solicitações de serviço
| Atividade | Descrição | ||
|---|---|---|---|
|
Atendimento em andamento
|
O agente ou a equipe atribuída começou a trabalhar ativamente no atendimento da solicitação de serviço. Isso indica que a solicitação saiu da fila e entrou em um estado de trabalho ativo. | ||
|
Por que isso importa
Marca o início do trabalho de atendimento que agrega valor. Analisar o tempo gasto nesta fase ajuda a entender a produtividade dos recursos e a complexidade do atendimento.
Onde obter
Inferido a partir de uma alteração de status no formulário SRM:Request para 'In Progress'.
Captura
Carimbo de 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 específica responsável pela conclusão do trabalho. Isso marca o fim da fase de triagem. | ||
|
Por que isso importa
Este marco é fundamental para medir o tempo de triagem e analisar a carga de trabalho dos agentes. Reatribuições frequentes podem indicar problemas de roteamento ou lacunas de conhecimento.
Onde obter
Este evento pode ser capturado explicitamente no log de auditoria dos campos 'Assigned Group' ou 'Assignee' do SRM:Request ou de formulários relacionados ao atendimento, como WOI:WorkOrder.
Captura
Carimbo de data e hora do log de auditoria que mostra a definição, pela primeira vez, de um valor não nulo no campo 'Assignee'.
Tipo de evento
explicit
|
|||
|
Solicitação de serviço cancelada
|
A solicitação de serviço foi retirada pelo solicitante ou pela central de serviços antes da conclusão do atendimento. Este é um estado terminal 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, contribuindo para melhorias no catálogo de serviços.
Onde obter
Inferido a partir de uma alteração de status no formulário SRM:Request para 'Canceled'.
Captura
Carimbo de 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, normalmente 'Submitted'. | ||
|
Por que isso importa
Este é o ponto de partida de cada caso de solicitação de serviço, essencial para medir a duração total do ciclo de vida e analisar o volume de solicitações recebidas.
Onde obter
Este evento é inferido a partir do carimbo de data e hora de criação e do status inicial, por exemplo, 'Submitted', de um registro no formulário SRM:Request.
Captura
Identifique o carimbo de 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 é formalmente fechada e movida para um estado arquivado, somente leitura. Isso ocorre depois da resolução e do término 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 obter
Inferido a partir da alteração final de status no formulário SRM:Request para 'Closed'.
Captura
Carimbo de 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 resoluçã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 fundamental que indica o fim do ciclo de entrega do serviço. É o principal ponto final para medir o tempo de resolução e a conformidade com o SLA.
Onde obter
Inferido a partir de uma alteração de status no formulário SRM:Request para 'Resolved' ou 'Completed'.
Captura
Carimbo de 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 prosseguir com o trabalho. A solicitação normalmente é colocada no 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 causa de informações incompletas.
Onde obter
Inferido a partir de uma alteração de status no formulário SRM:Request para 'Pending', com um motivo de status como 'Customer Hold' ou 'Awaiting Information'.
Captura
Carimbo de data e hora da alteração para 'Pending', combinado com um motivo de status específico.
Tipo de evento
inferred
|
|||
|
Resolução confirmada pelo usuário
|
O solicitante confirmou ativamente que o serviço foi entregue de forma satisfatória e que a solicitação está resolvida. Isso geralmente aciona o fechamento final da solicitação. | ||
|
Por que isso importa
Fornece um indicador claro da satisfação do cliente e encerra formalmente a interação de serviço. Também separa a resolução do processo da aceitação pelo cliente.
Onde obter
Este evento pode ser capturado nos logs de trabalho ou nas notas de atividade da SRM:Request quando o usuário confirma pelo portal ou por e-mail. Ele nem sempre corresponde a um status específico.
Captura
Analise os logs de trabalho (SRM:WorkInfo) em busca de 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 enviada a um aprovador ou grupo de aprovação designado e aguarda uma decisão antes que o atendimento possa começar. Esta é uma 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 obter
Inferido a partir de uma alteração de status no formulário SRM:Request para um valor como 'Waiting Approval'.
Captura
Carimbo de 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 formalmente aprovada pela parte responsável, permitindo que o processo de atendimento avance. Esse evento normalmente ocorre depois do status 'Waiting for Approval'. | ||
|
Por que isso importa
Marca o fim do subprocesso de aprovação e é um marco importante para acompanhar quanto tempo as aprovações levam e seu impacto no tempo total de resolução.
Onde obter
Inferido a partir de uma alteração de status no formulário SRM:Request de 'Waiting Approval' para um status posterior, como 'Planning' ou 'In Progress'. A decisão de aprovação é registrada nos formulários de aprovação relacionados.
Captura
Carimbo de data e hora da alteração de status após 'Waiting Approval', depois de uma decisão de aprovação positiva.
Tipo de evento
inferred
|
|||
|
Solicitação em análise
|
A solicitação de serviço está passando pela análise inicial e triagem da central de serviços para determinar sua natureza, prioridade e equipe responsável pelo atendimento. Isso normalmente é representado por uma alteração 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 obter
Inferido a partir de uma alteração de status no formulário SRM:Request para um valor como 'In Review' ou 'Planning'.
Captura
Carimbo de 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 uma fase de aprovação. Este é um estado terminal 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 obter
Inferido a partir de uma alteração de status no formulário SRM:Request para 'Rejected'.
Captura
Carimbo de 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, normalmente depois que o usuário forneceu 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 os tempos de espera externos e seu impacto na conformidade com o SLA.
Onde obter
Inferido quando o status do SRM:Request muda de 'Pending' novamente para 'In Progress'.
Captura
Carimbo de 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 trabalho técnico necessário para atender à solicitação de serviço foi concluído pelo agente. Agora, a solicitação está pronta para ser confirmada com o usuário antes de ser formalmente resolvida. | ||
|
Por que isso importa
Esta atividade separa a conclusão técnica da resolução formal, ajudando a identificar atrasos entre a conclusão do trabalho e a confirmação do usuário.
Onde obter
Isso pode ser inferido a partir de uma alteração de status em um ticket de atendimento de back-end, como o status de uma Work Order para 'Completed', antes que a SRM:Request principal seja marcada como 'Resolved'.
Captura
Carimbo de data e hora em que um ticket de back-end, como Work Order ou Incident, vinculado à SRM:Request é marcado como concluído.
Tipo de evento
inferred
|
|||
Guias de extração
Pronto para começar?
Use este Template para simplificar a coleta de dados e iniciar sua jornada de Process Mining com confiança. Comece a otimizar hoje o gerenciamento de suas solicitações de serviço!
Libere eficiência: otimize hoje o gerenciamento de solicitações de serviço
Alcance 70% de automação, elimine atrasos no atendimento e encante os usuários.
Não é necessário cartão de crédito. Comece em poucos minutos.