El problema presentado para el Challenge de Octubre en la web del Decision Management Community nos ha inspirado para proponer una solución usando el BRMS de IBM ODM 8.6, en particular queremos aprovechar esta oportunidad para ver en detalle el Framework de Gobierno de Decisiones proporcionado por este producto. De esta forma veremos todas las etapas, desde la creación del proyecto hasta el despliegue en Producción, pasando por el ciclo de vida de reglas, de reléase y de actividades de un reléase.
El problema: Borrowing PASS/FAIL Decision with Mitigation Criteria
Implementación de las reglas de negocio del problema
La implementación inicial se ha realizado usando Rule Designer, la plataforma de desarrollo de ODM.
Se ha creado un Servicio de Decisión Borrowing PASS-FAIL Decision with Mitigation Criteria con una operación Borrowing PASS-FAIL Decision with Mitigation CriteriaOperation. Para realizar un proyecto ligero, no demasiado complejo, no se ha definido un modelo de negocio (BOM), se gestiona todo a través de Variables de Conjunto de Reglas, que constituyen los parámetros de entrada y salida del proyecto de reglas.
Los datos que se reciben en entrada son los siguientes:
- nBorr: New Borrowings
- cust: Customer
- tAss: Total Assets
- ecf: Executive Committee Flag
- ece: Executive Committee Exposure Override
- thold: 1-4 Threshold
- nRCo: Non-repo collateral available for the customer
Los datos que se devuelven en salida (el éxito de préstamo) son los siguientes:
- dvsout: Borrowing PASS or FAIL
Las reglas del proyecto están agrupadas en dos paquetes #1-Rules y #2-Rules, que representan las dos reglas definidas en el problema. Cada uno de estos paquetes tiene una regla de negocio y su correspondiente regla de mitigación.
La orquestación de las reglas de negocio se ha definido en dos fases, la fase I, #1-Rules, en la cual se evalúan las reglas del paquete #1-Rules, y la fase II, #2-Rules, en la cual se evalúan las reglas del paquete #2-Rules. El resultado de esta orquestación es el flujo siguiente.
Antes de ver en detalle cada regla, hay que tener en cuenta las siguientes asunciones que se han hecho a priori sobre el enunciado del problema:
- The ratio = New Borrowings / Total Assets
- New Borrowings cannot exceed 30% of Total Assets = The ratio < 0.3
El Proyecto inicial, realizado en el Rule Designer, se ha publicado en la aplicación web Decision Center, la consola que ODM proporciona para los usuarios de negocio y que se utiliza para gestionar el ciclo de vida de las reglas.
Tras la publicación del proyecto de reglas, en el Decision Center hay un Release inicial en estado Complete, que representa una foto, no modificable, del proyecto que se ha publicado.
Cuando seleccionamos el proyecto aparece una rama main, que es una rama disponible para trabajar fuera del Framework de Gobierno de Decisiones.
Lo que sigue es una visión general de todas las reglas y una visión detallada regla por regla:
Reglas del paquete #1-Rules:
Reglas del paquete #2-Rules:
Según el problema, Customer #200: ABC Bank y Customer #500: Bank One son dos clientes, y para los dos o para uno de ellos no se aprueba el préstamo.
Para comprobar que el Servicio de Decisión se haya creado según las necesidades de negocio, ejecutamos un test unitario a través del Decision Center mediante una hoja Excel donde definimos los datos de entrada y los resultados esperados.
Los datos de Customer #200: ABC Bank y Customer #500: Bank One se han insertado en la hoja tal y como se han definido en el problema, pero además para los dos clientes se han usado 10 posibles importes de presamos, entre 1.000.000 a 10.000.000.
Como resultado esperado hemos previsto que los préstamos de Customer #200: ABC Bank superiores a 30.000.000 y los préstamos de Customer #500: Bank One superiores a 40.000.000 no serán aprobados:
Al ejecutar el escenario, el resultado devuelto corresponde con el resultado esperado:
Mas en detalle:
Resolución del problema
Según el reto propuesto, tenemos que modificar las reglas de mitigación, con el fin de aprobar préstamos, que no se hayan aprobados en la primera ejecución (como por ejemplo los préstamos de Customer #200: ABC Bank superiores a 30.000.000 y los préstamos de Customer #500: Bank One superiores a 40.000.000).
El cambio solicitado por el usuario de negocio consiste en modificar el criterio de mitigación para aprobar un préstamo, en lugar que New Borrowings is less than Non-repo collateral available for the customer es New Borrowings is less than (Non-repo collateral available for the customer * 10).
Vamos a realizar el cambio desde la consola de usuario, el Decision Center, e imaginaremos que el proyecto de reglas se encuentrae en un entorno empresarial, donde existe un equipo que trabaja de forma colaborativa en la gestión del Servicio:
- Analista de negocio: Cristina, que levanta la necesidad de negocio.
- Desarrolladora de reglas: Raquel, que se encarga de modificar las reglas.
- Administrador: Andrea, que valida el cambio y gestiona el despliegue a Producción.
Para realizar el cambio, la usuaria Cristina crea una nueva release sobre la Initial Release, llamado Challenge Oct-2014, definiendo como fecha de vencimiento el 31 de octubre 2014 y asignando al usuario Andrea como aprobador de la release:
Todos los cambios que se aportan al release afectan unicamente al release (porque se genera una nueva rama de desarrollo), y solo cuando su el estado sea Complete, se podrá considerar finalizado el cambio y listo para su despliegue. Mientras tanto, el reléase puede pasar por varios estados:
La usuaria Cristina ahora tiene que crear las actividades necesarias para el cambio, esto se puede hacer hasta que el estado de la reléase no sea Complete. De esta manera, Cristina crea una actividad de cambio, para modificar las reglas, y la llama Change Mitigation Criteria Rule #2, con la siguiente información: ella es la propietaria el aprobador es Andrea, la persona del equipo que tiene que crear las reglas es Raquel, y la fecha de vencimiento será el 31 de Octubre 2014.
Para la validación de los cambios, Cristina crea una nueva actividad de validación, Challenge Oct-2014 Validation, asignando la fecha de vencimiento el 31 de Octubre 2014 y a Andrea como ejecutor y aprobador de la actividad.
Para esta actividad de validación Cristina crea un caso de prueba New Borrowings pass, igual al lo que se ha ejecutado al principio, solo que esta vez en el resultado esperado todos los préstamos de los dos clientes vienen aprobados:
Raquel, accediendo al Decision Center, en la sección de Work, tiene la actividad de cambio Change mitigation Criteria Rule # 2 pendiente:
La creación de esta actividad ha generado una nueva línea de desarrollo, que será visible en el release Challenge Oct-2014 solo cuando el estado de la actividad de cambio sea Complete. Mientras tanto, la actividad pasa por los siguientes estados:
El cambio que Raquel va a aportar es sobre la regla 02-Mitigation Criteria del paquete #2-Rules, actualizando la segunda condición de la regla:
Guardado el cambio, Raquel ha finalizado su trabajo, por lo que cambia la actividad de cambio Change mitigation Criteria Rule # 2 a Finish working.
Cristina, propietaria de la actividad de cambio, una vez revisado el trabajo de Raquel, tiene el permiso de modificar su estado, pasarlo a Cancel activity o Proceed to approval.
Como el cambio realizado por Raquel es satisfactorio, pasa el estado de la actividad a Proceed to approval, dejando a Andrea el cargo de aprobar o no menos el cambio.
Andrea, accediendo al Decision Center, en la sección de Work, tiene la actividad de cambio Change mitigation Criteria Rule # 2 pendiente de aprobar, revisa los cambios, y cambia el estado de la actividad a Approve changes:
Todo lo que se ha realizado sobre esta actividad se puede resumir visualizando la Timeline de la actividad:
Una vez que la actividad de cambio ha sido aprobada, el estado de la actividad pasa automáticamente a Complete (como se ve en la figura), y se realiza un merge entre la sub-rama de la actividad de cambio y la rama del release Challenge Oct-2014.
Solo ahora, cuando todas las actividades de cambio están en estado Complete, Andrea, el autor de la actividad de validación, puede empezar a ejecutar el caso de prueba definido para esta actividad, New Borrowings passed.
El resultado esperado de este test es que todos los préstamos de los dos clientes serán aprobados, es decir, que todos los escenarios tendrán como resultado PASS.
Una comparativa entre informes de pruebas ejecutadas antes y después del cambio nos enseña como para el escenario 6 el resultado era FAIL (a la derecha) mientras ahora es PASS (a la izquierda).
Tanto para las actividades de validación, como para las actividades de cambio, existen estados, y el autor, el propietario y el aprobador son los que los actualizan:
Ahora Andrea, siendo el autor y aprobador de la actividad, tiene permiso para actualizar la actividad a Finished y pasar el estado primero a Ready for Approval y luego a Approve changes:
Todas las actividades del release Challenge Oct-2014 están en estado Complete, así que Andrea, que es el aprobador, puede actualizar el estado del release, hasta llegar al estado Complete.
Despliegue a Producción de los cambios
Una vez completado el release, Andrea puede desplegarlo directamente en producción desde el Decision Center a través de las funcionalidades que proporciona esta consola.
Conclusiones
Una de las principales ventajas que se han introducido en este BRMS desde la versión IBM ODM 8.5, es la incorporación del concepto de «Gobierno» sobre las reglas que existen en el Servicio de Decisión.
Todos tenemos claro la mejora que introducen los BRMS en las organizaciones respecto al Time-to-Market y respecto a la auditabilidad de las decisiones, pero no debemos olvidar que esta mejora también trae consigo un aumento en la responsabilidad de usuarios con un carácter no técnico, y por lo tanto también exige de un mayor control sobre la Gestión de las Decisiones.
