h1

Modelado de reglas de negocio: un enfoque práctico

04/10/2010

Wizdoc [Icon By Buuf] Tips & Tricks.

Usted pregunte a cualquier gerente o trabajador de la industria [de software] lo que significan los requerimientos para desarrollar sistemas, y típicamente obtendrá respuestas centradas en características y funciones, o el look and feel de interfaces gráficas de usuario. La respuesta "vocabulario de negocio" (o "vocabulario de negocio compartido") nunca se encuentra entre las respuestas. Sin embargo, un vocabulario de negocio compartido y bien estructurado es de hecho un requisito.

— Ronald G. Ross.
Business Vocabulary: The Most Basic Requirement of All.
Agosto 2009.

Desde hace algún tiempo estoy apoyando en la implementación de un sistema web de gestión de reembolsos y cirugías programadas para cierta aseguradora de renombre. Como parte de este sistema se debe automatizar el dictamen de reclamaciones realizadas por los clientes, requiriendo la implantación de un motor de reglas de negocio para determinar el sí o no definitivo así como el monto a pagar en una reclamación. Resulta que la industria de los seguros médicos se mueve en base a catálogos de enfermedades y sus tratamientos, incluyendo inventarios de procedimientos quirúrgicos y medicamentos – conocidos en el medio como "nomenclátor". Por otro lado, la parte del billete se define en base a un índice de fórmulas – denominada "baremo" – que dependen de una larga lista de condiciones para ser aplicadas. Todo esto es usado para ejecutar un proceso que incluye detección de anomalías y generación de un resultado. Claro que para ejecutar dicho proceso, primero necesitamos saber QUÉ reglas de negocio deben utilizarse.

Por qué modelar

Pues bien, resulta que como de costumbre, el área de negocio conoce los procesos necesarios a implementar, pero dichos procesos están muy mal documentados, la documentación no está actualizada o de plano no existe. Entonces, incluso con la mejor disposición del cliente, siempre existirá el tema de cómo modelarlas: en casos de reglas de negocio altamente dinámicas y complejas siempre se recomienda que el usuario mismo sea el que documente sus procesos, pero la mayoría de la gente en estas áreas desconoce herramientas como BPML y capacitarlas puede ser todo un reto. Por ello, la necesidad de modelar las reglas de negocio de manera fácil de entender e implementar. Obviamente se requiere un tiempo para que el usuario de negocio aprenda a modelar, pero siempre será menor que tratar de enseñarle a manejar un gestor de reglas de negocio, un lenguaje de modelado como BPML o BPMN y encomendarse a Dios para que todo salga bien.

Por otro lado, el esfuerzo de documentar reglas de negocio mediante un lenguaje de modelado sencillo siempre reditúa en una base de conocimientos bien documentada que además de permitir la automatización de las tareas, forma el core de cualquier área de negocio: si se tienen bien definidos los procesos, es posible visualizar oportunidades como predictibilidad, optimización y mejora continua. En nuestro caso particular y egoísta, el modelado es necesario para determinar el alcance del proyecto y poder decir: "tú me definiste y documentaste esta regla, así que si algo salió mal, es tu culpa".

Modelando: ¿Por dónde empezamos?

Lo primero que debemos hacer es definir un lenguaje de negocio común que todos podamos entender. Por ejemplo, en el mundo de las aseguradoras, debemos saber qué es un baremo, qué es un nomenclátor y qué entidades participan dentro de un proceso de dictamen. Así, obtenemos un diccionario como el presentado a continuación:

Cobertura (coverage). Ver Garantía.

Garantía (guarantee). Compromiso aceptado por un asegurador en virtud del cual se hace cargo, hasta el límite estipulado, de las consecuencias económicas derivadas de un siniestro. Es también sinónimo de seguro (estar garantizado es igual que estar asegurado) o de capital asegurado (la garantía de la póliza es igual que el capital asegurado por ella). También es sinónimo de cobertura.

Factura (invoice; bill). Documento extendido por el vendedor al comprador en el que indica fecha de venta, nombres de vendedor y comprador, identificación, descripción de la mercancía vendida, cantidad, precio, descuentos e impuestos.

