When designing business processes solely by using process notation languages like business process model and notation (BPMN), I often feel a little uneasy. Some simple details caused my models to be far more complex than expected. Some other important facts could not be expressed simply and resulted in spaghetti notation. Finally, supposedly simple business processes resulted in complex drawings that were difficult to manage and maintain. The question arose: Why?
Limited scope of process notations
In fact, if you look closely at business processes it becomes obvious that their definitions comprise information that can be divided into three different categories: (1) procedural, (2) declarative, and (3) structural. The procedural aspects determine the order of steps (tasks, events, and gateways) that are needed to achieve the relevant process goals. This is comparable with algorithms or operating instructions. For example, standard procedures and routine operations in hospitals (plaster bandages, jabs, or appendectomy) are candidates for procedural descriptions. In the context of business process management (BPM), process notations are well suited for depicting this kind of information in an appropriate way.
How to deal with declarative aspects
Usually, processes are also based on declarative elements like complex decisions, relationships between variables, or data constraints. This information is expressed using business rules and some kind of functional or logical language. Thereby, business rule management (BRM) just declares the significant facts. It does not specify the computation steps or algorithms for the evaluation of the decisions, relationships, and constraints. As opposed to the procedural aspects, it is awkward and makes no sense to express these declarative aspects with the means of process notations. Moreover, the resulting models are difficult to write and to understand.
In the medical environment, basic knowledge like dosages, side effects, or inferences is declarative. Most BRM systems bring along their own rule modeling language (decision trees, decision tables, or even formalized natural language descriptions). Besides, there are standardization efforts like Semantics of Business Vocabulary and Business Rules (SBVR) and Decision Modeling and Notation (DMN) that have been adopted by the Object Management Group (OMG).
Unpredictable processes need structural information
In the hospital, another aspect becomes visible: emergency situations, for example, involve complicated processes like heart transplantations. It is nearly impossible to define such processes in advance because they are highly unpredictable and would have to provide for all contingencies. This does not mean that there are no standard processes or rules at all. On the contrary, they exist and must be combined in a very flexible way. It has been shown that many business processes in various industrial sectors have similar demands. This leads to the third aspect of process modeling: structural information. It determines the underlying structure of the individual process fragments, ad-hoc activities, and additional elements (e.g. documents).
This kind of information resembles templates that list the most common parts and must be complemented and adapted to concrete situations. The so-called adaptive (or dynamic) case management (ACM) is based on this mechanism. Apart from ad-hoc sub-processes in BPMN 2.0 with a rather limited scope, there is no commonly agreed standard notation for ACM. So, all existing tools use proprietary extensions or vendor-specific languages for defining ACM templates. Fortunately, early standardization attempts in the context of ACM are available like Case Management Process Modeling (CMPM), a “Request for Proposal” of OMG.
Combining BPM, BRM, and ACM
I am convinced that a sound handling of these three kinds of information would have made my models much clearer and easier to understand. As a result, I suggest using common process notations for procedural, BRM for declarative, and ACM for structural aspects of the business processes. On the other hand, this advice presumes that both business rules and adaptive cases are supported by the BPM suite. Furthermore, they must be seamlessly integrated with the process models. So, it is essential to consider these requirements early when choosing the right BPM product for your organization.