Digital Twin of the Organization and Process Twins: Process Mining, Simulation and Event Logs as Twin Data

Most digital twin programmes model a pump, a production line or a building, and then stop at the factory gate. The delays that hurt customers rarely live inside a machine. They live in the hand-offs between an order desk, a planner, a warehouse and a finance team, in queues nobody measures and rules nobody wrote down. A digital twin of the organization attacks that blind spot by treating the business itself as the asset to be modelled, monitored and simulated.

This matters in 2026 because the raw material already exists. Every ERP, MES, ticketing and CRM system emits timestamped records of who did what to which object. Process mining turns those records into a faithful model of how work actually flows, and simulation turns that model into a place to rehearse decisions. The hard part is no longer algorithms; it is data shape, fidelity and honest scoping.

You will leave with a working definition, a layered architecture, a clear view of why object-centric event logs (OCEL 2.0) are the right twin data format, runnable Python for discovery and simulation, and a list of failure modes.

What this covers: the Gartner definition, process twins versus operational twins, event logs as twin data, discovery versus conformance versus simulation, linking to asset twins, tooling, a worked example and limits.

Context and Background

Gartner defines a digital twin of an organization (DTO) as “a dynamic software model of any organization that relies on operational and/or other data”. The model is meant to show how the organization operationalises its business model, where it stands now, how it responds to change, how it deploys resources and how it delivers customer value. Gartner’s framing asks for the operating model of the physical organization, data from and about its constituents, a one-to-one alignment between twin and organization, and the ability to monitor those constituents. Note what is absent: no 3D graphics, no sensors, no physics engine. The “organization” is a system of people, rules, resources and information flows.

That puts a DTO at the far end of the spectrum from the asset twins this site usually covers. A bearing twin estimates remaining useful life from vibration; a DTO estimates how long a purchase order will sit unapproved if two buyers are on leave. The two share a skeleton (data in, model in the middle, decisions out) but differ in what counts as state and what counts as ground truth. For the physical side of that comparison, see our piece on the digital twin versus simulation architecture decision.

Process mining is the discipline that makes the data side tractable. Its inputs are event logs: records with a case or object identifier, an activity name and a timestamp. Its outputs include discovered process models, conformance diagnostics against a reference model, and performance analytics such as waiting times and bottlenecks. The community around the IEEE Task Force on Process Mining maintains the XES standard (IEEE 1849-2016) for case-centric logs, and vendor platforms such as Celonis and open tools such as PM4Py build on the same concepts.

What changed recently is the log format. Classic logs force every event into exactly one case, which distorts reality whenever one event touches many things at once. The Object-Centric Event Log standard, OCEL 2.0, was published on arXiv in March 2024 by a group of process-mining researchers including Wil van der Aalst and Alessandro Berti, and it removes that restriction. This post uses it as the backbone of the twin. Business events also arrive late and out of order, so the timing issues in our guide to event-time alignment, watermarks and late-arriving events apply directly.

The angle here is data-first. Instead of surveying vendors, we treat the event log as the twin’s state store and ask what a DTO needs from it: identity, relationships, time semantics, change history and provenance. Those requirements, not the dashboard, decide whether the twin is useful.

A Reference Architecture for the Process Twin

A process twin is a continuously updated, simulatable model of how work flows through an organization, built from event data and aligned to the live operation. In practice it is five layers: source systems, event extraction, a process-mining core, an organization model and a scenario engine, with a decision loop that feeds back into the real process.

Figure 1: Reference architecture of a digital twin of the organization, from operational systems through OCEL event logs, mining, the organization model and simulation, back to a real-world change.

The diagram reads clockwise. Operational systems and shop-floor events land in an extraction layer that writes a normalised log. Mining discovers and checks the process. The organization model adds resources, rules and capacity. The simulator runs scenarios, and a manager’s decision changes the real process, which in turn changes the data. That closed loop is what separates a twin from a one-off analysis project: if nothing flows back, you have built a report.

Layer 1: Source systems and extraction

The source layer is whatever records business activity: ERP transactions, MES operation confirmations, ticketing status changes, CRM stage moves and, for physical operations, sensor-derived events. Most of these systems do not store events at all. They store the current state of a row plus a change-document table, so extraction means reconstructing events from table diffs, audit tables or change-data-capture streams. This is the most expensive step in any real programme and the one vendors’ demos skip.

