Pretty big. Processes don't change near as often as business rules and there's nothing logical about business rules.
I'm not sure, but I do wonder if the proliferation of modeling notations (BPMN, CMMN, DMN) is getting us closer or further from the goal of being able to describe the businessin a comprehensible way rather than code the business in an incomprehensible way.
I think Decision Management will be huge.
If anything, in a digital enterprise, the business decision will be the single most expensive business activity, as it will mostly be done by humans after all relevant information and events have been processed and exposed by machines. So the focus will eventually move towards enhancing the relevance and timeliness (and therefore lowering the cost) of decisions.
That being said, DMN is a partial step. As I was commenting on Bruce's blog, I FEEL (pun intended) the notation is a bit too lax and I'm afraid that widespread adoption will be accompanied by widespread confusion and 'forking'.
Our experience is that there are three benefits for managing decisions as well as process:
While I have some sympathy for the multiple notation comment my experience is that this is an issue only for consultants. Most teams rapidly identify one or the other aspect as the key one for them and really use that notation day to day.
Links to a white paper and a video below.
It should play important role indeed.
Yet my personal practice so far was slightly disappointing: I find myself more often in the position of business rules evangelist - explaining the value to a prospect or customer - than answering their requests.
The current hype around DMN is a good thing as it may help rules/DM solutions attract more customers' attention.
I think it depends on which school you went to ... or a version thereof.
I wrote a paper for Pega way back in, I think 2005, entitled "Rules are from Mars, Processes from Venus" (it might have been the other way around), when I pointed out that they were just different approaches for handling complexity and change, and that they were better off together. Two sides of the same coin.
Now here I am exploring the DMN space - wishing I had been able to get to BPMNext this year (waving Hello to Nathaniel, Bruce, Neil, Clay and others).
It's clear that things have moved on significantly from that point in 2005 when most BPM customers preferred pretty simple rules that could be embedded in processes. Now we can expose those process decision points to robust representations of the rules in a standard way, but there are new levels of complexity for organisations to master.
"...should..." "'...will..." Does! I was smiling as I read some responses.
Decisions are intricately linked in process, whether you model them separately, they are manual, or you comingle decisions in your process
The question is open to decision management in process management. The article is about, as Bruce is, notation and modeling.
I was going to quote James until I saw he responded. Decisions to be considered are Valuable. Good ones can make or save you money.
And, to be clear, Processes are often much simpler when the decisions are analyzed & designed first.
Many have mentioned the different frequency change cycles. It is a consideration of the outcomes that really highlights how big of a role they have.
Apply for a loan, a policy or an account. Who are you? is the app valid yet? Credit? Level? Trust? Eligibility? Promotions? Pricing?
Next process step...
Most of the Business is in the decisions. Process just ties the Decisions together!
(now let's aggregate the events, decisions and actions, analyze them and create a cognitive framework for changing the decisions. More Value.)
A BPMN process diagram for a simple service escalation should be a standard use case for sales and demos. Common need, well understood. And yet when presented to management, your intuitively simple service escalation too often (for various reasons including product limitations and/or SE training) turns into high complexity spaghetti -- and you just lost a sale.
Why not go low-carb? Add decisioning to your recipe (even without DMN), where escalation rules are abstracted out to a table or other interface, and the resulting artifacts are much simpler, with much greater clarity. And management can see how parameterized rules can now be easily evolved.
Process and rules are complementary concepts for the modeling of work, with enough semantic distinction to warrant separate modeling notations. That's the theory; the result is better automation artifacts, faster, and better saleability too. Go DMN!
Frankly if your BPM supporting software does not support good decision making processes you are out of date before you start. It's is all about having real time data presented to the right person at the right time in the friendly format that supports good decisions. Collaboration of information across the organisation needs to be supported and of course a full audit trail also needed. We already see with in built rules you can build in automation of decision making following the desired logic. In built flexibility to quickly change processes also essential as inevitably decisions will often highlight better ways....?
Ultimately, in any process there is a decision to be taken, i.e. which activity has to be started. So, the decision management is very important for BPM. Now, the next set of questions: how many decision techniques are necessary (DMN is only one of them), are they explicit, are they machine-executable, are they understandable for the business, and can they work together?