Are Processes and Rules Two Separate Things

Mark Norton  3 January 2016 12:36:23 PM

In a recent blog, Ron Ross, who is a columnists for BPTrends, and therefore presumably aware of what process is all about, ends up making the following distinction:

"A major characteristic of the new digital world is that activity is never static in any sense of the word. You simply get no points for hardwiring repetitive behaviors. You must:
- Continuously make informed operational decisions in the blink of an eye (actually often faster
than that).
- Selectively respond to changing circumstances with subtle adjustments.
- Be as dynamic as possible, yet still produce outcomes of predictable, consistent quality.
These too are business rule problems, not process problems."

In effect, Ron is saying two things: First that processes describe static situations, and that Two, rules aren't a part of a process, but somehow separate from processes.

To my mind this is all wrong. It reflects that same bad thinking we find in Zachman's Framework that wants to separate things into little boxes, with rules in some boxes and processes in others. And, two, it represents the very unuseful thinking that we find in the Business Architecture Guild's approach, which suggests that processes are entirely defined by BPMN, and somehow define static things, while "value streams" are dynamic. And, incidentally, this goes very much against the grain of the OMG's efforts to establish a standard for Case Management.

My assumption is that Ross is feeling a little upset that a field that he's worked in for years has largely been subsummed into the business process field. From my perspective, after all, people do different things when they undertake activities, and one of them is that they make decisions (often using business rules). If you want to define what is done in a process or one of its activities, and what is done involves an activity, then you need to understand how the decision is made. In our process courses, we urge people to define the rules used in the decision. It's just one more tool in the process analysts tool kit.

I'd be interested in the views of others on this discussion group.

IDIOM Response

Hi Paul,

I am with Ron on this one. There are only 2 steps in a process - the current one, and the best-next one. And you can only determine the best-next one when you have completed the current one, because the current one might change the best next one. IDIOM calls this BinaryBPM.

So Ron is right in my view, there are no points for hardwiring process patterns.

A process is a real-time, rules driven orchestration of activities that is only visible in hindsight. It emerges based on the current state of the data, the rules, and the available activities, all of which can change independently, and all of which can have different owners. Think GPS managed navigation, not train tracks and bus routes!

The rules that determine best-next are fluid and responsive to organizational learning. They are the heart of the learning organisation, and have an existence quite separate from the activities, and from the processes that emerge.

Regards,

Mark

• Comments [0]