Introducing a new white paper: The Five Categories of Operational Decisions and their Impacts on Business Process Models

Business processes should enforce compliance to operational, legal and risk objectives. Yet how can one be assured that their processes are compliant? Increasingly, the best practices is to use a combination of business process modeling with a business rules approach- the operational decision (OD) approach. These frequently occurring, repeatable decisions are key to enforcing compliance.

A combination of BPM, OD and event processing can create comprehensive, agile solutions in many problem domains. In a new white paper from Bosch Software Innovations, we explain the role and interrelationships of these different visual modeling approaches. Most process modeling methods parse directly requirements into BPMN process elements. They incorporate with workflow patterns. There are alternate approaches that start with business rules and Bosch Software Innovations can support either. This white paper discusses how to develop processes requirements from a business rules perspective. Starting with this definition of a business process:

A business processes is an organized, coordinated flow of activities, conducted by participants, acting on and deciding with data, information, and knowledge, to achieve a business goal[1].

We can design a digitized business process based on business rules that describe the means of compliance, operational controls and risk mitigation[1]. So, from the perspective of the business process as per Ron Ross:

“A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or influence the behavior of the business.”[2]

The objective is the digitized process so the rules are expressed in executable, directed graphs and decision tables. When we design processes, we are defining the behavior of the business, so that processes comply with business rules by making operational decisions—a rules-compliant process.  

Operational decisions are frequently occurring, repeatable decisions that implement the compliance, operation and risk controls. They are settled with process data and evaluated by digitized business rules. So a business rule is an atomic logic step that uses data and knowledge to evaluate a part of a proposition about a process decision³.

 In a BPM/Business Rules approach, processes are activated by business events. Chandy and Schulte[3] define a business event as:

”A business event is an event that is meaningful for conducting commercial, industrial, and governmental or trade activities.”

The differences between process, rules and business events are simple; rules are overarching, stateless directors of behavior, processes are stateful responders to the directives, and external business events, are detected and processed.

The recent research of Martijn Zoet, Richard Welke, et al found that business managers expect business rules to govern and control business operations with on five concepts:

1. Rules should influence, order or sequence a process’ tasks, decisions and internal events
2. Rules should influence and decide who is included in and assigned to a task
3. Rules should influence and decide what course of action is taken
4. Rules should influence and decide what data is retained, its validity, and duration and
5. Rules should detect, control, and respond to events

When they are dynamic or controlled in a BRMS, these five concepts are categories of operational decisions. Static elements become elements of a business process map or diagram—transitions, activities and gateways. We described five different ways that a decision’s outcome can direct the pathways of the process. As a nexus for governance, risk and regulatory compliance, the process decision is both an important management concept and a strategic design tool for achieving business objectives and goals.

Our new white paper clearly demonstrates how the 5 categories of decisions create processes that are compliant with the operational, compliance and risk management objectives. We lay out an effective design method that recognizes that process behavior considers decision-generated events. Also, from a single operational decision, events and data can trigger and control many aspects of a business processes.

The figure below depicts these 5 categories:

The Bosch Software Enterprise Platform provides a powerful design environment that simplifies management control of business processes. The result of separating processes from rules stabilizes business processes and permits operational decisions to change without having to change the process application. Understanding the five operational decision categories simplifies the choice of what should be a dynamic operational decisions supported by business rules and what should be a static part of the process. The white paper presents approaches for deciding what should be an operational decision (business rule) and what should be on the BPMN process diagram (gateways and conditions).

You can download the complete white paper here:

---

[1] Martijn Zoet, Richard Welke, et al, ‘Aligning Risk Management and Compliance Considerations with Business Process Development’, Springer-Verlag, Berlin Heidelberg 2009

[2]Business Rules Group, Defining Business Rules ~ What Are They Really?, www.businessrulesgroup.org

[3] K.Chandy, R. Schulte, Event Processing: Designing IT Systems for Agile Companies, McGraw-Hill Osborne Media, 2009

---

[1] The Microguide to Process Modeling in BPMN 2.0, Debevoise, Geneva and Welke, Advanced Component Research, 2010

Decision Tables and Issues with the Decision Model

At  Bosch Software Innovations I have posted several posts on decision tables: here and here:

I ask the questions the proposition: can (or should) Decision Tables be used as in a pseudo-relational manner?

In the second part of the series I post that there is a theoretical breakdown of decision models purely based on Decision Tables.  Decision Tables are a useful and powerful metaphor for some aspects of decision modeling. But overuse can create serious issues when it is time to digitize the model.

