Descripción
Para el Challenge de Diciembre 2014 – Enero 2015 , la web Decision Management Community nos propone participar en el «UServ Product Derby». Hace más de 10 años en un foro de reglas de negocios, los vendedores tenían la oportunidad de demostrar las capacidades de sus productos, utilizando el mismo caso de uso conocido como «UServ Product Derby». La mayoría de vendedores competían entre ellos y daban la oportunidad a los usuarios potenciales de comparar las diferentes soluciones.
El caso de negocio que nos ocupa, aborda la problemática de los Seguros de Autos, incluyendo la viabilidad para ser asegurado y una cotización de la póliza del vehículo para una hipotética compañía de seguros. En este link tenemos un documento con un descripción mas detallada del caso de negocio, en el se encuentra un modelo de entidades de negocio y los escenarios de prueba a los que tenemos que dar solución.
Para abordar esta solución vamos a utilizar el BRMS IBM Operational Decision Manager 8.7.0. Esta nueva versión del producto, permite simular el impacto que tiene el cambio de las decisiones sobre una cartera de clientes.
A continuación vamos a detallar la solución que proponemos para el caso de negocio.
Proyecto de reglas
Nuestra solución recibe una propuesta de Póliza a cotizar. A partir de estos datos se irán ejecutando las reglas, calculando las primas tanto para los coches como para los conductores que contienen la póliza y en el paso final cotizar la prima anual de la póliza.
El flujo de ejecución de reglas o workflow es el siguiente:
 |
| El primer paquete de reglas decide el nivel de riesgo en función de las características de los coches y conductores. En el paquete de «Pricing», a partir del nivel de riesgo calculado previamente, asigna una puntuación a cada uno de los intervinientes en la póliza (coches y conductores) y en función de la puntuación total determina si el cliente es apto para poder contratar una póliza. Si el cliente es apto, cotizamos el valor de la prima anual. Si no fuera apto, terminaría la ejecución del workflow. |
Consola empresarial
La consola empresarial de Decision Center es la plataforma que utilizan los usuarios de negocio y/o analistas para gestionar el repositorio de reglas.
Como veremos a continuación las reglas que forman el Servicio de Decisión están escritas en lenguaje natural, facilitando a los usuarios de la plataforma mantener estas reglas sin depender del departamento de IT. Esto proporciona una mayor agilidad en la toma de decisiones ya que separamos la lógica de la aplicación de la lógica de negocio.
La solución que hemos definido para el caso de negocio, consta de 65 reglas. Vamos a ver en detalle alguna de estas reglas:
Eligible Driver senior driver and training certification
En esta regla, si el conductor es Senior y tiene Certificado de clases lo marcamos como apto para la póliza. |
 |
En este ejemplo vemos una regla del paquete «Pricing» donde vamos aumentando o disminuyendo la prima en función de unas condiciones. En la parte derecha, podemos observar la información y algunas propiedades de la regla. Usuario que ha editado la regla, el estado en el que se encuentra esta regla y propiedades de fechas que podemos usar para que la regla tenga validez durante un determinado periodo de tiempo.
Además de reglas de negoció también tenemos tablas de decisión. En esta imagen podemos ver una tabla que utilizaremos para la puntuación. En la tabla podemos definir unas precondiciones que deciden si la tabla se ejecuta o no, a continuación tendremos tantas columnas como necesitemos de condiciones y columnas de acción.
En la cabecera de la columna definimos la condición o acción y en las filas el valor.
A partir de los escenarios que nos presentan en el caso de negocio, completamos la información en los excel. Estos excel los ejecutaremos con una Simulación dentro de la Consola Empresarial y nos mostrara gráficamente los resultados.
Validación de la Solución
El caso de negocio nos propone una serie de escenarios a validar. Al ejecutar estos escenarios, tenemos que proporcionar unos resultados para asegurar que la solución ha sido la correcta.
Algunas reglas tienen en cuenta el año actual, para la ejecución de los escenarios nosotros utilizaremos el 2015.
Al final del artículo mostramos la implementación que hemos hecho para poder llegar a las soluciones que mostramos a continuación.
Preferred Client Business Rule V1
Para la ejecución de los escenarios la herramienta nos proporciona hojas excel para introducir los datos y los resultados que esperamos. Rellenamos la información en los excel con los datos de este escenario.
En la primera pestaña definimos la poliza con los conductores y coches.
En la siguiente pestaña definimos los conductores de la póliza.
Y ya por ultimo definimos los conductores de la póliza.
Resultado de la ejecución del escenario con una simulación. El cliente es considerado como «Preferred Client».
Preferred Client Business Rule V2
Generamos una excel con los nuevos datos de este escenario.
 |
 |
 |
