Seu Template de dados de Purchase to Pay - Requisition

NetSuite
Seu Template de dados de Purchase to Pay - Requisition

Seu Template de dados de Purchase to Pay - Requisition

Este Template oferece um roteiro claro para coletar os dados essenciais necessários à análise do seu processo Purchase to Pay, Requisition. Ele apresenta os principais atributos, define as atividades que devem ser monitoradas e traz orientações práticas para extrair essas informações do seu sistema de origem. Use este recurso para preparar seu Event Log para uma análise de Process Mining com insights relevantes.
  • Atributos recomendados para coleta
  • Principais atividades para monitorar na descoberta do processo
  • Orientações para extração de dados
Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Purchase to Pay - Requisição: atributos

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise completa do processo Purchase to Pay - Requisição.
3 Obrigatório 4 Recomendado 12 Opcional
Nome Descrição
Horário do evento
EventTime
A data e o horário exatos em que a atividade ocorreu.
Descrição

O horário do evento, ou timestamp, registra o momento exato em que uma atividade ocorreu. Esses dados temporais são essenciais para entender a dinâmica do processo de requisição, incluindo sua duração, a sequência dos eventos e seus respectivos horários.

Na análise de processos, os timestamps são usados para calcular tempos de ciclo, tempos de espera entre atividades e o cumprimento de acordos de nível de serviço. Eles são a base de todas as análises orientadas por tempo, permitindo criar Dashboards como "Tempo do ciclo de aprovação da requisição" e KPIs como "Tempo médio do ciclo da requisição". Timestamps precisos são fundamentais para um modelo de processo confiável.

Por que isso importa

Esse timestamp é a base de todas as análises relacionadas à performance, como o cálculo de tempos de ciclo, a identificação de atrasos e a medição da eficiência do processo.

Onde obter

Essas informações são capturadas em campos gerados pelo sistema, como "Date Created", ou nos timestamps disponíveis nas System Notes ou nos logs de execução do Workflow de cada transação.

Exemplos
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
ID da requisição de compra
PurchaseRequisitionId
O identificador exclusivo de cada requisição de compra, usado como Case ID principal para a análise do processo.
Descrição

O Purchase Requisition ID é o identificador central que vincula todas as atividades e eventos relacionados a uma solicitação específica de bens ou serviços. Cada requisição recebe um ID exclusivo ao ser criada no NetSuite, que permanece constante durante todo o seu ciclo de vida.

No process mining, esse atributo é fundamental para correlacionar os casos. Ele permite reconstruir a jornada de ponta a ponta de cada requisição, desde a criação inicial, passando por todas as etapas de aprovação e alterações, até os resultados finais, como aprovação, rejeição ou conversão em Purchase Order. Analisar os processos por esse ID é essencial para calcular as durações do ciclo de vida, acompanhar mudanças de status e identificar variações nos fluxos do processo.

Por que isso importa

Esta é a chave essencial para rastrear o ciclo de vida completo de uma única requisição de compra, permitindo analisar os fluxos do processo e calcular métricas no nível do caso.

Onde obter

Este é o ID interno ou número da transação do registro de Purchase Requisition no NetSuite. Normalmente, ele pode ser encontrado no campo 'tranid' da transação.

Exemplos
PR-001254PR-001255PR-001256
Nome da atividade
ActivityName
O nome de um evento ou tarefa de negócio específico que ocorreu durante o ciclo de vida da requisição de compra.
Descrição

O Activity Name descreve uma etapa distinta do processo de requisição, como 'Requisition Created', 'Approval Step Approved' ou 'Purchase Order Created'. Essas atividades são os blocos de construção do mapa do processo e representam o trabalho realizado.

Analisar essas atividades permite visualizar o fluxo do processo, identificar gargalos e medir o tempo gasto em diferentes etapas. A sequência de atividades de um determinado Purchase Requisition ID define sua jornada, que pode ser comparada aos procedimentos padrão para identificar desvios ou ineficiências.

