Technically, BPM/Business Rules approach place process logic with the BPM suite and decision logic in the business rules management system (BRMS). The process logic in a BPM suite sequences and controls activities and launches and cancels processes. Control is achieved with timers and exception handlers. Processes can be designed to recover from errors, restart processes and coordinate activities. The BRMS effectively designs, organizes and executes the logic behind a process decision. An effective BRMS can handle any depth and complexity of decision logic, including computationally complex logic and dense logic.
Bruce makes an interesting comment on business rules too: that “routing logic in process gateways” are not “business rules”. That doesn’t really make sense: for sure some gateways will be process-housekeeping decisions of little interest to the business user, but others will surely embed business-critical decisions. On the other hand, it has long been acknowledged that a best practice for BPM is to delegate such business decisions to a managed decision service - hence the explicit new business rule (aka decision) task in BPMN 2.0. And,in the CEP world, for tools like TIBCO BusinessEvents to invoke a decision managed by its Decision Manager tool.
Based on feedback from clients and earlier surveys, I have compiled and listed the benefit themes below:
Business Agility: Faster reactive and proactive time to market
Decision Making: Test rule-based scenarios at lower cost
Revenue Opportunities: Greater product, pricing and flexibility
Customer Satisfaction: More-customizable products and services
Compliance; Greater visibility into policy adherence
It strikes me that many companies who think they have either a unique process or a lot of process variations actually do not - they have a standard set of activities that must be assembled dynamically based on the circumstances, customer etc. This leads to a rules-first approach to defining the process and much simpler processes. This is particularly useful when you start considering case management processes where using the rules to determine what state the case has reached and what, therefore, is the right next step is a clearly better approach.
Was Regeln und Entscheidungen zusammenhält und was sie unterscheidet, ist eine oft gestellte Frage, wenn Sowatec zum Thema Business Rules Management berät: Was unterscheidet sie eigentlich genau und welche Abhängigkeiten sind am Werk.
Grundsätzlich lassen sich zu Entscheidungen und ihren Bedingungen drei wesentliche Aussagen treffen.
Entscheidungen sind von den Prozessen, Systemen bzw. Events strikt zu unterschieden d. h. sie müssen getrennt betrachtet werden. Erst dadurch ist erste ihre Identifizierung und damit Verwaltung möglich.
Regeln, die für Entscheidungen nötig sind, werden in je nach Ziel bzw. Fokus orientierten Regel”gruppen” zusammengefasst.
Die Verwaltung eines Regelsets obliegt den Verantwortlichen für die Herkunft der jeweiligen Regeln (Legal, Marketing, Firmenpolitik etc.). Erst wenn Regeln sich ändern, hat das Auswirkungen auf zu treffende Entschedungen, nicht umgekehrt.
Regeln bzw. Business Rules sind also Bedingungen für das Decision Management und seine Werkzeuge, den Decision Services. Bei James Taylor habe ich einen recht guten Artikel zu Decision Services gefunden: Here’s how decisions and rules relate
Incanto can be implemented to solve the following kinds of decision making problems:
Problems where the expert rule set is large or complex. Incanto is especially suited to managing complexity.
Problems where the rules change frequently. Incanto`s testing capabilities mean amended rule sets can be introduced swiftly and with confidence.
Problems where the expert rules set needs to be applied to large volumes of data.
Where all these conditions apply Incanto is probably the only good answer in the market at present.
Multiple channels and types of events…
… executing in multiple Inference Agents (Event Processing Agents on an Event Processing Network)…
… where Events drive Production Rules with associated (shared) data…
… and event patterns (complex events) are derived from the simple events and also drive Production Rules via inferencing…
… to lead to “real-time” decisions.
For those of you that could not make it, I wanted to give you the gist of what I presented. This presentation covers the evolution of the business rules technology focusing first on the drivers that forced the market to shift its focus from Business Rules Engines (BRE) to Business Rules Management Systems (BRMS). In a nutshell, the main ideas are summarized below. In a few days, the recording will also be posted on our community site for your convenience.
Rob sees three key areas where rules can help:
Tighter warranty controls
Claims processing is improved because financial limits, detailed coverage types, materials return and more can be automated and rapidly changed when necessary. The rules also allow “what-if” testing and impact analysis.
Better built vehicles
The decision making is tracked very closely thanks to rules so you can analyze specific repair types, specific VINs and so on. More effective parts return and generally better information also contribute.
Lower cost repairs
Rules allow goodwill repairs, labor-only repairs and specific kinds of repairs to be managed very precisely. Rules-driven decisioning can reduce the variation of costs between dealers and help intervene, rejecting or editing claims that seem overly expensive. The ability of rules to deploy data mining and predictive analytics can also really help here.
JT has posted his view on rules and decisions and how they relate. Given that James talks more about services than events, I thought it would be worth reviewing his post from both a Complex Event Processing and a TIBCO BusinessEvents event processing platform perspective.
”Decision Services:
Support business processes by making the business decisions that allow a process to continue.
Support event processing systems by adding business decisions to event correlation decisions (they are often called Decision Agents in this context).
Allow crucial and high-maintenance parts of legacy enterprise applications to be externalized for reuse and agility.
Can be plugged into a variety of systems using Enterprise Service Bus approaches.”
The power of Decision Management in this kind of scenario is threefold.
Firstly it focuses on the decisions themselves - what decisions matter to the customer interaction. This ensures that the data being collected and used is that which will make a difference. Beginning with the decision in mind in this way focuses analytics and data gathering.
Secondly it allows the decision to be made consistently across channels so that customers get the same service from the agent at the gate, the call center, the service center or the kiosk. Operational BI assumes there is a person to make the decision and so cannot deliver this true cross-channel consistency.
Thirdly, Decision Management recognizes that policies and regulations matter as much, sometimes more, than data. Presenting the data and even its analysis to someone who then fails to follow procedure is not helpful. Decision Management combines the policy aspects of a decision with the analytic aspects in a way Operational BI does not.
Let’s start by recapping decisions services. Decision services are services, generally stateless ones, that answer business questions for other services. Decision Services typically have no side effects so they can be called whenever they are needed without the caller worrying that something will change in the system. This means that database updates, event generation or other actions taken as a result of the decision are taken by the caller not by the Decision Service. This is not 100% true but works as a general rule. To work, Decision Services need to contain all the logic and algorithms necessary to make the decision correctly.
1. Decisions are the unit of work to which BI initiatives should be applied.
2. Providing access to data and tools isn't enough if you want to ensure that decisions are actually improved.
3. If you're going to supply data to a decision-maker, it should be only what is needed to make the decision.
4. The relationship between information and decisions is a choice organizations can make--from "loosely coupled," which is what happens in traditional BI, to "automated," in which the decision is made through automation.
5. "Loosely coupled" decision and information relationships are efficient to provision with information (hence many decisions can be supported), but don't often lead to better decisions.
6. The most interesting relationship involves "structured human" decisions, in which human beings still make the final decision, but the specific information used to make the decision is made available to the decision-maker in some enhanced fashion.
7. You can't really determine the value of BI or data warehousing unless they're linked to a particular initiative to improve decision-making. Otherwise, you'll have no idea how the information and tools are being used.
8. The more closely you want to link information and decisions, the more specific you have to get in focusing on a particular decision.
9. Efforts to create "one version of the truth" are useful in creating better decisions, but you can spend a lot of time and money on that goal for uncertain return unless you are very focused on the decisions to be made as a result.
10. Business intelligence results will increasingly be achieved by IT solutions that are specific to particular industries and decisions within them.
- leave anything related to transport, communication to other layers- use this revised CEP to express and execute event-relevant logic, the purpose of which is to translate the ambient events into relevant business events- have these business events trigger business processes (however lightweight you want to make them)- have these business processes invoke decision services implemented through decision management to decide what they should be doing at every step- have the business processes invoke action services to execute the actions decided by the decision services- all the while generating business events or ambient events- etc.
CEP module receives or intercepts a flurry of events and processes them with the objective of figuring out what those events are relevant for; it triggers the appropriate business processes or decision services
BPM module receives the request for a given process to be applied to a higher level entity (an application, a document...); it automates the steps defined in the business process
BRMS module is invoked with a given context to apply business rules; it makes a business decision
Substitute a standard web services interface for a speaking tube, a business rules management system for his encyclopedic knowledge of policies and regulations, data mining or predictive analytics for his customer knowledge and adaptive control for his experimentation and you have Decision Management. The Answerer but on an industrial scale.
I believe that the general consensus among those who study this kind of thing, is that any decision made wholly by a computer is an operational decision, even if it affects the behavior/tasks of many people or sub-components. Online decisions, being a subset of automated decisions, would then be operational in nature.
G. Trentham, and H. Scholl. HICSS '08: Proceedings of the Proceedings of the 41st Annual Hawaii International Conference on System Sciences, page 197. Washington, DC, USA, IEEE Computer Society, (2008)
D. Rosca, S. Greenspan, M. Feblowitz, and C. Wild. Requirements Engineering, 1997., Proceedings of the Third IEEE International Symposium on, (January 1997)
C. Wild, K. Maly, C. Zhang, C. Roberts, D. Rosca, and T. Taylor. TENCON '94. IEEE Region 10's Ninth Annual International Conference. Theme: Frontiers of Computer Technology. Proceedings of 1994, (August 1994)