Cómo construir un modelo de Comisión utilizando DecisionRules Parte II
Implementación
Las comisiones se recalculan típicamente una vez al mes como base para los pagos a empleados. Pero con DecisionRules, puedes realizar estos cálculos en cualquier momento durante el mes a nivel de equipo o de corredor individual para aumentar su motivación.
Estructura del modelo
La solución debe ser capaz de calcular tres modelos de comisión diferentes. Para definir este comportamiento complejo por un lado y simplificar la integración por el otro, hemos implementado una estructura de reglas jerárquica.
- La 1ª capa representa la regla principal (Calcular comisiones) que es responsable de la integración en ambas direcciones, EN y FUERA, y ejecuta reglas en las siguientes capas.
- La 2ª capa define diferentes modelos de comisión y contiene una lista de todas las reglas en cada modelo.
- La 3ª capa contiene las reglas finales que calculan la comisión final basada en los datos de entrada. Se crea una regla para cada tipo de producto en esta capa. Es posible definir varias versiones de una regla para cada tipo de producto y activarlas o desactivarlas según sea necesario.
1ª capa
La regla Calcular Comisiones está diseñada para evaluar todas las reglas aplicables para una entrada masiva, lo que significa que la entrada contiene todas las cuentas y/o acuerdos de un corredor. Sin embargo, siempre es posible evaluar cualquier regla de forma aislada si es necesario o más fácil para la implementación.
La regla tiene una propiedad de entrada commissionType que determina el tipo de comisión que se calculará, por lo que para cualquier subconjunto de estas comisiones la entrada puede permanecer igual.
Esta regla no está destinada a ser cambiada, a menos que el modelo cambie significativamente, como cuando se agregaría otro tipo de comisión. Si la estructura de las comisiones permanece igual y solo se eliminan o agregan reglas, entonces solo el esquema de entrada cambiaría para reflejar la estructura de tus datos de entrada.
2ª capa
Esta capa organiza las reglas en modelos de comisión individuales. Hay tres tablas, cada una para un modelo de comisión. Cada tabla contiene una lista de todos los ids de reglas de comisión activas. Solo las reglas actuales en estas tablas serán evaluadas.
La tabla para comisiones de Mérito también contiene una columna, donde se puede establecer un grupo de exclusividad. Esta característica permite definir más reglas para un caso. Todas las reglas de este grupo de exclusividad se evalúan al mismo tiempo y solo la que tenga la mayor comisión será otorgada. Esto crea una opción para diseñar múltiples niveles de comisiones de Mérito.
3ª capa
La última capa contiene la lógica real para evaluar las comisiones. Estas reglas son llamadas desde el script orquestador Calcular Comisiones. Pero también existe la posibilidad de evaluar todas ellas por separado si surge la necesidad.
Todas las comisiones tienen una regla separada donde se almacena su lógica, por lo tanto, cualquier regla puede ser modificada de forma independiente.
Gestión de reglas de comisión
Esperamos que el número de reglas aumente. Puede ser beneficioso para un usuario de negocio que pueda ver la oportunidad de desatar su creatividad. Para un administrador de aplicaciones, esto podría convertirse rápidamente en un dolor de cabeza. Por eso hemos introducido algunas técnicas para mantener el número de reglas en un nivel manejable.
Variables de regla
Para cada regla, podemos definir una variable de regla que resulta útil cuando un solo valor se utiliza en múltiples secciones de un algoritmo, o cuando hay necesidad de modificar fácilmente atributos significativos como el monto de la comisión.
Un buen ejemplo puede ser un porcentaje de comisión utilizado como parte de una condición en la regla Comisión de ventas - Venta de préstamo como se describió anteriormente. Usando una variable, podemos cambiarlo al mismo tiempo reduciendo la posibilidad de un error potencial.
Las variables de regla también pueden ser utilizadas de la misma manera que si fueran parte de la entrada.
Activar/Desactivar comisión
Como se describió anteriormente (Estructura del modelo - 2ª capa), solo se evalúan las reglas presentes en las tablas de Listas. Eso proporciona la posibilidad de gestionar fácilmente las comisiones activas; todo lo que el administrador tiene que hacer para desactivar una regla de comisión es desactivar su registro en esta tabla.
También es posible establecer un tiempo de activación para una regla particular, lo que da la opción de crear promociones limitadas en el tiempo o variar la configuración de la comisión según la temporada.
Modelos de Entrada/Salida
Los datos de entrada están estructurados alrededor del corredor. Toda la información para el procesamiento de comisiones se envía en un solo lote y también las comisiones para corredores individuales se evalúan de una vez. La estructura de datos se crea como un array, por lo que es posible procesar diferentes tipos de comisiones para un solo corredor, un tipo de comisión para múltiples corredores o cualquier otra combinación.
Modelo de datos de entrada
La estructura de entrada se establece en el Modelo I/O de la regla principal - Calcular Comisiones. La entrada se divide en tres partes: Tipo de comisión, un parámetro crítico que determina el modelo de comisión utilizado. Los valores posibles son: "VENTAS", "MÉRITO", "INGRESOS" Acuerdos - información necesaria sobre los acuerdos realizados. Esta estructura debe contener todos los datos requeridos por las reglas particulares que se van a evaluar. Corredor, proporcionando información sobre el corredor que realizó el acuerdo. Esa información es útil tanto para el procesamiento de comisiones, donde el monto de la comisión puede depender del rango del vendedor (por ejemplo), como también para fines de reporte.
La propiedad CommissionType es obligatoria en el procesamiento de comisiones. El contenido de las propiedades Deals y Consultant es variable y depende de la regla y los parámetros significativos para la lógica de negocio de la comisión.
Modelo de salida
Mientras que la estructura de entrada tiene algunos componentes obligatorios y muchos parámetros opcionales que varían según el modelo de comisión, la estructura de salida siempre será la misma:
- fecha de evaluación
- la sucursal en la que trabaja el corredor
- identificación del corredor
- Array de comisiones otorgadas al corredor
Modelo de Entrada/Salida de Reglas de Comisión
Cada regla puede tener un conjunto diferente de entradas para evaluar, por lo que la estructura de entrada es variable. Si echamos un vistazo a un ejemplo de la comisión de ventas SC_LOAN, su modelo de entrada se ve como el de la imagen no.1
La salida de cada regla de comisión tiene la misma estructura para hacer la salida final uniforme y simple de integrar. Puedes ver el modelo de salida en la imagen no.2 
Imagen no.1
Imagen no.2
Ejemplo de Reglas de Comisión
Echemos un vistazo a las reglas en la 3ª capa que definen la lógica de negocio de las comisiones individuales. Cada modelo de comisión tiene sus especificidades así como cada clase de producto tiene las suyas.
Para cada ejemplo describiremos los datos de entrada necesarios, la lógica y parámetros establecidos y también la salida de la regla.
Mientras que las estructuras de entrada a menudo variarán dependiendo del tipo de modelo de comisión, la salida será esencialmente la misma. Todas las reglas que hemos pretendido presentar pueden ser fácilmente establecidas en una forma simple de estructura de árbol, por lo que no hay necesidad de habilidades de programación. Esto puede ser útil para organizaciones donde los recursos de TI son muy escasos. Ten en cuenta que, como para cualquier otra herramienta de TI, se recomienda encarecidamente involucrar a un administrador de aplicaciones en el proceso de desarrollo de nuevas reglas.
Comisión de ventas - Venta de préstamo
La comisión de venta de un préstamo en nuestro caso se calcula a partir de tres entradas básicas:
- monto del préstamo, o el límite de crédito
- monto retirado
- y el tipo de producto
Puede haber varios otros parámetros para calcular la comisión, pero hemos decidido usar una regla simple.
Para facilitar el mantenimiento, también se definen dos variables de regla. Una define los valores porcentuales para la tasa de comisión, que se utiliza para calcular el pago de la comisión, y la otra especifica la proporción mínima del monto desembolsado.
Esta regla está construida en forma de un árbol de decisiones y su implementación toma la siguiente forma:
Condiciones
Solo hay una condición que verifica si el número de clientes excede el umbral predefinido.
Usamos la función ARRAY_FILTER para filtrar cualquier cuenta donde la propiedad newClient no sea verdadera, luego contamos estas entradas y verificamos si el conteo es mayor o igual al valor del umbral definido en las variables de regla como ACC_COUNT_THRESHOLD.
Resultado Positivo
Si se cumple la condición, entonces el valor de la comisión se establece en un valor predefinido (en nuestro caso 30.000) y la propiedad awarded se establece en verdadero.
Resultado Negativo
Si la condición no se cumple, entonces el valor de la comisión se establece en 0, la propiedad awarded se establece en falso y se genera un mensaje bajo el razonamiento que dice "No hay suficientes nuevos clientes" con el número de nuevos clientes que el corredor ha logrado.
Integración
DecisionRules se integra a través de Restful API (documentación). Para los propósitos de nuestro estudio de caso, aprovecharíamos el procesamiento masivo de conjuntos de datos más grandes. Además, también existe la posibilidad de llamar a una sola regla para un solo acuerdo. Eso podría ser útil en situaciones donde un corredor necesita validar el monto de la comisión para un acuerdo que pretende realizar.
Llamadas a la API
La comunicación con DecisionRules que maneja volúmenes de datos más grandes implica aprovechar una solución de middleware para facilitar la comunicación fluida entre DecisionRules y la fuente de datos. Esta herramienta intermediaria gestionará la transmisión de datos, asegurando un intercambio seguro y eficiente de información y manteniendo la integridad de los datos.
La respuesta de la llamada a la API contiene una estructura de salida predefinida descrita anteriormente en detalle. Después del procesamiento en el componente de middleware, puede ser utilizada como fuente para otros procesos de negocio para aprobar las comisiones y pagos.
Para probar la solución, podemos usar la herramienta https://www.postman.com/ para imitar el middleware, visualizar la respuesta recibida y probar la lógica de trabajo dentro de DecisionRules.io.
Una llamada desde una aplicación de postman puede verse así.
… y la respuesta de la regla de comisión de ventas:
Reporte
Los propietarios de negocios necesitarán un conjunto de informes que proporcionen información sobre la suma de la comisión a pagar y también información detallada sobre un caso único para poder decidir posibles quejas.
Power BI será nuestra arma elegida.
DecisionRules.io es capaz de almacenar información detallada sobre cada procesamiento de regla individual, incluidos los datos de entrada y la salida calculada. Este tipo de datos se almacenará en forma de registros de auditoría. Estos registros pueden ser recuperados a través de la API y procesados para informes en Power BI. Encuentra más sobre los registros de auditoría en nuestra documentación: enlace
En nuestro ejemplo, la regla registra alguna información básica sobre el corredor junto con todos los datos utilizados en la evaluación de la regla, monto de la comisión, nombre y tipo de la comisión, la fecha en que se otorgó la comisión y información básica anónima sobre la cuenta o cliente.
Conclusión
En este artículo, hemos descrito cómo se implementan los modelos de comisión en DecisionRules y hemos descrito en términos generales cómo funciona el modelo y la forma de evaluarlo. También hemos abordado el reporte de resultados de comisiones.
Mencionamos que DecisionRules.io no es una herramienta única que resolverá todos los aspectos del proceso de comisión, pero podría ser la crítica que contendrá y gestionará el valioso conocimiento.
En la siguiente y última parte de esta serie, profundizaremos en la implementación en DecisionRules.io para que puedas probarlo por ti mismo y experimentar con varios modelos de comisión.