«Resolución del Challenge de Decision Management Community – Tax Decision Table» , por Daniel Rodriguez Escabias y Alberto Grande Gómez.
Desafío
Desde DECISION MANAGEMENT COMMUNITY proponen cada ciertos meses unos retos sobre Decision Management que cuelgan en su web, en los que cualquiera puede participar y mandar su solución utilizando cualquier sistema de gestión de decisiones y reglas de negocio.
En el challenge “Tax Decision Table” nos han proporcionado una tabla de decisión creada por un analista de negocios de una agencia tributaria, y nos han solicitado usar nuestro BRMS favorito para resolver de forma automática la decisión representada en la misma.
Revisando la tabla observamos que el analista de la agencia tributaria necesita determinar qué formularios y anexos deben enviarse al contribuyente de cara a cumplir con la próxima temporada de impuestos. Para tomar la decisión correcta para cada contribuyente, el analista deberá tener en cuenta los datos del contribuyente en la campaña actual.
En nuestra propuesta vamos a usar el BRMS de IBM, Operational Decision Manager (ODM) para ayudar al agente tributario a automatizar su toma de decisiones. De esta forma ODM ejecutará las reglas de negocio que el propio usuario escriba sin necesidad de involucrar a un equipo técnico de programadores cada vez que sea necesario realizar cambios en las mismas. ¡Y todo esto usando el lenguaje natural!
Solución con IBM ODM
Para llegar al punto en el que el usuario de la agencia tributaria sea autónomo a la hora de gestionar las lógicas de qué formularios y qué anexos deben ser enviados a los contribuyentes, nosotros, el equipo técnico de ODM, deberemos crear una operación de decisión que ejecute de forma automática dichas lógicas, así como también las frases (o verbalizaciones) que serán usadas por los usuarios de la agencia tributaria para escribirlas. Una vez creada la operación de decisión, el usuario de la agencia tributaria será autónomo para modificarlas y desplegarlas tantas veces como necesite.
Flujo de reglas
El flujo de reglas define el orden en el que se ejecutarán las reglas de negocio.
Para este ejemplo y dada la simplicidad de la decisión a tomar, sólo hemos definido un flujo de reglas básico en el que primero realizaremos una validación inicial de los datos involucrados en la toma de la decisión. Si los datos que nos llegan para la ejecución son válidos se ejecutará el paso en el que se evaluarán y ejecutarán las reglas de negocio que apliquen para cada casuística (en este caso la tabla de decisión que nos han proporcionado como punto de partida). Si los datos que nos llegan no son válidos, se reportará un mensaje explicando el motivo de la imposibilidad de tomar una decisión para ese caso concreto.
Tabla de decisión
En la tarea “Selector” del flujo anterior, inicialmente se crea una única tabla de decisión en la que se han organizado las reglas de negocio descritas en la tabla proporcionada por el usuario en filas.
En ODM cada columna de color gris representa una condición (p.e. TAXABLE INCOME < 50.000), que debe cumplirse para solicitar un formulario y anexo concretos. En la parte derecha de la tabla, en color azul, tenemos las columnas que determinan la acción a ejecutar para ese conjunto de condiciones.
Por lo tanto, cada fila de la tabla de decisión en ODM representa todas las condiciones qué la información proporcionada por el contribuyente deberá cumplir en la campaña actual, de cara a enviarle el formulario y el anexo indicado en las últimas celdas de la fila.
Una de las cosas que más podrían llamaros la atención al observar las diferencias de nuestra tabla de decisión en relación a la tabla de decisión propuesta por el agente tributario es la aparición de una columna de acción “Priority”.
La prioridad de reglas consiste en asignar un peso a cada formulario/anexo de la tabla para definir un orden de prioridad a la hora de decidir qué formularios/anexos deben enviarse en cada caso.
El motivo por el que hemos incluido la columna “Priority” como un campo más de la decisión viene motivado porque durante las pruebas para validar la tabla de decisión que nos proporcionó el agente tributario, nos dimos cuenta que para algunas combinaciones de datos de entrada (es decir, de la información proporcionada por los contribuyentes) la salida esperada y la obtenida no eran la misma, ya que según la lógica propuesta por el agente tributario para esas combinaciones de datos, era válido enviar dos tipos diferentes de formularios/anexos.
Por medio de la asignación de prioridades a las reglas, una vez elegida la mejor opción, ODM ofrece la posibilidad de detener la ejecución del resto de reglas, es decir, podríamos marcar qué formularios/anexos deben enviarse antes que otros cuando se cumplan las condiciones para el envío de varios.
Sin embargo en nuestra solución hemos considerado que aportaría más valor al agente tributario si le indicamos, de forma ordenada, todos los formularios/anexos que podrían enviarse, dejando en su mano priorizar unos frente a otros.
De esta forma, si en un futuro el agente tributario quisiera podría ejecutar simulaciones usando datos reales, y analizando la lista con los formularios/anexos seleccionables podría mejorar la toma de decisiones para casos concretos.
Ventajas de usar IBM ODM
A parte de poder probar las tablas de decisiones, y permitir a los usuarios no técnicos identificar casos que no había tenido en cuenta sin depender de un equipo técnico, ODM es una herramienta que brinda muchas otras opciones para facilitar al usuario la creación de reglas de negocio y la manipulación de ellas.
Una de esas opciones es la posibilidad de crear dominios de valores, que facilitarán a los usuarios no técnicos la edición de las reglas de negocio, manejando conceptos de negocio en lugar de conceptos técnicos.
Los dominios definen los valores permitidos en los campos. Pueden estar disponibles en recuadros de diálogo de lista de búsqueda a los que también se hace referencia como listas de Seleccionar valor. Los dominios ayudan a asegurarse de que se especifican y se informa sobre datos válidos y coherentes. Este desplegable en la tabla de decisión es el resultado de realizar un dominio de valores, para indicar el tipo de impuestos que se aplica.
Ejemplo E/S con IBM ODM (SoapUI)
Se presenta un ejemplo de ejecución del sistema con SoapUI, donde se puede apreciar la salida múltiple ordenada por prioridad descendente (dcha) en función de los parámetros de entrada (izda).
Conclusión
Como hemos podido ver en las líneas anteriores, el producto de IBM Operational Decision Management (ODM) facilita la implementación y mantenimiento de la lógica que define el usuario de negocio, pudiendo modificarla él mismo.
Gracias a la facilidad de uso del producto, el usuario de negocio se puede dar cuenta fácil y rápidamente de posibilidades no contempladas en su lógica.
Según la técnica de desarrollo de Software Shift-Left, a la organización del usuario de negocio le interesa conocer toda la cauísitca que se descubre usando el producto IBM ODM para ahorrar costes a largo plazo.
¿Interesado en saber más sobre cómo aplicamos IBM ODM en decide4AI?
Si quieres saber más sobre decide4AI y mantenerte al tanto de futuros webinar o eventos, síguenos en las redes sociales (Linkedin, Twitter, Youtube).
