> Melhoria contínua de processos > Gestão de solicitações de serviço > Ivanti Service Manager > Template de dados

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

Ivanti Service Manager

Atributos da gestão de solicitações de serviço(21) Atividades da gestão de solicitações de serviço(14) Guias de extração(2)

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

Este Template apresenta um guia completo para coletar os dados essenciais à mineração de processos da gestão de solicitações de serviço. Ele mostra quais atributos reunir, quais atividades acompanhar e como extrair essas informações do seu sistema. Use este material para criar um Event Log consistente para sua análise.

Atributos recomendados para uma análise completa
Atividades principais para acompanhar na descoberta de processos
Orientações para extrair dados do sistema de origem

Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Baixar Template

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

Estes são os campos de dados recomendados para incluir no Event Log e analisar a fundo o processo de gestão de solicitações de serviço.

5 Obrigatório 9 Recomendado 7 Opcional

	Nome	Descrição
	Hora do evento EventTime	Registro de data e hora que indica quando uma atividade ou evento específico ocorreu.
Descrição A hora do evento, também chamada de hora de início, é a data e a hora exatas em que uma atividade foi registrada no sistema. Esse registro é essencial para ordenar corretamente os eventos e serve de base para todas as análises de Process Mining relacionadas ao tempo, como o cálculo dos tempos de ciclo, de espera e de duração das atividades. Por que isso importa Este registro de data e hora é essencial para ordenar os eventos cronologicamente e calcular todas as métricas de duração, fundamentais para a análise de performance. Onde encontrar Encontrado nos registros de auditoria, nas entradas do diário, por exemplo, Journal.CreatedDateTime, ou nos registros de mudança de status associados à solicitação de serviço. 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.
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 o elemento central que conecta todos os eventos seguintes, do registro inicial ao encerramento final, permitindo analisar de ponta a ponta a jornada de cada solicitação. Por que isso importa Este é o identificador essencial do caso, que conecta todas as atividades relacionadas em uma única instância do processo e permite a análise de ponta a ponta. Onde encontrar Esta é a chave primária do objeto de negócio Service Request, geralmente encontrada como ServiceReqNumber na tabela ServiceReq. Exemplos SR-0012345SR-0012346SR-0012347
	Nome da atividade ActivityName	Nome do evento ou da tarefa que ocorreu em um 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 enviada para aprovação' ou 'Solicitação de serviço resolvida'. Analisar a sequência e a frequência das atividades é fundamental para entender o fluxo do processo, identificar gargalos e descobrir desvios do procedimento padrão. Por que isso importa Define as etapas no mapa do processo e permite visualizar e analisar o fluxo, incluindo a identificação de retrabalho, gargalos e desvios. Onde encontrar Geralmente obtido das mudanças de status, das entradas no diário ou das descrições de eventos no registro de auditoria do Ivanti Service Manager. Exemplos Solicitação de serviço criadaSolicitação aprovadaSolicitação de serviço resolvidaSolicitação de serviço encerrada
	Sistema de origem SourceSystem	Sistema de onde os dados foram extraídos.
Descrição Este atributo identifica a origem dos dados do processo. Nesta visualização, o valor será constante, indicando que todos os dados vêm do Ivanti Service Manager. Isso é importante em ambientes onde os dados podem ser combinados de vários sistemas, pois garante clareza sobre a origem e o contexto dos dados. Por que isso importa Ele fornece um contexto essencial sobre a procedência dos dados e garante que as análises sejam atribuídas corretamente ao sistema de origem, especialmente em ambientes com vários sistemas. Onde encontrar Normalmente, é um valor estático adicionado durante a extração dos dados para identificar a origem do conjunto de dados. Exemplos Ivanti Service Manager
	Última atualização dos dados LastDataUpdate	Registro de data e hora da atualização mais recente dos dados do sistema de origem.
Descrição Este atributo indica a data e a hora da última extração de dados do Ivanti Service Manager. Ele informa o quão atualizados estão os dados analisados, para que você saiba qual período a análise abrange e quando esperar a próxima atualização. Por que isso importa Informa aos usuários 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 Este valor é gerado e registrado no conjunto de dados durante a extração. Exemplos 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Agente atribuído AssignedAgent	O usuário ou agente responsável pela solicitação de serviço.
Descrição O agente atribuído é a pessoa responsável por trabalhar na solicitação de serviço. Este atributo permite analisar o trabalho em nível individual, o que é útil para gerenciar a performance, equilibrar a carga de trabalho e identificar oportunidades de treinamento. Acompanhar as reatribuições entre agentes é essencial para calcular KPIs como “Média de reatribuições por solicitação” e entender as ineficiências do processo. Por que isso importa Permite analisar a carga de trabalho, a performance e os padrões de reatribuição de cada pessoa, que podem indicar problemas de treinamento, habilidades ou encaminhamento inicial. Onde encontrar Geralmente, está em um campo como “Owner” no objeto Service Request. O valor pode mudar a cada reatribuição e deve ser acompanhado no Event Log. Exemplos Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Data e hora da resolução ResolutionDateTime	A data e a hora em que a solicitação de serviço foi oficialmente resolvida.
Descrição Este atributo do caso registra a data e a hora finais em que o serviço foi prestado ou o problema foi corrigido, antes do fechamento formal da solicitação. Esse é o principal marco para calcular o tempo de ciclo completo de uma solicitação de serviço. É um componente essencial para medir a eficiência geral do processo e o cumprimento do SLA. Por que isso importa Define o ponto final do cálculo do tempo de ciclo do processo principal, um indicador-chave da eficiência na prestação de serviços. Onde encontrar Campo específico de data e hora no objeto Service Request, geralmente chamado de “ResolvedDateTime” ou algo semelhante. Exemplos 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Equipe atribuída AssignedTeam	A equipe ou o grupo de suporte responsável por atender à solicitação de serviço no momento.
Descrição Este atributo identifica a equipe responsável por atender à solicitação de serviço em determinado momento. Analisar as transferências entre equipes, o tempo dedicado por cada equipe e o volume de solicitações atendidas por cada uma é essencial para entender a distribuição da carga de trabalho, identificar gargalos e avaliar a performance das equipes. Esse atributo também dá suporte direto a Dashboards sobre cumprimento do SLA e carga de trabalho dos agentes. Por que isso importa Acompanha as responsabilidades e transferências, ajudando a analisar atrasos entre equipes, equilíbrio da carga de trabalho e quais equipes representam gargalos no processo. Onde encontrar Essas informações costumam ficar em um campo como “OwnerTeam” no objeto Service Request ou em registros de atribuição relacionados. Exemplos Central de serviços de TIOperações de redeSuporte de RHGestão de instalações
	Hora de término do evento EventEndTime	Data e hora que indicam quando uma atividade foi concluída.
