Your Purchase to Pay - Requisition Data Template

The Activity Name describes a single step or milestone in the requisition process, such as 'Requisition Created', 'Approval Step Approved', or 'Requisition Closed'. This data is typically derived from event logs, status changes, or specific user actions recorded in SAP Ariba.

This attribute is crucial for constructing the process map, which visually represents the flow of activities. By analyzing the sequence and frequency of these activities, analysts can identify common process paths, bottlenecks, deviations from the standard procedure, and areas of rework. It forms the backbone of any process mining analysis.

It defines the steps in the process, allowing for the visualization and analysis of the requisition workflow, including bottlenecks and deviations.

Derived from event logs, audit trails, or status change records within SAP Ariba, often associated with requisition header and line item tables.

The Event Timestamp records the exact moment an activity took place. This high-precision data is essential for ordering events correctly within each case and for calculating the duration between different steps in the process.

In analysis, this timestamp is the foundation for all time-based calculations, including cycle times, waiting times, and processing durations. It is used to power dashboards that analyze performance, such as the Requisition Approval Cycle Time and Approval Path Bottleneck Analysis. The accuracy of this field directly impacts the reliability of all performance metrics.

This attribute provides the chronological order of events and is the basis for all performance and duration calculations, such as cycle times and bottlenecks.

Typically found alongside activity or status change records in SAP Ariba's audit trail or transaction log tables.

The Purchase Requisition ID is the central key that links all activities related to a single request for goods or services. Each requisition created in SAP Ariba is assigned a unique ID that remains consistent throughout its lifecycle, from creation and submission to final approval, denial, or closure.

In process mining analysis, this attribute is fundamental for case correlation. It enables the reconstruction of the complete end-to-end journey of each requisition, allowing for accurate calculation of cycle times, identification of process variants, and analysis of rework loops. Without this identifier, it would be impossible to distinguish events belonging to different requisitions.

This is the essential case identifier that connects all related activities, making it possible to analyze the end-to-end requisition process for each unique request.

This is a primary key field in the main requisition header tables within SAP Ariba's data structure.

This attribute defines the standard process variant or approval matrix that a requisition should adhere to based on its characteristics, such as value, item category, and department. It represents the 'to-be' or 'happy path' process.

This is fundamental for conformance checking and is used in the 'Requisition Compliance Overview' dashboard. By comparing the actual sequence of activities against the expected Approval Workflow Path, analysts can automatically detect policy violations, unauthorized approval steps, or skipped controls. This is critical for internal audit and risk management.

Defines the standard process to be followed, enabling conformance checking to automatically detect deviations and policy violations.

Consult SAP Ariba documentation. This may be derived from the approval matrix configuration or a specific field on the requisition.

The Event User attribute identifies the individual responsible for executing a specific process step. This could be the employee who submitted the requisition, the manager who approved it, or the procurement agent who processed it.

This attribute is essential for workload analysis, performance comparisons, and identifying training opportunities. It powers the 'Approver Workload and Performance' dashboard by allowing analysis of approval times per user. It is also used to investigate sources of delays or deviations by tracing them back to specific individuals or teams.

It enables analysis of workload distribution, user performance, and resource allocation, helping to identify bottlenecks caused by specific users or teams.

Consult SAP Ariba documentation. This is often stored in audit trail or history tables, linked to user master data.

The Item Category provides details on what is being purchased. This classification helps in understanding spending patterns and applying category-specific procurement strategies and policies.

In process mining, this attribute is vital for the 'Requisition Amendment Analysis' dashboard, as it can highlight if certain categories of items are more prone to amendments, indicating unclear specifications or volatile pricing. It also allows for comparing process performance, such as approval times, across different types of purchases to see if specific categories face more friction.

Enables analysis based on the type of goods or services being purchased, helping to identify category-specific bottlenecks or compliance issues.

Consult SAP Ariba documentation. This information is typically found at the requisition line-item level.

When a requisition is denied, approvers often provide a reason, which can be free-text or selected from a predefined list. This attribute captures that crucial feedback.

This data is the cornerstone of the 'Requisition Rejection Rate Analysis' dashboard. Analyzing the most common rejection reasons helps to identify the root causes of process failures, such as incorrect coding, insufficient justification, or budget issues. These insights can then be used to improve training for requesters and enhance the quality of initial submissions, reducing rework.

Provides direct insight into why requisitions fail, enabling root cause analysis to reduce rework and improve first-time-right rates.

Consult SAP Ariba documentation. This information is typically captured in the comments or history section associated with a rejection event.

