Todos ellos plantearon sus inquietudes al área de sistemas. El gerente de sistemas ingreso los requerimientos a la fila de problemas existentes pendientes de ser solucionados. Los priorizó, y al cabo de unos días les comunico a las distintas áreas del banco la cantidad de semanas que deberían esperar para recibir una solución a los diferentes pedidos. Al mismo tiempo se preguntaba sobre la posible existencia de una herramienta que le permitiera a cada usuario diagramar y configurar sus requerimientos por si mismo. Esto le permitiría poder concentrarse en los grandes temas de sistemas y no estaría inundado por un sinfín de cambios e implementaciones.

La gente de crédito, el gerente de cobranzas, el área de marketing, los directores, se preguntaban exactamente lo mismo: cómo podemos hacer para diagramar nuestras políticas y sus cambios minimizando la intervención de sistemas? Que podemos hacer para ser los dueños de nuestros procesos?

Un decision engine o motor de decisión permite que los usuarios puedan controlar la definición e implementación de sus objetivos, crear y testear reglas de negocios y monitorear el impacto de las mismas. Esta flexibilidad permite acortar el tiempo de respuesta a las circunstancias, y esto se traduce en mejores resultados.

Un motor de decisión debe permitir modelar los procesos decisorios. Las dos acciones centrales de todo proceso de decisión son filtrar y segmentar. Filtrar significa definir un conjunto de condiciones mínimas que una solicitud o cuenta debe cumplir para continuar con el análisis, para no ser descartada del proceso. Un buen decision engine debe facilitar la diagramación y ejecución de los filtros. Debe ser flexible, permitir combinaciones de filtros, y contener una semántica o forma de definir los filtros que sea natural al lenguaje común. Cuando el gerente de crédito quiere bajar la edad mínima de 21 a 18 años para la obtención de una tarjeta de crédito, en definitiva pretende que alguien de su área simplemente ingrese a una pantalla y donde decía “edad >= 21 años” escriba “edad >= 18 años”.

La posibilidad de segmentar se representa mediante un árbol de decisión. Este último simboliza la gradual segmentación de un grupo o unidad. Imaginemos que tomamos a todas las tarjetas de crédito y las segmentamos de acuerdo al límite otorgado, luego algunos (o todos) los subgrupos serán divididos de acuerdo a la edad del tarjeta habitante, y finalmente segmentaremos en base a cierta información del bureau de los clientes. El motor de decisión debe permitir la segmentación de acuerdo al criterio que quiera ser utilizado, no debe restringir el número de segmentaciones y debe ser amigable como para que segmentaciones complejas que cuenten con una gran cantidad de niveles puedan ser interpretadas y modificadas sin problemas.

El propósito de la segmentación es el de diferenciar a los distintos perfiles de cuentas o solicitudes, para de este modo designar tratamientos o conjuntos de acciones apropiados para los perfiles definidos. Así en un árbol segmentador de cuentas morosas, los perfiles más riesgosos recibirán acciones mas duras en periodos de tiempo breves, mientras que los perfiles más proclives a pagar su deuda morosa recibirán acciones menos duras y con una prisa menor. El grafico siguiente muestra la estructura de un árbol de segmentación.


Otro postulado básico de los motores de decisión es el de poder generar nuevas variables, es decir, nueva información. Las variables podrán crearse a partir de la combinación de variables existentes en las bases de datos del banco o a partir de nuevas variables creadas anteriormente. Las mismas serán creadas por los empleados de las distintas áreas del banco, en un lenguaje natural. Por ejemplo para generar la variable Utilización del Limite, simplemente bastara con definirla como Saldo / Limite.

La incorporación de scorecards o modelos predictivos constituye un caso especial de nuevas variables. El motor de decisión debe facilitar la definición de las características del modelo predictivo, los intervalos en los que se divide el valor de las características, y los puntajes o pesos asociados a cada intervalo. Por ejemplo, un scorecard podría predecir la probabilidad que una cuenta no se atrase en sus pagos más de 90 días en los próximos seis meses. Una de las características podría ser la edad del cliente, la cual en su intervalo de 18 a 25 años podría tener un peso de 20 puntos. El decision engine calculará el score y facilitará la comparación con un cut off o valor umbral.

La funcionalidad champion/challenger o campeón/desafiante permite la ejecución en paralelo de distintas versiones o estrategias de un proyecto. El motor de decisiones facilitará la asignación en forma aleatoria de las distintas versiones a las cuentas o solicitudes. En forma amigable deberá proponer la definición de los porcentajes de cuentas o solicitudes que serán tratadas en cada versión de un proyecto. Por ejemplo un proyecto para determinar aumentos en los límites de una tarjeta de crédito podrá tener una versión campeona, más conservadora, la cual será asignada al 80% de las cuotas de cierta cartera, mientras que la versión desafiante, de política menos conservadora, será asignada aleatoriamente al 20% restante de la cartera.

La existencia de estrategias corriendo en paralelo permite desarrollar una forma de trabajo que procure una mejora constante, ya que las actuales versiones campeonas serán reemplazadas por versiones desafiantes, y estas a su vez serán desafiadas por nuevas versiones y eventualmente reemplazadas.

La substitución de una estrategia o versión campeona por una desafiante solo tendrá lugar si esta última supera a la anterior en el cumplimiento de los objetivos del negocio. Esto implica que se debe tener la posibilidad de monitorear las versiones de un proyecto y medir la performance de cada una. Solo la existencia de reportes flexibles, configurables por el usuario no técnico, y de clara interpretación, permitirá medir correctamente, comparar y actuar en consecuencia. El decision engine debe facilitar la creación de reportes.

También el motor de decisión deberá permitir la realización de simulaciones o experimentos del tipo what if. Esta funcionalidad permitirá estimar los resultados de una nueva versión de un proyecto sin la necesidad de ponerla en producción. Por ejemplo una nueva estrategia de cobranzas más intensa en llamados telefónicos puede implicar la necesidad de contratar más recursos y agrandar la infraestructura. Al simular los resultados se podrá ver esta necesidad adicional de recursos. Que habría pasado si se hubiera puesto esta nueva estrategia directamente en producción?

Finalmente un decision engine debe ser flexible y universal en cuanto a sus requerimientos técnicos. La condición de ser multi-plataforma y web based facilita la implementación y el uso del motor de decisión, respectivamente.

Participé en la implementación de motores de decisión en bancos, procesadores de tarjeteas de crédito y retailers desde Canadá hasta Chile y Argentina. Personalmente pude ver los resultados obtenidos por los usuarios tanto en la iniciación crediticia como en los procesos de gerenciamiento de cuentas y cobro de cuentas morosas. La automatización, minimización de la dependencia del área de sistemas, posibilidad de trabajar con versiones campeonas y desafiantes, y el generar reportes con facilidad y de acuerdo al gusto de cada área, promovieron un aumento en las ganancias de las instituciones financieras y un rápido recupero de la inversión realizada en la implementación del motor de decisión.

Saza Solutions desarrolló DES, una plataforma para toma de decisiones crediticias, de cobranzas, marketing y pricing, dirigido a distintas industrias como ser bancos, retailers, seguros, telecomunicaciones, etc.