REGLAS DE NEGOCIO

Autor: Mario Saffirio

Desde hace, al menos veinte años, existen artículos referidos a las Reglas de Negocio que las describen desde una
perspectiva del "negocio" o con un enfoque de "sistemas". En este artículo pretendo mostrar como incorporarlas
en un proyecto de implementación de procesos de negocios, para ello incluiré algunas definiciones comúnmente
aceptadas a objeto de tener un mismo entendimiento, presentaré un método de recopilación y una lista de los usos
posibles de éstas.

En primer lugar, tenemos que entender que las Reglas de Negocio siempre han estado presentes, lo que ocurre que
se han denominado de distintas maneras y se han tratado de manera parcializada. Es así como las tenemos en:

 Parámetros, por ejemplo tasas de impuestos, porcentajes de descuentos , listas de valores posibles,
etc.
 Procedimientos, flujos, rangos de autorización, instrucciones, manejo de excepciones, etc.
 Datos, características del dato, clasificaciones, elementos que indican como tratarlo, p. ej: activo fijo,
producto para la venta, materia prima, etc.

Al no estar presente el concepto de Reglas de Negocios en un proyecto de implementación tradicional de un ERP

se genera una dispersión de la información correspondiente a las Reglas de Negocio, y una dilución de la
responsabilidad de su mantenimiento y documentación.

La dispersión de la información se genera porque al no considerar el concepto en cuestión, las reglas se tratan en
distintos objetos como ser: herramientas para la parametrización de un sistema, programas (codificación en
duro - hardcore), estructuras de datos, reglamentos, manuales de procedimientos, conocimiento de los usuarios,
entre otros. A su vez la dilución de las responsabilidades se genera por el proceso de generación; que nos es
sistemático en cuanto a la recopilación, identificación de los responsables y a la forma de documentar. En
resumen, se mezclan responsabilidades propias del Negocio con las de Informática.

Por tanto, propongo que en un proyecto de implementación de procesos de negocio se incluya una tarea con
un método sistemático para la recopilación y documentación de las Reglas de Negocio, tal que tanto las áreas del
negocio, de auditoría e informática cuenten con una fuente única y válida para estos efectos.

En otras palabras a las dimensiones básicas de un proceso de negocio: Transacciones (Software) , Organización
(Estructura y Roles) y Procedimientos (Gobernabilidad) estaremos agregando la 4ta D, es decir, las Reglas de
Negocio.

Definiciones .
En general, todo el mundo sabe que es una "Regla de Negocios", literalmente, es aquello que usamos para operar
un negocio. Son las guías que determinan como se lleva el día-a-día de las operaciones. Sin reglas se estaría en
una situación en la que cada decisión se resuelve en el momento, eligiendo alternativas caso a cado o ad-
hoc, Y, este modo de operar es muy lento, costoso y puede generar resultados inconsistentes.

Para el término "Regla de Negocio" se tiene que para un especialista en procesos de negocio puede significar
un conjunto de requerimientos asociados con los procesos, que están o no formalizados en una gramática o
taxonomía por algún tipo de mecanismo. Para el especialista en Base de Datos, puede ser un requerimiento
específico que se satisface mediante la definición de alguna característica de los datos, que expresará en los valores
posibles de un determinado campo. Y, para la gente del negocio no son más que la "manera de hacer las cosas".

Una Regla de Negocio define o limita un aspecto del negocio con el objeto de establecer una estructura o un grado
de influencia que condiciona el comportamiento de los actores del negocio. A menudo las Reglas de Negocio
están focalizadas en el control, en la forma de realizar los cálculos, otras permiten establecer las políticas, y así
se tienen en cualquier actividad del negocio, que requiera que la gente actúe de una forma pre-establecida

Qué NO son las Reglas de Negocio

Las Reglas de Negocio no son software. Las Reglas de Negocio pueden ser implementadas en el software,
pero esto a menudo representa sólo una parcialidad de sus definiciones , ya que partes importantes quedan
expresadas en los Procedimientos Manuales. También existe la posibilidad, poco común por ahora, de habilitarlas
mediante una Máquina de Reglas o un Sistema Experto. De modo que se debe entender que efectivamente las
Reglas del Negocio, como su nombre lo indica, son parte del negocio y, no de alguna plataforma particular de
hardware / software que pudiera soportarlas.