Extraction should be incremental and idempotent: the same source change must always produce the same event identifier, so a replayed batch cannot double-count. A deterministic hash of source table, primary key, field and change timestamp works. Keep the raw landing data immutable, exactly as a warehouse does, and derive the log from it, so you can fix extraction logic later and rebuild.

Layer 2: The mining core

Mining has three jobs that the next sections treat in depth: discovery (what is the process), conformance (how does reality differ from the intended process) and enhancement (what are the timing, resource and cost properties). The core consumes the log and produces models and diagnostics, not decisions. Keeping it separate matters because mining output is a hypothesis about behaviour, and hypotheses need review before they drive a simulator.

Layer 3: Organization model

This is where a DTO departs from plain process mining. The organization model holds resources (people, roles, teams, machines), calendars and shift patterns, capacity, routing and approval rules, and cost rates. Some of it can be mined: resource pools and working-time patterns are observable in logs. Some cannot: policy intent, upcoming staffing changes and constraints that have never been triggered. Those must come from people and be versioned like code.

Layer 4: Scenario engine and decision loop

The scenario engine takes the current state plus a proposed change (add a shift, merge two approval steps, reroute a product family) and returns a distribution of outcomes, not a single number. It is fed live state so scenarios start from today’s queues rather than an empty system. Decisions then flow back as configuration changes in the real systems, which closes the loop. When the loop is automated, governance gates matter; our digital twin maturity model describes the fidelity levels that justify moving from advisory to automatic.

Event Logs as Twin Data

Twin data for an organization is a history of discrete events attached to the things they affect. The log must record an identifier for each affected object, an activity, a timestamp and attributes. Case-centric logs allow one case per event; object-centric logs allow many objects per event and relations between objects, which is how real organizations behave.

The case-centric limit

Take an order-to-cash flow. A purchase order has several items; items ship in different deliveries; deliveries are invoiced together. If you pick “order” as the case, an event shipping two items from different orders appears twice (convergence). If you pick “item”, the order-level event “approve order” is replicated for every item (divergence), inflating counts and distorting averages. Process mining literature calls these convergence and divergence problems. Celonis’s documentation makes the same point: case-centric mining is a linear chain of events tied to one case, and object-centric mining avoids duplicated logs and distorted KPIs in cases like partial invoicing and split deliveries.

What OCEL 2.0 adds

According to the specification paper, OCEL 2.0 is the successor to OCEL 1.0 (2020) and adds three things: object-to-object relationships, qualifiers on relationships (to objects or to events) and attributes that change over time. It defines three exchange formats: a relational database (SQLite), XML and JSON. The authors also describe it as more expressive and more readable than XES. For a twin, each addition has a concrete use.

Event-to-object links with qualifiers let one event reference an order, an item and a resource, each with a role.
Object-to-object relations record structure such as item belongs to order, delivery contains item.
Changing attributes capture state history, such as a price, a status or a credit limit, which a twin needs to replay conditions as they were.

Figure 2: An object-centric event log. One event can touch several objects, and objects relate to each other, so no single case notion is forced on the data.

In Figure 2, the “Pick items” event links to two items and the “Ship” event links to a delivery and an item. Flattening onto the order would duplicate Ship; flattening onto the item would duplicate Create PO. The object-centric model keeps one event, many links, and lets each analysis choose its own view.

Twin-grade log requirements

A log used as twin data needs more than a mining log does. Check these before you build anything on it.

Stable object identity. The same order must have the same identifier across systems, or you need a resolved mapping table.
Trustworthy timestamps. Distinguish the time something happened from the time it was recorded; batch postings at midnight destroy duration analysis.
Complete lifecycle. Start and end of activities, not just completion, are needed to separate waiting time from working time.
Resource attribution. Who or what performed the event, with roles.
Provenance. Which source row produced each event, so any number can be traced back.
Change history for attributes. Not just current state, so scenarios can be replayed under past conditions.

Extracting events: a minimal pattern

The extraction step is mostly SQL. The snippet below shows the idea against a hypothetical ERP change-document table: it emits one event row per status change and one link row per affected object. Table and column names are illustrative, not from any specific ERP.

-- illustrative schema: erp_change(doc_type, doc_id, field, old_val, new_val, changed_at, user_id)
CREATE VIEW event AS
SELECT
  md5(doc_type || doc_id || field || changed_at) AS event_id,
  CASE
    WHEN doc_type = 'PO'  AND field = 'status' AND new_val = 'APPROVED' THEN 'Approve PO'
    WHEN doc_type = 'DLV' AND field = 'status' AND new_val = 'SHIPPED'  THEN 'Ship Delivery'
    WHEN doc_type = 'INV' AND field = 'status' AND new_val = 'POSTED'   THEN 'Post Invoice'
  END AS activity,
  changed_at AS event_time,
  user_id AS resource
