Respuesta.

Historia de la pregunta:

En las primeras etapas de la automatización de procesos de negocio, a menudo se descubría que el cliente no comprendía completamente o pasaba por alto parte de las reglas de negocio importantes que no estaban documentadas formalmente. La falta de una fijación clara de tales reglas llevaba a errores lógicos, situaciones impredecibles y disputas entre el negocio y TI.

Problema:

Las reglas de negocio ocultas o implícitas son difíciles de identificar: solo las conocen empleados experimentados, pueden estar registradas solo en papel o no estar documentadas en absoluto. Esto aumenta el riesgo de aparición de errores y conflictos, complicando las pruebas y la implementación del producto.

Solución:

El analista de sistemas aplica:

• Entrevistas con usuarios clave y expertos
• Análisis de incidentes y situaciones no estándar
• Estudio de regulaciones, procesos relacionados, archivos de mensajes y correspondencia
• A través de la modelación de casos y la creación de diagramas BPMN/UML, identifica las brechas

Después de recopilar las reglas, el analista las formaliza utilizando plantillas de reglas de negocio, matrices de decisiones, y diagramas de estados y condiciones. Mantiene la documentación actualizada a medida que cambian los requisitos.

Características clave:

• Involucrar activamente a expertos para validar las reglas identificadas
• Uso de formatos de descripción estandarizados (por ejemplo, Tabla de Decisiones)
• Aprobación y validación de todas las reglas de negocio con el cliente

Preguntas trampa.

¿Se puede considerar que todas las reglas que menciona el cliente al inicio son exhaustivas?

No, a menudo parte de la información importante está oculta o se asume que es obvia. Se requiere un análisis profundo y trabajos adicionales.

¿Siempre se deben tener en cuenta las reglas que solo conocen ciertos empleados en el proyecto?

No, solo si estas reglas han sido aprobadas y validadas por la parte comercial y no contradicen los objetivos estratégicos. De lo contrario, esto puede convertirse en una fuente de contradicciones.

¿Es suficiente simplemente documentar una regla de negocio en la documentación técnica?

No, también debe validarse con expertos, describir excepciones, acordar formulaciones e incorporarse en la documentación de pruebas.

Errores comunes y anti-patrones

• Reglas omitidas o mal entendidas que llevan a retrabajos
• Descripción demasiado técnica de las reglas de negocio sin vinculación a los escenarios de los usuarios
• Falta de aprobación de la documentación por parte del cliente comercial

Ejemplo de la vida real

Caso negativo: El analista registró las reglas de negocio de boca del cliente sin preguntas aclaratorias ni retroalimentación de usuarios expertos. En producción se encontraron excepciones no contempladas (por ejemplo, casos especiales de pago). Pros:

• Preparación rápida de la documentación analítica Contras:
• Gran cantidad de errores, urgentes retrabajos

Caso positivo: El analista realizó sesiones con usuarios expertos, utilizó tablas de decisiones para todos los casos y sincronizó las formulaciones finales con varios interesados. Pros:

• Cobertura completa de escenarios
• Minimización de conflictos en la implementación Contras:
• Altos costos de tiempo para preparación y validación