Descrição A Hora de término do evento marca a conclusão de uma atividade. O intervalo entre a Hora do evento (início) e a Hora de término do evento corresponde ao tempo de processamento dessa atividade. Essa informação é essencial para identificar quais etapas do processo consomem mais tempo e apontar ineficiências e oportunidades de melhoria. Por que isso importa Permite calcular a duração de cada atividade, o que é essencial para identificar gargalos no processo e tarefas que levam muito tempo. Onde encontrar Pode não existir como um campo separado. Muitas vezes, corresponde à hora de início da atividade seguinte na sequência do mesmo caso. Exemplos 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Prazo do SLA SLADeadline	A data e a hora até as quais se espera que a solicitação de serviço seja resolvida.
Descrição O prazo do SLA é a data e a hora calculadas até as quais uma solicitação de serviço deve ser resolvida para cumprir o Acordo de Nível de Serviço. Esse prazo costuma ser definido com base em fatores como a prioridade e o tipo da solicitação. Comparar a hora real da resolução com esse prazo permite medir o cumprimento do SLA. Por que isso importa É a referência para medir a performance real, dando suporte direto ao cálculo das taxas de cumprimento do SLA e à identificação de solicitações em risco. Onde encontrar Muitas vezes, é um campo calculado no Ivanti, armazenado em campos relacionados ao Acordo de Nível de Serviço ou à oferta, como “ResolutionTargetDateTime”. Exemplos 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Prioridade Priority	O nível de prioridade atribuído à solicitação de serviço.
Descrição A prioridade indica a urgência de uma solicitação de serviço, geralmente em uma escala como “Baixa”, “Média”, “Alta” e “Crítico”. Esse atributo é fundamental para avaliar se o processo acelera o atendimento das solicitações de alta prioridade. A análise costuma comparar os tempos de ciclo e o cumprimento do SLA entre os níveis de prioridade para verificar se as regras de priorização estão funcionando como esperado. Por que isso importa É essencial para avaliar a eficácia da estratégia de priorização e garantir que as solicitações de alta prioridade sejam resolvidas mais rapidamente que as de baixa prioridade. Onde encontrar Campo padrão do objeto Service Request, geralmente chamado de “Priority”. Exemplos 1 - Crítico2 - Alta3 - Média4 - Baixa
	Status da solicitação de serviço ServiceRequestStatus	O status da solicitação de serviço no momento do evento.
Descrição Este atributo registra o estado da solicitação de serviço, como “Registrada”, “Em andamento”, “Pendente”, “Resolvida” ou “Fechada”. As mudanças de status costumam definir as atividades no registro do processo. Analisar o tempo em cada status pode revelar gargalos, como solicitações que ficam pendentes por muito tempo. Por que isso importa Mostra o estado da solicitação em determinado momento, o que é essencial para calcular o tempo em cada estado e identificar paralisações no processo. Onde encontrar Campo padrão do objeto Service Request, geralmente chamado de “Status”. Exemplos RegistradaAtivoAguardando o clienteAtendidaFechada
	Status do SLA SLAStatus	Indica se a solicitação de serviço foi resolvida dentro do prazo do SLA.
Descrição Este atributo derivado marca cada solicitação de serviço como “Cumprido” ou “Violado”, com base na comparação entre a hora da resolução e o prazo do SLA. Ele é a base do Dashboard “Performance de cumprimento do SLA” e do KPI “Taxa de cumprimento do Acordo de Nível de Serviço”. A lógica compara “ResolutionDateTime” com “SLADeadline” em cada caso. Por que isso importa Mede diretamente a performance em relação aos compromissos de serviço, algo essencial para avaliar a qualidade do serviço e manter a confiança dos usuários. Onde encontrar Calculado comparando “ResolutionDateTime” com “SLADeadline”. Se ResolutionDateTime <= SLADeadline, o status é “Cumprido”; caso contrário, é “Violado”. Exemplos CumpridoViolado
	Tipo de solicitação de serviço ServiceRequestType	A classificação ou categoria da solicitação de serviço.
Descrição Este atributo classifica a solicitação de serviço, por exemplo, como “Solicitação de hardware”, “Instalação de software” ou “Redefinição de senha”. É uma dimensão importante para que as equipes comparem a performance do processo, os tempos de ciclo e o cumprimento do SLA entre diferentes tipos de serviço. Entender essas diferenças ajuda a direcionar melhorias no processo e alocar recursos com mais eficiência. Por que isso importa Segmentar o processo por tipo de solicitação permite fazer análises direcionadas e identificar se determinados tipos de solicitação estão mais sujeitos a atrasos, retrabalho ou violações do SLA. Onde encontrar Provavelmente é um campo do objeto de negócio Service Request, muitas vezes chamado de “Service” ou “Category”. Consulte a documentação do Ivanti Service Manager para encontrar nomes de campos específicos, como “SvcReqTmplLink_Category”. Exemplos Nova solicitação de hardwareAcesso a softwareAlteração de contaSolicitação de informações
	Canal Channel	O método ou canal usado para enviar a solicitação de serviço.