FROM erp_change
WHERE field = 'status';

-- links: one row per event-object pair with a qualifier
CREATE VIEW event_object AS
SELECT event_id, doc_id AS object_id, doc_type AS object_type, 'subject' AS qualifier
FROM event e JOIN erp_change c USING (changed_at);

Deterministic event identifiers make the pipeline replayable. The join in the second view is deliberately naive; in a real extraction you would join on the change-document key rather than the timestamp.

Discovery, Conformance and Simulation

Process mining offers three complementary operations on a log: discovery builds a model from data, conformance compares data with a model, and enhancement or simulation adds performance behaviour and runs it forward. A process twin needs all three, in order, because a simulator built on an unvalidated model produces confident nonsense.

Figure 3: The twin-building loop. Discovery produces a model, conformance checks fit, and only a model that replays the log well is enhanced with timing and resource data for simulation.

Discovery

Discovery algorithms turn an event log into a model: a directly-follows graph, a Petri net or a BPMN diagram. The inductive miner family guarantees sound models; heuristics-style miners tolerate noise. For object-centric logs, PM4Py exposes discovery of an object-centric directly-follows graph and an object-centric Petri net, while a flattening operation projects the log onto one object type to reuse classical algorithms.

import pm4py

# OCEL 2.0 stored as SQLite (also available: read_ocel2_json, read_ocel2_xml)
ocel = pm4py.read_ocel2_sqlite("order_to_cash.sqlite")

print(pm4py.ocel_get_object_types(ocel))            # e.g. ['order', 'item', 'delivery', 'invoice']
print(pm4py.ocel_object_type_activities(ocel))      # activities per object type

# object-centric discovery
ocdfg = pm4py.discover_ocdfg(ocel)
ocpn  = pm4py.discover_oc_petri_net(ocel)           # returns the object-centric Petri net

# classical view: flatten on one object type, then use case-centric tools
flat = pm4py.ocel_flattening(ocel, "item")
net, im, fm = pm4py.discover_petri_net_inductive(
    flat, activity_key="ocel:activity",
    timestamp_key="ocel:timestamp", case_id_key="ocel:oid")

The function names above (read_ocel2_sqlite, ocel_get_object_types, ocel_object_type_activities, discover_ocdfg, discover_oc_petri_net, ocel_flattening) appear in PM4Py’s documented API. The flattened DataFrame’s column names and the keyword arguments of the inductive miner can vary by PM4Py version, so check your installed version before copying this.

Conformance

Conformance checking replays the log on a reference model and reports deviations: skipped steps, repeated steps, wrong order. For a DTO the reference model is often a documented standard operating procedure, which makes conformance the cheapest high-value output: it quantifies the gap between the process as designed and the process as run. Token-based replay is fast and gives a fitness score; alignments are exact but costlier. Fitness alone is not enough, because a model that allows everything has perfect fitness. Pair it with precision, which penalises a model for allowing behaviour never seen.

import pm4py

log = pm4py.read_xes("p2p.xes")                 # classical case-centric log
net, im, fm = pm4py.discover_petri_net_inductive(log)

fit  = pm4py.fitness_token_based_replay(log, net, im, fm)
prec = pm4py.precision_token_based_replay(log, net, im, fm)
print(fit["average_trace_fitness"], prec)

For twin purposes, record the fitness and precision per model version. A drop after a software release is an early signal that the real process drifted, and the twin should alarm on it just as an asset twin alarms on a residual.

Enhancement and simulation parameters

Enhancement attaches performance data to the model: inter-arrival times of new cases, activity processing-time distributions, waiting-time distributions, resource pools and their calendars, and branching probabilities at decision points. These become the parameters of a business process simulation model. Research tools automate this step: Simod, from the University of Tartu group, discovers business process simulation models from event logs in CSV form, can start from a supplied BPMN model, tunes parameters with a Bayesian optimiser (TPE), and runs on the Prosimos simulator, according to its documentation.

