James Taylor's Decision Management

Keith Swenson over at Go Flow had an interesting post this week - Decisions vs. Business Decisions in a Process. In it he discusses the challenges of decision nodes in BPMN diagrams and makes the great point that:

"In reality, those nodes don’t actually make decisions."

He is, of course, quite right. Those decision nodes are meant to represent something that can be decided by a piece of software in zero time and most business decisions are not like that (something I discussed before in this discussion on diamonds). Keith goes on to use an example of "An applicant with credit ratings below a certain value will not be eligible for loans over a certain magnitude” as suitable for a decision node. I would argue that the business decision here is, in fact, "applicant's credit is not good enough for loan requested", something that is clearly more complex than a decision node is designed to represent. While Keith feels that the “decision” was made when the rule was specified, I would argue that the business decision is going to be made for each transaction as it happens. Keith talks about "the execution of the rule simply branches the process based on that former parameterized decision in a completely mechanized way" but I think this is taking too much of a process-centric view.
The decision node is not really taking a decision, that's true, but the process requires that an actual decision be taken right then and in this example the decision about credit worthiness is, to use Keith's phrase "A real decision is the kind that is not easy to make".
So my point of view is that one should consider business decisions explicitly and then divide them into those we wish to automate and those we wish to refer. Managing the automation of some business decisions, typically high-volume operational ones, is a different but complementary approach to managing the automation of the processes that need those decisions made. Using business rules to act as the foundation, injecting insight into them with analytics, giving business users control of the rules and ensuring they are constantly refined and revisited is established as a way to do this, proven and easy to integrate with a process-centric view of the world.
Keith goes on to make some additional points. He says:

"While rules are very important in relieving us from the tedium of routine case assessments, there will never at time in the future be a point where we can stop adjusting and modifying the rules, and there will always be edge cases for which it will be quicker and more efficient to have a person simply 'decide'”

The fact that the way a decision is made must constantly evolve explains why decision management requires adaptive control to constantly check and refine how a decision is made. And there may well be some decisions that are easier to refer. But decision management technology allows far more of these decisions to be effectively automated - while still allowing the business to control how they are made - than is implied in Keith's discussion. Not all business decisions can and should be taken by people. Take credit card fraud detection. It has to be automated if it is to be done fast enough to matter. Take the decision to display a retention offer on a website - still a business decision, but an operational one taken in such high volume and short timeframes that it too must be automated.
I did like his phrase "Business Decision Activity" for a person making a decision, just like I like decision services for those that are automated. I discussed some of this in a post on BPM in 2007 and beyond (IDC). Finally he has a great quote:

"Good decisions come from experience … and experience comes from bad decisions."

This is, of course, why analytics matter. Bad decisions are recorded in the data in your systems. Using analytic techniques to make predictions from that data is how systems learn from experience.
BTW if you are interested in Blink, I reviewed it here.

Technorati Tags: BPMN, business rules, decision service, SOA