Siniestro (loss; claim). Es la manifestación concreta del riesgo asegurado, que produce unos daños garantizados en la póliza hasta determinada cuantía. Siniestro es el incendio que origina la destrucción total o parcial de un edificio asegurado; el accidente de circulación del que resultan lesiones personales o daños materiales; el naufragio en el que se pierde un buque o las mercancías transportadas; el granizo que destruye una plantación agrícola, etc. Siniestro es pues, un acontecimiento que, por originar unos daños concretos previstos en la póliza, motiva la aparición del principio indemnizatorio, obligando a la entidad aseguradora a satisfacer, total o parcialmente, al asegurado o a sus beneficiarios, el capital garantizado en el contrato. …

Un diccionario o vocabulario de negocio, específico del área de seguros. (Fuente: Diccionario MAPFRE de Seguros)

Cabe destacar que este no es el diccionario que usamos en nuestro proyecto (ni tampoco el mismo cliente, dicho sea de paso) pero en términos generales, nos da una idea de lo que se debe recopilar y documentar.

Luego, dentro del vocabulario se pueden obtener los productos y entidades específicos para realizar un proceso, tales como Factura, Reclamación, Incidencia, Siniestro, Asegurado. También de manera natural se descubre qué atributos o características intervienen en el proceso, como moneda, concepto y monto de una Factura; fecha de inicio y de fin de vigencia de una Póliza o fecha de ocurrencia y diagnóstico de un Siniestro. Aquellos que conocemos la programación orientada a objetos sabemos que UML es ideal para modelar estas entidades, pero con el afán de simplificar, un Excelazo puede hacer maravillas de cara al cliente:

Entidad Origen de datos
Origen Interfaz Web Service
Objeto Atributo Sistema Atributo Tipo Longitud (BDD) Longitud (Java) UDDI Binding Key
Asegurado fechaAlta L001 fecha_alta Date NA 64 http://produccion.mx/uddi/api/inquire.asmx f46fced9-2b8a-4817-b957-f8d8aca0a2f9
Asegurado fechaNacimiento L001 fecha_nacimiento Date NA 64
Asegurado numPoliza L001 num_poliza String 20 320
Asegurado sexo L001 sexo Char 1 1
Asegurado tipo L001 tipo_persona String 6 96

En la tabla mostrada, se está modelando la entidad Asegurado, que posee atributos tales como fecha de alta (fechaAlta), fecha de nacimiento (fechaNacimiento) o número de póliza (numPoliza). Estos atributos provienen de un origen que generalmente es una tabla de base de datos. Sin embargo, algunos sistemas pueden publicar web services para facilitar la extracción de su información, en cuyo caso debe incluirse la dirección y llave necesarios para acceder a dicho servicio desde el directorio UDDI de un SOA. También se incluye en la tabla el datatype usado en el origen de datos, así como el que será empleado durante el proceso de ejecución.

Modelando las reglas

En su forma más simple, una regla de negocio posee varios parámetros de entrada, una validación entre éstos y de acuerdo a dicha validación, realiza una acción de salida. Por ejemplo, tenemos la siguiente regla de negocio como parte de un proceso real de dictamen y que nos fue proporcionado por el cliente para su modelado:

Si la reclamación contiene el número de siniestro se toma como una reclamación complementaria, en caso contrario se trata de una reclamación inicial.

Para modelar esta regla de negocio se identifican los siguientes elementos:

• Entidades involucradas: Reclamación.
• Parámetros involucrados: número de siniestro.
• Validaciones a realizar: si número de siniestro <> nulo
• Acción a tomar: modificar tipo de reclamación como complementaria.
• Caso alterno: modificar tipo de reclamación como inicial.

Esto en pseudocódigo se expresa como IF Reclamacion.numSiniestro != null THEN Reclamacion.tipo = complementaria ELSE Reclamacion.tipo = inicial y en un Excel puede quedar de la siguiente manera:

Descripción de la regla Criterios de validación (IF x AND y) Acción (THEN z) Observaciones
ID Nombre de la regla Descripción de la Regla Objetos de negocio Atributo Operador Operador Lógico Objetos de negocio Atributo Operador Valor Objetos de negocio Atributos Operador Operador Lógico Objetos de negocio Atributo Operador Valor Excepciones
M_1218_RN001 Asignación de tipo de reclamación Si la reclamación contiene el número de siniestro se toma como una reclamación complementaria, en caso contrario se trata de una reclamación inicial. Reclamacion numSiniestro <> VACÍO Reclamacion tipo 1 1. Todas las reclamaciones nacerán como Iniciales (tipo = 0) a menos que en esta regla se asignen como complementarias

