I've read a few mentions lately of business rules and BPM. Do you see business rules playing a bigger role in the future of BPM? If so, what will that role be?
Where BPM is in the technical context I'm inclined to say yes. Why? With increasing developing of technology (e.g. process mining) it will become easier to extract trends on which you can (automatically) base business rules.
Where BPM is in the non-technical context I'm not too sure. As the beauty (am I saying this?) of technology that it is not human. In other words, technology is without emotions... Now... if technology becomes more human (e.g., AI) this could change again...
Business Rules have always played a role in BPM. Business rules are the roles, responsibilities, policies, procedures, routing, deadlines, escalations, and more that govern each activity of a business process. Further, rules govern application interactions such as dynamic look-ups, validatiions, task outs, and reporting such as which metrics to capture, when and how to display them. That is why BPM is quite complex: everyone involved in the design and use of applications should be thinking up front what rules matter when and how to measure their effect. As we move forward I see really elegant rules capabilities enabling Power Users to create and dictate straight through processing. BPM continues to expand and excite.
Rules are a result of process design, not a goal and whether or not there will be more is depending on the way you like to manage your processes. Rules should tell 'how we do business here'
If you think standardization by automation and dictation is the way to go, than rules are needed to manage the cases in the process.
If you're processes are more like 'I don't care what you do, as long as you reach the goal in time' there will be less rules needed.
Of course there are still restrictions because of things like law. But I see these more as guides than as rules.
In the end you should buy/apply methods and stuff because it supports the way you'd like to manage your processes, not because it's cool or Gartner has a quadrant for it.
Business Rules have always played a role in BPM, but it was mostly implicit. Hence spaghetti processes and "imbricated" XOR gates.
Making business rules explicit helps design much simpler processes, but also exposes them to regular business scrutiny and editing, which increases the agility of the process-driven applications.
But rules are just automated decisions. Human decisions will still benefit from them, because another impact of explicit business decision design is the impact in the audit trace. I can envision an auditor trying to understand how a decision was made (which is a superior type of audit instead of the typical compliance audits) just logging into a DMN-compatible system and understanding what was the information available at the time of the decision. Not yet perfect, but miles better than whatever exists now.
There's tons of work to be done on information consistency and proper decision science fundamentals, but the prospect is interesting, I agree.
I think the future of Business Rules is to be completely integrated into BPM Suites, but maintaining those rules isolated from the process diagram (BPMN or whatever). I don’t see stand alone Business Rules applications in the future, with complex integration to use those rules in your processes.
In terms of implementation, big players already have BR integrated into their BPMS. Those who have not, will be buying BR companies and integrating their technology into their BPMSs. Smalls and agile BPM vendors will be developing their own BR tools to be integrated into their solutions, if the hadn’t already done it.
In sum, I don’t believe there is a Business Rules market for standalone applications, but I see a promissory future as part of BPM Suites.
I think we're going to see a fundamental shift in BPM driven by Cognitive Computing powered insights, and I see Business Rules as being one of the primary mechanisms for guiding the "Cognitor"... Business Rules establish the guard-rails and trip-wires within which automated actions and "next best action" suggestions are made. Business Rules will become a communication mechanism for explaining the policies and procedures to the Cognitor - and the mechanism for communicating changes in policies and procedures as they become necessary.
Sure—rules are important now, and their importance will continue to grow. As they get more complex, however, we'll need new and better ways to manage them. We'll want to make sure we can hide the details of rules from implementers who don't need to see how the sausage is made, while still making the rules easily modifiable (and the changes trackable) for those whose job it is to do so. Rule scoping, as well as rules-driven transitory roles, will also gain significance.
Great question, and especially timely since DMN 1.0 (from earlier beta) is just released this September (OMG's "Decision Model and Notation"). And there are already some products incorporating DMN.
For all the reasons stated by BPM.com correspondents here , business rules are important and becoming more so. Some comments:
1) ANTI-SPAGHETTI - A demo of business process technology for a simple responsibility escalation looks like spaghetti. Business people in the room are no longer interested. But apply business rules and the resulting simplification is quite amazing. Complexity-be-gone. Business people now interested! Sale or subscription or project moves ahead.
2) SURFACE THE DARK - I don't think business rules are becoming more important. They just "are", as part of the dark matter of tacit knowledge on which we depend. I like to say that the addition of a rules engine enables you to "surface" the rules that you are already using -- for transparency, auditing, management and easy evolution of your processes etc..
3) GOOD FOR IOT TOO -- As for the importance of decisions themselves, a good case can be made that much of management is really only about decisioning. So the developing science and technology of decisioning is about applying technology to the core of what management should be doing. A good argument can be made that almost anything involving the IoT somehow concerns decisioning.
4) BUSINESS ANALYSIS -- Business analysts, and maybe even business managers, can often directly maintain business rules, or at least rule parameters. A huge step forward in how business semantics are managed.
5) AND FOR THE REALLY BUSINESS-MINDED -- BPM + BRM makes it possible to build all those exciting new digitized business models that everyone is worried about. Not possible in code and not possible in ERP and not possible in just BPM alone.
So apply BPM and BRM technology on top of a good data model and you'll have a great foundation that'll enable you to progress to where you need to be.
As radio stations say in Canada, "Happy Rocktober" . . .
Business rules drive everything now, and I don't see a time (at least not in the near future) that they won't be needed. As a Business Analyst, writing concise and accurate business requirements that capture the needs of my client (and that developers and testers can understand and use to drive their actions) is the main chore of my job. As client expections increase, the BPM product offerings will become more complex and will need to be multi-channel. That being said, they will still need requirements to define the applications' functionality. Even with "cognitive computing," as mentioned above, you still have to define the cognitive actions. Yay! Job security!
I personally see business rules as a "control mechanism" that helps to fine tune an engine (business processes) to allow it to yield optimal performances.
While processes are somehow rigid, rules tend to be where the flexibility lie in a BPM project. This agility is key to BPM adoption.
The main benefit of business rules is that they are decoupled from the process design so they can be updated independently. This is generally done via a tooling that is friendlier to less technical users (you do not need a developer to update them). This allows process managers to move away from base specifications with theoretical metrics while getting closer to real-life applications.
In the end, combined with monitoring, business rules clearly play a part in the “optimization” phase of the BPM life cycle (design, modeling, execution, monitoring, and optimization).
Business rules have been and will still play a crucial role for any application implementation. Any application developed by leveraging the programming languages (C, C++, Java, .NET etc…) or packaged product stacks, the common scenario we always come across are IF THIS THEN WHAT (or If This Then That ITTT. These scenarios can be addressed via simple if else statements or nested conditions, or decision tables or decision trees or map tables or packaged BRMS solutions (with drag and drop of these features) etc.
Following are the key areas where BPM + BRMS (Business Rules) Duo can create a big impact :
In the context of decision-making, yes.
We have found that there is an upper limit to how much you can improve a process by focusing only on the process and its rules. To really add value, especially to make it more effective (not just more efficient) you need to understand and manage the decisions within the process. As noted above this means identifying, modeling (with DMN) and then managing them (with business rules and increasingly also predictive analytics). Processes with decisions explicitly called out and managed in this way tend to be simpler, smarter and more agile.
Business rules matter to processes for sure but what really matters are DECISIONS.
To become digital (see ref1) it is mandatory to establish dependencies between various enterprise artefacts as explicit and machine-executable models. For some dependencies typical business rules / decisions are sufficient, for others – business processes (and even DSL) are necessary. Potentialy, those models and actual data will provide predictive analytics.
A couple of considerations about the choice of models:
1. Any notation for explicit and machine-executable expression of dependencies should be understandable for their business owners.
2. If a business domain is already “covered” by business process then any use of business rules outside processes must be justified.