Resultado de la ejecución del escenario con una simulación. Aunque los datos son prácticamente idénticos que el anterior cliente, al no considerarle «Preferred Client» el precio se incrementa.
En este escenario únicamente cambiarían los datos del coche, ya que nos dicen que los vehículos tienen un año más. Para ello cambiamos el año de los vehículos.
Resultado de la ejecución del escenario con una simulación. En este escenario re-tarificamos el primer cliente que sigue siendo «Preferred Client», el precio varía ya que el vehículo al tener un año más no entra dentro del rango «entre 5 y 10 años».
Eligibility Within and Outside an Elite Client Relationship
 |
 |
 |
Resultado de la ejecución del escenario con una simulación. Shane es considerado como «Elite Client» porque está dentro del portfolio de su padre. Por lo tanto su «Eligibility Score» es 0
 |
 |
 |
Resultado de la ejecución del escenario con una simulación. Shane deja de estar dentro del portfolio de su padre y por lo tanto no es considerado con «EliteClient». Con sus datos el «Eligibility Score» es 100 y por ello el resultado de elegibilidad es:
«the client’s application/policy renewal must be reviewed by underwriting manager who will determine whether the client is eligible for auto insurance«
Calculamos el valor de su prima considerando que después de revisarla ha sido considerada elegible.
Simulaciones
Aprovechamos el Challenge para mostrar las simulaciones en la Consola Empresarial, las simulaciones empiezan a estar disponibles a partir de la versión la 8.7. Con las simulaciones conseguimos, además de mostrar los resultados que deseamos, ante un cambio de una regla observar el impacto que tiene sobre las demás reglas y sobre todos los escenarios. Vamos a mostrar el flujo de trabajo para la creación de una simulación y una breve descripción de cada uno de los elementos que se necesitan para la simulación.
 |
| Métricas Las métricas definen los elementos que se utilizan en los ICR. Debe crear medidas para poder realizar ICR. |
 |
| KPIs o ICR Las Los ICR muestran los resultados de ejecutar una simulación. |
 |
| Datos Las simulaciones utilizan la información empresarial que se suministra como datos de entrada. Para ejecutar una simulación, debe utilizar un archivo de escenario de Excel o un archivo de un proveedor de datos |
 |
| Formatos de informes Cuando se ejecuta una simulación, esta muestra sus resultados en un informe. Puede definir varios formatos para que una simulación genere diversos informes. |
 |
| Simulaciones Puede configurar una simulación para reunir ICR, datos de entrada, un servidor y un formato de informe. Cuando se ejecuta una configuración de simulación, utiliza reglas del servicio de decisiones asociado y coloca los resultados en un informe. |
 |
En este ejemplo, mostramos un gráfico donde se muestra la variación de la prima anual en los 3 primeros escenarios anteriormente ejecutados.
Conclusión
En este nuevo Challenge hemos visto como un BRMS puede ayudar a las Compañías de Seguros,
convencidos de que esta tecnología debería formar parte de su Plan Estratégico de Sistemas ya que:
- Mejora su «Time To Market» agilizando la toma de decisiones en los entornos productivos.
- Permite que Servicios críticos del sector puedan ser legibles y trazables mejorando la explicación a la hora de atender reclamaciones de clientes.
- Reduce la dependencia de los equipos de IT disminuyendo así el coste del mantenimiento.
- Centraliza en un único sistema los Servicios de Decisión permitiendo que estos se encuentren centralizados y sean reutilizables por distintas aplicaciones y tecnologías (On-Line, Batch).
- Simula el impacto que tiene el cambio de las decisiones sobre la cartera de clientes.
Implementación
Vamos a detallar el desarrollo, para mostrar como determinamos si es apto para la póliza y como calculamos la prima anual.
Por defecto el algoritmo que utilizaremos es RetePlus, criterio de salida ninguno y el orden es por prioridad. La prioridad por defecto es 0. Cuando queremos que se ejecuten antes unas reglas que otras, lo hacemos dándole una prioridad mayor.
| |||||||||||||||
EligibilityEl primer paquete que se ejecuta en el flujo es «Eligibility».
| |||||||||||||||
El primero de los subpaquetes es «AutomobileEligibility«, en el determinaremos la categoría de los riesgos en función de las características del automóvil. El orden seria:
| |||||||||||||||
El siguiente de los subpaquetes es «DriverEligibility«, categorizamos a los conductores en función de sus características. En estas reglas no necesitamos prioridad porque no se pueden ejecutar varias reglas de un paquete, ya que son excluyentes. Lo dividimos en 2 paquetes más:
| |||||||||||||||
| El siguiente de los subpaquetes es «ScoringEligibility«. No necesitamos la prioridad, son excluyentes las reglas:
| |||||||||||||||
PricingEs el siguiente paquete que se ejecuta, en este paquete nos encargamos de calcular las primas de los coches y de los conductores. No necesitamos prioridad
| |||||||||||||||
| |||||||||||||||
AnnualPremiumEn este paquete es donde calcularemos la prima anual. A este paquete habremos llegado si el cliente ha sido declarado «Elegible». Aquí si necesitan prioridad, porque necesitamos ejecutar unas reglas antes que otras.
| |||||||||||||||
En este orden se irán ejecutando las 4 reglas del último paquete:
|
