Documentación Reglas de Negocio

[LEO]

Deseo documentar reglas de negocio durante el levantamiento de
procesos. No sólo con herramientas libres del mercado, sino en la
sintaxis y en el formato, que sea de manera clara orientada a personas
no expertas en procesos. ¿Alguien me podria dar una recomendación?

[Javier Bermudez]

Leo,

el tema que planteas es muy atingente, y lamentablemente no está completamente resuelto. Me he dedicado a investigar en el mercado desde hace un par de años alguna forma "estándar" de representar y ejecutar reglas de negocio. No he llegado a buen puerto.

Existe un acercamiento que hizo la OMG, lo puedes encontrar en su web. Sin embargo, no logré hacer algo útil con lo que encontré.

Creo que lo más razonable es tratar de usar alguna de las definiciones "propietarias", ya que hay buenas herramientas dando vuelta que permiten manejar reglas de negocio y conectarlas con sistemas de información existentes, como Drools u Openlexicon. Para reglas simples, muchas herramientas BPMS tienen un motor básico de reglas, y hay que escribirlas en su propio formato.

Si alguien tiene otra visión o ha usado algún "estándar" para representar las reglas, sería super bueno escucharlo.

Saludos!

Javier

2011/1/14 LEO <leosil...@gmail.com>

--
Saludos,

Javier Bermudez O.

[Felipe Piccolini]

Hay grupos que definen formatos mas o menos standard para esto, ademas
la mayoria de
los motores de reglas implementan el uso de tablas de decision o
arboles de decision...
en el caso de Drools la tabla de decision es una planilla excel con
columnas como:
-id regla
-nombre regla
-descripcion (en palabras del analista, lo que hace la regla)
-condicion [1..n] (puede haber mas de una condicion) (aqui se puede
hacer con palabras o con pseudo codigo)
-accion [1..n] (puede haber mas de una condicion) (aqui se puede hacer
con palabras o con pseudo codigo)
-Error o Excepcion (no se deben escribir reglas con "else", pero es
bueno markar como descripcion que pasa si hay un error de negocio)

ademas:
-Toda regla debe ser consisa y auto-contenida (debe tener toda la
informacion necesaria para resolverse)
-debe ser auto-explicativa
-debe ser independiente de otras reglas (puedes componer reglas, pero
una regla no debe preguntar por otra, puede preguntar por una
condicion que podria
ser definida por otra regla, pero la regla actual no debe saber de la
existencia de la otra regla).

Ademas, la suma de condiciones simulan un AND y entre una regla y otra
se construye un OR

Hay otras definiciones para reglas, pero no las recuerdo todas...

Espero que esto te ayude... Saludos.


On Jan 17, 12:41 pm, Javier Bermudez <javier.bermude...@gmail.com>
wrote:

> Leo,
>
> el tema que planteas es muy atingente, y lamentablemente no está
> completamente resuelto. Me he dedicado a investigar en el mercado desde hace
> un par de años alguna forma "estándar" de representar y ejecutar reglas de
> negocio. No he llegado a buen puerto.
>
> Existe un acercamiento que hizo la OMG, lo puedes encontrar en su web. Sin
> embargo, no logré hacer algo útil con lo que encontré.
>
> Creo que lo más razonable es tratar de usar alguna de las definiciones
> "propietarias", ya que hay buenas herramientas dando vuelta que permiten
> manejar reglas de negocio y conectarlas con sistemas de información
> existentes, como Drools u Openlexicon. Para reglas simples, muchas
> herramientas BPMS tienen un motor básico de reglas, y hay que escribirlas en
> su propio formato.
>
> Si alguien tiene otra visión o ha usado algún "estándar" para representar
> las reglas, sería super bueno escucharlo.
>
> Saludos!
>
> Javier
>

> 2011/1/14 LEO <leosilvad...@gmail.com>

[LEO]

Muy interesante lo que comentas Felipe y en general, la opinión de
todos me ayuda bastante, seguiré algunos consejos e investigando
algunas formas para este análisis, cualquier novedad al respecto, lo
comentaré por este medio. Seria bueno, que pudiesemos seguir con este
tema, ya que lo encuentro interesante de desarrollar.

[Patricio Muñoz]

Hola a  Todos!,

