«Resolution of the Decision Management Community Challenge – Tax Decision Table» , by Daniel Rodriguez Escabias and Alberto Grande Gómez.
Challenge
Every few months, DECISION MANAGEMENT COMMUNITY proposes challenges on Decision Management that are posted on their website, in which anyone can participate and submit their solution using any decision management and business rules system.
In the “Tax Decision Table” challenge we have been provided with a decision table created by a tax agency business analyst, and have been asked to use our favourite BRMS to automatically solve the decision represented in the table.
Reviewing the table we see that the tax agency analyst needs to determine which forms and schedules should be sent to the taxpayer to comply with the upcoming tax season. To make the correct decision for each taxpayer, the analyst will need to take into account the taxpayer’s data for the current tax season.
In our proposal we are going to use IBM’s BRMS, Operational Decision Manager (ODM) to help the tax agent to automate his decision making. In this way, ODM will execute the business rules that the user writes without the need to involve a technical team of programmers every time changes need to be made to them, and all this using natural language!
Solution with IBM ODM
To get to the point where the tax agency user is autonomous in managing the logic of which forms and attachments should be sent to taxpayers, we, the ODM technical team, will have to create a decision operation that automatically executes those logics, as well as the sentences (or verbalisations) that will be used by the tax agency users to write them. Once the decision operation has been created, the tax agency user will be autonomous to modify and deploy them as many times as needed.
Rule flow
The rule flow defines the order in which the business rules will be executed.
For this example and given the simplicity of the decision to be made, we have only defined a basic rule flow in which we will first perform an initial validation of the data involved in making the decision. If the data we receive for execution is valid, the step in which the business rules that apply to each case (in this case the decision table provided to us as a starting point) will be evaluated and executed will be executed. If the data we receive is not valid, a message will be reported explaining the reason why it is impossible to decide for that specific case.
Decision table
In the “Selector” task of the previous flow, initially, a single decision table is created in which the business rules described in the user-supplied table have been organised in rows.
In ODM each grey column represents a condition (e.g. TAXABLE INCOME < 50.000), which must be fulfilled to request a specific form and annexe. On the right-hand side of the table, in blue, we have the columns that determine the action to be taken for that set of conditions.
Therefore, each row of the decision table in ODM represents all the conditions that the information provided by the taxpayer must fulfil in the current campaign, to send you the form and annexe indicated in the last cells of the row.
One of the things that you might notice when looking at the differences in our decision table about the decision table proposed by the tax agent is the appearance of a “Priority” action column.
Priority rules consist of assigning a weight to each form/attachment in the table to define an order of priority when deciding which forms/attachments should be sent in each case.
The reason why we have included the “Priority” column as another field of the decision is motivated because, during the tests to validate the decision table provided by the tax agent, we realised that for some combinations of input data (i.e. from the information provided by the taxpayers) the expected output and the output obtained were not the same, since according to the logic proposed by the tax agent for those combinations of data, it was valid to send two different types of forms/attachments.
By assigning priorities to the rules, once the best option has been chosen, ODM offers the possibility of stopping the execution of the rest of the rules, i.e., we could mark which forms/attachments should be sent before others when the conditions for sending several are met.
However, in our solution we have considered that it would provide more value to the tax agent if we indicate, in an orderly fashion, all the forms/attachments that could be sent, leaving it up to the tax agent to prioritise some over others.
In this way, if in the future, the tax agent could run simulations using real data, and by analysing the list of selectable forms/attachments, he/she could improve the decision-making process for specific cases.
Advantages of using IBM ODM
Apart from being able to test decision tables, and allowing non-technical users to identify cases that they had not considered without relying on a technical team, ODM is a tool that provides many other options to make it easier for the user to create and manipulate business rules.
One of these options is the possibility to create value domains, which will make it easier for non-technical users to edit business rules by handling business concepts instead of technical concepts.
Domains define the values allowed in fields. They may be available in search list dialogue boxes also referred to as Select Value lists. Domains help ensure that valid and consistent data is specified and reported. This drop-down in the decision table is the result of making a value domain, to indicate the type of tax that applies.
Example I/O with IBM ODM (SoapUI)
An example of the system execution with SoapUI is presented, showing the multiple outputs sorted by descending priority (right) according to the input parameters (left).
Conclusion
As we have seen in the previous lines, the IBM Operational Decision Management (ODM) product facilitates the implementation and maintenance of the logic defined by the business user, being able to modify it himself.
Thanks to the ease of use of the product, the business user can easily and quickly realise possibilities not contemplated in his logic.
According to the Shift-Left Software Development Technique, it is in the interest of the business user’s organisation to know all of the caustics that are discovered using the IBM ODM product to save costs in the long run.
Interested in learning more about how we implement IBM ODM at decide4AI?
If you want to know more about decide4AI and keep up to date with future webinars or events, follow us on social networks (Linkedin, Twitter, Youtube).