Por que isso importa

Ele define as etapas do processo, permitindo visualizar mapas de processo, analisar variantes do processo e identificar gargalos.

Onde obter

Isso normalmente é obtido a partir de uma combinação do status da transação, das entradas do log do sistema, do histórico do Workflow ou do rastreamento personalizado de eventos no NetSuite.

Exemplos
Requisição criadaEtapa de aprovação aprovadaRequisição alteradaPedido de compra criado
Departamento
Department
O departamento da empresa ao qual a requisição ou o solicitante pertence.
Descrição

O atributo Departamento representa a unidade organizacional associada à requisição de compra, que geralmente é o departamento do solicitante. Essas informações permitem segmentar e analisar o processo sob uma perspectiva organizacional.

Essa é uma dimensão importante para várias análises, como comparar tempos de ciclo de aprovação entre departamentos, entender padrões de gastos ou identificar quais departamentos têm as maiores taxas de rejeição. Essa segmentação ajuda a gestão a alocar recursos, adaptar treinamentos e otimizar Workflows para unidades de negócio específicas.

Por que isso importa

Permite segmentar os dados do processo de forma detalhada para comparar performance, custos e conformidade entre diferentes unidades de negócio.

Onde obter

Essas informações geralmente estão associadas ao registro do funcionário solicitante ou podem ser definidas diretamente no cabeçalho da transação da Purchase Requisition.

Exemplos
MarketingTIFinançasOperações
Solicitante
Requester
O funcionário que criou e enviou a requisição de compra.
Descrição

O solicitante é a pessoa que inicia o processo de compras ao criar a requisição. Normalmente, é um funcionário que precisa de determinados bens ou serviços para realizar seu trabalho.

Analisar os dados por solicitante é essencial para identificar padrões de comportamento dos usuários. Isso ajuda a criar Dashboards como "Performance do solicitante e necessidades de treinamento", destacando pessoas com altas taxas de rejeição ou alterações frequentes. Esse insight pode indicar onde treinamentos adicionais ou orientações mais claras ajudariam a melhorar a qualidade do envio na primeira tentativa e a eficiência geral do processo.

Por que isso importa

Identifica quem iniciou o processo, o que é essencial para analisar o comportamento dos usuários, as taxas de rejeição por solicitante e as necessidades de treinamento.

Onde obter

Normalmente, este é o campo "Employee" ou "Created By" no registro da Purchase Requisition.

Exemplos
John SmithJane DoePeter Jones
Status da requisição
RequisitionStatus
Indica o estado atual da requisição em seu ciclo de vida.
Descrição

O status da requisição mostra em que ponto do processo uma requisição de compra está em determinado momento. Os status comuns incluem "Pending Approval", "Fully Approved", "Rejected" e "Closed".

Esse atributo é fundamental para criar Dashboards como "Status e envelhecimento das requisições", que acompanham as requisições ativas e há quanto tempo elas estão no estado atual. Analisar as transições de status é uma parte importante da descoberta de processos, ajudando a entender tanto os caminhos esperados quanto as exceções. Ele também é usado para determinar o resultado final de um caso.

Por que isso importa

Fornece um retrato do progresso de um caso, permitindo analisar requisições antigas e identificar onde os casos ficam parados.

Onde obter

Este é o campo "Status" ou "Approval Status" no cabeçalho da transação Purchase Requisition.

Exemplos
Aguardando aprovaçãoTotalmente aprovadaRejeitadaEncerrada
Valor total
TotalAmount
O valor monetário total da requisição de compra.
Descrição

Esse atributo registra o custo total de todos os itens listados na requisição de compra. É um dado financeiro essencial que frequentemente influencia o próprio processo, por exemplo, acionando diferentes Workflows de aprovação com base em faixas de valor.