The decision that matters is what you simulate. Discrete-event simulation (DES) is the default for queueing and resource contention, which is most of business process behaviour. Agent-based models fit when individual behaviour, such as human prioritisation, drives outcomes. System dynamics fits aggregate flows over long horizons. Most process twins should start with DES because its parameters can be estimated directly from an event log.

A runnable what-if simulation

The following SimPy script is a minimal DES of an approval queue. The parameters are placeholders you would replace with values mined from your own log. The numbers are illustrative only and not measured from any real system.

import random, statistics, simpy

def run(approvers, arrival_mean=4.0, service_mean=9.0, horizon=60*24*5, seed=1):
    random.seed(seed)
    env = simpy.Environment()
    staff = simpy.Resource(env, capacity=approvers)
    waits = []

    def request(env):
        t0 = env.now
        with staff.request() as req:
            yield req
            waits.append(env.now - t0)                      # queue wait in minutes
            yield env.timeout(random.expovariate(1/service_mean))

    def source(env):
        while True:
            yield env.timeout(random.expovariate(1/arrival_mean))
            env.process(request(env))

    env.process(source(env))
    env.run(until=horizon)
    waits.sort()
    return statistics.mean(waits), waits[int(0.95*len(waits))]

for n in (3, 4, 5):
    reps = [run(n, seed=s) for s in range(30)]
    mean_w = statistics.mean(r[0] for r in reps)
    p95_w  = statistics.mean(r[1] for r in reps)
    print(f"approvers={n}  mean wait={mean_w:6.1f} min  p95 wait={p95_w:6.1f} min")

With these illustrative parameters, three approvers face a utilisation of 9/(3×4) = 0.75 and four face 0.56, so queueing theory predicts waits fall sharply from three to four. That sanity check, comparing simulator output to an analytic queue formula, is a cheap verification step every process twin should include. Always run many replications with different seeds and report intervals, because a single run is one sample.

Linking Operational Twins and Process Twins

An operational twin models physical assets and a process twin models the work flowing through and around them. Linking them lets a machine state change update a process forecast, and lets a process decision reach back to the asset schedule. The link works on events: asset twins publish state changes, and the process twin consumes them as events with object identifiers it can join.

Figure 4: Operational twin events update the process twin’s state. A what-if request starts from that live state, and the approved scenario returns to the operational layer as a schedule change.

Join keys are the whole problem

An asset twin knows machine M-204 stopped at 09:14. The process twin knows that work order WO-7781 was due on M-204 at 09:00. The integration is a shared identifier: the work order must reference the machine, and the machine’s downtime event must be expressible as an event on the work-order and machine objects. In OCEL terms, the downtime is an event linked to a machine object, and the object-to-object relation from work order to machine lets the process twin propagate the delay. Without a stable asset registry, this join degenerates into fuzzy string matching, and the twin’s forecasts degrade with it.

For manufacturing, the natural integration point is the execution layer. Our reference architecture for a digital twin with MES shows how work orders, operations and confirmations form exactly the event stream a process twin wants. Quality knowledge fits the same pattern: failure modes and controls that live in a knowledge graph, such as those in a digital FMEA linked to the PLM digital thread, can become conformance rules, so that a skipped inspection step is flagged as a deviation with a known risk attached.

Time and ordering across twins

Sensor events and business events have different clocks. A conveyor jam is stamped by an edge gateway; the order status is stamped by an ERP posting job that may run hourly. If the process twin treats both as simultaneous it will misattribute delays. Apply the same discipline as for sensor streams: keep event time and ingestion time separate, use watermarks to decide when a window is complete, and plan for late corrections. Business logs add a twist, namely back-dated entries, where a user records yesterday’s action today. These should be ingested as late events, not rewritten history.

Coupling modes

There are three levels of coupling worth distinguishing.

Offline twin. Logs are loaded in batches, mined and simulated for planning. This is the most common and most reliable starting point.
Synchronised twin. The log updates continuously and the simulator initialises from the live queue state, so forecasts reflect current work in progress. This requires incremental mining and state reconstruction, which is substantially harder than batch.
Closed-loop twin. Recommendations or actions flow back automatically. This needs conformance monitoring, rollback and approval gates, and it should be earned by evidence from the lower levels.

Tooling Landscape

The tooling splits into three groups: commercial process-mining platforms, open-source libraries, and simulation engines. Capabilities change quickly, so treat this as a map of categories and verify each product’s current features before purchase.

