Description This event log has been artificially generated and curated to provide a comprehensive view of car insurance claims, allowing users to discover and identify bottlenecks, automation opportunities, conformance issues, reworks, and potential fraudulent cases using any process mining software.

You can find more event logs here: https://processminingdata.com/JfVPOR

Standard Process flow: “First Notification of Loss (FNOL)” -> “Assign Claim” -> “Claim Decision” -> “Set Reserve” -> “Payment Sent” -> “Close Claim”

Attributes: - case ID - activity name - timestamp - claimant name - agent name - adjuster name - claim amount - claimant age - type of policy - car make - car model - car year - date and time of the accident - type of accident - user type

Total number of claims: 30,000

Dates: Claims belong to years 2020, 2021, and 2022.

Disclaimer: Personal names are fake.

This datasets includes 9 event logs, which can be used to experiment with log completeness-oriented event log sampling methods.

· exercise.xes: The dataset is a simulation log generated by the paper review process model, and each trace clearly describes the process of reviewing papers in detail.

· training_log_1/3/8.xes: These 3 datasets are human-trained simulation logs for the 2016 Process Discovery Competition (PDC 2016). Each trace consists of two values, the name of the process model activity referenced by the event and the identifier of the case to which the event belongs.

· Production.xes: This dataset includes process data from production processes, and each track includes data for cases, activities, resources, timestamps, and more data fields.

· BPIC_2012_A/O/W.xes: These 3 dataset are derived from the personal loan application process of a financial institution in the Netherlands. The process represented in the event log is the application process of a personal loan or overdraft in a global financing organization. Each trace describes the process of applying for a personal loan for different customers.

· CrossHospital.xes: The dataset includes the treatment process data of emergency patients in the hospital, and each track represents the treatment process of an emergency patient in the hospital.

This realistic incident management event log simulates a common IT service process and includes key inefficiencies found in real-world operations. You'll uncover SLA violations, multiple reassignments, bottlenecks, and conformance issues—making it an ideal dataset for hands-on process mining, root cause analysis, and performance optimization exercises.

You can find more event logs + use case handbooks to guide your analysis here: https://processminingdata.com/

Standard Process Flow: Ticket Created -> Ticket Assigned to Level 1 Support -> WIP - Level 1 Support -> Level 1 Escalates to Level 2 Support -> WIP - Level 2 Support -> Ticket Solved by Level 2 Support -> Customer Feedback Received -> Ticket Closed

Total Number of Incident Tickets: 31,000+

Process Variants: 13

Number of Events: 242,000+

Year: 2023

File Format: CSV

File Size: 65MB

Twelve public event log datasets for Collaborative Business Processes (CBPs) are presented here. Among them, the event logs Log-01~Log-04 are collected from some CBPs for the treatment of certain diseases such as gastric ulcer and diabetes in the hospital, the event logs Log-05~Log-07 are collected from some CBPs for designing and manufacturing products such as automobiles, the event logs Log-08~Log-09 are collected from some CBPs for financial services such as bank loans, and the event logs Log-10~Log-12 are collected from some CBPs in e-commerce such as return processing in online stores.

Dataset

This dataset was created by boomerang476

Contents

DEPRECATED - current version: https://figshare.com/articles/dataset/Dataset_An_IoT-Enriched_Event_Log_for_Process_Mining_in_Smart_Factories/20130794

Modern technologies such as the Internet of Things (IoT) are becoming increasingly important in various domains, including Business Process Management (BPM) research. One main research area in BPM is process mining, which can be used to analyze event logs, e.g., for checking the conformance of running processes. However, there are only a few IoT-based event logs available for research purposes. Some of them are artificially generated, and the problem occurs that they do not always completely reflect the actual physical properties of smart environments. In this paper, we present an IoT-enriched XES event log that is generated by a physical smart factory. For this purpose, we created the DataStream XES extension for representing IoT-data in event logs. Finally, we present some preliminary analysis and properties of the log.

In this work, we extract an event log from the MIMIC-IV-ED dataset by adopting a well-established event log generation methodology, and we name this event log MIMICEL. The data tables in the MIMIC-IV-ED dataset relate to each other based on the existing relational database schema, and each table records the individual activities of patients along their journey in the emergency department (ED). While the data tables in the MIMIC-IV-ED dataset catch snapshots of a patient journey in the ED, the extracted event log MIMICEL aims to capture an end-to-end process of the patient journey. This will enable us to analyse the existing patient flows, thereby improving the efficiency of an ED process.

Source: https://archive.ics.uci.edu/ml/datasets/Incident+management+process+enriched+event+log

Reposting as kaggle dataset for convenience and fast usage

