≡ Menu

Risks of pursuing BPM without decisioning


Syndicated from ebizQ

Inspired by this post by Vijay on Art of Software Reuse (Risks With Pursuing BPM Without SOA) I thought I would write something about the risks of pursuing BPM without decisioning – without decision management.

When BPM is pursued without pursing decision management in parallel the direct consequence is that decisions become an afterthought in the processes that need them. In contrast, applying decision management techniques and technologies in parallel means that Decisions become a first class object that are identified, managed and improved distinct from processes. But what does this mean in terms of risks?

  • Buried Decisions
    The first risk of a BPM-only approach is that decisions are buried in process. The complexity of a decision gets merged with the complexity of the process. The management of the decision gets merged with the management of the process. But most importantly the decision cannot be evaluated, measured and improved as a distinct element of our overall system. In contrast, applying decision management as well as BPM means that Decisions are linked to the processes that use them but not buried in them.
  • Process becomes complex
    Failing to keep a decision separate but linked from a process that uses means that that process will become more complex. The steps of the decisions, the rules that must be applied will now be steps or details within a process. Instead of a simple process with a single decision-making activity our process will have many activities and paths that are managing the relationship (as I discuss in this post on the topic). With decision management your process is simplified because the complexity of the decision is externalized.
  • Inconsistency is likely
    Many decisions are reused between processes and many decisions reuse decision logic, business rules. With decisions mixed into your processes it will be hard to ensure that these decisions are made consistently across processes, hard to reuse the rules that drive those decisions. With decision management you get one version of rules and you know which decisions use which rules.
  • Decisions only evolve with process
    If the rules and decisions are mixed with processes then any change to the rules, to the decision, means a change to the process. If my how you determine which price to use with a customer is embedded in the process then any pricing change must change the process. Yet decision changes like new pricing rules, new eligibility rules and more are not the same as a “real” process change and often come much more often. Managing decisions means you can make independent process & decision changes so that the decision used is always current and that processes don’t need to be redeployed every time decision making must be updated.

The combination of BPM and Decision Management is a very strong one. The combination of process simulation and decision simulation sets you up to manage uncertainty better. Because the steps in your process are clear and the rules in your decision are equally clear you can ensure compliance. You can make workflow and process changes easily but also let business users change the decision making inside otherwise stable processes to maximize agility. Finally you can cut costs, using BPM to avoid coding changes across multiple applications for instance and decision management to lower maintenance costs for logic changes and reducing the number of manual reviews.

Business processes and business decisions are not the same. Business users determine sequence in a process and determine actions in a decision. Keep them separate, manage them both, link them together.

Next week some thoughts on how to get started doing this. You could also come hear me speak at the same presentation I will give at Gartner for those who can’t make it.


Comments on this entry are closed.

  • Gagan Saxena September 18, 2009, 2:47 pm

    Agreed that in general decision engineering needs to be decoupled from process engineering; but assuming that each process will just be a sequence of steps with no alternate flow paths based on conditions may be too extreme.
    I believe the point you made is that DM cannot be an afterthought to BPM. Both go together and good engineering should treat them such.

  • Colin Campbell September 18, 2009, 6:19 pm

    Am interested to see what you have to say about linking business decisions (via business rules) into a business process model. At present I have the very simple idea (not implemented yet) of using a different style of “activity” box that contains the rule IDs or Rule Group names and attaching it to the appropriate Party, Data element or Activity/Task in the BP model. An obvious guideline is to use the subject of a rule as the key to its placement in the model (meaning the terms used in rules and in the process models are the same, or at the very least, synonymous). The enforcement level of the rules could also be included.

    Can I add that it is very easy to say “business rules will take care of decisioning” whilst engaged in business process modelling, and the actual rules required may not be given the proper attention they require then and there. We recently did this, concentrating heavily on BP modelling, and now that it is time to add the rules into the model, I am hoping the model can cope!