Descrição O canal indica como a solicitação de serviço foi criada, por exemplo, pelo portal de autoatendimento, por e-mail, por telefone ou automaticamente por outro sistema. Analisar o volume de solicitações e os prazos de resolução por canal pode revelar quais são mais eficientes e quais podem precisar de melhorias no processo ou de treinamento para os usuários. Por que isso importa Ajuda a entender o comportamento dos usuários e a eficiência de cada canal, orientando decisões sobre a estratégia de prestação de serviços e oportunidades de automação. Onde encontrar Muitas vezes, fica em um campo como “Source” ou “CreatedBy” no objeto Service Request. Exemplos AutoatendimentoE-mailTelefoneEntrada direta
	Categoria da resolução ResolutionCategory	Uma classificação da solução fornecida para a solicitação de serviço.
Descrição A categoria da resolução oferece uma forma estruturada de classificar como uma solicitação de serviço foi resolvida. Geralmente, é uma classificação hierárquica, como categoria e subcategoria, que ajuda na análise de causa raiz e na identificação de tendências. Por exemplo, pode destacar problemas recorrentes ou tipos comuns de ações de atendimento, que podem servir para melhorar os serviços ou criar artigos para a base de conhecimento. Por que isso importa Oferece insights sobre as soluções aplicadas, ajudando a identificar problemas comuns, oportunidades de melhoria dos serviços e possibilidades de automação. Onde encontrar Geralmente, fica em campos de categorização preenchidos durante a resolução, como “ResolutionCategory” ou um campo personalizado de código de fechamento. Exemplos Treinamento do usuário necessárioSoftware implantadoHardware reparadoAcesso concedido
	Contagem de atribuições AssignmentCount	O número total de vezes que uma solicitação de serviço foi atribuída ou reatribuída.
Descrição Esta métrica calculada conta as atividades relacionadas à atribuição, como “Atribuído à equipe” e “Atribuído ao agente”, para cada solicitação de serviço. Um número alto de reatribuições, muitas vezes chamado de “pingue-pongue de chamados”, indica problemas de encaminhamento, falta de resolução no primeiro contato ou responsabilidades pouco claras entre as equipes. Este atributo é essencial para o KPI “Média de reatribuições por solicitação”. Por que isso importa Quantifica transferências ineficientes e problemas de encaminhamento. Uma contagem alta indica fortemente prazos de resolução prolongados e frustração dos usuários. Onde encontrar Calculado contando as ocorrências de atividades relacionadas à atribuição para cada ServiceRequestID único durante a preparação dos dados. Exemplos 12345
	Contagem de reaberturas ReopenCount	O número de vezes que uma solicitação de serviço resolvida foi reaberta.
Descrição Este atributo é um contador que aumenta sempre que uma solicitação de serviço passa do estado “Resolvida” ou “Fechada” para “Ativo”. Uma contagem alta de reaberturas indica fortemente problemas na qualidade da resolução na primeira tentativa, soluções incompletas ou problemas recorrentes. O atributo dá suporte direto ao KPI “Taxa de retrabalho em solicitações de serviço”. Por que isso importa Mede diretamente o retrabalho e é um indicador-chave da qualidade da resolução. Uma contagem alta sugere que a solução inicial não foi eficaz. Onde encontrar Normalmente, é um campo de contador no objeto Service Request, incrementado por uma regra de negócio quando o status muda conforme as condições definidas. O campo pode se chamar “ReopenCounter”. Exemplos 0123
	Departamento solicitante RequestorDepartment	O departamento da empresa ao qual pertence o usuário que enviou a solicitação de serviço.
Descrição Este atributo identifica o departamento do funcionário ou sistema que iniciou a solicitação de serviço, como “Vendas”, “Finanças” ou “Recursos Humanos”. Ele permite analisar a qualidade e a demanda dos serviços em diferentes áreas da organização. Por exemplo, ajuda a identificar se determinados departamentos enfrentam prazos de resolução mais longos ou enviam mais solicitações. Por que isso importa Permite analisar o consumo e a qualidade dos serviços por unidade de negócio, ajudando a identificar problemas ou tendências específicos de cada departamento. Onde encontrar Essas informações geralmente vêm do perfil do usuário solicitante, vinculado à solicitação de serviço. O campo pode ser “Department” no objeto Profile.Employee. Exemplos FinançasVendasMarketingTecnologia da informação
	É retrabalho IsRework	Um indicador booleano que informa se a solicitação de serviço envolveu atividades de retrabalho.
Descrição Este indicador calculado recebe o valor verdadeiro quando uma solicitação de serviço apresenta sinais de retrabalho, como ser reaberta após a resolução ou ter determinadas atividades repetidas em um ciclo. Ele simplifica o cálculo do KPI “Taxa de retrabalho em solicitações de serviço” e ajuda a filtrar instâncias ineficientes do processo em Dashboards como “Fluxos de retrabalho e reatribuição”. Por que isso importa Ajuda a identificar e quantificar facilmente o volume de solicitações que exigem esforço adicional não planejado, destacando problemas de qualidade e eficiência. Onde encontrar Derivado dos dados. A lógica pode se basear no atributo “ReopenCount” ser maior que zero ou na detecção de sequências específicas de atividades, como vários eventos “Atribuído ao agente”. Exemplos truefalse
	Nome do fornecedor VendorName	O nome do fornecedor externo envolvido na resolução da solicitação.
Descrição Este atributo identifica o fornecedor terceirizado contratado para ajudar a atender ou concluir uma solicitação de serviço. É essencial para o Dashboard “Duração das atividades de fornecedores externos”, pois permite medir e comparar a performance de diferentes fornecedores. Acompanhar esse dado ajuda a gerenciar o relacionamento com fornecedores e identificar gargalos causados por dependências externas. Por que isso importa Permite analisar a performance de terceiros e o impacto deles nos prazos gerais de resolução das solicitações de serviço, dando suporte à gestão de fornecedores. Onde encontrar Pode ser um campo de um objeto de tarefa associado à solicitação de serviço ou um campo específico da própria solicitação, caso haja um fornecedor atribuído. Exemplos Suporte da DellConsultoria OracleMicrosoft Premiernull