Las Reglas de Negocio de no son "Proceso", de ninguna forma. Roger Burlton indica que: "Se debe separar el
flujo del conocimiento" . Dónde las Reglas de Negocio representan la parte conocimiento que guía al flujo, de aquí
su nombre de Regla de Negocio.

Recopilación
Dado que las Reglas del Negocio son conocimiento, su formulación -la acción de explicitarlas por escrito- es
un proceso de recopilación, entendiendo que están en la cabeza de los empleados, a diferencia del flujo que
habitualmente se documenta en un manual de procedimiento o en un workflow.

Podemos, entonces, decir que las Reglas de Negocio corresponden a un conocimiento tácito, por consiguiente
el proceso de recopilación consistirá en convertir este conocimiento que tienen las personas en conocimiento
explícito.

Es necesario tener presente que el poseer el conocimiento de determinadas Reglas de Negocio es poder. Y,
que por tanto su recopilación puede tener complicaciones.

Para proceder a la recopilación de las Reglas de negocios me parece un buen punto de partida tener en
consideración los principios denominados "The business rule approach" desarrollados por Ronald Ross , estos son:
• Deben ser explícitas y escritas .
• Expresadas en términos sencillos.
• Existen independientemente de los procedimientos y workflows (ej.: modelos).
• Se construyen a partir de hechos, éstos se definen a partir de conceptos, los que a su v ez se r epresentan
por medio de términos (ej.: glosarios).
• Guían o influencian el comportamiento conforme a una forma pre-establecida.
• Son motivadas por factores de negocios identificables e importantes .
• Son accesibles a las partes autorizadas (ej.: tienen dueños).
• Están en una fuente única (ej.: repositorio de reglas).
• Son especificadas por las personas que tienen directa relación con ellas y que poseen el conocimiento
relevante (ej.: los usuarios claves) .
• Son gestionadas -administradas- (ej.: son parte de la Gobernabilidad de los Procesos de Negocios)

Una manera simple para recopilarlas es utilizar alguna herramienta para modelar, p. ej.: modelos EPC, al cual se le
define un objeto denominado Regla de Negocio el que se enlaza con:

• Una función, esta ligazón permite relacionarla con Roles, secuencias de eventos y facilita su inclusión en
la generación de procedimientos a partir de los EPC.

A un documento -texto, planilla, etc.- donde se incluye la descripción detallada, para este efecto recomiendo utilizar
la formulación Rule Speak , que la pueden solicitar en español en el enlace indicado. Si bien, es cierto que algunos
expertos encuentran compleja la utilización de Rule Speak a mi parece que simplifican el proceso de
documentación, dado que las definiciones se especifican en español, con un expresiones sin ambigüedades.
Ejemplo de especificación de una Regla de Negocios usando Rule Speak.

El proceso de recopilación puede ser apoyado técnicamente por Business Process Expert (BPX) pero, la
responsabilidad sobre el contenido y mantenimiento de la Regla de Negocio es del Dueño de Proceso de
Negocio, quien puede obtener información detallada de las mismas por medio de los Usuarios Claves -
Key Users.

La etapa del proyecto de implementación de procesos de negocios en la cual me parece adecuado realizar
la recopilación de las Reglas de Negocios es la de Diseño o Business Blueprint .

Usos
Entre otros , el disponer de las Reglas de Negocio en un repositorio y formalmente descritas -por ejemplo

en ARIS, donde pueden ser un objeto conectado a una función en un modelo EPC y a documentos -por ejemplo
en SAP Solution Manager, con sus respectivas especificaciones- se logran los resultados siguientes:

 Visibilidad y transparencia de las definiciones de las Reglas de Negocio, tanto para la gente del
negocio como para la de informática.
 Gobernabilidad para las Reglas de Negocio: procedimiento para su creación y mantenimiento
