Organizational Mining: Unified Process Analysis

• Organizational Mining Feature is a unified framework integrating multilevel and object-centric paradigms to analyze workflows and interactions across diverse organizational entities.
• It employs recursive case construction and bridge relations to consolidate multi-level event logs into distortion-free, color-coded process graphs that reveal causal relationships.
• Leveraging SQL-accelerated data processing and automated log parsing, it enhances scalability and operational efficiency in ERP, compliance, and cross-department analyses.

An organizational mining feature enables process mining tools to discover, analyze, and visualize workflows and interactions spanning multiple organizational entities—such as people, roles, business objects, or cross-functional teams—across various levels of abstraction. Recent academic and industrial advances have focused on unifying multilevel and object-centric paradigms, with IBM’s Organizational Mining serving as a distinct instantiation that synthesizes the best aspects of both Multilevel Process Mining (MLPM) and Object-Centric Process Mining (OCPM) (Ronzoni et al., 3 Dec 2025).

1. Formal Definitions and Core Artifacts

Organizational mining relies on the integration of multi-entity, multi-level event data. In the MLPM formalism, the data foundation is the multilevel event log:

$$L_{ML} = \bigl(E,\,A,\,P,\,ID,\,\pi_{act},\,\pi_{time},\,\{\pi_{pid}^p\}_{p\in P},\,B\bigr)$$

where:

• $E$: Finite event set.
• $A$: Set of activity labels.
• $P = \langle P_1,\dots,P_k \rangle$: Ordered sequence of entity types (ProcessID types).
• $ID = \bigcup_{i=1}^k ID_i$: Disjoint identifier domains for each level.
• $\pi_{act}$, $\pi_{time}$: Activity and timestamp functions.
• $\pi_{pid}^p: E \to ID_p \cup \{\bot\}$: Maps each event to relevant ProcessIDs at levels $p$.
• $B \subseteq E \times E$: "Bridge" relations linking events across entity levels, enabling correct assignment of events to multilevel cases.

This formalism allows an event to carry up to two non-$E$0 ProcessID values: a "native" entity, and a possible bridge to another entity level.

2. Case Construction and Assignment Mechanism

Case discovery in multilevel event logs is recursive. For each highest-level entity $E$1, a case is formed by chaining all related events across lower entity levels via bridge relations. Formally:

1. Base cases: $E$2.
2. Recursive chaining: For $E$3,

$E$4

1. Full case: The union $E$5.

The case-mapping function $E$6 assigns events to cases, allowing proper deduplication of bridge events for downstream statistics.

3. Architecture, Workflow, and Algorithms

Organizational mining in the IBM implementation comprises three main phases:

1. Data preparation and log parsing: Assign $E$7 and construct $E$8.
2. Case composition: Chain ProcessIDs via bridges recursively.
3. Model discovery: Extended α-style mining generates a unified process graph $E$9, with vertices representing activities and edges computed by a causal strength metric:

$A$0

Edges are retained above a threshold, yielding a single, color-coded, end-to-end process graph.

The workload is SQL-accelerated; event log storage, parsing, and computation utilize window functions and bitmap indexes in a relational schema.

4. Comparative Analysis: Multilevel vs. Object-Centric Paradigms

Organizational mining was designed to unify the strengths of both MLPM and OCPM:

Aspect	Multilevel PM	Object-Centric PM
Case notion	Recursive chaining of entity levels	No “case”; events may involve multiple objects
Data model	Flat event table with ProcessID columns/bridges	Event log + object tables per type (OCEL)
Model output	Unified process graph, colored by entity	Object-centric Petri nets, BPMN, causal nets
Statistics	Deduplication by merged events in cases	Cross-object metrics via multisets of object links
Conformance	Deviation in any entity fails entire case	Checks per object or link
Scalability	Scales via SQL, challenged by deep/horizontal chains	Heavy for many-to-many; optimized in object-centric libs
Use cases	End-to-end, cross-entity workflows	Multi-process, ad hoc, cross-object analytics
Limitation	May obscure intra-entity subprocesses	Lacks unified cross-object KPIs

The objective of organizational mining is to retain unified, distortion-free end-to-end graphs and accurate statistics of MLPM, while leveraging OCPM’s relational, flexible data modeling and preparation pipelines.

5. Illustrative Example and Empirical Characteristics

Consider a process with hierarchical entities: Order ($A$1), Receipt ($A$2), Invoice ($A$3). In the provided example:

• The raw log shows bridge events linking Receipts to a single Invoice.
• The case chaining algorithm collapses 11 event rows into 10 unique events in the process model, correctly merging duplicate events from cross-links.
• Entity statistics per case are deduplicated: $A$4.
• Throughput time between activities such as "Order Creation" and "Goods Receipt Confirmed" is computed by path enumeration within chained cases.

This ensures no artificial inflation or event duplication across levels, a requirement unmet by prior non-unified approaches.

6. Evolution into Organizational Mining: Productization and Improvements

Based on limitations identified in MLPM—such as scalability with increased entity levels/fan-out, laborious log preparation, and conformance criteria being overly rigid—IBM evolved the framework into the Organizational Mining feature:

• Retains: mathematically rigorous, unified model and correct statistics from MLPM.
• Incorporates: object-centric, relational storage and event log architecture from OCPM, avoiding manual flattening.
• Automates: log parsing, path discovery, and cross-log correlation using SQL metadata.
• Enhances: performance on large, distributed datasets (via NextGen engine) and enables simplified data preparation and cross-process analytics.

7. Practical Implications, Use Cases, and Best Practices

Organizational mining is best suited for processes that require seamless, end-to-end visibility across multiple organizational units or business object types, such as Procure-to-Pay, Order-to-Cash in ERP scenarios, and compliance monitoring spanning departments. Key operational guidelines include:

• Define clear entity ordering from highest to lowest level.
• Ensure each event captures only its direct and (optionally) bridge entity IDs.
• Explicitly tag bridge events during ETL or log extraction.
• Leverage relational indexes and SQL-based filtering to optimize scalability.
• Configure throughput-time calculations carefully in the presence of repeated events for the same entity.

This unification effectively delivers a distortion-free, explainable, and scalable view of organizational workflows, supporting both operational efficiency and regulatory compliance (Ronzoni et al., 3 Dec 2025).