The dataset contains object-centric event logs in the OCEL 2.0 ( https://www.ocel-standard.org/ ) format.

The event logs originate from 100,000 Age of Empires 2 matches. In this real-time strategy game, players control units (like villagers or archers) and build structures (like houses or lumber camps) to create an efficient economy and win against the other players. Players can control multiple units at once, and they can utilize game mechanics to automate parts of the process for them, so they must not trigger every event themselves. The beginning of the game focuses on building economic structures that are as efficient as possible. Normative process descriptions, so-called build orders, describe battle-tested interaction patterns for the beginning of the game, similar to chess openings.

The large object-centric event log contains 1000 matches and has the following properties:

The following table describes the most important object types:

The following table describes the most important activities:

The zip file contains filtered object-centric event logs that only contain 10 matches to explore the data set with faster loading time.

This dataset contains a simplified excerpt from a real event log that tracks the trajectories of patients admitted to a hospital to be treated for sepsis, a life-threatening condition. The log has been recorded by the Enterprise Resource Planning of the hospital. Additionally, the dataset contains three synthetic logs that increase the number of trajectories within the original log timespan, while maintaining other statistical characteristics.

In total, the dataset contains four files in .zip format and a companion that describes the statistical method used to synthesize the logs as well as the dataset content in detail. The dataset can be used in testing the performance of event-based process-mining and log (runtime) monitoring tools against an increasing load of events.

This dataset contains the event log table with 10-minute wind statistics from the scanning lidar at AWAKEN's site A1. This is a good dataset to start from for people unfamiliar with the AWAKEN project.

Real life business processes change over time

How does Facebook always seems to know what the next funny video should be to sustain your attention with the platform? Facebook has not asked you whether you like videos of cats doing something funny: They just seem to know. In fact, FaceBook learns through your behavior on the platform (e.g., how long have you engaged with similar movies, what posts have you previously liked or commented on, etc.). As a result, Facebook is able to sustain the attention of their user for a long time. On the other hand, the typical mHealth apps suffer from rapidly collapsing user engagement levels. To sustain engagement levels, mHealth apps nowadays employ all sorts of intervention strategies. Of course, it would be powerful to know—like Facebook knows—what strategy should be presented to what individual to sustain their engagement. To be able to do that, the first step could be to be able to cluster similar users (and then derive intervention strategies from there). This dataset was collected through a single mHealth app over 8 different mHealth campaigns (i.e., scientific studies). Using this dataset, one could derive clusters from app user event data. One approach could be to differentiate between two phases: a process mining phase and a clustering phase. In the process mining phase one may derive from the dataset the processes (i.e., sequences of app actions) that users undertake. In the clustering phase, based on the processes different users engaged in, one may cluster similar users (i.e., users that perform similar sequences of app actions).

List of files

0-list-of-variables.pdf includes an overview of different variables within the dataset. 1-description-of-endpoints.pdf includes a description of the unique endpoints that appear in the dataset. 2-requests.csv includes the dataset with actual app user event data. 2-requests-by-session.csv includes the dataset with actual app user event data with a session variable, to differentiate between user requests that were made in the same session.

This dataset is a simulated event log in standard XES format. It contains events pertaining to restaurant operations of a fictional Udon, a Japanese noodle dish, Restaurant. In Japanese:うどん屋 [udon-ya]. There are 16,412 generated cases distributed over the span of one year, containing in total 674,486 events of 36 unique activities. The log makes use of the lifecycle extension, providing start and complete events per event instance (+ schedule for one activity).

Timestamps are (semi-)realistically distributed over daily and weekly business patterns. The underlying simulation respects resource availability and capacity and incorporates queueing as its main dynamics-drivers in addition to a specified medium-complexity control flow. There is looping behavior, interleaving concurrency and event attribute-dependent control-flow routing.

The event log is comprised of three different restaurant processes: preparation (prep), store opening/closing and service.

prep: In the mornings, senior employees prepare ingredients with long cooking/resting times.

opening/closing: Restaurant setup, opening, cleanup and closing performed with higher propensity by part-time employees.

service: Customer groups arrive, queue for tables, are seated and order one dish per customer. Then, ordered dishes are prepared concurrently as resource availability permits and served all at once. Finally, the customers at one table eat concurrently but pay and leave the restaurant together (synchronized). There is lunch service ~11:30-14:30 and dinner service ~18:00-21:00 with peak customer rush hours at ~13:00-13:15 and ~18:30-19:00 on weekdays. The restaurant is closed on Mondays.

The dish preparation subprocess has a 1 to n multiplicity with cases, making the log pseudo-object centric. Dishes have a unique global id which is referenced in all associated events.

Organizationally, there are six different employees with varying working hours, capacity and activity assignments, propensities and skill. Activity assignments are based on a division of back of the house (BOH) and front of the house (FOH). There are also additional resources to represent, e.g., the restaurant table capacity.

Tenchou-san (Jap. 店長), the shop manager. Up to two times faster than the other cooks. Mostly BOH.

Oku-san, the shop manager's wife. Bridge between BOH and FOH.

Deshi-san A & B, two skilled cooks. Only BOH.

Baito-san A & B, two part-time workers mostly serving customers (FOH).

Furthermore, there are five engineered instances of temporary concept drift with varying impact within the overall process span from 2023-04-01 to 2024-03-31.

From 2023-06-20 to 2023-07-26: Decreased customer arrival rate and group size, resulting in visibly reduced activity.

From 2023-09-01 to 2023-10-22: Slightly increased customer arrival rate and group size.

From 2023-10-15 to 2023-11-05: Most important (human) resource becomes unavailable, resulting in increased utilization of compensating resources.

From 2023-11-19 to 2023-12-10: Reduced restaurant table capacity, not causing any prominent effects.

From 2023-12-10 to 2024-01-15: Increased restaurant table capacity, not causing any prominent effects.

The simulation software used is a past version of https://git.rwth-aachen.de/leah.tgu/qprsim, by the same author as this dataset. The repository specifically contains the configuration for this log generation as a Jupyter notebook in sample/udonya.ipynb.

Extensible Event Stream (XES) software event log obtained through instrumenting the Statechart Workbench ProM plugin using the tool available at {https://svn.win.tue.nl/repos/prom/XPort/}. This event log contains method-call level events describing a workbench run invoking the Alignments algorithm using the BPI Challenge 2012 event log available and documented at {https://doi.org/10.4121/uuid:3926db30-f712-4394-aebc-75976070e91f} . Note that the life-cycle information in this log corresponds to method call (start) and return (complete), and captures a method-call hierarchy.

This dataset contains synthetic event data of a business process used in the paper "Agent System Mining: Vision, Benefits, and Challenges" for the motivating example.

Event-logs and Business Process Simulation Models used in the experimentation of the paper "Enhancing Business Process Simulation Models with Extraneous Activity Delays", where the 'inputs' folder contains all the files used as input, and the 'output' folder the results of the evaluation. Inputs: event-logs, BPS models, and simulation parameters used as input in the experimentation. Real-life: real-life event logs, corresponding to two disjoint subsets of traces from an Academic Credentials' process, and the BPIC 2012 and BPIC 2017 event logs (filtered as explained in the paper), and the BPS model (plus simulation parameters) used as input for each dataset in the presented approach. Synthetic: simulated event-logs and corresponding BPS models (plus simulation parameters) for four different processes with 0, 1, 3 and 5 timer events. Outputs: results of the experimentation. Real-life: results corresponding to the evaluation with real-life event logs. Each of the folders is composed by the original and the enhanced BPS models, 10 event logs simulated with each of them, two folders with the best iteration of the two hyperparameter optimization processes, and the values for the injected timers in each case. In addition, a CSV file with the EMD metrics (cycle time and absolute hour event distribution) for each dataset is provided. Synthetic: results corresponding to the simulated event-logs. Before-After: BPS models and discovered timer events for the four synthetic processes, with five timers placed before and after different activity instances. Complete: BPS models and quality measures (precision, recall, and SMAPE of the discovered timers) for the four synthetic processes with zero, one, three, and five timer events. Individual: event logs enhanced with the discovered extraneous delay for each activity instance, for the four synthetic processes with zero, one, three, and five timer events; and SMAPE of the estimations.

The cruise is complete. The sampling event log is being reviewed.

The event log includes a record of all scientific sampling events completed during the cruise. The event log includes information about event dates and times, latitude and longitude position, event type and the name of the lead scientist for each event.

Cruise Participants:
Lead scientist names that appear in the event log:
Kenneth (Ken) Buesseler (Woods Hole Oceanographic Institution)
Steven Jayne (Woods Hole Oceanographic Institution)
Jun Nishikawa (University of Tokyo)
Hiroomi Miyamoto (University of Tokyo)
Nuria Casacuberta (University Barcelona Autonama)
Hannes Baumann (State University of New York at Stony Brook)
Jarvis Caffrey (Oregon State University)

Other cruise participants:
Steven Pike (Woods Hole Oceanographic Institution)
Crystal Brier (Woods Hole Oceanographic Institution)
Alison Macdonald (Woods Hole Oceanographic Institution)
Kenneth Kostel (Woods Hole Oceanographic Institution)
Sachiko Yoshida (Woods Hole Oceanographic Institution)
Irina Rypina (Woods Hole Oceanographic Institution)
Kamila Stastna (University of Hawaii)
Taylor Alexander Borrius Broek (University of California Santa Cruz)
Jennifer George (State University of New York at Stony Brook)
Melissa Truth Miller (Scripps Institution of Oceanography)

XES software event log obtained through instrumenting JUnit 4.12 using the tool available at {https://svn.win.tue.nl/repos/prom/XPort/}. This event log contains method-call level events describing a single run of the JUnit 4.12 software, available at {https://mvnrepository.com/artifact/junit/junit/4.12} , using the input from {https://github.com/junit-team/junit4/wiki/Getting-started}. Note that the life-cycle information in this log corresponds to method call (start) and return (complete), and captures a method-call hierarchy.

This dataset contains results of the experiment to analyze information preservation and recovery by different event log abstractions in process mining described in: Sander J.J. Leemans, Dirk Fahland "Information-Preserving Abstractions of Event Data in Process Mining"
Knowledge and Information Systems, ISSN: 0219-1377 (Print) 0219-3116 (Online), accepted May 2019

The experiment results were obtained with: https://doi.org/10.5281/zenodo.3243981