sistemático con responsable único y del área de negocios.
 Mayor agilidad para abordar los cambios en el negocio.
 Facilitan las auditorías - recorridos- de los procesos de negocios.
 Lista de Reglas de Negocio por: Proceso, Responsable, Rol, Funciones.
 Clasificación por uso: Parametrización, Datos o Procedimientos.
 Documentación disponible centralizadamente.

Ejemplo de algunas Reglas de Negocio de un proceso de un banco son:

• El banco ofrece a sus clientes varios tipos de productos: cuentas corrientes, cuentas de ahorro y
préstamos . Es requisito imprescindible para que una persona sea considerada cliente que disponga de
al menos un producto. Si, llegado el caso, el cliente se da de baja y se elimina de la base de datos,
entonces se eliminará toda la información relativa a las cuentas en las que figura como titular
manteniéndose, por motivos estadísticos , la relativa a los préstamos .

• Todos los clientes tiene un nombre, una dirección, un tipo, una fecha de alta y se identifican por su
código de cliente. Los clientes del banco pueden ser de tres tipos diferentes: personas físicas, empresas
privadas e instituciones u organizaciones. En el primer caso, el código de cliente es el NIF y en los dos
últimos el CIF.
 Todos los productos se deberán poder gestionar desde cualquiera de las sucursales del banco. Para ello
se dispondrá de un identificador único de producto compuesto por el identificador de la entidad, un código
de sucursal y el número de producto que es un valor asignado por el empleado de la sucursal al contratar
el producto. Respecto a esto, interesa registrar la fecha de contratación de cada producto y quién es el
empleado que da de alta cada producto.
REGLAS DE NEGOCIO
//www.ibm.com/
Una regla de negocio es una condición que se debe satisfacer cuando se realiza una actividad de negocio.
Una regla puede imponer una política de negocio, tomar una decisión o inferir nuevos datos de datos
existentes.
Si utiliza IBM® lntegration Designer, puede formar soluciones de negocio integrativas sin programar
habilidades y desarrollar reglas de negocio en un entorno de programación gráfica.

Ejemplo de una regla de negocio

Un proveedor establecer el estado preferido de cada cliente y crea una regla de negocio para determinar
cuánto cuesta a cada cliente el mismo objeto. A continuación, se indican términos básicos que definen los
bloques de creación de cada regla de negocio: Condiciones
Una condición describe una situación o estado que se debe colocar en orden para que ocurra una acción
determinada. En este ejemplo, la condición es el estado del cliente.

Acciones
Una acción es el suceso resultante de la evaluación de la condición. Cada acción se enlaza únicamente con
la condición que le precede. En este ejemplo, la acción es la cotización del precio; es diferente para cada
una de las condiciones que se encuentran.

La interacción entre las condiciones y las acciones determina la forma de la regla de negocio. Si la condición
se cumple, se realiza la acción. Hay dos posibles formas, conjuntos de reglas y tablas de decisiones, las
cuales se describen a continuación.

Conceptos clave
Antes de empezar a utilizar este editor, debe comprender y conocer los conceptos claves relacionados con
las reglas de negocio:
• Grupos de reglas
• Conjuntos de reglas
• Tablas de decisiones
• Roles de negocio en el desarrollo de reglas de negocio
• Plantillas
• Planificación
Nota: Las reglas de negocio sólo se pueden desplegar en IBM Business Process Manager.

Grupos de reglas
Un grupo de reglas es el componente de implementación de nivel más elevado de una regla de negocio. El
grupo de reglas actúa como una pasarela para las reglas de negocio debido a que está expuesto como un
componente SCA en el entorno de ejecución.
El grupo de reglas define la interfaz y la operación que implementarán las reglas de negocio. Los conjuntos
de reglas y las tablas de decisiones que comparten un enfoque de negocio común se pueden recopilar bajo
un único grupo de reglas. Los conjuntos de reglas y las tablas de decisiones no se pueen invocar
directamente y sólo se podrían invocar a través de un grupo de reglas. Una de las funciones más importantes
del grupo de reglas es definir un rango de hora y fecha durante el cual se utilizará un conjunto de reglas o
una tabla de decisiones determinada.
Conjuntos de reglas
Un conjunto de reglas es un conjunto de reglas de negocio que se evalúan de forma secuencial. Hay dos
tipos de reglas que se pueden utilizar en un conjunto de reglas.
Regla lf-then
Regla en la que if es la condición y then es la acción. Sólo se realiza la acción si la condición se evalúa
en true.