Analisar o valor total ajuda a entender padrões de gastos e o impacto financeiro. Isso permite filtrar requisições por valor, relacionar desvios do processo a solicitações de alto valor e priorizar análises de casos financeiramente relevantes. É um atributo fundamental para qualquer análise de processos financeiros ou de conformidade.

Por que isso importa

Fornece contexto financeiro, permitindo análises baseadas em valor, que frequentemente determina os caminhos de aprovação e a prioridade do negócio.

Onde obter

Este é um campo padrão do registro da Purchase Requisition, geralmente chamado de "Total" ou de uma variação semelhante.

Exemplos
500.001250.7525000.00
Aprovador
Approver
O funcionário ou usuário responsável por aprovar ou rejeitar uma etapa de aprovação.
Descrição

O aprovador é a pessoa designada para revisar e tomar uma decisão sobre uma requisição de compra em uma etapa específica do Workflow de aprovação. Pode haver vários aprovadores para uma única requisição, cada um associado a uma atividade de aprovação diferente.

Esse atributo é essencial para analisar a performance do próprio processo de aprovação. Ele ajuda a criar Dashboards como "Distribuição do tempo de ciclo das etapas de aprovação", que podem identificar gargalos individuais ou de grupos. Ao acompanhar quem realiza as aprovações, as organizações podem garantir a responsabilização, equilibrar cargas de trabalho e identificar atrasos causados por aprovadores específicos.

Por que isso importa

Identifica o usuário que executa as tarefas de aprovação, o que é essencial para analisar a performance, a carga de trabalho e os gargalos dos aprovadores.

Onde obter

Essas informações geralmente são encontradas no log de execução do Workflow ou nas System Notes associadas às alterações do status de aprovação. Elas também podem ser armazenadas em campos personalizados relacionados ao Workflow de aprovação.

Exemplos
Sarah JenkinsDavid ChenGrupo de aprovação financeira
Caminho do Workflow de aprovação
ApprovalWorkflowPath
Uma representação da sequência de etapas de aprovação pelas quais uma requisição passou.
Descrição

O caminho do Workflow de aprovação é um atributo derivado que concatena a sequência de atividades ou status de aprovação de uma determinada requisição, como "Submitted -> Manager Approval -> Finance Approval". Isso cria uma assinatura exclusiva do caminho seguido por cada caso.

Esse atributo é a base da verificação de conformidade e da análise de variantes. Ele dá suporte direto aos Dashboards "Caminhos não conformes de requisições" e "Conformidade do caminho do Workflow de aprovação", facilitando a filtragem e o agrupamento de casos pelo fluxo exato do processo. Ao comparar os caminhos reais com os caminhos padrão predefinidos, as organizações podem quantificar a conformidade e investigar as causas raiz dos desvios.

Por que isso importa

Permite realizar análises de variantes e verificações de conformidade detalhadas, resumindo a sequência exata das etapas de aprovação de cada caso.

Onde obter

Este é um atributo derivado, calculado pela concatenação dos valores de "ActivityName" em ordem cronológica para cada "PurchaseRequisitionId".

Exemplos
Criada > Enviada > AprovadaCriada > Enviada > Rejeitada > Alterada > Enviada > AprovadaCriada > Enviada > Aprovada > Retirada
Categoria do item
ItemCategory
A categoria dos bens ou serviços solicitados na requisição.
Descrição

A categoria do item classifica os itens de uma requisição de compra em grupos lógicos, como "Hardware de TI", "Materiais de escritório" ou "Serviços profissionais". Ela pode ser obtida a partir dos registros de itens vinculados às linhas da requisição.

Esse atributo permite uma análise mais profunda e detalhada do processo de requisição. Ele ajuda a responder perguntas como: "As requisições de hardware de TI levam mais tempo para serem aprovadas do que as de materiais de escritório?". Ao segmentar o processo por categoria do item, as empresas podem descobrir gargalos específicos de cada área, analisar os gastos por categoria e adaptar as estratégias de compras.

