Resolved
4 votes

As Bruce Silver wrote about last week's bpmNEXT: "One highlight for me was the rapid pace of progress in DMN implementation." So how big of a role do you see Decision Management playing in the future of BPM?

Tuesday, April 26 2016, 09:50 AM
Share this post:
Responses (11)
  • Accepted Answer

    Tuesday, April 26 2016, 09:54 AM - #Permalink
    Resolved
    5 votes

    Pretty big. Processes don't change near as often as business rules and there's nothing logical about business rules.

    • Patrick Lujan
      more than a month ago
      I really should include a hyperlink here to one of my own blog posts from 2014, but nahhhh.... ;)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 10:03 AM - #Permalink
    Resolved
    4 votes
    Decisions have been taken in processes since billions of years, so the answer is always yes.
     
    But, this question is from a technical point of view and in that case I agree with Patrick. It's always smart to keep things that change at a different frequency separated from each other from an adaptability standpoint.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 10:09 AM - #Permalink
    Resolved
    5 votes

    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.

     

    • Patrick Lujan
      more than a month ago
      It's about brevity. Modeling notations' usage, like Agile documentation, should be to "the necessary degree of understanding."
    • E Scott Menter
      more than a month ago
      Yeah, this is a very good point. We're conflating two matters: one, the problem itself, which is to say, how to develop techniques for overcoming business challenges. Second, the meta problem—how do we standardize our language for doing so?

      The meta problem is not unimportant, but we cannot sacrifice the essential goal on the altar of notation and standardization.

      Cart ⇄ Horse and all that.
    • karl walter keirstead
      more than a month ago
      Further
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 10:19 AM - #Permalink
    Resolved
    6 votes

    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'.

    • Patrick Lujan
      more than a month ago
      No better, no worse, no different than anything else - "How much is enough?" will vary from one project, one client to the next. [shrug]
    • Bogdan Nafornita
      more than a month ago
      I agree, still we might be missing one of the purposes of the notation standards, which is... standardization?

      I for one started out very enthusiastically with DMN tables, only to find very quickly that you can only execute extremely simple stuff with them. Anything else requires extra coding, not easily done in FEEL. So... must use multiple scripting languages...? What's the point?

      Another example: my client loves to be able to edit decisions tables in the portal, but iterating those tables according to DMN requires MI sub-processes in BPMN that contain the decision table... what?? I'll have a tough time explaining that notation to that client...
    • Patrick Lujan
      more than a month ago
      Going back to the iLog jRules days (remember them? ), I've always given the client an Excel workbook with some... 'operating parameters,' some macros and then staged a facade out there somewhere to update whenever they do. Usually takes a few passes though for them to get the hang of the road rules tho'. :D
    • Bogdan Nafornita
      more than a month ago
      "the iLog jRules days (remember them?)"

      nah, I'm too young for that :P
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 11:37 AM - #Permalink
    Resolved
    5 votes

    Our experience is that there are three benefits for managing decisions as well as process:

    1. The process is simpler once decisions are externalized and managed separately. Modeling decision making in processes is often complex and makes for a complex, messy, over-gateway'd process.
    2. The process is more agile both because it is simpler (1) and because processes and decisions can be changed independently. It turns out that you rarely need to change a process and a decision to respond to a business change. Plus as noted decisions are often very high change components so managing them separately with business rules technology makes it much easier to safely respond to change
    3. The process can be made smarter through the use of analytics - analytics about customers or transactions rather than the process. Applying data mining and predictive analytics means applying them to decision making. If your process does not explicitly identify decisions then it's really hard to apply advanced analytics effectively

    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.

    • Patrick Lujan
      more than a month ago
      "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."
    • Bogdan Nafornita
      more than a month ago
      The multiple notation issue is valid for implementers too, as it bogs down the process engine with unneeded process instances to iterate through very simple rules.

      It's not an insurmountable issue, it's just an example of where the standard could be more helpful and compelling to use.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 12:12 PM - #Permalink
    Resolved
    4 votes

    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.

    • Patrick Lujan
      more than a month ago
      Depends on the app. Some have lots of rules and decisioning, some don't. My immediately prior engagement to the one du jour had a Big Four telling me, as the BPM solutions architect, that no case management/rules engine solution could satisfy the complexity requirements of an underwriting workbench, that the app would have to be a custom one. They were wrong. And stoopid. But that's a story for another day.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 12:52 PM - #Permalink
    Resolved
    5 votes

    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.

    • Patrick Lujan
      more than a month ago
      Rules (everything in PegaPRPC is a rule) is Pega's primary differentiation, not frameworks. They do it - decisioning- better than anybody else.
    • Derek Miers
      more than a month ago
      Clearly thinking a bit more about this let's consider a pretty challenging scenario for BPM and DMN. Imagine if you will an oil company with 4000 wells that were drilled over time with components on each oil well from some of 400 suppliers, each with various versions of their products, etc. Imagine the mess of documentation and the challenge of having an engineering crew stripping down a given well head ... you see where this is headed. We dont want the team getting creative with the process here, but what components should be taken apart in what order, with what safety checks made ... in order to avoid an oil spill and a damaged environment (to say nothing of the fines).

      Clearly, a robust methodology for expressing the business intent and guidelines (DMN) ... combined with a BPM/Case enabled platform to capture the context and update the relevant documentation ... I would think that most large oil companies could only dream of such sophistication. Or do they rely on people (hopefully) just doing the right thing because they are experienced. Seems obvious.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 12:59 PM - #Permalink
    Resolved
    4 votes

    "...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.)

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 01:21 PM - #Permalink
    Resolved
    4 votes

    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!

    • Patrick Lujan
      more than a month ago
      One TLA - 'PDA.'
    • John Morris
      more than a month ago
      Thanks Patrick! Patrick explains -- I asked -- that in this case PDA doesn't mean "Personal Display of Affection" or "Personal Digital Assistant" -- but "Process Driven Architecture", i.e. the concept promoted by Volker Stiehl, who is someone that anyone interested in BPM and business can profitably learn from, in case you haven't already done so. Coincidentally Signavio is hosting a webinar with Mr. Stiehl this May 11th, 2016.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 26 2016, 01:56 PM - #Permalink
    Resolved
    3 votes

    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....?

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 27 2016, 04:17 PM - #Permalink
    Resolved
    2 votes

    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?

    Thanks,

    AS

    • George Chast
      more than a month ago
      Many times, the Activity or Step IS a Decision. All by itself.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
278 Replies
01/10/2016
David Chassels
271 Replies
30/09/2016
Emiel Kelly
223 Replies
30/09/2016
Bogdan Nafornita
210 Replies
30/09/2016
E Scott Menter
182 Replies
28/09/2016