Celonis Technical Deep Dive

Directly-Follows Graph (DFG): The simplest model — nodes are activities, directed edges represent "A was directly followed by B." Edge weights show frequency or average time. Fast to compute, easy to understand, but doesn't capture concurrency or exclusive choices explicitly.

Petri Net: A formal mathematical model with places (circles) and transitions (rectangles) connected by arcs. Can express concurrency (AND-splits/joins) and exclusive choices (XOR). More expressive but harder to read. Discovery algorithms like the Alpha Miner, Inductive Miner, and Heuristic Miner produce Petri nets from event logs with varying noise tolerance and structural guarantees.

Use window functions with conditional aggregation or self-joins:

WITH events AS (SELECT case_id, vendor_id, activity, event_time FROM activities)
Join or use CASE WHEN activity = 'PO Created' THEN event_time END with MIN() and MAX() over case partitions. Then: AVG(DATEDIFF(day, po_time, payment_time)) grouped by vendor. In Celonis PQL this would be AVG(CALC_THROUGHPUT(CASE_START, CASE_END, DAYS)) with a dimension filter on vendor.

Process mining queries have very specific access patterns that differ from OLTP workloads: (1) Most queries aggregate over single columns (activities, timestamps) across billions of rows — columnar storage is dramatically faster than row storage for this. (2) Process-specific operations (variant detection, conformance checking, sequence analysis) require custom operators that don't exist in SQL. (3) In-memory storage eliminates disk I/O latency for interactive analytics. (4) The data model (event log) is append-only and analytical — optimized for reads, not transactional writes. A general-purpose RDBMS would be 10–100x slower and would require complex workarounds.

"Spaghetti" refers to process models that are visually incomprehensible — hundreds of crossing edges, activities connected in all directions — because real-world processes have many variants. It often occurs in O2C/P2P when you force multi-object processes into a single case ID. For example, if one Sales Order has 3 deliveries, flattening to case = Sales Order creates artificial event duplication (each delivery event appears 3 times), generating spurious paths. OCPM solves this by allowing events to belong to multiple objects simultaneously — the model stays interpretable because each object type has its own natural flow, and cross-object dependencies are shown explicitly rather than as tangled single-case paths.

Step 1 — Event Log: Extract AP payment process events (Invoice Received → Approved → Paid) with attributes: vendor, amount, approver, timestamp, payment method.
Step 2 — Conformance: Define the "normal" payment flow. Use conformance checking to flag cases that deviate (e.g., payment without GR, skipped approval step).
Step 3 — Anomaly Detection: Apply PQL ML operators to score each case by deviation from statistical norms — unusual payment amount, speed, vendor-approver pair, time-of-day.
Step 4 — Execution: Action Flows auto-route high-risk cases to a fraud review queue. Process Copilot pushes alerts to the AP team in real time. This is the full Celonis loop: Detect → Decide → Act.

Both are "Knowledge" functions for handling multi-value relationships in the data model.
KU() (Knowledge Unique): Used when each case maps to exactly ONE value (1:1 or many-to-1). E.g., each PO has one vendor → KU("EKKO"."LIFNR"). Returns a single scalar per case.
KM() (Knowledge Multiple): Used when a case can have multiple values (1:many or many:many). E.g., one PO with multiple line items across different cost centers → KM("EKPO"."KOSTL"). Returns a comma-separated string. If you use KU() on a many-valued column, it will pick an arbitrary value and silently lose data — a common bug.