Obrigatório Recomendado Opcional

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

Estas são as etapas e os marcos essenciais do processo que você deve registrar no Event Log para descobrir e analisar o processo com precisão.

5 Recomendado 9 Opcional

	Atividade	Descrição
	Solicitação atribuída à equipe	A solicitação de serviço é atribuída a uma equipe de suporte específica para atendimento. Isso é identificado pelo preenchimento ou pela alteração do campo 'OwnerTeam' no registro da solicitação de serviço.
Por que isso importa Este evento é essencial para analisar a performance de cada equipe, a distribuição da carga de trabalho e os tempos de transferência entre equipes. Ele ajuda a identificar quais equipes se tornam gargalos no processo. Onde encontrar Acompanhado pelas alterações no campo 'OwnerTeam' no histórico de auditoria ou no diário da solicitação de serviço. Coleta Evento de atualização do campo 'OwnerTeam', normalmente registrado em uma trilha de auditoria. Tipo de evento explicit
	Solicitação atribuída a um agente	Um agente específico assume a responsabilidade pela solicitação de serviço. Essa atividade costuma ser identificada quando o campo 'Owner', que indica o agente responsável, é preenchido ou atualizado pela primeira vez.
Por que isso importa Este evento marca o fim do tempo inicial de espera ou na fila. Medir o tempo até esta atividade ajuda a identificar problemas na alocação de recursos e dá suporte ao Dashboard de carga de trabalho dos agentes. Onde encontrar Identificado pelo preenchimento ou pela alteração do campo 'Owner' no registro da solicitação de serviço, conforme o histórico de auditoria. Coleta O primeiro registro de data e hora em que o campo 'Owner' é preenchido com o nome de um agente após a criação ou a atribuição à equipe. Tipo de evento inferred
	Solicitação de serviço criada	Esta atividade marca o início do ciclo de vida da solicitação de serviço, quando uma nova solicitação é enviada formalmente e registrada no Ivanti. O evento é capturado quando um novo registro é criado no objeto de negócio Service Request, gerando um ID exclusivo para a solicitação.
Por que isso importa Este é o principal evento de início do processo. Analisar o tempo entre esse ponto e a resolução é fundamental para medir o tempo de ciclo total e a eficiência do processo. Onde encontrar Este dado é obtido do registro de data e hora de criação do registro da solicitação de serviço, por exemplo, do campo CreatedDateTime no objeto de negócio ServiceReq. Coleta Evento de criação do registro na tabela ServiceReq, identificado pelo registro de data e hora de criação. Tipo de evento explicit
	Solicitação de serviço encerrada	A solicitação de serviço foi oficialmente encerrada e não permite novas ações. Isso costuma acontecer automaticamente após um período definido no estado 'Resolvida', marcando o fim do ciclo de vida.
Por que isso importa Esta atividade marca o fim definitivo do processo. O tempo entre 'Resolvida' e 'Encerrada' pode revelar atrasos na confirmação ou em processos automatizados do sistema. Onde encontrar Identificado pela mudança do campo 'Status' do registro da solicitação de serviço para 'Encerrada', junto com o registro de data e hora correspondente. Coleta Identificação da atualização do campo 'Status' para 'Encerrada' no histórico de auditoria. Tipo de evento inferred
	Solicitação de serviço resolvida	A solicitação de serviço é considerada resolvida e a solução foi entregue ao usuário. Este é um marco importante, identificado pela mudança de status para 'Resolvida', que muitas vezes interrompe a contagem do SLA.
Por que isso importa Este é um ponto final essencial para medir o tempo de resolução e o cumprimento do SLA. O tempo entre a criação e esta atividade é um KPI central da performance do processo. Onde encontrar Identificado pela mudança do campo 'Status' do registro da solicitação de serviço para 'Resolvida', junto com o registro de data e hora correspondente. Coleta Identificação da atualização do campo 'Status' para 'Resolvida' no histórico de auditoria. Tipo de evento inferred
	Fornecedor externo acionado	O atendimento da solicitação de serviço foi transferido para um fornecedor externo ou terceiro. Isso costuma ser identificado por uma mudança de status para 'Aguardando terceiro' ou um estado semelhante.
Por que isso importa Esta atividade é essencial para medir a performance do fornecedor e seu impacto no tempo de ciclo total. Ela permite analisar atrasos relacionados a fornecedores e dá suporte ao Dashboard de duração das atividades de fornecedores externos. Onde encontrar Identificado por uma mudança de status no registro da solicitação de serviço para algo como 'Aguardando terceiro' ou 'Pendente com fornecedor'. Coleta Identificação de uma mudança no campo 'Status' para um estado definido como 'aguardando fornecedor'. Tipo de evento inferred
	Informações fornecidas pelo usuário	O solicitante forneceu as informações necessárias, permitindo que o agente retome o trabalho. Isso é identificado quando a solicitação sai do status 'Aguardando cliente' e volta para um estado ativo.
Por que isso importa Este evento encerra o ciclo da solicitação de informações. O tempo entre pedir e receber as informações é um componente importante dos atrasos do processo e dos ciclos de retrabalho. Onde encontrar Identificado quando o campo 'Status' da solicitação de serviço muda de 'Aguardando cliente' para um estado ativo, como 'Ativo' ou 'Em andamento'. Coleta Identificação de uma mudança de status de 'aguardando usuário' para um estado ativo. Tipo de evento inferred
	Informações solicitadas ao usuário	O agente responsável precisa de mais informações do solicitante para dar andamento ao atendimento. Isso é identificado quando o status da solicitação muda para algo como 'Aguardando cliente'.