Reglas de acción
Una regla de acción es una regla en la que la acción siempre se realiza.
Un conjunto de reglas if-then es un conjunto de reglas o sentencias textuales en las que if es la condición de
la regla y then es la acción.
En el primer ejemplo que mostraremos se utiliza un conjunto de reglas if-then:

En el entorno de ejecución, cada regla se evalúa de forma secuencial y se lleva a cabo cada condición que
se evalúa en true, lo cual podría resultar en más de una acción. Un ejemplo de ello puede ser un esquema
de fidelidad de cliente en el que un cliente
que realiza una compra siete semanas de cada diez recibe un regalo y un cliente que realiza una compra en
todas las diez semanas recibe un descuento adicional de 10% para futuras compras. Los clientes que
realizaron la compra en todas las diez semanas evalúan en true ambas condiciones y reciben ambos
incentivos.

Tablas de decisiones
Otra forma que puede tener una regla de negocio es una tabla de decisiones.
Igual que el conjunto de reglas if-then, la tabla de decisiones es controlada por la interacción de condiciones
y acciones. No obstante, en una tabla de decisiones, más de una condición decide la acción. La lógica
condicional está representada en una tabla donde las filas y las columnas se cruzan para determinar la
acción apropiada. Cada columna representa una condición. En una tabla de decisiones, se pueden evaluar
distintas condiciones pero sólo actúa una acción.
Por ejemplo, en este ejemplo el estado del cliente está representado por las filas de la tabla, y la cantidad
potencial de dinero que el cliente gasta está representada por las columnas. Durante la transacción, el cliente
recibe un descuento mayor cuando él o ella compran más elementos. El descuento dependen del estado del
cliente. La tabla de decisiones impone este comportamiento de regla de negocio a través de la intersección
del estado (filas) y elementos comprados (columnas) . La primera columna muestra que los resultados de
cada intersección es el mismo que el del conjunto de reglas if-then: si el cliente con el estado bronce compra
menos de 20 elementos, paga 5 dólares por cada elemento; si el cliente con el estado plata compra menos
de 20 elementos, paga
4 dólares por cada elemento· mientras ue el cliente con el estado oro pa a 3 dólares por cada elemento.
A continuación se describen algunos conceptos exclusivos de las tablas de decisiones:
Condición Otherwise (de lo contrario)
Si utiliza una condición Otherwise, puede planificar por adelantado al diseñar la tabla de decisiones y
anticipar situaciones en las que las condiciones no produzcan una acción . Por ejemplo, si un cliente no
tiene un estado, al menos según la tabla, puede cambiar la fila bronce para que utilice la condición
otherwise, de modo que el cliente que no tenga un estado plata u oro reciba automáticamente los precios
que normalmente recibe el cliente bronce.
Regla de acción de inicialización
Si utiliza una regla de acción de inicialización, automáticamente se lleva a cabo una operación determinada
cuando los datos pasan a una tabla de decisiones. También puede crear reglas de acción de inicialización
en plantillas de modo que pueda modificar la regla en el tiempo de ejecución.

Roles de negocio en el desarrollo de reglas de negocio

