PaperlayerView exact revision on arXiv

Source-linked AI summary

ERP Event Logs: A Canonical Form for KPI Time-Series Extraction and Characterization

Sherri Hadian, Adrian Rebmann, Atacan Korkmaz, Gregor Berg, Ulf Brackmann

arXiv:2610.09903v1cs.DB

TL;DR

ERP KPI extraction from normalized tables requires bespoke joins for individual metrics. This paper derives a canonical event log from ERP data and uses it to extract and compare KPI time series across customers and processes. Forecastability shows a recurring ordering from volumes through durations to rates across both processes, while cross-process weekly arrivals are moderately correlated without a systematic lead or lag.

  • Problem

    ERP data are spread across normalized tables, so extracting each operational KPI requires locating metric-specific timestamps and writing bespoke joins.

    Source: §I · p. 1

  • Method

    The paper maps ERP records once into a canonical event log and extracts volumes, durations, and active-case-normalized rates as reusable operations over that representation.

    Source: §I · p. 1, §IV · p. 4

  • Results

    Forecastability decreases from volumes through durations to rates across both processes, while weekly sales- and procurement-side arrivals have a grand-median lagged cross-correlation of ρ ≈0.24 with no systematic lead or lag.

    Source: §VI · p. 5, §V · p. 5

  • Takeaways & Limitations

    The canonical form supports reusable KPI extraction and direct comparison of sales- and procurement-side signals across the studied customers and processes.

    Source: §VIII · pp. 6–7

    No benchmark is released because customer transactions cannot legally be published, and the material-group match is only a coarse proxy for shared demand exposure.

    Source: §VII · p. 6

Abstract

from arXiv · show

Enterprise resource planning (ERP) systems record operations as transactions spread across hundreds of normalized relational tables. Extracting an operational key performance indicator (KPI) from this schema requires a separate, bespoke join for almost every metric. We show that an event log, a canonical (case, activity, timestamp) representation derived from the same tables, collapses this heterogeneity into one flat structure, from which KPI families reduce to reusable operations after a one-time mapping. Using standardized event logs built from hundreds of SAP S/4HANA customers under a shared activity ontology, we define three families of process-derived KPIs (volumes, durations, and rates) and extract them uniformly across customer systems for two common end-to-end organizational processes, order-to-cash and procure-to-pay. We normalize rates and screen series for minimum coverage to support comparison across customers of very different sizes. We then characterize heterogeneity across industries and tenants using descriptors derived directly from the canonical form, before analyzing the resulting KPI time series. The same process executes heterogeneously across customers and industries, yet this shared representation enables direct comparison of sales- and procurement-side signals, including lead times and order arrivals. Using this shared representation, we characterize which KPI families are forecastable and find a recurring ordering from volumes through durations to rates across both processes and a highly heterogeneous customer base; a pretrained time-series foundation model (Chronos) is competitive with classical baselines such as ARIMA and ETS on rate and duration series, while classical models retain an edge on volumes.

I. INTRODUCTION

ERP KPI extraction usually requires a separate join for each metric across normalized tables. The paper frames an event log as a canonical form that centralizes those joins once and makes KPIs reusable operations over a common structure.

I. INTRODUCTION

  • The event log adds no expressive power over relational algebra; its advantage is paying the schema-specific extraction cost once instead of writing a new join for every KPI.The shared schema then supports reusable, comparable, model-ready KPI time series.Source: §I · p. 1
  • The paper defines volumes as activity counts per period, durations as timestamp differences between activities in a case, and rates as population-normalized counts of exceptions.These families capture throughput, lead times, and process-health signals such as cancellations or price changes.Source: §I · pp. 1–2
  • The study builds standardized event logs for order-to-cash and procure-to-pay from hundreds of SAP S/4HANA customers using a shared activity ontology.It uses the logs to characterize customer heterogeneity, extract comparable time series, and analyze cross-process comparability and forecasting.Source: §I · p. 2
  • The paper characterizes customer and industry heterogeneity using descriptors from the canonical form and compares sales- and procurement-side signals, including lead times and order arrivals.The shared representation enables direct cross-process comparison.Source: §I · p. 2
  • Across both processes and customers, forecastability follows a recurring ordering across KPI families, with classical baselines contrasted against Chronos.The introduction identifies this family-level ordering as a central finding.Source: §I · p. 2

II. THE EVENT LOG AS A CANONICAL FORM

The event log reshapes normalized ERP data into cases with ordered, timestamped activity records. Standardized source tables and a shared activity ontology align labels and times across tenants, while the flat relational view makes KPI operations reusable.