Celonis. Its documentation describes an object-centric data model built from objects, events and relationships, with perspectives as filtered views and prebuilt core process packages such as accounts payable, order management and procurement. It positions object-centric mining for many-to-many relations.
PM4Py. An open-source Python library with readers for XES and for OCEL 1.0 and 2.0 in several formats, discovery, conformance and object-centric functions. It is the natural choice for scripted, reproducible twin pipelines.
Simod and Prosimos. Research-grade tooling to discover and run business process simulation models from logs. Check the licence and maintenance status for your use.
Apromore. A process-mining platform with a simulation capability, commonly cited alongside the above. I did not verify its current feature set for this post, so confirm against vendor documentation.
General simulation libraries. SimPy for DES in Python, or commercial simulation suites when animation and large models matter.

A pragmatic stack for a first twin is PM4Py for mining, SimPy or Simod/Prosimos for simulation, an OCEL file in SQLite as the interchange format, and a notebook or dashboard on top. A commercial platform earns its cost when you need connectors to enterprise systems, governed access and many business users, because extraction and data modelling dominate effort.

Worked Example: Order Approval Backlog

The following scenario is hypothetical and illustrative; no real company or measurements are involved. A distributor’s sales orders over a value threshold need manager approval. Customers complain that large orders take days to confirm.

Step 1, extract. From the order system’s change documents, build an OCEL log with object types order, item and approver, and events such as Create Order, Request Approval, Approve and Release. Verify timestamps are event time, not batch-posting time.

Step 2, discover and check conformance. Discovery shows a main path and a loop in which orders return to Request Approval after a credit-check rejection. Conformance against the written procedure shows that some orders skip the credit check. The twin records this as a policy deviation, not a data error, after someone confirms the check is manually waived for key accounts.

Step 3, enhance. Mine arrival rates by hour, approval processing times and approver calendars. The log reveals that two of three approvers also run a weekly meeting that blocks mid-week mornings, which no process document mentions. This is the type of finding a purely modelled twin would miss.

Step 4, validate the simulator. Replay last quarter’s arrivals through the simulated process and compare simulated and observed waiting-time distributions. If the simulator’s median wait is far from the observed one, fix parameters before testing any scenario. Report a validation metric alongside every scenario result.

Step 5, run scenarios. Compare adding a fourth approver, delegating small high-trust orders to a rule, and moving the weekly meeting. Report the waiting-time distribution under each, with confidence intervals across replications, plus cost per scenario from cost rates in the organization model.

Step 6, decide and monitor. Suppose the delegation rule wins. After rollout, the twin watches conformance and waiting-time drift. If the real distribution diverges from the forecast, that is evidence the model missed a mechanism, such as approvers batching work, and it goes back into the loop.

The outcome of this example is a process, not a number: a validated model, a recorded set of assumptions and a monitoring signal. The verification and validation discipline for physical twins applies here too; see our write-up on digital twin verification and validation with uncertainty quantification.

Trade-offs, Gotchas, and What Goes Wrong

A digital twin of the organization fails more often from data and scoping problems than from modelling ones. The failure modes below recur across process-mining and simulation projects.

The log is not the process. Event logs record what systems captured. Work done by email, phone, spreadsheet or in a meeting is invisible, so a mined model of a clean-looking process can omit the hardest steps. Treat the log as a partial sensor, and validate the model with the people who do the work.

Simulation inherits mining’s blind spots. A simulator built from a log can only reproduce behaviour present in the log. It cannot predict a response to a change that has no precedent, such as people changing how they work once a new rule exists. This is the central limit of data-driven business process simulation: it extrapolates the past under stated assumptions, and the assumptions must be shown to decision makers.

Human behaviour is not stationary. Processing times depend on workload, fatigue and priority rules. Models that assume independent, identically distributed durations understate the variance, and queue behaviour is very sensitive to variance. Estimate durations conditional on load where the data allows, and test sensitivity.

Flattening reintroduces distortion. Teams adopt OCEL and then flatten everything to a single case notion for convenience, bringing back convergence and divergence. Flatten per question, record which object type you chose, and keep the object-centric log as the source of truth.

Concept drift. Processes change after reorganisations, software releases and policy updates. A model validated in March can be wrong by June. Version models, store fitness and precision per version, and schedule re-validation.

Privacy and surveillance risk. Event logs name individuals. A twin that ranks employees by speed is a surveillance tool, and in many jurisdictions it raises data-protection obligations. Pseudonymise resources, aggregate to roles where possible, agree the purpose with works councils or HR before deployment, and get legal review. This is not legal advice.