Por que isso importa

Permite analisar o processo com base no que está sendo comprado, ajudando a identificar gargalos específicos de cada categoria ou problemas de conformidade.

Onde obter

Essas informações são obtidas dos registros de "Item" vinculados no nível das linhas da Purchase Requisition. A categoria pode ser um campo padrão ou personalizado no registro do item.

Exemplos
Hardware de TILicenças de softwareMateriais de escritórioServiços de marketing
É retrabalho
IsRework
Um indicador booleano que informa se a requisição passou por um ciclo de rejeição e reenvio.
Descrição

É retrabalho é um atributo booleano derivado que recebe o valor true quando uma requisição de compra foi rejeitada em algum momento e posteriormente alterada ou reenviada para aprovação. Ele identifica casos que exigiram trabalho e tratamento adicionais além do "happy path" padrão.

Esse atributo simplifica a análise da ineficiência do processo. Ele é usado para calcular o KPI "Contagem de ciclos de rejeição da aprovação" e ajuda a quantificar o impacto das rejeições no processo geral. Ao filtrar os casos em que É retrabalho é true, os analistas podem isolar variantes problemáticas do processo e investigar as causas raiz das rejeições iniciais, como baixa qualidade dos dados ou falta de entendimento das políticas.

Por que isso importa

Ajuda a quantificar a frequência e o impacto dos ciclos de retrabalho, que são uma das principais fontes de ineficiência e atraso nos processos.

Onde obter

Este é um atributo calculado. A lógica verifica se uma atividade "Requisition Submitted for Approval" ocorre depois de uma atividade "Approval Step Rejected" para o mesmo caso.

Exemplos
truefalse
ID do pedido de compra
PurchaseOrderId
O identificador do pedido de compra criado a partir da requisição aprovada.
Descrição

O ID do pedido de compra é o identificador exclusivo do pedido gerado como resultado de uma requisição aprovada. Esse atributo funciona como um vínculo essencial entre o processo de requisição e as atividades de compras posteriores.

Na análise de processos, esse vínculo é fundamental para uma análise P2P de ponta a ponta. Ele permite calcular o KPI "Lead time de criação do PO", medindo o tempo entre a aprovação da requisição e a criação do PO. Também ajuda a calcular a "Taxa de conversão de requisição em PO", fornecendo um insight sobre a eficiência com que as requisições são convertidas em pedidos acionáveis.

Por que isso importa

Vincula a requisição ao pedido de compra resultante, permitindo medir o lead time de criação do PO e analisar o processo de ponta a ponta.

Onde obter

Essa informação está no registro da Purchase Requisition, geralmente em uma aba de registros relacionados ou em um link "Created From" no próprio Purchase Order.

Exemplos
PO-005432PO-005433PO-005434
Moeda
Currency
O código da moeda do valor total da requisição.
Descrição

O atributo Moeda especifica a moeda na qual os valores financeiros da requisição são expressos, como USD, EUR ou GBP. Isso é especialmente importante para organizações multinacionais que operam com várias moedas.

Esse campo garante que os dados financeiros sejam interpretados corretamente. No Process Mining, ele permite agregar e comparar valores monetários de forma adequada, convertendo todos os valores para uma única moeda-base ou segmentando a análise por moeda. Isso evita relatórios financeiros imprecisos e garante clareza nas operações globais.

Por que isso importa

É essencial para uma análise financeira precisa em organizações multinacionais, garantindo que os valores monetários sejam interpretados e agregados corretamente.

Onde obter

Este é um campo padrão "Currency" no registro da transação Purchase Requisition, especialmente em instâncias do NetSuite com várias moedas.

Exemplos
USDEURGBP
Motivo da rejeição
RejectionReason
A explicação fornecida por um aprovador quando uma requisição é rejeitada.
Descrição