Debido a que varios usuario desarrollan y mantienen las reglas de negocio, debe crear roles que indiquen
las distintas maneras en las que los distintos usuarios crean, implementan y modifican reglas de negocio y
cómo estos usuarios interactúan al trabajar con una regla de negocio.
Hay dos roles principales para trabajar con reglas de negocio:
Analista de negocio
El analista de negocio debe tener conocimientos sobre lenguajes de programación de sistemas para poder
crear reglas de negocio. El analista aplica sus conocimientos sobre cómo funciona el negocio para crear
políticas de negocio y reglas de negocio. Cuando se hayan desplegado estas reglas en un servidor, el
analista aplica sus conocimientos sobre el entorno de negocio y utiliza herramientas de gestión basadas en
web para las reglas sigan siendo relevantes.
Desarrollador de integración
El desarrollador de integración utiliza sus conocimientos de programación de sistemas para implementar y
desplegar las reglas que el analista de negocio ha creado. Durante la implementación de reglas, el
desarrollador de integración utiliza plantillas para determinar los detalles que puede modificar
posteriormente otro analista de negocio y escribe mensajes que ayudarán a dicho usuario a hacer las
anotaciones.

Figura 1. Cómo interactúan dos roles distintos cuando se trabaja con una regla de negocio

Plantillas
Una de las responsabilidades del analista de negocio es hacer que las reglas de negocio sigan siendo
relevantes. Esto es especialmente necesario cuando un entorno de negocio debe ser dinámico para
satisfacer las necesidades de negocio siempre cambiantes. Por ejemplo, su empresa puede tener que ajustar
periódicamente los precios de venta para que sean equiparables a los precios de la competencia. Después
del despliegue , es posible que todavía necesite modificar los precios u otras propiedades . Casi nunca es
factible o rentable obtener un desarrollador de integración para realizar cada ajuste.
Para poder crear reglas de negocio que se pueden modificar dinámicamente en el tiempo de ejecu ción, las
reglas·de negocio se deben basar en plantillas. Las tablas de decisiones también se podrían modificar
dinámicamente en el tiempo de ejecución si se basan las condiciones o acciones de la tabla de decisiones
en plantillas.
Una plantilla define las partes de una regla de negocio desplegada que pueden modificar un usuario
autorizado. La plantilla utiliza parámetros y restricciones para proporcionar dinamismo. Los parámetros y las
restricciones definen qué valores que se pueden modificar y en qué medida.
Parámetros
Los parámetros son elementos de la regla de negocio que se pueden modificar dinámicamente. "price"
(precio) sería un parámetro si desea ajustar el precio de venta para equipararse a un competidor.
Restricciones
Se trata de una restricción en una plantilla que limita por cuánto se puede modificar un parámetro
determinado. Hay dos tipos principales de restricciones:
• Restricciones de rango
• Las restricciones de rango se aplican a parámetros numéricos utilizados en reglas. Un usuario
autorizado puede ajustar un parámetro pero dicho parámetro se debe mantener dentro de un
determinado rango numérico. Por ejemplo, si sabe que su producto cuesta 100 al fabricante , el rango
de precios podria estar entre 105 y 500.
• Restricciones de enumeración
• Las restricciones de enumeración se encuentran en una lista que puede ser numérica o textual. El
usuario autorizado debe elegir una de las opciones de la lista. Por ejemplo, el usuario podría mejorar
la capacidad de crédito de un cliente de "plata" a "oro".
•
Figura 2. Ejemplo de una plantilla que restringe una regla de negocio

En este ejemplo, el Proveedor A puede utilizar la plantilla de regla de negocio para ajustar el precio del
elemento para superar los precios del Proveedor B. No obstante , cuando el Proveedor B intenta hacer
algo similar, la restricción de la plantilla de regla de negocio no lo permitirá. La restricción no permite que
haya un precio inferior al precio que hay actualmente .

Planificación
Cuando los cambios realizados en las reglas de negocio son obligatorios y esperados, también puede diseñar
reglas y desplegarlas en el servidor , de modo que pasen a ser activas cuando sean necesarias . Esta
funcionalidad es importante cuando, por ejemplo, los analistas de negocio tienen que estar preparados para
los cambios en regulaciones de tasas gubernamentales que no entrarán en vigor hasta el primer día del año,
o (tal como se muestra en el ejemplo siguiente) , cuando un precio especial entra en vigor sólo durante un
día especial.

Figura 3. Ejemplo de como una regla de negocio se puede crear para ser utilizada posteriormente