Nótese que se está modelando un IF/THEN/ELSE de manera que un usuario de negocio pueda entenderlo y modelarlo.

Una regla un poco más compleja

Pero ¿qué ocurre cuando una regla posee varias validaciones? ¿Y si al validar una condición debe ejecutar caminos alternos? Este mismo formato de documentación de reglas de negocio permite acomodar mayor complejidad:

Para reembolsos, verificar que la factura esté cubierta por la vigencia de la póliza. En caso de ser correctos, verificar el periodo de prescripción de gastos; en caso contrario, registrar una incidencia.

En este caso, falta detalle – cómo generar una nueva incidencia, qué es la "verificación de periodo de prescripción de gastos" – pero podemos dejarlo igualmente como un IF/THEN/ELSE que podemos modelar así:

• Entidades involucradas: Póliza, Factura.
• Parámetros involucrados: echa de emisión de la factura, fechas de inicio y fin de la póliza.
• Validaciones a realizar: si fecha de emisión > fecha inicio póliza Y fecha de emisión < fecha fin póliza
• Acción a tomar: ejecutar la regla "verificar periodo de prescripción de gastos".
• Caso alterno: generar una nueva incidencia.

Que en pseudocódigo se expresa como IF Factura.fechaEmision > Poliza.fechaInicioVigencia && Factura.fechaEmision < Poliza.fechaFinVigencia THEN ejecuta "verificar periodo de prescripción de gastos" ELSE new Incidencia. Nótese que la ejecución de otras reglas de negocio a partir de una validación ya conforma procesos de negocio.

Descripción de la regla Criterios de validación (IF x AND y) Acción (THEN z) Observaciones
ID Nombre de la regla Descripción de la Regla Objetos de negocio Atributo Operador Operador Lógico Objetos de negocio Atributo Operador Valor Objetos de negocio Atributos Operador Operador Lógico Objetos de negocio Atributo Operador Valor Excepciones
S_1165_RN0156 Verificación de fecha de gasto Iniciales Para reembolsos, verificar que la factura esté cubierta por la vigencia de la póliza. En caso de ser correctos, verificar el periodo de prescripción de gastos; en caso contrario, registrar una incidencia. Factura
Factura
fechaEmision
fechaEmision
>
<
Poliza
Poliza
fechaInicioVigencia
fechaFinVigencia
AND S_1717_PN0218 En caso exitoso ejecutar regla S_1717_PN0218
ELSE Incidencia
Incidencia
Incidencia
Incidencia
Incidencia
nivel
idNivel
codigo
descripcion
severidad
=
=
=
=
=
Factura idFactura ‘FAC’

S_1165_RN0156{ID}
S_1165_RN0156{DESC}
‘FATAL’

Y bueno, con esto ya tenemos un modelado de tareas e incluso empezamos a conformar procesos de negocio más complejos.

Implementando las reglas

Y bueno, todo este modelado debe tener como objetivo el facilitar su implementación dentro de un gestor de reglas de negocio (Business Rules Management System – BRMS). Por ejemplo, la extracción de las entidades necesarias para un proceso de ejecución de reglas de negocio nos permitirá crear los POJOs (Plain Old Java Objects – objetos de Java planos y simples) necesarios para extraer información así como su uso dentro de dichos procesos. Usando el ejemplo de la entidad Asegurado de más arriba, tenemos el siguiente código en Java:

package com.cliente.mx.sistema.brvo;

import java.util.Date;

public class Asegurado {
private Date fechaAlta;
private Date fechaNacimiento;
private String numPoliza;
private char sexo;
private String tipo;

public Date getFechaAlta() {
return fechaAlta;
}
public void setFechaAlta(Date fechaAlta) {
this.fechaAlta = fechaAlta;
}
public Date getFechaNacimiento() {
return fechaNacimiento;
}
public void setFechaNacimiento(Date fechaNacimiento) {
this.fechaNacimiento = fechaNacimiento;
}
public String getNumPoliza() {
return numPoliza;
}
public void setNumPoliza(String numPoliza) {
this.numPoliza = numPoliza;
}
public char getSexo() {
return sexo;
}
public void setSexo(char sexo) {
this.sexo = sexo;
}
public String getTipo() {
return tipo;
}
public void setTipo(String tipo) {
this.tipo = tipo;
}
}

Clase de Java Plana y Simple o POJO definido para la entidad Asegurado.