Por que isso importa Esta atividade destaca atrasos causados por informações iniciais incompletas. Acompanhar sua frequência e duração é essencial para a análise do impacto das solicitações de informação e para identificar oportunidades de melhoria do processo. Onde encontrar Identificado por uma mudança de status no registro da solicitação de serviço para um status como 'Aguardando cliente' ou 'Pendente'. Coleta Identificação de uma mudança no campo 'Status' para um estado definido como 'aguardando usuário'. Tipo de evento inferred
	Prioridade alterada	A prioridade da solicitação de serviço foi atualizada após sua criação. Este evento é capturado no registro ou histórico de auditoria que acompanha as alterações nos campos.
Por que isso importa Acompanhar as mudanças de prioridade é essencial para a visão geral da eficácia da priorização. Isso ajuda a determinar se os escalonamentos são gerenciados corretamente e se a priorização inicial está adequada. Onde encontrar Este é um evento explícito capturado no histórico de auditoria do registro da solicitação de serviço, que registra as alterações no campo 'Priority'. Coleta Evento de atualização do campo 'Priority', registrado na trilha de auditoria do sistema. Tipo de evento explicit
	Solicitação aprovada	A solicitação de serviço recebeu todas as aprovações necessárias e pode seguir para o atendimento. Este evento é capturado quando o fluxo de aprovação é concluído com sucesso e o status da solicitação muda.
Por que isso importa Esta atividade marca um momento importante: o fim da etapa de aprovação e o início do atendimento. Ela permite medir a eficiência do próprio processo de aprovação. Onde encontrar Identificado pela mudança de status de 'Aguardando aprovação' para 'Aprovada' ou 'Atendida'. Também pode ser um evento explícito registrado no objeto de negócio FRS_Approval. Coleta Mudança do campo 'Status' do registro da solicitação de serviço de um estado de aprovação para um estado ativo. Tipo de evento inferred
	Solicitação de serviço atendida	Todas as tarefas necessárias para atender à solicitação de serviço foram concluídas pelo agente ou pelo sistema. Isso é identificado por uma mudança de status para 'Atendida', que muitas vezes ocorre antes do status final 'Resolvida'.
Por que isso importa Este marco indica a conclusão do trabalho técnico ou processual. É um ponto importante para medir o tempo de atendimento ativo antes da confirmação final e do encerramento. Onde encontrar Identificado pela mudança do campo 'Status' do registro da solicitação de serviço para 'Atendida'. Coleta Mudança do campo 'Status' para 'Atendida', identificada no histórico do registro. Tipo de evento inferred
	Solicitação de serviço cancelada	A solicitação de serviço foi cancelada pelo usuário ou por um agente antes da resolução. Este é um estado final alternativo, identificado pela mudança de status para 'Cancelada' ou 'Retirada'.
Por que isso importa Este evento representa um encerramento fora do fluxo padrão. Analisar os motivos dos cancelamentos pode revelar problemas no próprio processo de solicitação ou mudanças nas necessidades dos usuários. Onde encontrar Identificado pela mudança do campo 'Status' do registro da solicitação de serviço para 'Cancelada'. Coleta Identificação da atualização do campo 'Status' para 'Cancelada' no histórico de auditoria. Tipo de evento inferred
	Solicitação de serviço reaberta	Uma solicitação de serviço já resolvida foi reativada porque o problema persiste ou a solução não foi satisfatória. Isso é identificado quando o status muda de 'Resolvida' para um estado ativo, como 'Ativa' ou 'Atribuída'.
Por que isso importa Esta atividade indica diretamente retrabalho e baixa qualidade na resolução na primeira tentativa. Analisar as reaberturas ajuda a identificar pontos fracos do processo e a melhorar o KPI de taxa de retrabalho das solicitações de serviço. Onde encontrar Identificado no histórico de auditoria quando o campo 'Status' muda de 'Resolvida' ou 'Fechada' para um status ativo. Coleta Mudança de status de um estado final ('Resolvida', 'Fechada') para um estado aberto ('Ativa', 'Atribuída'). Tipo de evento inferred
	Solicitação enviada para aprovação	A solicitação de serviço foi enviada para as aprovações necessárias antes de ser atendida. Isso costuma ser identificado quando o status da solicitação muda para 'Enviada' ou 'Aguardando aprovação', o que geralmente inicia um fluxo de aprovação.
Por que isso importa Acompanhar esta atividade ajuda a identificar atrasos na etapa de aprovação. Esperas longas podem se tornar um gargalo significativo, afetando o tempo total de resolução e a satisfação dos usuários. Onde encontrar Identificado por uma mudança de status no registro da solicitação de serviço, provavelmente para um status como 'Enviada' ou 'Aguardando aprovação'. Os dados também podem vir dos objetos de negócio FRS_Approval ou FRS_ApprovalVoteTracking. Coleta Mudança do campo 'Status' do registro da solicitação de serviço para um estado de aprovação pendente. Tipo de evento inferred

Recomendado Opcional

Guias de extração

Como extrair seus dados do Ivanti Service Manager

Etapas

Faça login no Ivanti Service Manager com um perfil que tenha acesso de leitura às solicitações de serviço e ao histórico de auditoria delas.
No painel de navegação principal, acesse o espaço de trabalho Service Request.
Este processo exige duas exportações de dados separadas, que serão combinadas externamente. A primeira captura o evento de criação e os atributos principais; a segunda registra o histórico detalhado de alterações.
Primeira exportação (eventos de criação): crie uma nova Saved Search no objeto de negócio ServiceReq. Defina um filtro para CreatedDateTime e selecione as solicitações de serviço criadas no período de análise desejado, por exemplo, nos últimos seis meses.
Configure as colunas da pesquisa de criação para incluir RecId, ServiceReqNumber (para ServiceRequestID), CreatedDateTime (para EventTime), SvcReqTmplLink_Category (para ServiceRequestType), OwnerTeam, Responsável, Priority, Status, ResolutionDateTime e TargetDateTime (para SLADeadline).
Execute a pesquisa e use a função de exportação da grade, geralmente representada por um ícone de disco ou seta, para exportar os dados para um arquivo CSV. Dê a ele o nome ServiceRequests.csv.
Segunda exportação (eventos do histórico de auditoria): crie uma nova Saved Search, desta vez no objeto de negócio FRS_data_audit_history, que registra alterações nos campos.
Filtre a pesquisa para incluir somente alterações relacionadas a solicitações de serviço. Adicione um filtro em que ParentObjectType seja igual a 'ServiceReq'. Adicione também um filtro em AuditDate para usar o mesmo período de análise da etapa anterior.
Configure as colunas da pesquisa de auditoria para incluir ParentLink_RecID (para vincular à solicitação de serviço), FieldName, OldValue, NewValue e AuditDate (para EventTime). Exporte os dados para um segundo arquivo CSV chamado AuditHistory.csv.
Transforme e combine os dados: os arquivos CSV exportados precisam ser combinados e reorganizados em um único Event Log. Use uma ferramenta de preparação de dados, como Power Query no Excel, Python ou uma ferramenta de banco de dados, para seguir estas etapas:
- Carregue ServiceRequests.csv e AuditHistory.csv.
- Use o arquivo ServiceRequests.csv para gerar o evento 'Solicitação de serviço criada' para cada solicitação.
- Use o arquivo AuditHistory.csv para gerar todos os outros eventos. Mapeie os valores das colunas FieldName e NewValue para os nomes de atividade necessários. Por exemplo, se FieldName for 'Status' e NewValue for 'Resolvido', defina ActivityName como 'Solicitação de serviço resolvida'.
- Una os eventos de auditoria transformados aos dados das solicitações de serviço usando ParentLink_RecID do arquivo de auditoria e RecId do arquivo de solicitações. Assim, os atributos do caso serão incluídos em cada evento.
- Combine os eventos de criação e os eventos derivados da auditoria em uma única tabela.
Formate a tabela final combinada com os cabeçalhos de coluna necessários: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate e outros atributos recomendados. Confirme se todos os timestamps usam um formato consistente.
Salve o Event Log final em um único arquivo CSV, pronto para ser carregado.

Configuração

Objetos de negócio: Este método exige a exportação de dois objetos de negócio: ServiceReq, com os dados principais das solicitações, e FRS_data_audit_history, com os dados dos eventos.
Filtro de período: É essencial aplicar um filtro de período às duas exportações para controlar o volume de dados. Use o campo CreatedDateTime em ServiceReq e o campo AuditDate em FRS_data_audit_history. Para a análise inicial, recomendamos um período de 3 a 6 meses.
Filtros principais do histórico de auditoria:
- Filtre ParentObjectType por 'ServiceReq' para extrair somente alterações relacionadas a solicitações de serviço.
- Se quiser, filtre FieldName para incluir apenas campos relevantes ao processo, como 'Status', 'Owner' (Responsável), 'OwnerTeam' e 'Priority'. Isso pode reduzir bastante o tamanho da exportação.
Pré-requisitos: É necessário ter uma conta de usuário no Ivanti Service Manager com permissão para criar pesquisas salvas e exportar dados dos objetos de negócio ServiceReq e FRS_data_audit_history.
Considerações de performance: A tabela FRS_data_audit_history pode ser muito grande. Exportar dados sem um filtro de período restritivo pode afetar a performance do Ivanti e causar uma falha por tempo limite. Se necessário, exporte os dados em lotes mensais ou trimestrais menores.

Consulta de exemplo sql

-- This script represents the transformation logic to be applied in a data preparation tool (e.g., Power Query, Python, SQL) after exporting the two CSV files from Ivanti.

-- Step 1: Define the 'Service Request Created' events from the ServiceRequests.csv export.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    'Service Request Created' AS ActivityName,
    sr.CreatedDateTime AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    sr.Status AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    DATEDIFF(hour, sr.CreatedDateTime, sr.ResolutionDateTime) AS CycleTime,
    CASE WHEN sr.ResolutionDateTime IS NOT NULL AND sr.ResolutionDateTime <= sr.TargetDateTime THEN 'Met' ELSE 'Breached' END AS SLAStatus,
    sr.RecId -- Internal key for joining
FROM
    ServiceRequests_Export sr -- Represents the ServiceRequests.csv file

UNION ALL

-- Step 2: Transform records from AuditHistory.csv into specific activities and join with service request attributes.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 'Request Submitted for Approval'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 'Request Approved'
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Team'
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Agent'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 'Information Requested from User'
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 'Information Provided by User'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 'External Vendor Engaged'
        WHEN audit.FieldName = 'Priority' THEN 'Priority Changed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 'Service Request Fulfilled'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 'Service Request Resolved'
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 'Service Request Reopened'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 'Service Request Closed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 'Service Request Cancelled'
    END AS ActivityName,
    audit.AuditDate AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    audit.NewValue AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    NULL AS CycleTime,
    NULL AS SLAStatus,
    sr.RecId
FROM
    AuditHistory_Export audit -- Represents the AuditHistory.csv file
JOIN
    ServiceRequests_Export sr ON audit.ParentLink_RecID = sr.RecId
WHERE
    -- This filter ensures that only rows corresponding to a defined activity are included.
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 1
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 1
        WHEN audit.FieldName = 'Priority' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 1
        ELSE 0
    END = 1;

Etapas