O motivo da rejeição é um atributo de texto no qual o aprovador pode informar por que uma requisição de compra não atendeu aos requisitos para aprovação. Isso fornece contexto qualitativo para a atividade "Approval Step Rejected".

Essas informações são valiosas para a análise de causa raiz. Elas alimentam Dashboards como "Análise da taxa de rejeição de requisições", mostrando não apenas o que foi rejeitado, mas também o motivo. Alguns motivos comuns podem ser "Conta contábil incorreta", "Orçamento excedido" ou "Detalhamento insuficiente". Analisar esses motivos ajuda a identificar problemas sistêmicos, melhorar o treinamento dos usuários e aperfeiçoar as orientações de envio para reduzir retrabalho e taxas de rejeição.

Por que isso importa

Fornece um contexto essencial sobre as causas das rejeições, permitindo analisar a causa raiz para reduzir rejeições futuras e melhorar a qualidade na primeira tentativa.

Onde obter

Isso geralmente é registrado em um campo "Memo" durante a ação de rejeição ou em um campo personalizado adicionado ao Workflow de aprovação. Também pode ser encontrado nas System Notes.

Exemplos
Orçamento excedidoFornecedor incorreto selecionadoDetalhes do item ausentesSolicitação duplicada
Nível de urgência
UrgencyLevel
Uma classificação da prioridade da requisição, como Standard ou Urgent.
Descrição

O nível de urgência é um atributo categórico que indica a prioridade de negócio de uma requisição de compra. Ele permite que os funcionários sinalizem solicitações que precisam de tratamento acelerado devido a necessidades críticas do negócio.

Esse atributo foi criado especificamente para apoiar o Dashboard "Performance do tratamento de solicitações urgentes" e o KPI "Tempo de tratamento de requisições urgentes". Ao filtrar os dados do processo com base nesse atributo, os analistas podem comparar os tempos de ciclo e os caminhos de processo de solicitações urgentes e padrão para determinar se o tratamento prioritário é eficaz ou se os gargalos ainda causam atrasos.

Por que isso importa

Permite comparar a performance do processo para solicitações de alta prioridade e padrão, garantindo que necessidades críticas sejam atendidas com eficiência.

Onde obter

Normalmente, este seria um campo personalizado no corpo da transação Purchase Requisition.

Exemplos
AltaMédiaBaixa
Nome do fornecedor
VendorName
O nome do fornecedor sugerido ou preferencial para a requisição.
Descrição

O atributo Nome do fornecedor identifica o fornecedor do qual se pretende comprar os bens ou serviços. Embora a requisição seja um documento interno, muitas vezes um fornecedor preferencial é especificado.

Analisar esse atributo pode revelar padrões relacionados à gestão de fornecedores. Ele ajuda a acompanhar quais fornecedores são solicitados com mais frequência, verificar se requisições de determinados fornecedores enfrentam tempos de aprovação maiores e garantir a conformidade com acordos de fornecedores preferenciais. Essas informações podem ser valiosas para o strategic sourcing e a gestão do relacionamento com fornecedores.

Por que isso importa

Ajuda a analisar padrões de compras por fornecedor, garantir a conformidade com listas de fornecedores preferenciais e identificar variações do processo específicas de cada fornecedor.

Onde obter

Pode ser um campo "Vendor" no nível do cabeçalho ou ser especificado nas linhas de itens do registro da Purchase Requisition.

Exemplos
Dell Inc.StaplesMcKinsey & Company
Sistema de origem
SourceSystem
Identifica o sistema de origem do qual os dados foram extraídos.
Descrição

Esse atributo especifica o sistema de origem dos dados do processo, que, neste caso, é o NetSuite. Ele é especialmente útil em ambientes nos quais dados de vários sistemas estão sendo combinados para oferecer uma visão holística do processo.

Embora possa parecer estático em uma análise de um único sistema, ele fornece um contexto essencial e é uma boa prática de governança e rastreabilidade de dados. Ele ajuda a confirmar a origem dos dados e garante que qualquer lógica ou transformação específica do sistema seja compreendida corretamente durante a análise.