Que utilizaremos como objeto de valor al extraer información de la base de datos y durante el proceso de ejecución. Por otro lado, con el modelado de las reglas podemos usar de manera más eficiente un BRMS, pues se tiene la "receta" para construir las sentencias de las reglas de negocio:

JRules Business Rule Definition

Definición de una regla de negocio en el BRMS ILOG JRules 7.0.1 de IBM.

Finalmente dentro de nuestro modelo, aquellas reglas que poseen como acción la ejecución de otras reglas, son los bloques constitutivos de procesos de negocio:

JRules Business Rule Flow

Definición de un flujo o proceso de reglas de negocio en el BRMS ILOG JRules 7.0.1 de IBM.

No detallaré en la implementación para un BRMS específico, pues además de ser el tema de un extenso tutorial, de momento lo que más nos interesa es el modelo de reglas con miras al entendimiento por parte del cliente. Sin embargo, al modelar debemos tomar en cuenta un par de puntos que nos pueden definir en gran medida cómo realizaremos el delivery:

• Hasta ahora hemos trabajado bajo el supuesto que las entidades de negocio existen y toda la información que las compone es accesible desde nuestro sistema. Un punto crítico para el éxito consiste en determinar justamente, a qué bases de datos conectarnos o qué servicios consumir para obtener esta información. En caso de sistemas como ERPs, CRMs o "legados", tendremos que sentarnos con el área IT correspondiente para cerrar temas de acceso, seguridad y desempeño; mientras más pronto, mucho mejor.

• Por otro lado, no todos los sistemas son iguales: algunas fuentes de datos de nuestros procesos de negocio trabajan por lotes mientras otras permiten ser llamadas en tiempo real. Saber de dónde vienen los datos de nuestro sistema puede hacer toda la diferencia. Por ejemplo, en nuestro caso particular nos dimos cuenta que no todos los sistemas que usábamos podían ser llamados en tiempo real, sobre todo por el pequeño detalle de que son sistemas endebles que no soportan mucha carga. Y si consideramos que nuestro sistema ejecuta un máximo de 1,166 reglas de negocio por segundo, teníamos un stopper en nuestras manos. Para resolverlo, existen varias opciones, pero propusimos dos: hacer todos los procesos mediante llamadas asíncronas a los sistemas que utilizan, o hacer una precarga de la información en bases de datos locales para después correr todo como un proceso por lotes. Como el cliente es más bien del tipo "legado", se decidió que la precarga era la mejor opción.

• Otro tema es la seguridad. Existen algunas reglas de negocio que no todos deberían poder ver, como el cálculo de primas o descuentos por antigüedad. Esto implica coordinarse con todos los involucrados desde un inicio para saber quién ve qué, y no llegar a malos entendidos con diferentes áreas usuarias.

• Finalmente, el BRMS. Los hay algunos muy buenos, pero si vamos por la opción de uno comercial, es indispensable que el cliente haya adquirido todas las licencias necesarias; si es posible, incluso antes de que empiece la etapa de construcción. En este proyecto, a alguien se le ocurrió decir que "somos partners de IBM", por lo que el cliente asume que ya tenemos las licencias para usar el producto. Sin embargo, "la realidad es un poco diferente" y aunque tenemos derecho a bajar algunas cosas, no podemos descargar la versión comercial del BRMS con estadísticas y funcionalidad completa, por lo que a la hora de sentarse a implementar nos dimos un par de topes contra la pared antes de llegar al punto de decir "si no consigues las licencias, no podemos continuar".

Conclusiones

Implementar reglas de negocio no es difícil, siempre y cuando sepamos qué plasmar en un "documento de reglas de negocio". Más cuando queremos que el usuario de negocio se haga cargo de la definición y documentación de la información, para que nosotros la automaticemos o mínimamente dentro de un proyecto de consultoría de negocios las usemos como parte de un plan de gobernabilidad de procesos. A final de cuentas, esto es para facilitarle la vida al cliente y a nosotros mismos, pues la siguiente es una gran verdad:

Nosotros tenemos un mantra: no seas malo, que significa hacer el mejor uso de nuestro know how para nuestros usuarios, nuestros clientes, para todos. Por ello, creo que si fuésemos conocidos por este mantra, sería algo fabuloso.

Larry Page, ingeniero de software y empresario estadounidense, co-fundador de Google, Inc.

One comment

  1. Excelente articulo!!!, me sirvio muchisimo



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: