Thursday, February 4, 2010

How to find decision point

In ABRD we propose to start the rule harvesting process by looking at decision points. Recently I have a question from a business user, on how to extract the decision point. So let give some practices I'm using.

A decision point is a task in a business process or a step in the use case that involve decision to be taken. When looking at a task description it is important to search for mental thinking verb, most of the time there is a set of knowledge to apply to execute this task, which leads to decision. This could be human knowledge or business logic implementation in a software component. The type of decision will most likely be a reject or accept of the business event or flag it for future processing downstream in the business process. The decision may also include some computational expressions to assign value to attribute of the business transaction.

Therefore to find decision point in a business process or use case description start by searching for verb like analyze, check, validate, evaluate, verify. You can also leverage industry model and business process description. When there is a human task and conditional node you can expect to find decision point there. A human task can also sub decomposed in an automatic task which perform the main stream of decisioning and the exception done by the expert. In most business process there is the existence of validation step to ensure data quality: those steps are source for business rules. Decision point enforces the execution of business rules. The implementation can be done in different technology depending of the type of rule.

It is recommended to define the interface of each decision point and then consider the implementation choice later. Using rule engine technology is the best choice when business users want to change the business logic over time, to enforce auditability to trace the decisions done on a given business event. During the inception phase the project team is doing business modeling activities which aim at describing the business process and decisions applied to any business events supported by the application. Decision points are extracted at that moment and logged in the decision point table.

2 comments:

Paul Haley said...

This is an interesting take on the decision management perspective in which the use of policies/requirements/rules are considered only at points (i.e., in a box corresponding to a decision) within a business process (diagram). Your suggestion about focusing on the verbs is good, but I would like to offer a further clarification that it is the verbs that indicate action rather than relationships that indicate decisions.

JBoy said...

You are right Paul. Verbs which indicate actions and decision. When using a business process modeling approach, practitioners, sometime, consider business rules for the routing logic only. The BRMS is a better used to automate decision within an activity.