Por que isso importa

Fornece um contexto essencial sobre a origem dos dados, garantindo clareza e uma governança adequada, especialmente em ambientes com vários sistemas.

Onde obter

Este é um valor estático, "NetSuite", que deve ser adicionado durante o processo de extração e transformação dos dados.

Exemplos
NetSuiteNetSuite SuitePeopleNetSuite ERP
Tempo de ciclo
CycleTime
O tempo total decorrido entre a criação e a resolução final de uma requisição.
Descrição

O tempo de ciclo é uma métrica calculada que mede a duração total do processo de requisição de compra para um único caso. Normalmente, ele é calculado como a diferença entre a primeira atividade, por exemplo, "Requisition Created", e a última atividade terminal, como "Requisition Fully Approved" ou "Requisition Finally Rejected".

Esse é um dos principais indicadores de performance da eficiência geral do processo. Ele é usado para calcular o KPI "Tempo médio do ciclo da requisição" e ajuda a identificar tendências, outliers e o impacto das iniciativas de melhoria de processos. Analisar a distribuição do tempo de ciclo pode revelar requisições com duração muito longa que reduzem significativamente a performance média.

Por que isso importa

Mede diretamente a eficiência do processo de ponta a ponta, sendo uma métrica central para identificar atrasos e avaliar a performance geral.

Onde obter

Este é um atributo calculado, obtido pela subtração do timestamp do primeiro evento do timestamp do último evento para cada "PurchaseRequisitionId".

Exemplos
25920060480086400
Última atualização dos dados
LastDataUpdate
O timestamp que indica quando os dados foram extraídos ou atualizados pela última vez a partir do sistema de origem.
Descrição

Esse atributo registra a data e o horário da extração mais recente de dados do NetSuite. Ele é um metadado essencial para qualquer Dashboard ou análise de Process Mining.

Esse timestamp fornece contexto sobre a atualidade dos dados, permitindo que os usuários entendam se estão visualizando informações em tempo real ou um retrato de um momento específico. Ele é fundamental para validar os dados e comunicar aos stakeholders o quão atuais são os insights gerados pela análise do processo.

Por que isso importa

Informa aos usuários o quão atuais são os dados, garantindo que eles entendam a atualidade dos insights do processo.

Onde obter

Esse timestamp é gerado e adicionado durante o processo de extração, transformação e carregamento (ETL) dos dados.

Exemplos
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
Obrigatório Recomendado Opcional

Purchase to Pay - Requisição: atividades

Estas são as principais etapas e marcos do processo que você deve registrar no seu Event Log para realizar uma descoberta precisa do processo e identificar gargalos.
5 Recomendado 6 Opcional
Atividade Descrição
Pedido de compra criado
Um Purchase Order (PO) é gerado a partir da requisição totalmente aprovada, comprometendo oficialmente os recursos com um fornecedor. Este é um evento explícito, marcado pela criação de uma nova transação de PO vinculada à requisição de origem.
Por que isso importa

Este é o principal resultado de uma requisição bem-sucedida e uma transferência importante no processo Purchase to Pay. O tempo entre a aprovação e a criação do PO é um KPI crítico para a eficiência das compras.

Onde obter

Identificado ao localizar um registro de Purchase Order cujo campo 'Created From' ou outro campo de vínculo semelhante faça referência ao Purchase Requisition ID. A data de criação desse PO é o Timestamp da atividade.

Captura

Encontre o PO em que o campo 'Created From' seja igual ao Requisition ID e use o campo 'Date Created' do PO.

Tipo de evento explicit
Requisição criada
Um usuário inicia o processo de compras criando e salvando um novo registro de requisição de compra. Este é o primeiro evento do ciclo de vida da requisição e é capturado quando o registro da transação é salvo pela primeira vez no NetSuite.
Por que isso importa