Scope creep toward “a model of everything”. Gartner’s definition covers any organization, but a useful twin covers one value stream with a stated decision in mind. Start with a decision (how many approvers, which shift pattern) and build the minimum model that can inform it.

Overconfident outputs. A single KPI value from one simulation run invites false precision. Report distributions, intervals and the validation gap, and show the assumptions list next to every chart.

Aspect	Process mining only	Process twin with simulation	Closed-loop DTO
Question answered	What happened and where it deviated	What would happen if we changed X	What should we change and apply it
Data need	Event log	Event log plus resources and calendars	Live events plus actuation interfaces
Main risk	Incomplete log	Unvalidated parameters	Unsafe automated change
Typical first step	Discovery and conformance	Validated DES model	Advisory mode with approval

Practical Recommendations

Build the twin in the order that exposes risk earliest. Begin with the log, because if the data cannot support identity, time and lifecycle, nothing downstream will rescue it. Then mine and check conformance, then enhance, then simulate, and only then consider coupling to live operations. At each step produce an artefact a business owner can review.

Choose the data format deliberately. If your processes involve many-to-many relations (orders and items, batches and lots, tickets and assets), adopt OCEL 2.0 as the log format and project onto case-centric views when a tool needs one. If your process is genuinely linear and your tools expect XES, XES remains adequate.

Anchor everything on a decision. A twin without a named decision owner and a named decision becomes a dashboard nobody opens. Write the question, the metric and the acceptable error before building.

Treat the model as a product. Version it, test it on held-out periods, publish its validation results and retire it when it fails. Link it into your wider twin estate through shared identifiers and an asset registry so the operational and process layers can be joined.

Launch checklist

Decision, owner and metric defined in one sentence.
Source systems and the event-reconstruction method documented, with deterministic event IDs.
Object identity mapping verified across systems.
Event time versus recording time separated, with a policy for back-dated entries.
Lifecycle and resource fields present, or the gap acknowledged.
Conformance fitness and precision recorded per model version.
Simulator validated against a held-out period, with replications and intervals.
Assumptions list published with every scenario result.
Resource data pseudonymised and purpose approved by the relevant owners.
Re-validation schedule and drift alarm in place.

Frequently Asked Questions

What is a digital twin of the organization?

Gartner defines it as a dynamic software model of any organization that relies on operational and other data. It represents how the organization runs, its current state, how it reacts to change, how resources are deployed and how value reaches customers. In practice it combines an operating model, event data from business systems and a simulation capability, so managers can test decisions in software before changing the real process.

How is a process twin different from a digital twin of the organization?

A process twin models the flow of work through one or more processes, using event logs, mined models and simulation. A digital twin of the organization is broader: it adds the organization’s resources, structure, rules, capacity and costs across many processes. Think of process twins as the building blocks. A DTO is realistic when several validated process twins share common objects, identifiers and an organization model.

What is an object-centric event log, and why does it matter?

An object-centric event log lets one event reference several objects, such as an order, an item and a delivery, instead of forcing each event into a single case. OCEL 2.0, published in 2024, also supports relations between objects, qualifiers and attributes that change over time, with SQLite, XML and JSON formats. It avoids duplicated events and distorted counts that case-centric logs produce in many-to-many processes.

Can process mining alone act as a digital twin?

Not by itself. Process mining discovers and checks how work actually ran, which is the data and model foundation. A twin additionally needs alignment with the live operation, an organization model of resources and rules, and a way to run forward-looking scenarios. Mining without simulation answers what happened; adding calibrated simulation and a feedback path to decisions is what makes it a twin.

Which tools should I use to build a process twin?

For a scripted, reproducible start, PM4Py handles XES and OCEL logs, discovery and conformance, and SimPy or Simod with Prosimos handle simulation. Commercial platforms such as Celonis provide enterprise connectors, an object-centric data model and governed access, which matters when extraction across many systems dominates the effort. Verify current features and licences yourself, as these products change quickly.

How accurate are business process simulations?

It depends on log quality, model validity and how stable the process is. There is no universal accuracy figure, and any vendor claim should be tested on your data. Validate by replaying a held-out period and comparing simulated with observed waiting-time distributions, run many replications, and report intervals. Simulations are most reliable for incremental changes, such as capacity, and least reliable for changes that alter human behaviour.

Digital Twin of the Organization and Process Twins: Process Mining, Simulation and Event Logs as Twin Data (2026)