Process mining is widely used to analyze, understand, and improve business processes. Object-Centric Process Mining (OCPM) extends traditional approaches by capturing interactions between multiple object types within a process. In supply chains, these interactions exhibit domain-specific behavior, such as order fragmentation, for example, when a supplier cannot complete an order. Yet suitable event data are scarce due to multi-party privacy constraints. We introduce FrOG (Fragmented Order Generator), a configurable generator of object-centric event logs (OCEL) derived from a warehouse simulation with industry-standard stock policies. FrOG produces near-realistic supply-order data that capture fragmentation and cross-object dependencies, enabling OCPM studies without access to sensitive OCPM, warehouse simulation, synthetic OCEL, data generator, fragmented orders operational logs.
CEUR ceur-ws.org
https://github.com/klu-ds/FrOG https://github.com/klu-ds/FrOG/blob/main/README.md https://github.com/klu-ds/FrOG https://youtu.be/MxbSjiawY30
Global supply chains are complex, fast-moving, and inherently uncertain. As demand and supply fluctuate, suppliers often adapt by splitting large orders into multiple shipments based on what is available. This improves service, but it also complicates post-order evaluation, because it blurs lead times, fulfillment rates, and cost comparisons.
One established concept for analyzing supply orders is Process Mining [
Item Configuration
Simulation
Repeat for x days Simulate Deliveries
Simulate
Demand Simulate Orders Generated
OCEL
plays an important role in identifying deviations, ineficiencies, and improvement opportunities.
Traditional process mining techniques typically assume the availability of flat event logs, where
each event is associated with a single case identifier. While efective in many scenarios, this
representation introduces limitations, for instance due to the duplication of events when multiple
process entities interact within a single execution [
Object-centric process mining (OCPM) has emerged as a paradigm that accounts for multiple
interacting objects within a process. Instead of relying on a single case notion, OCPM represents
events in terms of the objects they afect, enabling a more accurate and flexible view of the
execution of real-world processes [
Existing tools for synthetic event log generation [
To facilitate the investigation of novel OCPM techniques that address the challenges of SCM, we propose FrOG (Fragmented Order Generator), a synthetic OCEL generation tool, that uses a warehouse simulation to create authentic orders based on common stock-policies. The tool lets it users customize the simulation and especially the degree to which orders are split. It ofers access to basic OCPM techniques to analyze the resulting OCEL as well as extract it.
FrOG is implemented in Python. The frontend is built with DASH [
Place Order whole item unavailable
Check
Availability Item partially available
Split Item unavailable parts of item
Whole item available
Pick Item
Pack item
end available parts of item of the FrOG. It lets the user configure various parameters of a common warehouse simulation on the simulation page. Then, users can define various items with diferent behavior that the warehouse manages. After that, the simulation runs for the set amount of days. Over the course of the simulation, the warehouse has to fulfill demand and prevent shortages. Each day, it cycles through the simulation of deliveries, demand and orders. These orders are gathered and consolidated into an OCEL. At the end the user is on the one hand presented with data about the simulation and on the other hand they can analyze the created OCEL and export it on the analysis page.
The core of FrOG is the user-configured warehouse simulation. In supply chain management,
warehouse simulation is a proven tool to investigate and optimize warehouse policies [
The warehouse follows the classical continuous review policy [
Each simulated day follows the same structure. First, the warehouse receives the due deliveries, evaluates the corresponding orders and updates its parameters like the reorder point accordingly. Second, it invokes the random demand for each of its managed items and reduces the inventory accordingly. Third, if the stock-level of any item drops below the respective ROP it creates a new order for that item and hands it over to the OCEL-generation module to convert that pre-configured order into one process instance of an OCEL.
Figure 2 shows BPMN diagram of the fixed order process that the simulation triggers at each
ROP. It modifies the order-to-delivery process found in [
Once the order is placed, item availability is continuously evaluated through the “Check Availability” activity. Based on material availability at the time of checking, the process branches into three possible paths: 1. No availability: If none of the materials for an item are currently available, the item is disregarded and re-evaluated in the next availability check. 2. Full availability: If the full quantity of materials is available, the item is directly picked, packed, and included in a shipment. 3. Partial availability: If only part of the item’s materials are available, a split occurs (as modeled by the “Split item” activity). The item is divided into two new item objects: one containing the available materials, and another holding the remaining quantity. The available portion continues through the pick, pack, and deliver sequence, while the remaining portion loops back to the availability check.
This fragmentation may repeat multiple times until all materials are eventually picked and delivered. The user defines the average degree to which orders of an item are split, when they configure the item.
After the simulation is complete, FrOG ofers two types of output to the user. First is the supply chain perspective ofering data with regards to the simulation itself. This includes the total fulfilled the demand, the amount of orders, unfulfilled demand, and the service level (relative fulfilled demand). These information are computed for each item as well as for the whole warehouse globally.
The second type of output is the OCEL that FrOG constructs using all orders issued during
the simulation. It adheres to the OCEL 2.0 standard [
We assess the maturity of FrOG by assessing its scalability. For increasing parameter values that target the tool’s complexity, we evaluate the runtime of the simulation and the following OCEL creation. This benchmark can be recreated on benchmark page.
We consider the simulation days, the amount of items, and the mean amount of splits to be the driving dimensions of FrOG’s scalability. They are the most relevant dimensions for the envisaged use case. We diagonalize the benchmark over these dimensions to cover all possible configurations within the following bounds: 1000, 2000, 5000 and 10000 simulation days, 1, 5, 10, and 50 items, as well as 0, 1, 5, 10 mean splits. We repeat each configuration three times.
The results in Figure 3 indicate diferent efects on the scalability depending on which dimension is increased. Increasing the splits from zero to one, as well as 5-10 results in similar run times, albeit an increase between one and five severely increases the run time. The efect on the run time of increasing amounts of items decreases with more items. Increasing the amount of days leads to slight super linear growth of the run time.
In this paper, we proposed FrOG, which generates OCELs from orders created as part of a realistic warehouse simulation. While the tool is a step towards facilitating OCPM techniques for more complex supply chain related processes, there a still improvement opportunities left. Future work should consider adding more functionality, such as a dedicated OCPM page that hosts existing OCPM techniques to apply them on the created OCEL. It could also concern itself with other processes related to the warehouse or adding diferent behavior to the warehouse, such as configurable stock policies. The current implementation does not consider the availability of resources that could limit warehouse throughput.
The author(s) used ChatGPT to: polish the code of the frontend. The author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content.