Esta atividade marca o início oficial do processo de compras para uma necessidade específica. Analisar o tempo entre a criação e o envio pode revelar atrasos na entrada de dados ou na formulação inicial da solicitação.

Onde obter

Este evento é capturado pelo Timestamp da data de criação do registro de transação da Purchase Requisition. Ele pode ser encontrado no cabeçalho principal do registro ou na subaba System Notes, que registra a ação 'Create'.

Captura

Use o campo 'Date Created' no registro da Purchase Requisition.

Tipo de evento explicit
Requisição encerrada
A requisição é encerrada formalmente, indicando que nenhuma ação adicional é esperada. Isso geralmente acontece automaticamente depois que todas as quantidades da requisição são solicitadas por meio de Purchase Orders vinculados.
Por que isso importa

Esta atividade marca o fim definitivo do ciclo de vida da requisição. Ela confirma que a necessidade do negócio foi atendida e que o registro foi finalizado.

Onde obter

Inferido a partir da subaba System Notes, identificando o Timestamp em que o campo 'Status' no nível da linha ou do cabeçalho é atualizado para 'Closed'.

Captura

Timestamp da alteração do campo 'Status' para 'Closed'.

Tipo de evento inferred
Requisição finalmente rejeitada
A requisição de compra é rejeitada definitivamente e não será mais processada. Este evento é inferido quando o 'Approval Status' final da requisição é atualizado para 'Rejected'.
Por que isso importa

Esta atividade é um ponto final crítico para requisições malsucedidas. Entender por que e quando as requisições são finalmente rejeitadas fornece insights sobre Conformidade com as políticas e problemas orçamentários.

Onde obter

Inferido a partir da subaba System Notes, identificando o Timestamp em que o campo 'Approval Status' é definido com seu estado final 'Rejected'.

Captura

Timestamp da alteração de 'Approval Status' para 'Rejected'.

Tipo de evento inferred
Requisição totalmente aprovada
A requisição de compra conclui com sucesso todas as etapas obrigatórias do Workflow de aprovação. Isso é inferido quando o 'Approval Status' final do registro muda para 'Approved'.
Por que isso importa

Este é um marco importante, pois indica que a requisição está pronta para ser convertida em um Purchase Order. Ele marca o fim do ciclo de aprovação e o início da etapa de atendimento da compra.

Onde obter

Inferido a partir da subaba System Notes, identificando o Timestamp em que o campo 'Approval Status' é definido com seu estado final 'Approved'.

Captura

Timestamp da alteração de 'Approval Status' para 'Approved'.

Tipo de evento inferred
Etapa de aprovação aprovada
Um usuário autorizado aprova sua etapa atribuída no Workflow, aproximando a requisição da aprovação final. A plataforma SuiteApprovals do NetSuite registra explicitamente essa ação, com os dados do usuário e do Timestamp.
Por que isso importa

Esta atividade representa um avanço no fluxo de aprovação. Analisar o tempo entre as etapas de aprovação ajuda a entender a eficiência do Workflow e o desempenho de cada aprovador.

Onde obter

Capturado no log do SuiteApprovals ou na subaba System Notes, que registra a ação de aprovação, o aprovador e o Timestamp exato do evento.

Captura

Identifique as ações de aprovação no log do SuiteApprovals ou em System Notes.

Tipo de evento explicit
Etapa de aprovação iniciada
A requisição entra em uma etapa específica do Workflow de aprovação e aguarda a ação de um aprovador ou grupo designado. Normalmente, isso é inferido quando o Workflow atribui a requisição ao próximo aprovador da sequência.
Por que isso importa

Esta atividade marca o início do tempo de espera de cada etapa individual de aprovação. Ela é essencial para localizar gargalos na hierarquia de aprovação e identificar aprovadores lentos.

Onde obter

Inferido a partir dos logs de execução do Workflow ou de alterações em um campo 'Current Approver' ou de estado do Workflow. A plataforma SuiteApprovals acompanha a etapa de aprovação ativa.

