Su Template de datos de Purchase to Pay - Requisition
Su Template de datos de Purchase to Pay - Requisition
- Atributos recomendados para un análisis completo
- Actividades clave del proceso que debe supervisar
- Orientación práctica para extraer datos
Purchase to Pay - Requisition: Atributos
| Nombre | Descripción | ||
|---|---|---|---|
|
Hora del evento
EventTime
|
La fecha y hora exactas en las que tuvo lugar la actividad. | ||
|
Descripción
La hora del evento, o marca de tiempo, registra el momento exacto en que se registró una actividad para una solicitud de compra. Estos datos son fundamentales para ordenar cronológicamente los eventos y crear el flujo del proceso. Constituyen la base de todos los análisis temporales, incluido el cálculo de los tiempos de ciclo, la identificación de cuellos de botella mediante la medición de la duración entre actividades y la comprensión del rendimiento del proceso en distintos periodos. Las marcas de tiempo precisas y detalladas son esenciales para realizar un análisis significativo del proceso.
Por qué es importante
Esta marca de tiempo es crucial para ordenar correctamente los eventos y calcular todas las métricas basadas en la duración, como los tiempos de ciclo y los cuellos de botella.
Dónde obtenerlo
Esta información se captura en el registro de auditoría o en los registros históricos de cada solicitud en Coupa, normalmente en un campo «created_at» o «updated_at» para cada acción.
Ejemplos
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
|
|||
|
ID de solicitud de compra
PurchaseRequisitionId
|
El identificador único de cada solicitud de compra, que sirve como identificador principal del caso en el proceso. | ||
|
Descripción
El ID de solicitud de compra es la clave central que vincula todas las actividades relacionadas con una única solicitud de bienes o servicios. Cada solicitud recibe un ID único al crearse, que permanece constante durante todo su ciclo de vida. Esto permite hacer un seguimiento integral de la solicitud, desde su creación y envío iniciales, pasando por todos los pasos de aprobación o rechazo, hasta su abastecimiento y cierre finales. En Process Mining, cada entrada del registro de eventos está vinculada a este ID, lo que permite reconstruir el recorrido completo de cada caso.
Por qué es importante
Este es el Case ID esencial que conecta todos los pasos del proceso y permite analizar por completo el ciclo de vida de la solicitud, desde el inicio hasta el final.
Dónde obtenerlo
Es un campo de clave principal que se encuentra en el módulo Requisitions de Coupa y en las exportaciones de datos relacionadas.
Ejemplos
PR-102934PR-102935PR-102936
|
|||
|
Nombre de la actividad
ActivityName
|
El nombre de la actividad empresarial o evento específico que tuvo lugar en un momento determinado para la solicitud. | ||
|
Descripción
Este Atributo registra los distintos pasos del ciclo de vida de la solicitud de compra. Algunos ejemplos son «Requisition Created», «Approval Step Approved» y «Requisition Sourced». Cada actividad representa un hito o una acción específica realizada sobre la solicitud. Analizar la secuencia y la frecuencia de estas actividades es fundamental para Process Mining, ya que permite visualizar mapas de procesos, identificar rutas habituales y detectar desviaciones del procedimiento estándar.
Por qué es importante
Define los pasos del mapa de procesos y permite visualizar y analizar el flujo de las solicitudes.
Dónde obtenerlo
Normalmente se obtiene de registros de eventos, registros de cambios de estado o registros de auditoría del sistema Coupa. Puede ser necesario realizar una asignación a partir de campos de estado o códigos de acción.
Ejemplos
Solicitud creadaSolicitud enviadaEtapa de aprobación aprobadaSolicitud rechazadaOrden de compra creada
|
|||
|
Sistema de origen
SourceSystem
|
Identifica el sistema de origen del que se extrajeron los datos. | ||
|
Descripción
Este Atributo especifica el sistema de registro en el que se originaron los datos del proceso. Para este análisis, el valor será siempre «Coupa». Incluir este campo es una buena práctica, especialmente en entornos en los que los datos pueden combinarse desde varios sistemas. Proporciona un contexto esencial sobre la trazabilidad de los datos y ayuda a gestionar las reglas de gobierno y calidad de datos.
Por qué es importante
Proporciona una trazabilidad clara de los datos, algo crucial para el gobierno de datos y para combinar datos de varios sistemas empresariales.
Dónde obtenerlo
Normalmente es un valor estático que se añade durante el proceso de extracción y transformación de datos para indicar el origen del conjunto de datos.
Ejemplos
Coupa
|
|||
|
Última actualización de datos
LastDataUpdate
|
La marca de tiempo que indica la última vez que se actualizaron los datos desde el sistema de origen. | ||
|
Descripción
Este atributo registra la fecha y hora de la extracción de datos más reciente de Coupa. Proporciona transparencia sobre la actualización de los datos analizados. Saber cuándo se actualizaron los datos es fundamental para determinar si la información refleja el estado operativo actual o un momento anterior. Esto es especialmente importante en los Dashboards que supervisan operaciones en curso.
Por qué es importante
Informa a los usuarios sobre la actualidad de los datos, para que comprendan el periodo del análisis y tomen decisiones basadas en información actualizada.
Dónde obtenerlo
Esta marca de tiempo la genera y añade el pipeline de datos o la herramienta ETL al finalizar correctamente una ejecución de extracción de datos.
Ejemplos
2024-05-21T02:00:00Z
|
|||
|
Aprobador
Approver
|
La persona o el grupo responsable de una actividad de aprobación. | ||
|
Descripción
Este Atributo identifica a la persona o al grupo de aprobación específico asignado a un paso de aprobación. Se completa para actividades como «Approval Step Started», «Approval Step Approved» y «Approval Step Rejected». Analizar los datos por aprobador es clave para crear el panel «Rendimiento y carga de los aprobadores». Ayuda a medir los tiempos de aprobación individuales, identificar cuellos de botella causados por aprobadores concretos y evaluar la distribución de la carga de trabajo.
Por qué es importante
Es fundamental para analizar el rendimiento de los aprobadores, equilibrar la carga de trabajo e identificar cuellos de botella relacionados con personas o grupos de aprobación específicos.
Dónde obtenerlo
Esta información se encuentra en los detalles de la cadena de aprobación asociados a cada solicitud en Coupa. Puede ser necesario combinarla con datos de User.
Ejemplos
David MillerAprobadores de Finanzas, nivel 2Susan Chen
|
|||
|
Departamento
Department
|
El departamento empresarial o centro de costes al que se imputa la solicitud. | ||
|
Descripción
El atributo Departamento vincula cada solicitud con una unidad organizativa o un centro de coste específico. Es una dimensión fundamental para el análisis comparativo. Permite filtrar y segmentar los Dashboards y los KPI por departamento, de modo que quienes gestionan el proceso puedan comparar los tiempos de ciclo de aprobación, las tasas de rechazo y el cumplimiento entre distintas áreas de la organización. Esto ayuda a localizar problemas o buenas prácticas específicos de cada departamento.
Por qué es importante
Permite comparar KPI del proceso, como el tiempo de ciclo y las tasas de rechazo, entre distintas unidades de negocio y destacar áreas de mejora.
Dónde obtenerlo
Es un campo estándar del objeto Requisition en Coupa, normalmente asociado al perfil de usuario del solicitante o especificado en las partidas de la solicitud.
Ejemplos
MarketingOperaciones de TIInstalacionesInvestigación y desarrollo
|
|||
|
Estado de la solicitud
RequisitionStatus
|
El estado actual o final de la solicitud de compra. | ||
|
Descripción
Este Atributo indica el estado general de la solicitud en el momento de la extracción de datos o su resultado final. Entre los estados habituales se incluyen «Pending Approval», «Approved», «Rejected», «Withdrawn» y «Closed». Es una dimensión clave para el filtrado y el análisis. Se utiliza para calcular las tasas de aprobación y rechazo, supervisar la carga de trabajo actual de las solicitudes abiertas y comprender el resultado final de las solicitudes.
Por qué es importante
Es esencial para comprender los resultados de las solicitudes, calcular las tasas de aprobación y rechazo y supervisar el estado actual de las solicitudes en curso.
Dónde obtenerlo
Es un campo estándar del objeto Purchase Requisition en Coupa, normalmente denominado «status» o «state».
Ejemplos
Pendiente de aprobaciónAprobadoRechazadoRetiradoCerrado
|
|||
|
Importe total
TotalAmount
|
El valor monetario total de la solicitud de compra. | ||
|
Descripción
Este Atributo representa el coste total de todos los bienes y servicios solicitados. El importe es un factor crucial en el análisis del proceso, ya que suele influir en la complejidad del Workflow de aprobación; las solicitudes de mayor valor normalmente requieren más pasos de aprobación. Analizar las métricas del proceso por rangos de valor, por ejemplo, <1.000 $, 1.000 $-10.000 $, puede revelar cómo gestiona el proceso solicitudes de distinta relevancia financiera.
Por qué es importante
Ayuda a analizar cómo varía el proceso según el valor de las solicitudes, ya que los importes más altos suelen activar Workflows de aprobación más complejos.
Dónde obtenerlo
Es un campo estándar de la cabecera del objeto Requisition en Coupa, normalmente denominado «total» o «total_amount».
Ejemplos
500.0012550.7599.99
|
|||
|
Solicitante
Requester
|
La persona empleada que creó y envió la solicitud de compra. | ||
|
Descripción
Este Atributo identifica a la persona que inició la solicitud. Analizar los datos por solicitante ayuda a identificar patrones relacionados con usuarios concretos, como tasas elevadas de modificación o rechazos frecuentes, que pueden indicar la necesidad de formación adicional. También se utiliza para analizar los volúmenes de solicitudes y el comportamiento del proceso de distintos usuarios o grupos de usuarios.
Por qué es importante
Permite analizar el comportamiento del proceso por usuario, identificar necesidades de formación y comprender cómo interactúan distintas personas con el proceso.
Dónde obtenerlo
Está disponible como campo estándar del objeto Requisition en Coupa, normalmente vinculado al objeto User y denominado «requester» o «created_by».
Ejemplos
Alice JohnsonBob SmithCharlie Brown
|
|||
|
Categoría de compra
Commodity
|
La categoría general de los bienes o servicios solicitados. | ||
|
Descripción
El Atributo Categoría de compra proporciona una clasificación estandarizada de los artículos de una solicitud, como «Office Supplies», «Computer Hardware» o «Marketing Services». Esto permite analizar los patrones de compra y las variaciones del proceso según lo que se adquiere. Algunas categorías pueden tener requisitos de aprobación o estrategias de abastecimiento específicos, y analizar el proceso por categoría puede ayudar a optimizar las compras para distintos grupos de gasto.
Por qué es importante
Ayuda a analizar las categorías de gasto y a comprender si el comportamiento del proceso, como los tiempos de aprobación, varía según el tipo de bienes o servicios adquiridos.
Dónde obtenerlo
Es un campo estándar de Coupa, normalmente disponible en el nivel de partida de la solicitud. Puede ser necesario agregarlo al nivel de cabecera.
Ejemplos
Suministros de oficinaHardware informáticoServicios de marketingViajes
|
|||
|
Duración del paso de aprobación
ApprovalStepDuration
|
El tiempo que una solicitud permanece esperando en un único paso de aprobación. | ||
|
Descripción
Esta métrica calculada mide la duración entre una actividad «Approval Step Started» y la actividad correspondiente «Approval Step Approved» o «Approval Step Rejected». Aísla el tiempo de espera en cada etapa diferenciada de la cadena de aprobación. Es fundamental para el panel «Cuellos de botella críticos en la aprobación», ya que señala exactamente qué aprobadores o etapas de aprobación provocan los retrasos más importantes del proceso general.
Por qué es importante
Identifica cuellos de botella específicos dentro del Workflow de aprobación al medir el tiempo de espera de cada paso individual, en lugar de limitarse al tiempo de ciclo total.
Dónde obtenerlo
Se calcula en la herramienta de Process Mining obteniendo la diferencia de tiempo entre «Approval Step Started» y el evento de aprobación terminal posterior, «Approved» o «Rejected».
Ejemplos
1,2 días4 horas3,8 días
|
|||
|
Ha sido modificada
IsAmended
|
Un indicador booleano cuyo valor es verdadero si la solicitud se modificó una o más veces después de su envío inicial. | ||
|
Descripción
Este Atributo calculado es un indicador sencillo, Verdadero/Falso, que señala si se produjo una actividad «Requisition Amended» en un caso determinado. Simplifica el análisis y el filtrado, ya que permite aislar fácilmente las solicitudes que requirieron cambios. Se utiliza para calcular el KPI de tasa de modificación de solicitudes y alimentar el panel «Volumen de modificaciones de solicitudes», lo que ayuda a identificar las causas raíz del retrabajo y mejorar la calidad a la primera.
Por qué es importante
Simplifica el cálculo del KPI de tasa de modificación y permite segmentar fácilmente los casos que requirieron retrabajo frente a los que no.
Dónde obtenerlo
Se calcula en la herramienta de Process Mining comprobando si existe una actividad «Requisition Amended» en el registro de eventos de cada caso.
Ejemplos
truefalse
|
|||
|
ID de orden de compra
PurchaseOrderId
|
El identificador de la orden de compra creada a partir de la solicitud aprobada. | ||
|
Descripción
Una vez que una solicitud se aprueba por completo y se envía a abastecimiento, normalmente se crea una orden de compra. Este Atributo almacena el ID de la PO resultante. Sirve como vínculo fundamental entre el proceso de Requisition anterior y el proceso de Purchase Order posterior. Permite calcular el KPI «Tiempo desde la aprobación de la solicitud hasta la creación de la PO» y realizar un análisis integral de todo el ciclo Purchase-to-Pay.
Por qué es importante
Vincula la solicitud con la orden de compra posterior, permite analizar el tiempo de traspaso y facilita una visión más amplia e integral de P2P.
Dónde obtenerlo
Es un campo estándar del objeto Requisition en Coupa que se completa después de crear la PO.
Ejemplos
PO-45000123PO-45000124PO-45000125
|
|||
|
Moneda
Currency
|
El código de moneda del importe total de la solicitud. | ||
|
Descripción
Este atributo especifica la moneda, por ejemplo, USD, EUR o GBP, en la que se expresa el importe total de la solicitud. Es un contexto esencial para cualquier análisis financiero, especialmente en organizaciones multinacionales que operan con varias monedas. Garantiza la correcta interpretación de los valores monetarios y permite realizar conversiones y agregaciones adecuadas en los informes financieros y los Dashboards.
Por qué es importante
Proporciona el contexto necesario para el Atributo «Importe total» y garantiza un análisis financiero preciso en entornos multidivisa.
Dónde obtenerlo
Es un campo estándar del objeto Requisition en Coupa, normalmente denominado «currency_code» o similar.
Ejemplos
USDEURGBP
|
|||
|
Motivo del rechazo
RejectionReason
|
El motivo que proporciona un aprobador cuando se rechaza una solicitud o un paso de aprobación. | ||
|
Descripción
Cuando un aprobador rechaza una solicitud, normalmente proporciona el motivo de su decisión. Este Atributo recoge esa explicación textual. Analizar los motivos de rechazo proporciona información cualitativa directa sobre las causas de los fallos de las solicitudes. Esta información es muy valiosa para el análisis de causas raíz, ya que ayuda a identificar problemas habituales, como una codificación incorrecta, falta de presupuesto o justificación insuficiente, que pueden abordarse mediante formación o mejoras del proceso.
Por qué es importante
Proporciona información directa sobre las causas raíz de los fallos del proceso y ayuda a identificar áreas de formación para los usuarios o de aclaración del proceso.
Dónde obtenerlo
Normalmente, esta información se captura en el campo de comentarios o notas asociado a un cambio de estado a «Rejected» en el historial de aprobación de la solicitud.
Ejemplos
Centro de costos incorrectoSupera el presupuesto de este trimestreSolicitud duplicadaJustificación insuficiente
|
|||
|
Nivel de urgencia
UrgencyLevel
|
Una clasificación que indica la urgencia de la solicitud, como «High», «Medium» o «Low». | ||
|
Descripción
El nivel de urgencia, normalmente asignado a un campo de prioridad, permite a los solicitantes señalar las solicitudes que requieren un procesamiento acelerado. Este Atributo es esencial para el panel «Tiempo de procesamiento de solicitudes urgentes». Al comparar los tiempos de ciclo de las solicitudes de alta urgencia con los de las solicitudes estándar, las organizaciones pueden evaluar si sus mecanismos de priorización son eficaces y si las necesidades urgentes del negocio se atienden a tiempo.
Por qué es importante
Permite analizar si las solicitudes urgentes se procesan más rápido que las estándar y validar la eficacia de las políticas de priorización.
Dónde obtenerlo
Puede ser un campo estándar o personalizado del objeto Requisition en Coupa. Consulte la documentación de Coupa o la configuración del sistema.
Ejemplos
AltaMediaBaja
|
|||
|
Nombre del proveedor
SupplierName
|
El nombre del proveedor seleccionado para la solicitud. | ||
|
Descripción
Este Atributo identifica al proveedor previsto para los bienes o servicios solicitados. El solicitante puede especificarlo o añadirse posteriormente durante el proceso de abastecimiento. Analizar las métricas del proceso por proveedor puede ayudar a evaluar su rendimiento e identificar si las interacciones con determinados proveedores generan tiempos de ciclo más largos u otras ineficiencias. Proporciona un contexto importante para la estrategia de compras y la gestión de las relaciones con proveedores.
Por qué es importante
Permite analizar el rendimiento del proceso según el proveedor seleccionado, lo que puede orientar las estrategias de abastecimiento y la gestión de proveedores.
Dónde obtenerlo
Esta información está disponible en el objeto Requisition Line de Coupa, normalmente en un campo «supplier» o «vendor».
Ejemplos
StaplesDell TechnologiesAccentureCDW
|
|||
|
Número de pasos de aprobación
ApprovalStepCount
|
El número total de pasos de aprobación por los que ha pasado una solicitud. | ||
|
Descripción
Este Atributo calculado cuenta el número de actividades distintas «Approval Step Approved» de cada solicitud. Ayuda a cuantificar la complejidad del Workflow de aprobación de cada caso. Es la base del KPI «Número medio de pasos de aprobación» y resulta útil para identificar solicitudes que siguen rutas de aprobación inusualmente largas o complejas, lo que puede indicar la necesidad de simplificar el Workflow.
Por qué es importante
Cuantifica la complejidad del Workflow de aprobación de cada solicitud y ayuda a identificar rutas demasiado complejas que deben simplificarse.
Dónde obtenerlo
Esta métrica se calcula en la herramienta de Process Mining contando las apariciones de «Approval Step Approved» para cada Case ID.
Ejemplos
253
|
|||
|
Ruta del Workflow de aprobación
ApprovalWorkflowPath
|
Un identificador de la cadena de aprobación o Template de Workflow específico aplicado a la solicitud. | ||
|
Descripción
Este Atributo identifica la secuencia predefinida de aprobadores que debería seguir una solicitud. La determinan las reglas de negocio, a menudo según factores como el importe, el departamento y el tipo de solicitud. Analizar este Atributo es fundamental para el panel «Cumplimiento de políticas de solicitudes». Al comparar la secuencia real de aprobadores con la ruta de Workflow asignada, es posible detectar desviaciones, medir las tasas de conformidad e identificar excepciones no gestionadas.
Por qué es importante
Permite analizar el cumplimiento al comparar los pasos de aprobación previstos con los reales y destacar las desviaciones del proceso.
Dónde obtenerlo
Consulte la documentación de Coupa. Puede derivarse del nombre de la cadena de aprobación o de la regla de Workflow que se activó para la solicitud.
Ejemplos
Aprobación estándar <$5kAprobación de hardware de TI >$10kRevisión del CFO para gasto de capital
|
|||
|
Tipo de solicitud
RequisitionType
|
La categoría o el tipo de solicitud, como «Capital Expense», «Operational Expense» o «Software». | ||
|
Descripción
El tipo de solicitud es una clasificación que ayuda a categorizar las solicitudes según su finalidad empresarial o la naturaleza de la compra. Este Atributo es valioso para el análisis de cumplimiento y para comprender cómo fluyen por el proceso los distintos tipos de solicitudes. Por ejemplo, las solicitudes de gastos de capital pueden seguir una ruta de aprobación más estricta y prolongada que las solicitudes operativas estándar. Analizar el proceso por tipo de solicitud puede revelar información valiosa para optimizarlo.
Por qué es importante
Permite segmentar el análisis según la finalidad empresarial de la solicitud, ya que los distintos tipos pueden tener flujos de proceso y políticas diferentes.
Dónde obtenerlo
Probablemente es un campo de clasificación estándar o personalizado del objeto Requisition en Coupa.
Ejemplos
Gasto de capitalGasto operativoHardware de TIServicios profesionales
|
|||
Purchase to Pay - Requisition: actividades
| Actividad | Descripción | ||
|---|---|---|---|
|
Orden de compra creada
|
Se genera correctamente una orden de compra (PO) a partir de la información de la solicitud aprobada. Este evento se infiere cuando se crea un registro de PO que hace referencia al ID de la solicitud de origen. | ||
|
Por qué es importante
Este es el resultado positivo principal del proceso de solicitud y marca el traspaso a la siguiente etapa de Purchase-to-Pay. Analizar el tiempo transcurrido entre «Solicitud aprobada» y este evento permite detectar retrasos en la ejecución.
Dónde obtenerlo
Se infiere a partir de la creación de un registro en la tabla «purchase_orders» que contiene una referencia al ID de «requisition_headers» o «requisition_lines» de origen.
Recopilar
Usar la marca de tiempo «created-at» del registro de PO vinculado al ID de la solicitud.
Tipo de evento
inferred
|
|||
|
Solicitud aprobada
|
La solicitud ha superado correctamente todos los pasos requeridos del Workflow de aprobación. Esto se infiere cuando el estado general de la cabecera de la solicitud cambia a «approved». | ||
|
Por qué es importante
Se trata de un hito de éxito fundamental que marca el final del ciclo de aprobación. El tiempo necesario para alcanzar esta actividad es un KPI principal y sirve como desencadenante de las acciones de compras posteriores.
Dónde obtenerlo
Se infiere a partir de un cambio de estado en la tabla «requisition_headers» cuando el campo «status» se actualiza a «approved». La marca de tiempo se registra en el registro de auditoría asociado.
Recopilar
Identificar la marca de tiempo en la que el estado general de la solicitud cambia a «approved».
Tipo de evento
inferred
|
|||
|
Solicitud cerrada
|
La solicitud se cierra formalmente, lo que indica que no se realizarán más acciones sobre ella. Esto puede ocurrir después de crear y completar una PO, o si la solicitud se cancela después de la aprobación, pero antes de realizar el pedido. | ||
|
Por qué es importante
Esta actividad sirve como punto final definitivo del ciclo de vida de la solicitud. Garantiza una conclusión clara para los casos y evita que aparezcan indefinidamente como «activos» en el análisis del proceso.
Dónde obtenerlo
Se infiere a partir de un cambio de estado en la tabla «requisition_headers» cuando el campo «status» se actualiza a «closed». La marca de tiempo se registra en el registro de auditoría asociado.
Recopilar
Identificar la marca de tiempo en la que el estado general de la solicitud cambia a «closed».
Tipo de evento
inferred
|
|||
|
Solicitud creada
|
Una persona usuaria inicia una nueva solicitud de compra y la guarda como borrador. Este es el punto de partida de cada caso de solicitud y normalmente se infiere a partir de la marca de tiempo de creación del propio registro de la solicitud. | ||
|
Por qué es importante
Esta actividad marca el inicio del ciclo de vida de la solicitud. Analizar el tiempo transcurrido desde la creación hasta el envío puede revelar retrasos causados por la incertidumbre de la persona usuaria o por la complejidad del sistema.
Dónde obtenerlo
Este evento se captura a partir de la marca de tiempo «created-at» de la tabla «requisition_headers» para un ID de Purchase Requisition determinado.
Recopilar
Utilice la marca de tiempo de creación del registro de cabecera de la solicitud.
Tipo de evento
inferred
|
|||
|
Solicitud enviada
|
La persona solicitante envía formalmente la solicitud completada al Workflow de aprobación. Este evento se infiere al observar el cambio de estado de la solicitud de «draft» a «pending_approval» en los Registros de eventos de auditoría o en las tablas de historial del sistema. | ||
|
Por qué es importante
El envío activa el proceso de aprobación, por lo que constituye un hito crítico para medir el KPI «Average Requisition Approval Cycle Time». Los retrasos anteriores a este punto están relacionados con la persona usuaria, mientras que los posteriores están relacionados con el proceso.
Dónde obtenerlo
Se infiere a partir de un cambio de estado en la tabla «requisition_headers», concretamente cuando el campo «status» cambia a «pending_approval». La marca de tiempo de este cambio se encuentra en el registro de auditoría asociado.
Recopilar
Identifique la marca de tiempo en la que el estado de la solicitud cambia por primera vez a «pending_approval».
Tipo de evento
inferred
|
|||
|
Solicitud rechazada
|
La solicitud se rechaza definitivamente durante el proceso de aprobación y no se convertirá en una orden de compra. Esto se infiere cuando el estado general de la cabecera de la solicitud cambia a «rejected». | ||
|
Por qué es importante
Esta actividad representa un fallo terminal del proceso. Analizar estos eventos es clave para mejorar la «tasa de rechazo de solicitudes» e identificar causas raíz, como incumplimientos de políticas o problemas presupuestarios.
Dónde obtenerlo
Se infiere a partir de un cambio de estado en la tabla «requisition_headers» cuando el campo «status» se actualiza a «rejected». La marca de tiempo se registra en el registro de auditoría asociado.
Recopilar
Identificar la marca de tiempo en la que el estado general de la solicitud cambia a «rejected».
Tipo de evento
inferred
|
|||
|
Etapa de aprobación aprobada
|
Un aprobador individual del Workflow aprueba la solicitud. Se trata de una acción explícita que el sistema registra con una marca de tiempo específica y la información del usuario. | ||
|
Por qué es importante
Esta actividad ofrece información detallada sobre el flujo del proceso de aprobación. La agregación de estos pasos ayuda a calcular el «tiempo medio de espera por paso de aprobación» y a analizar el rendimiento de los aprobadores.
Dónde obtenerlo
Se obtiene de una acción explícita de «aprobación» registrada en la tabla «approvals» o en su registro de auditoría, vinculada a la solicitud y al aprobador correspondientes.
Recopilar
Filtrar los eventos de «aprobación» en el historial de aprobación de la solicitud.
Tipo de evento
explicit
|
|||
|
Etapa de aprobación iniciada
|
Se asigna una tarea de aprobación a una persona aprobadora concreta o a un grupo de aprobación, y la solicitud queda a la espera de su actuación. Esto se infiere cuando se crea un registro de aprobación asociado a la solicitud con estado «pending». | ||
|
Por qué es importante
Esto marca el inicio del tiempo de espera de una aprobación concreta. Medir la duración entre este evento y el evento correspondiente «Approval Step Approved/Rejected» ayuda a identificar cuellos de botella específicos en la cadena de aprobación.
Dónde obtenerlo
Se infiere a partir de la marca de tiempo de creación de un registro de la tabla «approvals» vinculado a la solicitud, en el que el estado de la acción de la persona aprobadora es «pending» o equivalente.
Recopilar
Utilice la marca de tiempo de creación del registro de aprobación pendiente de una persona en la cadena de aprobación.
Tipo de evento
inferred
|
|||
|
Paso de aprobación rechazado
|
Un aprobador individual rechaza la solicitud en su etapa del Workflow, normalmente devolviéndola al solicitante para que la modifique. Se trata de una acción explícita registrada por Coupa. | ||
|
Por qué es importante
Los rechazos en cualquier paso generan retrabajo y prolongan los tiempos de ciclo. Analizar dónde y por qué se producen es fundamental para mejorar el proceso y capacitar a los usuarios.
Dónde obtenerlo
Se obtiene de una acción explícita de «rechazo» registrada en la tabla «approvals» o en su registro de auditoría, vinculada a la solicitud y al aprobador correspondientes.
Recopilar
Filtrar los eventos de «rechazo» en el historial de aprobación de la solicitud.
Tipo de evento
explicit
|
|||
|
Solicitud enviada a abastecimiento
|
La solicitud aprobada se envía a un evento de abastecimiento, como una RFQ o una subasta, en lugar de convertirse inmediatamente en una orden de compra. Este evento se infiere cuando la solicitud se vincula a un objeto de evento de abastecimiento. | ||
|
Por qué es importante
Esta actividad revela una ruta alternativa importante dentro del proceso de compras. Distingue las compras sencillas de las actividades de abastecimiento estratégico más complejas, lo que permite analizar los tiempos de ciclo con mayor precisión.
Dónde obtenerlo
Se infiere al detectar un cambio de estado a «sourcing» o al identificar la creación de un vínculo entre la tabla «requisition_lines» y una tabla de eventos de abastecimiento.
Recopilar
Comprobar si se produce un cambio de estado a «sourcing» o si se crea un vínculo con un ID de evento de abastecimiento.
Tipo de evento
inferred
|
|||
|
Solicitud modificada
|
La persona solicitante u otra persona usuaria autorizada edita la solicitud después de que ya se haya enviado. Coupa registra explícitamente esta acción como una nueva versión o una entrada de auditoría y, a menudo, reinicia parte o la totalidad del Workflow de aprobación. | ||
|
Por qué es importante
Hacer un seguimiento de las modificaciones es fundamental para comprender el retrabajo y la ineficiencia del proceso. Un volumen elevado de modificaciones puede indicar requisitos iniciales poco claros o políticas de compras complejas, lo que afecta al KPI «Requisition Amendment Rate».
Dónde obtenerlo
Esta información se obtiene de las tablas del registro de auditoría asociadas a la tabla «requisition_headers», que registran los cambios de versión o acciones específicas de «edit».
Recopilar
Busque eventos explícitos de «edit» o «update» en el registro histórico de la solicitud posteriores al envío.
Tipo de evento
explicit
|
|||
|
Solicitud retirada
|
El solicitante original cancela la solicitud antes de que reciba la aprobación final. Se trata de una acción explícita iniciada por el usuario que termina el proceso de esa solicitud. | ||
|
Por qué es importante
Las retiradas pueden indicar cambios en las necesidades del negocio, solicitudes duplicadas o intentos de los usuarios de eludir el proceso. Hacer un seguimiento ayuda a comprender la variabilidad de la demanda y posibles problemas de cumplimiento del proceso.
Dónde obtenerlo
Se infiere a partir de un cambio de estado en la tabla «requisition_headers» a «withdrawn» o a un estado similar, basado en una acción explícita del usuario registrada en el registro de auditoría.
Recopilar
Identificar la marca de tiempo en la que el estado de la solicitud cambia a «withdrawn».
Tipo de evento
inferred
|
|||
Guías de extracción
¿Listo para empezar?
Comience hoy mismo a optimizar su proceso Coupa Purchase to Pay, Requisition con este Template. Obtenga información valiosa e impulse mejoras de eficiencia en sus compras.
Optimice sus requisiciones Coupa P2P y reduzca hoy el tiempo de ciclo
Localice las ineficiencias y reduzca un 30 % el tiempo de ciclo de sus requisiciones P2P.
No necesita tarjeta de crédito. Optimice sus procesos en cuestión de minutos.