Respuesta.

Historia de la cuestión:

La automatización de procesos de negocio no estándar o en formación se ha considerado durante mucho tiempo una tarea compleja debido a la falta de escenarios claramente reglamentados y a la alta variabilidad. Los enfoques tradicionales de análisis de sistemas no siempre son adecuados, y se requiere una metodología más flexible.

Problema:

El principal problema al trabajar con tales procesos es su dinamismo: la descripción al inicio a menudo no refleja la esencia de parte de las operaciones, y los requisitos de los clientes pueden cambiar o aclararse rápidamente durante el trabajo.

Solución:

Para identificar y describir correctamente los requisitos, se utilizan enfoques iterativos (Agile, Lean), se recopilan datos a través de observación y prototipos rápidos, se involucra activamente a los usuarios (por ejemplo, a través de talleres) y se documentan los requisitos en formato de historias de usuario, complementándolos con documentación viva en Confluence, Miro, Figma, etc. Características clave del enfoque:

Recepción continua de retroalimentación del usuario y del equipo de negocios
Uso de prototipado y MVP rápidos para concretar escenarios vagos
Aclaración incremental de requisitos: fijamos solo lo que es viable y repetible

Preguntas capciosas.

¿Son iguales los requisitos al principio y al final del análisis de un proceso inestable?

No, al final del análisis, los requisitos cambian: parte se vuelve obsoleta, y parte se formaliza solo tras el uso de prototipos en la práctica real.

¿Es necesario documentar todo el proceso de negocio de una vez, si está cambiando?

No, solo es necesario documentar fragmentos comprobados y funcionales, dejando lo demás como hipótesis o aclarando a medida que se desarrolla.

¿Deben elegirse solo unos pocos medios para la documentación de requisitos?

No, es importante utilizar varios canales: tableros de stand-up, borradores electrónicos, prototipos, para diferentes audiencias y etapas.

Errores comunes y anti-patrones

Intento de detallar todos los aspectos por adelantado (waterfall)
Ignorar la retroalimentación del usuario
Trabajar exclusivamente con documentación ya aprobada o solo con requisitos verbales, sin ejemplos vivos

Ejemplo de la vida real

Caso negativo:

La empresa decidió automatizar un proceso que aún no estaba completamente establecido. El analista describió el proceso estrictamente según el esquema, documentando todo lo que dijeron los empleados. Después del lanzamiento, el proceso cambió rápidamente, y el sistema no respondía a las nuevas realidades.

Ventajas:

Rápida integración de los esquemas existentes

Desventajas:

El proceso se automatizó solo parcialmente, la mayoría de los cambios no se tuvieron en cuenta, costosas correcciones

Caso positivo:

El analista realizó una documentación parcial solo de las etapas estables, construyó un MVP con un conjunto mínimo de funciones, recopiló retroalimentación, ajustó los requisitos junto con el negocio, dejando espacio para los cambios.