Summary. This post introduces the notion of process atoms, small facts or queries, each describing an organizationally relevant property or constraint of a business process that cannot be further split without losing its business meaning. An example of a process atom is: “only if an order with a purchase amount greater than 10,000€ is requested, management approval has to take place afterwards” (more abstractly: “if A then eventually B”). As process atoms are executable as queries on data and allow for dynamic contextualization across process and organizational contexts, they complement and augment traditional process models, such as BPMN diagrams, particularly in the era of data-driven process analysis and AI-generated process content.

Introduction 

Business process management is a discipline undergoing continuous change; progress is particularly fast-paced regarding software support. While the 2000s have seen the rise of model-driven development, cumulating in the emergence of open standards such as Business Model and Notation (BPMN) and (later) Decision Model and Notation (DMN), during the 2010s the focus switched to data-driven process analysis approaches such as process mining; moving beyond that, current trends are the facilitation of enacted process change based on obtained analysis results (from insight to action) and the lowering of the entry hurdles to advanced modeling and analysis tasks by utilizing generative AI approaches. 

Process modeling paradigms must also adjust with the evolution of business process management tasks and objectives. Here, a classical question is whether to use imperative or declarative models for a given task: 

• Imperative models are supposed to specify exactly how a process runs, providing step-by-step instructions on how to run it. In practice, this typically means that the process model is overly strict, as the level of precision is rarely high enough to account for all edge cases. The arguably most popular language for imperative process models is BPMN. Still, few organizations cover the chasm between a diagram informing the executors of a process what (approximately) is expected next and the suitable working operating procedures which inform them how (exactly) this task is to be performed. 
• Declarative models specify constraints a process should satisfy, i.e., they define a space of allowed process executions by stipulating rules that the execution must not violate, or goals that the execution must achieve. The idea behind declarative approaches is to focus on what matters and otherwise allow for autonomy during process execution. There is no lingua franca for declarative process models. Still, the technology ecosystem is vibrant, comprising standardized notations Case Management Model and Notation (CMMN) and academic projects such as DECLARE (an abstraction on top of linear temporal logic for finite traces). Also, structured query languages for querying process data, such as SAP Signavio’s SIGNAL language, can be considered tools for creating declarative models of business processes that are then executed on process data. 

In the era of model-driven development, when process execution engines were expected to be the ultimate bridges between business and IT, the focus was on imperative models – the corresponding hope was that business users would easily maintain these models, alleviating the traditional communication overhead at the business-IT gap. The dream of business user-friendly model-driven development of information systems has not fully materialized: few organizations manage to do this at a high maturity level, and for the ones who manage, it incurs substantial costs and requires high expertise levels, e.g., in technical modeling skills among business (process) analysts. Still, imperative models are important, and frequently used to provide a broad, approximate specification of an actual or future state process, often for human consumption or social proof of compliance and not for direct deployment. In contrast, declarative approaches play a crucial role in the data-driven era of business process management, most notably in the form of query languages. Here, an industry assumption is that imperative models are – at least without further manipulation — not particularly useful for data analysis: they are often overly specific (too strict) and not easily executable by symbolic data management systems, such as traditional relational databases or OLAP-style data warehouses that utilize structured query languages. Crucially, this renders imperative model not organically suitable for cross-organizational comparative analysis (e.g., in a benchmarking context). 

Now, considering that imperative models are the lingua franca of human-centric BPM, whereas declarative models (queries) are what typically enables data-driven BPM, the question is how the two approaches can be fused in sufficiently elegant, yet practicable manner: imperative model provide a broad, high-level description that is somewhat intuitive for human experts, but typically neither precise on a technical process data-level, nor easily portable to different context; this shortcoming can be addressed by augmenting imperative models with the most crucial facts about a process in a manner that is precise yet re-usable across process contexts and organizations. In this write-up, we argue that such a fusion can be achieved by introducing process atoms, facts about a business process that are minimal in the sense that splitting them further would obfuscate their business meaning (analogously to the notion of a propositional atom in logics). We introduce process atoms conceptually and using practical examples, lay out the role process atoms are expected to play in AI-augmented business process management, and discuss challenges and open questions that need to be addressed to scale the usage of process atoms. 

What are Process Atoms? 

Conceptually, process atoms are statements about a process or instance thereof that have a specific organizational meaning and that cannot be split into further statements without losing the connection to an overarching organizational objective. Hence, process atoms are already prevalent in business process analysis software, for example, as metrics in the SAP Signavio Process intelligence metric library or as standard performance indicators in SAP Signavio Process Insights. 

The figure below shows the interplay between process atoms and an imperative process model. We have a credit quote creation process, modeled as a simple BPMN diagram. The diagram’s control flow covers the happy path, in which standard conditions apply, and one variant, in which special terms need to be prepared. Given a case that follows the happy path, we see that two active process atoms are highlighted that apply to the corresponding variant: 

• “calculate terms has to occur within 48h after review request if standard terms are applicable” (red); 
• “send quote has to occur within 12h after prepare contract” (green). 

In contrast, the process atom “special terms must only be prepared for contract volume > 100k” is inactive, as this atom is not tracked and/or enforced by the process variant that applies. 

Process atoms as overlays over a BPMN diagram.

More technically, process atoms are concise constraints that relay a business purpose that cannot be split into smaller, yet meaningful parts. A process atom describes activity behavior that occurs in a process or relates several (then typically two) behaviors using a logical operator, e.g., to specify a temporal relationship. In this context, a behavior description can be considered a filter of the activities that can occur. For example, we may specify that we identify all approvals for cases that exceed a certain purchase amount. The notion of a behavior is derived from process data query languages, particularly SIGNAL, the SAP Signavio Analytics Query Language. Below, we illustrate how a SIGNAL query can be broken down into process atoms (the query is an example provided in the SIGNAL technical report): 

