Respuesta

Históricamente, los analistas de sistemas a menudo comenzaban su trabajo con un análisis profundo de los procesos de negocio de la empresa. Esto permitía entender dónde y cómo un sistema de información podía automatizar u optimizar las actividades de la organización. Sin embargo, no es raro que las fronteras entre el análisis de procesos de negocio y el diseño técnico se mezclen.

Características clave:

• La descripción de procesos de negocio se enfoca en identificar y formalizar las actividades de la organización como un sistema, sin tener en cuenta los detalles de implementación con herramientas de TI.
• El diseño de un sistema de información comienza después de la formación de requisitos, e incluye el desarrollo de la arquitectura, interfaces, integraciones y formatos de datos.
• Es importante separar estas etapas: primero el analista define "qué hacer", luego — "cómo hacer".

Historia de la cuestión

Anteriormente, la frontera entre estas etapas era más clara: el analista de negocio era responsable de modelar procesos, mientras que el analista de sistemas se encargaba de traducir requisitos en especificaciones técnicas. En la práctica moderna, las tareas a menudo se mezclan.

Problema

Muchos analistas comienzan a diseñar el sistema antes de realizar un análisis completo de los procesos, lo que lleva a una definición incorrecta de los requisitos y a una excesiva especificación técnica.

Solución

Separar claramente el análisis del dominio del diseño, utilizar BPMN y EPC para describir procesos, y para el diseño — UML, diagramas de flujo de datos (DFD), entre otros.

Preguntas engañosas.

¿Qué es más importante: analizar procesos de negocio o diseñar el sistema?

No se puede destacar uno solo: el análisis de procesos es necesario para elaborar requisitos correctos, y el diseño es necesario para su implementación. Estas son etapas secuenciales.

¿Se pueden utilizar los mismos diagramas para describir procesos y diseñar el sistema?

No, BPMN/EPC son aplicables para procesos, UML/DFD son para análisis y diseño estructural u orientado a objetos.

¿En qué caso se puede omitir la modelación de procesos de negocio?

Solo si el proyecto es pequeño y ya están completamente formalizados en documentos o estándares. En la mayoría de los casos, la modelación es necesaria.

Errores típicos y anti-patrones

• Transición prematura y detallada al esquema de datos sin comprender las tareas del negocio.
• Mezcla de descripción de procesos y soluciones técnicas.
• Ignorar los intereses de los usuarios finales.

Ejemplo de la vida real

Caso negativo:
El analista comenzó de inmediato a dibujar el esquema de la base de datos y servicios, sin investigar cómo trabajaban los empleados y qué necesitaban. Ventajas: implementación rápida, todos satisfechos con la primera versión.
Desventajas: el sistema no resuelve problemas reales, los usuarios están insatisfechos, se requiere desarrollo adicional.

Caso positivo:
El analista primero llevó a cabo una serie de entrevistas con empleados, construyó BPMN, luego pasó al diseño de API y base de datos. Ventajas: requisitos claros, el sistema cubre procesos reales.
Desventajas: inicio del proyecto más largo, mayores gastos en análisis.