Pré-requisitos e configuração: confirme se o Python 3.6 ou superior está instalado no seu sistema. Instale as bibliotecas necessárias, requests para fazer chamadas à API e pandas para manipular dados, executando pip install requests pandas. Solicite ao administrador do Ivanti Service Manager uma chave de API com pelo menos permissões de leitura para os objetos de negócio ServiceReq e FRS_Audit_ServiceReq.
Configure o script: baixe o script Python fornecido. Abra-o em um editor de texto ou IDE e atualize as variáveis de espaço reservado no início do arquivo: TENANT_URL, API_KEY, START_DATE e END_DATE, de acordo com seu ambiente Ivanti e o período de extração desejado.
Execute o script: execute-o na linha de comando com python your_script_name.py. Primeiro, o script exibirá uma mensagem informando que está se conectando e autenticando na API do Ivanti.
Recupere os dados das solicitações de serviço: o script começa consultando o objeto de negócio ServiceReq para recuperar todas as solicitações criadas no período especificado. Ele gerencia automaticamente a paginação da API para recuperar a lista completa de solicitações e exibe atualizações de progresso enquanto busca cada página de dados.
Recupere o histórico de auditoria: para cada solicitação de serviço recuperada, o script faz uma segunda consulta ao objeto de negócio FRS_Audit_ServiceReq. Assim, obtém o histórico completo de alterações nos campos daquela solicitação, essencial para criar um Event Log detalhado.
Gere o evento 'Criada': ao processar cada solicitação de serviço, o script cria primeiro o evento 'Solicitação de serviço criada'. O horário desse evento vem diretamente do campo CreatedDateTime do registro da solicitação.
Gere eventos com base na trilha de auditoria: em seguida, o script percorre os registros da trilha de auditoria de cada solicitação de serviço. Ele analisa cada registro para identificar alterações em campos importantes, como Status, OwnerTeam, Responsável e Priority.
Mapeie as alterações para atividades: uma lógica de mapeamento predefinida no script converte essas alterações nos campos em nomes de atividades específicos. Por exemplo, uma alteração no campo Status de 'Ativo' para 'Resolvido' é registrada como a atividade 'Solicitação de serviço resolvida'.
Monte o Event Log: todos os eventos gerados, tanto o evento inicial de criação quanto as alterações posteriores da trilha de auditoria, são reunidos em uma lista estruturada. Cada evento inclui o ID da solicitação de serviço, o nome da atividade, o horário e outros atributos relevantes.
Transforme e formate os dados: a lista de eventos coletados é convertida em um DataFrame do Pandas. O script garante que todas as colunas correspondam ao esquema exigido pelo ProcessMind, incluindo ServiceRequestID, ActivityName e EventTime.
Exporte para CSV: depois de processar todas as solicitações de serviço e seus históricos, o script salva o DataFrame final em um arquivo CSV chamado ivanti_servicereq_event_log.csv, no mesmo diretório em que foi executado. O arquivo está pronto para ser carregado.

Configuração

URL do endpoint da API: URL base da API REST do ambiente Ivanti Service Manager. Defina esse valor na variável TENANT_URL do script, por exemplo, https://your-tenant.ivanti.com.
Chave de API: Chave válida da API REST, gerada no console de administração do Ivanti. Ela deve estar associada a um perfil com permissões de leitura nos objetos de negócio ServiceReq e FRS_Audit_ServiceReq.
Período: O script exige START_DATE e END_DATE no formato 'YYYY-MM-DD'. Para a análise inicial, recomendamos um período de 3 a 6 meses, que oferece um volume de dados viável e permite capturar variações suficientes do processo.
Tamanho da página (TOP_COUNT): Essa variável do script define o número de registros buscados por chamada à API. O valor padrão é 500, um bom equilíbrio entre performance e uso de memória. Você pode ajustá-lo conforme a performance do servidor da API.
Campos necessários (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): O script especifica quais campos buscar na API para reduzir o tamanho dos dados transferidos. Confira se as listas incluem todos os campos necessários para os atributos obrigatórios e recomendados.

Consulta de exemplo python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Ivanti tenant URL and API Key
TENANT_URL = class="hl-string">"https://[your-tenant.ivanti.com]"
API_KEY = class="hl-string">"[Your Ivanti REST API Key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># API settings
TOP_COUNT = 500
API_BO_URL = fclass="hl-string">"{TENANT_URL}/api/odata/businessobject"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"rest_api_key={API_KEY}",
    class="hl-string">"Content-Type": class="hl-string">"application/json"
}

class=class="hl-string">"hl-comment"># Fields to select from the API to reduce payload size
SELECT_FIELDS_SR = class="hl-string">"RecId,ServiceReqNumber,CreatedDateTime,OwnerTeam,Owner,Priority,Status,Subject,Resolution,ResolvedDateTime,ResponseTarget,Service"
SELECT_FIELDS_AUDIT = class="hl-string">"FieldName,OldValue,NewValue,ModifiedDateTime,ParentLink_RecID"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def get_paginated_data(url, params):
    class="hl-string">"""Fetches all pages of data from a given Ivanti API endpoint."""
    all_records = []
    page_url = url
    while page_url:
        try:
            response = requests.get(page_url, headers=HEADERS, params=params)
            response.raise_for_status() 
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            page_url = data.get(class="hl-string">'@odata.nextLink')
            print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
            class=class="hl-string">"hl-comment"># Parameters are only needed for the first request
            params = {}
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break
    return all_records