This attribute provides organizational context by identifying which part of the business initiated the request. It is typically derived from the requester's user profile or specified directly on the requisition form.

In analysis, this is a powerful dimension for filtering and comparison. It is used in nearly all dashboards, such as 'Requisition Approval Cycle Time' and 'Requisition Rejection Rate Analysis', to break down metrics by department. This allows for identifying which departments have the longest cycle times, highest amendment rates, or most non-compliant requests, guiding targeted process improvement efforts.

Allows for segmenting and comparing process performance across different parts of the organization, highlighting department-specific issues or best practices.

Consult SAP Ariba documentation. Usually available in the requisition header data, often linked from the requester's user profile.

This attribute reflects the real-time status of a requisition, such as 'Composing', 'Submitted', 'Approved', 'Denied', or 'Closed'. It provides a snapshot of where each case is in the process at the time of data extraction.

While process mining reconstructs the historical flow, this attribute is vital for operational monitoring. It is the primary data point for the 'Live Requisition Status Tracker', allowing managers to see the current workload and identify requisitions that are stalled or aging. It provides immediate, actionable visibility into the active requisition pipeline.

Enables real-time monitoring of the requisition pipeline, helping to identify and address stalled or aging requests before they become problematic.

Consult SAP Ariba documentation. This is a standard status field on the requisition header.

This attribute captures the financial value of the entire request. It is a critical piece of business context that helps in categorizing and prioritizing requisitions.

Analyzing process metrics against this value can reveal important patterns. For example, high-value requisitions may follow different, more stringent approval paths or experience longer cycle times. This attribute is essential for understanding the financial impact of process inefficiencies and for categorizing requisitions into value bands for comparative analysis.

Provides crucial financial context, enabling analysis of how requisition value impacts process behavior, such as approval times and workflow complexity.

Consult SAP Ariba documentation. This is a standard field on the purchase requisition header.

The Urgency Level, often represented as a priority flag, signals the business need for expedited processing. This is typically set by the requester to ensure critical needs are addressed promptly.

This attribute is the key driver for the 'Urgent Requisition Process Monitor' dashboard and the 'Urgent Requisition Proc. Time' KPI. It allows for a direct comparison of cycle times between urgent and standard requisitions to validate if priority handling is effective. Analyzing deviations or delays in urgent requests is a key use case for ensuring business continuity.

Allows for prioritizing analysis and monitoring whether high-priority requisitions are processed faster, ensuring critical business needs are met.

Consult SAP Ariba documentation. This is often a selectable field on the requisition creation form.

This calculated metric measures the duration of individual segments within the broader approval workflow. It isolates the time spent waiting for a specific approver or approval level.

This attribute is essential for the 'Approval Path Bottleneck Analysis' dashboard and the 'Avg Approval Step Duration' KPI. It is calculated as the time between an 'Approval Step Started' event and the corresponding 'Approval Step Approved' or 'Approval Step Rejected' event. This granular measurement pinpoints specific approvers or steps that are causing delays.

Provides granular insight into the approval workflow, pinpointing the specific steps or approvers that are the source of bottlenecks.

Calculated as the difference between the timestamps of 'Approval Step Started' and its corresponding terminal event ('Approved' or 'Rejected').

This attribute identifies the specific manager or stakeholder responsible for an approval activity. It is distinct from the general 'Event User' as it specifically relates to approval tasks.

This is a key attribute for the 'Approver Workload and Performance' dashboard. It allows for tracking the number of requisitions handled by each approver and their average approval time. This helps in identifying individual bottlenecks, balancing workloads, and assessing performance against targets.

Pinpoints the specific individual responsible for an approval, enabling detailed workload balancing and performance analysis of approvers.

Consult SAP Ariba documentation. This information is stored in the approval flow data linked to the requisition.

This calculated attribute identifies cases that have undergone at least one 'Requisition Amended' activity. It simplifies the process of flagging requisitions that required changes during their lifecycle.

This flag is used to calculate the 'Requisition Amendment Rate' KPI. By counting the number of cases where this flag is true, analysts can easily measure the frequency of rework and investigate the root causes by correlating it with other attributes like 'Requester Name' or 'Item Category'.

Simplifies the calculation of the amendment rate KPI, helping to quantify rework and identify areas needing clearer initial specifications.

Calculated as true if a case contains one or more 'Requisition Amended' activities, and false otherwise.

This attribute distinguishes between automated system events, such as auto-approvals or system-driven status changes, and manual activities performed by users. This is crucial for understanding the level of automation in the process.