II. THE EVENT LOG AS A CANONICAL FORM

  • An event log is a nested table of cases with case-level attributes and ordered event records, each carrying an activity label, timestamp, and optional payload.A shared format such as XES does not by itself ensure that customers use the same label for the same processing step.Source: §II · p. 2
  • A fixed shared activity ontology maps source records to canonical labels, using standardized S/4HANA Cloud tables, fields, and codes to align processing-step names across customers.Rules can label a goods receipt by movement type or a purchase-order price change by the changed field.Source: §II · p. 2
  • Customized fields or codes may be missed or mislabeled because the mapping rules assume standard fields and codes.The stated comparability boundary is tenants’ use of the conventions assumed by those rules.Source: §II · pp. 2–3
  • The same mapping assigns each activity occurrence a native transactional timestamp or a change-log timestamp, aligning event times across tenants.The resulting time series are comparable across customers.Source: §II · p. 3
  • The flat relational view gathers facts from multiple ERP tables under one schema, so KPI operators can be reused after source-specific joins are centralized in the mapping.The ontology aligns labels; the common schema supports reusable operators.Source: §II · p. 3

III. THE CUSTOMER BASE: PROCESS HETEROGENEITY

Three descriptors derived directly from case, activity, and timestamp records characterize customer-level process heterogeneity. The same process varies substantially across customers and industries.

III. THE CUSTOMER BASE: PROCESS HETEROGENEITY

  • The customer-base characterization derives case counts, distinct-activity counts, and median completed-case duration directly from case, activity, and timestamp records.Duration runs from order creation to final payment.Source: §III · p. 3
  • Within a single industry, process volumes span two to three orders of magnitude across customers.The descriptors are grouped by industry in Fig. 2.Source: §III · p. 3
  • Process complexity and typical durations vary systematically across industries.Together with the within-industry volume spread, these differences show that customers execute the same end-to-end process heterogeneously.Source: §III · p. 3

IV. KPI EXTRACTION

The section defines volumes, durations, and active-case-normalized rates as reusable KPI operations over the event log. It specifies how these measures are timed and screened, and shows how the shared structure supports drill-down without bespoke joins.

IV. KPI EXTRACTION

  • Volumes count activities per period, durations measure within-case time between activities, and rates normalize qualifying-event counts by an active population.These operations capture process throughput, lead times, and exception incidence, respectively.Source: §IV · p. 3
  • Volumes are bucketed at arrival, rates at the defining event, and durations at interval completion so each period contains only complete observed durations.Bucketing durations at the terminal event avoids right-censoring, at the cost of a completion-time lag.Source: §IV · p. 3
  • Rates count distinct cases with a qualifying event at most once per period and divide by active cases; the result is an event rate, not a probability.Cases remain active from arrival until completion, or until 12 weeks after their last event when completion is unobserved.Source: §IV · pp. 3–4
  • Series require at least 30 cases per period and 100 weekly periods; those below either threshold are held out as coverage caveats.All metrics use weekly granularity, and reported counts are post-screening.Source: §IV · p. 4
  • Event-log templates replace KPI-specific raw-schema join paths, and retaining material references enables material-group drill-down without a new join.Per-material arrival series can expose demand structure dampened in customer-level aggregates.Source: §IV · pp. 4–5

V. CROSS-PROCESS COMPARISON

The shared representation makes sales- and procurement-side signals comparable. Procurement lead times are longer, while weekly arrivals show contemporaneous co-movement without a consistent lead or lag.

V. CROSS-PROCESS COMPARISON

  • Because both processes reduce to the same event-log structure, their customer-level lead times and weekly arrival series can be compared directly.The corresponding comparison over raw ERP data would require reconciling two unrelated join paths.Source: §V · p. 5
  • Procurement lead times are longer than sales lead times, with customer-level medians of 9 versus 1 day among 112 tenants observed in both processes.The paired comparison reports a Wilcoxon p < 10−8.Source: §V · p. 5
  • Weekly sales- and procurement-side arrivals by material group in wholesale distribution peak in cross-correlation at lag zero, with no systematic lead or lag.The grand-median correlation is approximately 0.24; co-movement is consistent with, but does not establish, a replenishment link.Source: §V · p. 5

VI. FORECASTABILITY

Across both processes, forecastability declines from volumes through durations to rates, and this ordering recurs across a heterogeneous customer base. Classical models edge Chronos on volumes, while Chronos is competitive on durations and often strongest on the rate families that are forecastable, though rate-family evidence is thin.

