Las reglas de negocio Son lo primero

Recientemente, colegas y yo estuvimos hablando con el desarrollador jefe de software de una gran organización de clientes sobre el progreso en un gran esfuerzo de reingeniería allí. Nuestra preocupación era si los miembros del equipo del proyecto podían cumplir un plazo de unos nueve meses para entregar un prototipo a gran escala. Acabamos de pasar varios meses intensos desarrollando un modelo de negocio integral, y aún les quedaban varios meses de diseño de sistemas por completar.

Este desarrollador principal es muy inteligente, no uno que se comprometa con ninguna respuesta a la ligera. Durante mucho tiempo, no dijo nada, perdido en sus pensamientos. Finalmente, mirando los detallados diagramas de negocios pegados en las paredes, dijo :” Si ya hubiéramos empezado a programar, diría que no teníamos ninguna posibilidad. Pero como aún no hemos empezado a programar, diría que las posibilidades son bastante buenas.”

Tuve que repasarlo varias veces en mi mente antes de captar su significado. “Si ya hubiéramos empezado a programar, diría que no teníamos ninguna posibilidad.”

Sabía que pensaba que la codificación de la aplicación en sí iba a ser bastante difícil. Implicaría el uso de un motor de reglas, una red de distribución mundial, interfaces gráficas de usuario y algunos middleware significativos.

Estaba diciendo que si tuvieran que resolver todos los problemas de negocio mientras codificaban, nunca lo lograrían a tiempo—o probablemente nunca. Sin embargo, dado que el equipo del proyecto estaba abordando los difíciles problemas de negocio por adelantado (incluida la especificación de las reglas de negocio), pensó que tenían una buena probabilidad de completar el código para la fecha objetivo.

En gran medida, el enfoque de reglas de negocio consiste simplemente en hacer las preguntas correctas a las personas adecuadas. Solo hay una manera de cumplir honestamente una fecha límite, y es resolver el problema del negocio primero.

TI impulsada por el negocio

En los primeros días de la creación de sistemas de negocio, el lado del negocio podía sentarse y simplemente dejar que sucedieran. Las ventajas de la automatización eran tan convincentes que prácticamente no se podía hacer nada malo. Ahora, para todos los propósitos prácticos, el negocio y la TI operan inseparablemente. Al emprender proyectos, el paso lógico sería entonces reunir equipos de proyectos de negocios/TI sin fisuras y hacer que sigan un enfoque orientado a los negocios para desarrollar los requisitos. Sin embargo, muchas empresas no están cerca de hacer eso hoy en día.

Con demasiada frecuencia, el lado del negocio todavía produce “requisitos” difusos y mal enfocados, y el lado de TI continúa haciendo “requisitos” solo una o dos muescas por encima de la programación. ¿Cómo se puede eliminar esta brecha entre los profesionales de negocios y los profesionales de TI en el desarrollo de requisitos?

La respuesta es relativamente sencilla. El negocio necesita un enfoque organizado que permita a los profesionales de negocios impulsar el desarrollo de los requisitos. Este enfoque debe proporcionar una hoja de ruta que muestre cómo hacer el tipo correcto de preguntas sobre las cosas correctas en el momento adecuado. Lo que se necesita es un enfoque orientado al negocio.

En los enfoques de desarrollo tradicionales, generalmente se pierde mucho en la traducción de los requisitos iniciales al sistema en ejecución real. Pero escribir un conjunto de reglas de negocio claras mejora la comunicación entre el lado de la empresa y la TI, y proporciona un puente entre el análisis de negocio y el diseño de sistemas. El enfoque de reglas de negocio ayuda a cerrar la brecha de requisitos entre el lado de la empresa y el lado de TI.

¿Qué es una regla de negocio? Desde el punto de vista empresarial, es una directiva destinada a influir o guiar el comportamiento. Las reglas de negocio son literalmente el conocimiento codificado de sus prácticas de negocio. Desde el punto de vista de TI, una regla de negocio es una pieza atómica de lógica de negocio reutilizable.

En cierto modo, todo el mundo sabe qué son las reglas de negocio: son las que guían a su empresa en la gestión de sus operaciones diarias. Sin reglas de negocio, siempre tendría que tomar decisiones sobre la marcha, eligiendo entre alternativas caso por caso. Hacer las cosas de esa manera sería muy lento.

Las reglas nos son familiares a todos en la vida real. Jugamos con reglas, vivimos bajo un sistema legal basado en un conjunto de reglas, y establecemos reglas para nuestros hijos. Sin embargo, la idea de las reglas en los sistemas empresariales es irónicamente ajena a la mayoría de los profesionales de TI. Digamos “reglas” y muchos profesionales de TI piensan vagamente en sistemas expertos o inteligencia artificial. Hay poco reconocimiento de lo centrales que son las reglas en realidad para las operaciones básicas del día a día del negocio.