The suggested existence of the relations or (inferancing relations) between tables asserts that there is a well formed function that can connect these. This is evident when the predicates are pure data types; however, decision tables can contain functions, such as the functions common to decision tables the relations break down.

My regular readers will know that I am taking aim at the Decision Model Approach. We are now working with a number of clients to 'Fix' there radically flawed and unstable models that have been built this way.  

My central issue with the decision model approach is that, events and process become buried in the approach. Our recent experiences prove this.

- Tom Debevoise

Unpacking Decision Management: A Changing Landscape

There is an excellent recent review of knowledge management as written by Fahmi Ibrahim (here). I was struck by the parallels between KM and business rules, so I 'borrowed' his conclusions and mapped them to my understanding of the business rules industry.

Criticisms	Key Points
Poor Conceptual Understanding	The vast majority of the business rules literature (1)(2)(3)(4) and products are built on the assumption that business rules should be expressed as a linguistic, symbolic or interpreted evaluation of facts. However, the characteristics of this approach make it difficult to create, control and manage changes (5)(6). The alternate approach views business rules as a set of sequential sequence of logic that categorize, compares, computes and controls a business decision or direction. Many organizations have successfully implemented both approaches.
Lack of Common Framework	In reviewing the literature and standards, business rules and the business rules approach lacks a common framework and there is no consensus of a working definition of either. Commercial software focuses on IT infrastructure. In the OMG standard there is the semantic business rules vocabulary (SBRV). SVBR has very little to do with the needs of IT operations. Consequently, the business rules are misunderstood and underutilized, especially in rules intensive-areas such as health care, logistics, risk management and finance,
“Rebottled Old Wine‟	Many products employed expert systems that were developed over 3-decades ago to solve unrelated AI problems. Other approaches evolved from the limitations of the relational data bases (7)(8). The result is that the definition of business rules and business decisions is too narrow and will not encompass the evolving event driven infrastructures of tomorrow.
Bandwagon Effect	In the last 10 years, many companies jumped onto the rules bandwagon without understanding the meaning and implications of expert systems, fact-based modeling, or vocabulary approaches. In fact, many companies became bogged down in analysis paralysis and endless ‘death by meeting’.
Success or Failure	The business rules approach has delivered significant results but the success rate is mixed. There are many examples of organizations which have successfully implemented BRA. Yet anecdotally, we encounter initiatives will fail to have significant results. Like knowledge management, some have declared that BRA is a fad without real business benefits.
Value and Measurement	While business rules are widely recognized as a valuable metaphor for controlling business results there is little understanding of how to manage these.

I think business rules should support an expanded view of business rules in the enterprise-one that encompasses and moves beyond supporting a process decision (or endless meetings that might make that someday). New metaphors, especially events, are on the horizon. As with every method, the complexity of the situation will significantly expand. To survive, the business rules approaches should reduce complexity and increase transparency with today's model-driven approaches.

Business Rules Requirements in the Real World

In a recent blog post on the requirement network group, Chris Kosba posed a question concerning the role of 'business rules' in requirements gathering activities. Again, this raises a common misconception about requirements and business rules.

I agree that it is necessary to know when your requirement is supporting a business decision through rules. To approach this issue, we need to meet the eternal question: what problem are we trying to solve? As messy as the requirements page in Wikipedia is, the meaning is pretty concise -a requirement is a singular documented need of what a particular product or service should be or perform.

If our requirement is that we should support the business rules, as defined by the business operations, (i.e. credit risk rating) then it is usually useless to document these business rules in requirements elicitation. The business rules are the data that drive the system. Documenting these rules would be equivalent to defining an employee database then defining the instances of employees in the tables. We know our employee table needs columns of first name, last name and middle initial. This is a requirement. Is it a requirement that the table organize the records "John A. Smith, Bob H. Jones, and Sally L. Quill"?

If your system requires that business rules be supported by BRMS then, business rules should be visually expressed as truth tables or logic trees. The truth table is a two-dimensional indication of conditions and conclusions. In Visual Rules, we call the logic tree a rule flow. In the real world, we often run into application requirements that are stored in spread sheets with logic that flows from worksheet to worksheet. Often, there are many tabs with dozens, if not hundreds, of lines of logic. We especially see this in score cards for probability of default (PD) models. These spread sheets can be converted into a visual model with the Visual Rules approach.

If the requirements documents show too many business rules, or business rules that should be in a BRMS, then they will become unnecessarily complicated.