Captura

Faça a inferência a partir dos logs do Workflow ou quando o registro for atribuído a um novo aprovador.

Tipo de evento inferred
Etapa de aprovação rejeitada
Um aprovador rejeita a etapa atribuída a ele, normalmente enviando a requisição de volta ao solicitante para correção. Essa ação é registrada explicitamente pelo mecanismo de Workflow do SuiteApprovals.
Por que isso importa

Este evento é um indicador importante de retrabalho e ineficiência do processo. Analisar os pontos de rejeição ajuda a identificar motivos comuns de falha, como violações de políticas ou dados incorretos.

Onde obter

Capturado no log do SuiteApprovals ou na subaba System Notes, que registra a ação de rejeição, o usuário que a realizou e o Timestamp.

Captura

Identifique as ações de rejeição no log do SuiteApprovals ou em System Notes.

Tipo de evento explicit
Requisição alterada
Um usuário modifica qualquer campo da requisição de compra após sua criação inicial, geralmente em resposta a uma rejeição ou mudança nos requisitos. Este evento é capturado diretamente pelo recurso de trilha de auditoria do NetSuite.
Por que isso importa

Acompanhar alterações é essencial para identificar ciclos de retrabalho e problemas de qualidade dos dados. Uma frequência alta de alterações pode indicar requisitos iniciais pouco claros ou necessidades de treinamento dos solicitantes.

Onde obter

Capturado na subaba System Notes do registro da Purchase Requisition. Cada entrada com 'Type' igual a 'Change' ou 'Edit' em um campo relevante representa uma alteração.

Captura

Registre um evento para cada entrada do tipo 'Change' no log de System Notes.

Tipo de evento explicit
Requisição enviada para aprovação
O solicitante envia formalmente a requisição preenchida para o Workflow de aprovação designado. Isso geralmente é inferido a partir de uma mudança de status no registro da requisição, por exemplo, de 'Draft' ou 'Pending Submission' para 'Pending Approval'.
Por que isso importa

Esta atividade inicia o ciclo de aprovação e é um ponto de partida essencial para medir os prazos de aprovação. Ela ajuda a identificar quanto tempo as requisições aguardam antes do início do processo formal de aprovação.

Onde obter

Inferido a partir da subaba System Notes, identificando o Timestamp em que o campo 'Approval Status' muda pela primeira vez para um valor como 'Pending Approval'.

Captura

Identifique o primeiro Timestamp em que o campo 'Approval Status' muda para 'Pending Approval'.

Tipo de evento inferred
Requisição retirada
O solicitante original ou um administrador cancela a requisição antes que ela seja totalmente aprovada ou convertida em um PO. Normalmente, isso é inferido a partir de uma mudança de status para 'Cancelled' ou 'Withdrawn'.
Por que isso importa

Esta atividade representa uma exceção ou o encerramento do processo iniciado pelo solicitante. Analisar as retiradas pode revelar mudanças nas necessidades do negócio ou requisições que deixaram de ser válidas.

Onde obter

Inferido a partir da subaba System Notes, acompanhando o Timestamp em que o campo 'Approval Status' é atualizado para um valor como 'Cancelled' ou um status personalizado de retirada.

Captura

Timestamp da alteração de 'Approval Status' para 'Cancelled' ou 'Withdrawn'.

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como obter seus dados do NetSuite

Pronto para começar?

Use este Template para dar o primeiro passo na sua jornada de Process Mining e obter insights valiosos sobre seu processo Purchase to Pay, Requisition no NetSuite. Comece hoje a otimizar a eficiência e acelerar as aprovações.

Otimize seu Purchase to Pay - Requisition. Comece hoje!

Acelere em 30% as aprovações de requisições e elimine gargalos.

Começar o teste grátis

Não é necessário cartão de crédito. Comece a otimizar hoje.