No por casualidad, muchos trabajadores y gerentes de empresas se han adoctrinado tan bien en puntos de vista procedimentales para desarrollar requisitos que pensar en términos de reglas puede parecer extraño o abstracto. Prácticamente todas las metodologías son culpables en este sentido, ya sea para la reingeniería de procesos institucionales, el desarrollo de sistemas o el diseño de software.

Esto es desafortunado por dos razones:

1. Pensar en cualquier actividad organizada en términos de reglas es en realidad muy natural. Por ejemplo, imagine intentar explicar un juego como el ajedrez, las damas, el béisbol o el fútbol americano sin explicar las reglas.

2. Los trabajadores y gerentes del lado de la empresa tienen el conocimiento necesario para crear buenas reglas.

Reglas de ejemplo

Eche un vistazo a las reglas de ejemplo que siguen y observe cómo se pueden abordar todos los aspectos del control operativo en un sistema empresarial mediante reglas:

• Restricciones: Un cliente no debe realizar más de tres pedidos urgentes con cargo a su cuenta de crédito.

• Heurística: Un cliente con estatus de preferencia debe recibir sus pedidos de inmediato.

• Cálculos: El volumen anual de pedidos de un cliente debe calcularse como el total de ventas cerradas durante el año fiscal de la empresa.

• Inferencia: Un cliente debe considerarse preferido si realiza más de cinco pedidos de más de $1,000.

• Tiempo: Un cliente debe archivarse si no realiza ningún pedido durante 36 meses consecutivos.Disparadores

•: “Enviar aviso por adelantado” debe ejecutarse para una orden cuando se envía la orden.

Las reglas se basan directamente en términos y hechos. Los términos, como cliente, envío y factura, deben tener una definición precisa e inequívoca en el negocio. Por ejemplo, el cliente puede definirse como: “Una organización o persona individual que ha realizado al menos un pedido pagado durante los dos años anteriores.”

Los hechos se dan por oraciones simples y declarativas que conectan los términos con un verbo o frase verbal, como, “El cliente hace un pedido.”

Un “modelo de hechos” es un conjunto de declaraciones de hechos que describen los resultados de una operación comercial. Un modelo de hechos debe servir como un modelo inicial para un modelo de datos, pero su propósito principal es capturar el conocimiento sobre el negocio de una forma estructurada, extraído de los trabajadores y gerentes del lado del negocio que lo poseen.

Las reglas esencialmente agregan el sentido de las palabras debe o no debe a los términos y hechos, como en, “Los pedidos a crédito de más de $1,000 no deben aceptarse sin una verificación de crédito.”

Las reglas deben expresarse en inglés de negocios claro, inequívoco y bien estructurado, comenzando con un tema explícito. Las reglas no deben tener pelusa ni datos faltantes. Las reglas pueden ser calificadas, como en “Un envío debe estar asegurado si el valor del envío es superior a 5 500.”Y las reglas pueden incluir criterios de tiempo, como en” Un estudiante debe estar matriculado en al menos dos cursos al cierre de la inscripción.”

Independencia de reglas

Un negocio es muy parecido a un cuerpo humano. La estructura de conocimiento (término y hecho) es como el esqueleto; los procesos son los músculos poderosos; y las reglas son el sistema nervioso que controla los otros dos. Las tres son esenciales y están interrelacionadas. Pero las reglas de negocio deben estar separadas de las otras dos. Un principio básico de este enfoque es que las normas son independientes de los procesos y procedimientos. Un beneficio adicional de esa “independencia de las reglas” es una enorme simplificación en los procesos.

El resultado es un “proceso delgado”, un objetivo de larga data de muchos profesionales de TI. Al eliminar las reglas de los procesos, puede producir procesos que son relativamente simples y se pueden cambiar según sea necesario.

En la Liga Nacional de Fútbol, si un juego no funciona para un equipo, desaparecerá de su libro de jugadas en un par de juegos. Las jugadas son esencialmente descartables. Del mismo modo, las empresas deben ver sus propios procedimientos como descartables, lo suficientemente baratos como para desecharlos y reemplazarlos fácilmente cuando los procedimientos ya no funcionan bien.

Los procedimientos desechables son una necesidad para que el negocio sea adaptable y competitivo. Esta idea engañosamente simple, posible gracias al enfoque de reglas de negocio, puede revolucionar la forma en que se realiza el trabajo y se diseñan los sistemas.

Reimpreso con permiso de Principles of the Business Rule Approach, por Ronald G. Ross (Addison-Wesley, 2003). Ross es cofundador y director de Business Rule Solutions LLC y editor ejecutivo del sitio Web BRCommunity.com.

Modelo de datos de biblioteca
Este diagrama muestra un modelo gráfico de datos para una biblioteca. La redacción de la regla se basa directamente en el modelo fact, que es un diagrama de conceptos empresariales básicos, una estructura de conocimiento. Un modelo fact puede y debe proporcionar un primer plano de cómo se organizarán los datos en una base de datos. REGLA: Una tarjeta de biblioteca se puede usar para retirar un libro solo si el libro es propiedad de una biblioteca para la que la tarjeta está autorizada.