In analysis, this helps to accurately measure human effort and identify opportunities for further automation. For instance, filtering for manual activities allows for a precise calculation of user-centric processing times. It also helps in validating that automated rules are functioning as expected within the process.

Distinguishes between human and system actions, which is essential for measuring automation rates and identifying new automation opportunities.

This is typically derived by checking if the 'Event User' corresponds to a system or batch user ID.

This calculated attribute is a broader measure of inefficiency than 'IsAmended'. It flags cases that have experienced significant rework loops, typically defined as having one or more 'Approval Step Rejected' events or multiple 'Requisition Amended' events.

This flag is used to calculate the 'Requisition Rework Rate' KPI. It helps quantify the hidden costs and delays associated with process failures. Analyzing cases marked as rework can uncover patterns related to certain approvers, departments, or request types that lead to process friction.

Identifies cases with significant process friction, such as rejections, allowing for a focused analysis of the causes of inefficiency and delay.

Calculated as true if a case contains a rejection activity or more than one amendment activity.

This attribute shows the date and time of the most recent data extraction or update for a given event. It provides transparency into the freshness of the data being analyzed, which is especially important for monitoring ongoing processes.

Analysts use this information to understand the recency of the insights generated. For dashboards like the 'Live Requisition Status Tracker', this field is critical to inform users how up-to-date the displayed information is. It helps manage expectations about the data's timeliness.

Indicates the freshness of the data, which is essential for understanding the timeliness and relevance of the process mining insights.

This timestamp is typically generated and added to each record during the data ingestion process.

This attribute links a purchase requisition to its downstream document, the Purchase Order (PO). Its presence signifies the successful conversion of a request into an order.

This is essential for end-to-end process analysis that extends beyond the requisition phase. It is used to calculate the 'Requisition to PO Lead Time' KPI by connecting the requisition creation event with the PO creation event. This provides a holistic view of the procurement cycle's front-end.

Links the requisition to the subsequent purchase order, enabling measurement of the end-to-end Requisition-to-PO cycle time.

Consult SAP Ariba documentation. This is typically stored in the requisition line item data after a PO has been generated.

This case-level attribute identifies the creator of the purchase requisition. It provides context on the origin of the request and the individual stakeholder.

In analysis, this attribute is used to filter the process and analyze behavior by specific requesters. For example, the 'Requisition Amendment Analysis' and 'Requisition Rejection Rate Analysis' dashboards use this to identify individuals who may require additional training due to high rates of amendments or rejections. It helps personalize feedback and improvement initiatives.

Identifies the creator of the request, allowing for analysis of process behavior and quality on a per-requester basis.

Consult SAP Ariba documentation. This is a standard field on the requisition header, often labeled as 'Created By' or 'Requester'.

This is a calculated metric that measures the duration of the core approval process. It is a key performance indicator that reflects the efficiency of the approval workflow.

This KPI directly powers the 'Requisition Approval Cycle Time' dashboard and is the basis for the 'Avg Requisition Approval Time' KPI. It is calculated as the time difference between the 'Requisition Submitted' and 'Requisition Approved' events for each case. Analyzing this metric helps identify overall delays in the approval chain.

Measures the core approval process efficiency, directly supporting a key KPI and dashboard for identifying and reducing delays.

Calculated by subtracting the timestamp of 'Requisition Submitted' from the timestamp of 'Requisition Approved'.

This is a calculated metric that measures the full end-to-end duration for converting a business need into an actionable purchase order. It provides a comprehensive view of the efficiency of the initial phase of the procurement process.

This attribute directly supports the 'Requisition to PO Lead Time' KPI. It is calculated as the time difference between the 'Requisition Created' and 'Purchase Order Created' events. Analyzing this metric helps organizations understand the total lead time experienced by business users and identify areas for holistic improvement.

Measures the full end-to-end time from request to order, providing a holistic KPI for procurement cycle efficiency.

Calculated by subtracting the timestamp of 'Requisition Created' from the timestamp of 'Purchase Order Created'.

This attribute identifies the origin of the process data. For this view, the value would consistently be 'SAP Ariba', but in a broader context where data might be merged from multiple systems, this field is crucial for data lineage and troubleshooting.

In analysis, it helps confirm the data's origin and can be used to filter for or compare processes that span different systems. It ensures clarity and trust in the data source, which is important for stakeholder buy-in.

Identifies the data's origin, which is crucial for data governance, troubleshooting, and ensuring the context of the analysis is understood.

This is typically a static value added during the data extraction and transformation process to label the dataset's origin.