VI. FORECASTABILITY

  • At cutoffs four weeks apart, classical models use at least 80 prior weeks and forecast the next 12; forecasts are scored by median MASE relative to an in-sample one-step naïve forecast.Classical models are refit at each cut-off; Chronos is applied zero-shot with the per-horizon median of 20 samples. No selection or tuning uses test windows.Source: §VI · p. 5
  • Forecastability decreases from volumes through durations to rates across both processes, and the ordering recurs across independently extracted processes and a highly non-uniform customer population.At least one model beats the naïve baseline on roughly 83–94% of volume series; paired tests find significant improvements for all four volume KPIs, two of four durations, and one of four rates.Source: §VI · p. 5
  • Classical models have a small, consistent median-MASE edge over Chronos on volumes; Chronos is near the best model on most duration families except purchase-order to goods receipt.Chronos is often strongest on forecastable rate families, but two rate families have n ≤ 12, so that result is suggestive rather than conclusive.Source: §VI · p. 5
  • Active-case counts serve only as rate-normalization denominators and are not evaluated as forecasting targets.Source: §VI · p. 5

VII. DISCUSSION AND LIMITATIONS

The analyses use aggregated KPI series because customer transactions cannot be legally released, and some comparisons remain limited by thin rate samples and coarse matching. Mapping coverage and screening-threshold sensitivity were not assessed.

VII. DISCUSSION AND LIMITATIONS

  • Customer transactions cannot be legally released, so no public benchmark is provided and analyses are reproducible only within the authors’ environment.The reported analyses use aggregated KPI series.Source: §VII · p. 6
  • Thin sales-side rate families lead the authors to tier claims by sample size, while material-group matching is only a coarse proxy for shared demand exposure.The proxy does not establish item-level inventory or replenishment links.Source: §VII · p. 6
  • Per-tenant ontology mapping coverage and screening-threshold sensitivity were not analyzed and are left to an extended version.Table III documents dataset and post-screening coverage.Source: §VII · p. 6

VIII. CONCLUSION

The conclusion frames the event log as a common ERP representation whose value is extraction leverage: once mapped, KPI extraction uses reusable operations rather than bespoke joins. The paper applies this representation to three KPI families across hundreds of customers.

VIII. CONCLUSION

  • Once mapped, the event log lets process-derived KPIs use reusable operations over one structure instead of bespoke joins across many tables.The paper emphasizes extraction leverage rather than added expressiveness.Source: §VIII · pp. 6–7
  • Across hundreds of customers, the paper defines three KPI families and characterizes their heterogeneity, cross-process comparability, and forecastability.Source: §VIII · p. 7

APPENDIX A REPRESENTATIVE ACTIVITIES FOR KPI CONSTRUCTION

The appendix lists representative activities in the shared ontology for order-to-cash and procure-to-pay, with durations expressed as start-to-end activity pairs.

APPENDIX A REPRESENTATIVE ACTIVITIES FOR KPI CONSTRUCTION

  • The listed order-to-cash and procure-to-pay activities are illustrative, not exhaustive; duration examples use start-to-end activity pairs.Source: Appendix A · p. 7

APPENDIX B DATASET STATISTICS

The appendix distinguishes log statistics for all tenants with extracted logs from KPI series computed on specified tenant subsets and screened per tenant and KPI.

APPENDIX B DATASET STATISTICS

  • Log statistics cover tenants with extracted logs, while KPI series use listed tenant subsets and are screened per tenant–KPI series.The screening procedure is described in the table notes.Source: Appendix B · p. 7

APPENDIX C EXTRACTION EFFORT

The section contrasts bespoke raw-schema joins with reusable event-log operations for KPI extraction, alongside representative KPI definitions and series-screening criteria.

APPENDIX C EXTRACTION EFFORT

  • For KPI instantiation, generic activity-based operators cover representative metrics, including duration start/end pairs and change/rework rates spanning price, quantity, and material variants.Table II gives representative O2C and P2P activities.Source: Appendix C · p. 7, Table II · p. 8
  • Tenants below 500 events are excluded; retained series span at least 100 weeks, are at least 80% observed, have no gap over four weeks, and take at least five distinct values.Periods with fewer than 30 cases are masked; “Completion” denotes the terminal event for the corresponding process.Source: Appendix C · p. 8
  • Table IV contrasts two KPI definitions: each needs a bespoke multi-table join over the raw schema, while event-log extraction uses generic operators instantiated with relevant activities.The rate also requires separate denominator reconstruction over the raw schema.Source: Appendix C · p. 7, Table IV · p. 8
Loading 2610.09903v1…