SELECT case_id FROM THIS_PROCESS
WHERE BEHAVIOUR (event_name = 'Close ticket' AND "status" = 'blocked')) as closed_while_blocked
MATCHES(closed_while_blocked ∼> 'Open ticket') 

We can break down this query into two process atoms and a process context: 

• The assignment of (event_name = 'Close ticket' AND "status" = 'blocked') to closed_while_blocked is our first process atom; the behavior in itself is an abstraction and can be used for process analysis: arguably, tickets should ideally not be closed while blocked but be first resolved and then closed. 
• Our second process atom is the temporal constraint closed_while_blocked ∼> 'Open ticket'. 
• THIS_PROCESS is our process context, abstracted aways in the example query, as the system maintains the reference to the event log. 

Intuitively, it may be subjective whether a matching subquery is atomic in the sense of the process atom notion or can be split further. As mentioned before a ‘only if A then B’ statement (equivalence) can be split into two implications (‘if A then B’ and ‘if B then A before B’) but the abstraction level is likely too low from an application perspective. Similarly, one could argue that our example query should contain only one process atom: perhaps, a business analyst should only be interested in ‘closed while blocked’ behavior if it leads to additional work (i.e., the re-opening of the ticket) down the line. 

Process Atoms and the Future of Business Process Management 

We expect that in the future, process atoms will play a crucial role in business process management as pragmatic bridges between knowledge and data. For example: 

• Process atoms can be auto-extracted from process model collections to contextualize them in process data analyses, where they can be directly executed on the available data. 
• Generative AI approaches can automatically generate process atoms from unstructured process document artifacts, such as text documents or slide shows, independently of the exact representation format. 
• On the other hand, plausible process atoms can be inferred from collections of process event logs, e.g., of the same process running at different organizations; here, the satisfaction or violation of a particular process atom can be tied to particularly good or bad business performance. A simpler special case of this scenario is the extraction of process atoms from a single event log, analogously to how imperative process diagrams can be discovered. 
• Process atoms can be recommended to process analysts based on a particular data, organization, and process domain context to be evaluated and refined with human experts in the loop. 
• Non-compliance with particular process atoms can be tied to root causes and types thereof, such as data quality issues and lack of process discipline. From a more fine-grained perspective, particular actions to ensure future compliance can be triggered. These action triggers can be based on hard-coded knowledge initially; eventually, gathering process data, IT system configurations, and models across organizations can help automatically identify the actions required to reach compliance. Then, the corresponding process atoms may express classical Boolean constraints (either satisfied or violated), or represent nuanced quantitative objectives, e.g., compliance with a set of target process performance indicators. 

None of the above scenarios can be achieved with traditional imperative process model alone; instead, they require small, concise constraints that can be moved around, contextualized, and evaluated as independent units. Hence, we claim that process atoms are a crucial foundation of our Large Process Model vision of business process management in the age of generative AI. 

Challenges 

Let us argue that already now, process atoms are to some extent a reality in modern business process management software. For example, some vendors of data-driven business process management software (e.g., of process mining tools) maintain so-called metric libraries of query templates that allow analysts to produce the most relevant aggregations on a set of process data, such as cycle time or failure rate, with the click of a button. Still, the following questions need answering to elevate process atoms to first-class citizens of business process modeling. 

• How to best model process atoms?
  From a technical perspective, it intuitively makes sense to see process atoms as queries (typically on data, but potentially also on knowledge). Then, process atoms can be expressed in traditional query languages such as SQL and domain-specific languages for process data querying, such as SIGNAL or PQL. However, these languages do not necessarily provide intuitive abstractions for business users. The questions of how to best design these abstractions at the right abstraction level for process atoms as business user-centric artifacts remain to be answered. 
• How to best manage process atoms?
  We expect hundreds of thousands of process atoms to be created based on best practice knowledge and benchmarks. In addition, customers may (auto)-generate thousands of process atoms themselves. This raises the question of how such large collections of process atoms (large as in Large Process Model) should be managed. Here, it may make sense to distinguish between crucially important process atoms that provide substantial business value in small collections and hence warrant careful manual maintenance and process atoms that are entirely auto-generated (e.g., mined from structured process models or unstructured process documentation artifacts) and whose value has not been proven, yet. The latter process atoms may be managed entirely automatically, disregarding nuance, until they can be tied to practically useful insights or actions. This triggers the transfer of process atoms from the latter set into the former. Still, the details of how to realize this dual management approach and lifecycle require further investigation. 
• How to best integrate process atoms with existing modeling approaches?
  Process atoms are not meant to replace existing process modeling and querying approaches but augment them. The example figure shows a basic intuition of how process atoms can be mapped to graphical business process models, such as BPMN diagrams. However, it is not yet clear how exactly process atoms can be integrated into such models on the one hand and into visualizations of process data on the other. Ideally, process atoms help bridge the gap between classical process models and data visualizations. For example, given a BPMN diagram and a process atom-based conformance analysis of process data, the process atoms that are most interesting in the context of the analysis results can be highlighted in the diagram, augmented with quantitative information about the conformance rate as well as relevant case attributes affecting conformance (e.g., region or other attributes that help identify process variants). 

Conclusion 

This post has introduced the notion of process atoms – facts or queries about a business process that carry a minimal (atomic) business meaning. We expect process atoms to play a major role in the era of AI-augmented business process management, as they bridge the gap between imperative and declarative models and allow for the ad-hoc contextualization of process knowledge as queries on event logs, databases, and system configurations, thus making knowledge actionable.