def map_status_change_to_activity(old_status, new_status):
    class="hl-string">"""Maps status transitions to activity names."""
    class=class="hl-string">"hl-comment"># Normalize statuses by removing spaces and converting to lower case
    old = str(old_status).lower().replace(class="hl-string">" ", class="hl-string">"") if old_status else class="hl-string">""
    new = str(new_status).lower().replace(class="hl-string">" ", class="hl-string">"") if new_status else class="hl-string">""

    if new in [class="hl-string">'submitted', class="hl-string">'pendingapproval']:
        return class="hl-string">'Request Submitted for Approval'
    if new == class="hl-string">'approved':
        return class="hl-string">'Request Approved'
    if new == class="hl-string">'waitingforcustomer':
        return class="hl-string">'Information Requested from User'
    if old == class="hl-string">'waitingforcustomer' and new not in [class="hl-string">'resolved', class="hl-string">'closed', class="hl-string">'cancelled']:
        return class="hl-string">'Information Provided by User'
    if new == class="hl-string">'waitingfor3rdparty':
        return class="hl-string">'External Vendor Engaged'
    if new == class="hl-string">'fulfilled':
        return class="hl-string">'Service Request Fulfilled'
    if new == class="hl-string">'resolved':
        return class="hl-string">'Service Request Resolved'
    if old == class="hl-string">'resolved' and new not in [class="hl-string">'closed']:
        return class="hl-string">'Service Request Reopened'
    if new == class="hl-string">'closed':
        return class="hl-string">'Service Request Closed'
    if new == class="hl-string">'cancelled':
        return class="hl-string">'Service Request Cancelled'
    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting Ivanti Service Request extraction...")

    class=class="hl-string">"hl-comment"># 1. Fetch all Service Requests within the date range
    sr_url = fclass="hl-string">"{API_BO_URL}/ServiceReqs"
    sr_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z"
    sr_params = {
        class="hl-string">"$filter": sr_filter,
        class="hl-string">"$select": SELECT_FIELDS_SR,
        class="hl-string">"$top": TOP_COUNT
    }
    print(fclass="hl-string">"Fetching Service Requests from {START_DATE} to {END_DATE}...")
    service_requests = get_paginated_data(sr_url, sr_params)

    if not service_requests:
        print(class="hl-string">"No service requests found for the given date range.")
        return

    print(fclass="hl-string">"Found {len(service_requests)} service requests. Now fetching audit histories...")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 2. For each Service Request, fetch its audit history and build events
    for i, sr in enumerate(service_requests):
        print(fclass="hl-string">"Processing SR {i+1}/{len(service_requests)}: {sr.get('ServiceReqNumber')}")
        sr_id = sr.get(class="hl-string">'RecId')
        sr_number = sr.get(class="hl-string">'ServiceReqNumber')
        
        class=class="hl-string">"hl-comment"># Event: Service Request Created
        event_log.append({
            class="hl-string">'ServiceRequestID': sr_number,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': sr.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
            class="hl-string">'LastDataUpdate': current_time,
            class="hl-string">'EventEndTime': None,
            class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
            class="hl-string">'AssignedTeam': sr.get(class="hl-string">'OwnerTeam'),
            class="hl-string">'AssignedAgent': sr.get(class="hl-string">'Owner'),
            class="hl-string">'Priority': sr.get(class="hl-string">'Priority'),
            class="hl-string">'ServiceRequestStatus': sr.get(class="hl-string">'Status'),
            class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
            class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
            class="hl-string">'CycleTime': None, class=class="hl-string">"hl-comment"># To be calculated later if needed
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># To be calculated later if needed
        })

        class=class="hl-string">"hl-comment"># Fetch audit history for this SR
        audit_url = fclass="hl-string">"{API_BO_URL}/FRS_Audit_ServiceReqs"
        audit_params = {
            class="hl-string">"$filter": fclass="hl-string">"ParentLink_RecID eq '{sr_id}'",
            class="hl-string">"$select": SELECT_FIELDS_AUDIT,
            class="hl-string">"$orderby": class="hl-string">"ModifiedDateTime asc"
        }
        audit_history = get_paginated_data(audit_url, audit_params)

        if not audit_history:
            continue

        class=class="hl-string">"hl-comment"># Process audit history to create events
        for audit_entry in audit_history:
            field_name = audit_entry.get(class="hl-string">'FieldName')
            event_time = audit_entry.get(class="hl-string">'ModifiedDateTime')
            old_value = audit_entry.get(class="hl-string">'OldValue')
            new_value = audit_entry.get(class="hl-string">'NewValue')
            activity_name = None
            current_team = None
            current_agent = None
            current_priority = None
            current_status = None

            if field_name == class="hl-string">'Status':
                activity_name = map_status_change_to_activity(old_value, new_value)
                current_status = new_value
            elif field_name == class="hl-string">'OwnerTeam' and new_value:
                activity_name = class="hl-string">'Request Assigned to Team'
                current_team = new_value
            elif field_name == class="hl-string">'Owner' and new_value:
                activity_name = class="hl-string">'Request Assigned to Agent'
                current_agent = new_value
            elif field_name == class="hl-string">'Priority' and old_value is not None:
                activity_name = class="hl-string">'Priority Changed'
                current_priority = new_value

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestID': sr_number,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
                    class="hl-string">'LastDataUpdate': current_time,
                    class="hl-string">'EventEndTime': None,
                    class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
                    class="hl-string">'AssignedTeam': current_team or sr.get(class="hl-string">'OwnerTeam'), class=class="hl-string">"hl-comment"># Use current if changed, else original
                    class="hl-string">'AssignedAgent': current_agent or sr.get(class="hl-string">'Owner'),
                    class="hl-string">'Priority': current_priority or sr.get(class="hl-string">'Priority'),
                    class="hl-string">'ServiceRequestStatus': current_status or sr.get(class="hl-string">'Status'),
                    class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
                    class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
                    class="hl-string">'CycleTime': None,
                    class="hl-string">'SLAStatus': None
                })

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated.")
        return

    print(class="hl-string">"Extraction complete. Creating CSV file...")
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure chronological order
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], ascending=[True, True])
    
    class=class="hl-string">"hl-comment"># Forward fill key attributes to provide context for each event
    df[class="hl-string">'AssignedTeam'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedTeam'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssignedAgent'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedAgent'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'Priority'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'Priority'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ServiceRequestStatus'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'ServiceRequestStatus'].fillna(method=class="hl-string">'ffill')

    output_filename = class="hl-string">'ivanti_servicereq_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log saved successfully to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

Pronto para começar?

Conheça todo o potencial do processo de gestão de solicitações de serviço com este Template detalhado de dados. Comece a otimizar suas operações hoje.

Voltar ao guia de melhoria

Baixar Template

Comece hoje a otimizar a gestão de solicitações de serviço

Acabe com a demora no atendimento, reduza a frustração dos usuários e alcance uma taxa de automação de 70%.

Começar o teste grátis

Não é necessário informar cartão de crédito. A configuração leva poucos minutos.

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

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

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

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

Guias de extração

Pesquisa salva e exportação de dados da grade do Ivanti para CSV

Etapas

Configuração

Consulta de exemplo sql

Script Python usando a API REST do Ivanti

Etapas

Configuração

Consulta de exemplo python

Pronto para começar?

Comece hoje a otimizar a gestão de solicitações de serviço