disculpen mi intromision pero he seguido la discusion  y me gustaria preguntarles a uds. si pudiesen dar alguna referencia en libros para poder investigar mas el tema, ya que al parecer las nomenclaturas, formatos o  representacion  del estandar aun no esta claro y yo al menos estoy pretendo preparar mi tesis con BPM.

Se los agradeceria mucho si me pudiesen orientar tambien sobre este tema.

Saludos!
--
Patricio  Muñoz R.

2011/1/19 LEO <leosil...@gmail.com>

[Patricio Rojas]

Estimados (estoy aprendiendo como ustedes y quiero compartir este texto)

La idea central detras del concepto de reglas de negocios es que cualquier organización tiene una lógica de cómo lleva a cabo su operación y administración en las tareas que realiza día a día. Estas se pueden organizar en tres grupos

a) Reglamentación legal (que regula la operación de la empresa).
b) Reglas de operación para sus procesos internos (Separar la política interna de la práctica)
c) Reglas de operación del software

 Las reglas de negocio deben cumplir un conjunto características que todos los negocios buscan

a) Incrementar la velocidad de implementación
b) Administrar la diversidad de cambio de algunos negocios
c) Deben ser auditables claramente
d) reglas de negocio reusables
e) Mejor alineamiento a través de la empresa
f) Deben cumplir estándares de ingeniería (de especificación e implementación)


Para su implementación (búsqueda en el mercado de administradores de reglas de negocios) hay desde los más básicos:

a) Cualquier procesador de textos que le permita manejar un archivo y almacenarlo con la clasificación dewey respectiva.

b) Complejos software que permite llevar a  operación flujos de trabajo (persona a persona),  interceptar mensajes y realizar complejos cálculos a través de administradores de reglas de negocio (BRMS ver en wikipedia)

Las componentes y características técnicas que deben cumplir los BRMS son en general:

a) Rules.- Las reglas deben poder almacenarse y escribirse como sentencias y  procedimientos en lenguajes formales, cada empresa del mercado a tratado de imponer su propio estilo (jbmp, jrules v/s drools, etc.)
b) Rule Templates.- Templates de reglas Si existen características comunes en un conjunto de negocios por qué no agruparlas y ofrecerlas como una regla ya implementada (Rule templates)
c) Rule Syntax Checking (Revisión de sintaxis). Al momento de escribir una regla debe poder en tiempo real revisarse
d) Procedures and Algorithms.-  Todo buen software de BRMS debe tener la característica de poder invocar tanto un procedimiento  como un conjunto de reglas que retornen valores.

e) RuleFlow.- Característica de seguir una secuencia o flujo de trabajo para desarrollar las reglas.
f) Decision Tables and Decision Trees (Clave) Todo buen BRMS debe tener la característica de poder visualizar, modificar árboles de desiciones (Importante al momento de realizar debug y comunicación entre el equipo de analista, experto del negocio, arquitecto
g) Inference: Motor de Inferencias, es el medio por el cual se puede aplicar conocimiento a los datos (estrategias comunes como backward chaining
 , forward chaining o goal-directed )

h) Uncertainty and Explanation.- Sistema separado que permiten a un conjunto de reglas dar explicación a características casi de simulación  a preguntas tales como ¿Qué sucede si?, ¿Qué unidades se ven afectadas si cambio tal regla ?, esto permite incorporar elementos de juicio cualitativo y administración del cambio de reglas

¿A quién le sirven estas cosas ? a las personas que quieran hacer la evaluación de un Software BPMS por supuesto.


Ahora
Para comenzar su implementación se debe seguir una recomendación de buenas prácticas por ejemplo la recomendación del ciclo de vida BPM (http://www.bpmn.org/), es decir  seguir la estrategia de la Arquitectura empresarial (Arquitectura de negocio, cadena de valor diagrama de la organización transformación de la cadena de valor en EPC, etc.) Un diagrama muy bueno es el mostrado en este sitio:

http://www.idungu.com/EnterpriseArchitect/EnterpriseArchitect.aspx

Bibliografía para quienes desean consultar:
Business Rules Management and Service Oriented Architecture A pattern Language de Ian Graham

How to Build a Business Rules engine Extending Application funcionality through Metadata engineering
Malcom Chisholm.



Saludos,


PATRICIO ROJAS O.   +56 9 74991604