Hemos hablado de la importancia que tiene la definición de los requerimientos a la hora de establecer qué debe hacer un sistema, y de la forma que pueden tener esos requerimientos expresados de forma narrativa, pero existen otras técnicas más apropiadas, y poco usadas, como la obtención de requerimientos mediante análisis de procesos.
Mi proyecto de final de carrera fue el desarrollo de una metodología para la implantación de ERPs, metodología que había ido construyendo a medida que iba haciendo implantaciones de ERP. Esa metodología tenía un eje fundamental, los procesos de negocio, más concretamente la obtención de requerimientos mediante análisis de procesos.
En mis 5 cursos de carrera no se mencionó ni una sola vez (o igual no asistí a esa clase, vete a saber) qué era un proceso de negocio. Espero que muuuuuuchos años después eso ya no suceda en la universidad pero, como medida preventiva, ¿qué te parece si hablamos de ello?
¿Qué es un proceso?
Un proceso es una secuencia lógica de actividades (pasos o tareas) que se realizan para llevar a cabo algo y, así, lograr un resultado específico.
Por tanto, un proceso:
- Debe lograr un resultado específico, discreto e identificable cada vez que se ejecuta.
- Hay algo (un evento) que lo dispara, lo arranca.
- Tiene entradas y salidas específicas.
- Utiliza recursos.
- Tiene un número determinado de actividades que se ejecutan en cierto orden.
- Suele afectar a más de una unidad organizativa.
- Crea valor.
¿A quién le importan los procesos?
En el 2015 aterricé como analista en una gran empresa. El equipo de proyecto debía constriur una solución para distribuir el producto que se comercializaba a los distintos clientes de distintos mercados por distintos canales al mejor precio posible.
Pretendía arrancar con la obtención de requerimientos mediante análisis de procesos. Como analista necesitaba conocer cómo funcionaba la empresa antes de “meterle mano” y, caramba, ¡porque es mi método de trabajo!.
Cuál fue mi sorpresa al ver que era la primera vez que se abordaba un proyecto de esa forma.
Una empresa es tan buena como lo sean sus procesos, todos ellos: los que marcan la estrategia, los que establecen los mecanismos de producción y abastecimiento, los que determinan los canales de venta y el precio de productos/servicios en esos canales, los que gestionan el cash-flow, …
Las distintas actividades que llevamos a cabo en cada uno de los procesos es lo que marca el éxito de ese proceso y, por ende, el éxito de la empresa.
El análisis de procesos es fundamental para garantizar que esos procesos se ejecutan adecuadamente y nos permiten alcanzar los objetivos que la empresa se ha marcado; por tanto, sí, los procesos deberían preocuparte, y mucho.
Qué es el análisis de procesos
El análisis de procesos es una forma de contar una historia, una vía para el entendimiento de cómo funciona, o debería funcionar, un negocio, a efectos de adaptar esos procesos y darles respaldo con las aplicaciones que desarrollamos o adquirimos, y ahí es donde procesos de negocio y aplicaciones tienen su punto de encuentro.
Porque sí, los procesos son soportados, total o parcialmente, por las aplicaciones que adquirimos o desarrollamos, y si para adquirir o desarrollar aplicaciones tomamos requerimientos, entenderás la relación fuerte que tienen requerimientos y procesos, pues los requerimientos son el eslabón que engancha procesos con aplicaciones.
Vimos que existe una relación directa entre calidad del software y requerimientos. Cuanto más finos seamos en la elaboración de los requerimientos, mayor calidad del software y mayor velocidad en su entrega… un motivo más para fortalecer ese vínculo entre proceso y requerimientos.
Además, necesitamos alguna técnica que nos permita satisfacer una característica importantísima de los requerimientos: que sean completos. El enfoque a proceso ayuda, y mucho, a conseguir que los requerimientos sean completos (puedes ver este artículo donde hablamos de las características de los buenos requerimientos).
Qué aporta el análisis de procesos
Modelar el proceso de negocio es una parte esencial en proceso de desarrollo de software.
- Permite capturar el ‘modus operandi’ actual del negocio, a efectos de entender cómo funciona la empresa o una parte de ella.
- Permite trabajar en la mejora de ese ‘modus operandi’, detectando reglas que deben regir, ineficiencias, problemas y necesidades, reformando así los procesos actuales (reingeniería de procesos).
- Establece qué funciones ha de realizar el sistema, quién las debe llevar a cabo, qué información se requiere y se genera, así como los eventos que las ponen en marcha.
- Provee del contexto de dónde se va a ajustar el software en la estructura organizativa y de las actividades de la empresa.
- Justifica la construcción del software al capturar las actividades manuales y los procedimientos automatizados que se incorporarán al nuevo sistema.
- Ayuda a aclarar ideas complejas mediante la visualización de modelos.
- Facilita la elaboración de historias de usuario y la toma de requerimientos más detallados.
- Proporciona construcciones que ayudan a organizar las ideas y a la agrupación de requerimientos.
- Aporta el contexto en el que se ve inmerso un requerimiento, proporcionando una mejor trazabilidad del requerimiento y una mejor imbricación en las UAT, donde lo que pruebas son distintos escenarios en realción a un proceso y, por ende, el cumplimiento de los requerimientos.
- Permite identificar qué está dentro del alcance del sistema propuesto y qué se implementará de otras formas (por ejemplo: un proceso manual) por el hecho de que el modelo de procesos de negocio normalmente es más amplio que la parte de sistema de sotware considerada.
- Sirven de guía en la toma de requerimeintos completos.
¿Qué técnica uso para el modelado de procesos?
Puedes usar las que te proporciona Archimate, en su capa de arquitectura de procesos, las que te proporciona UML con sus diagramas de actividades, o alguna precursora a todas ellas, como IDEF0, pero creo que la más expresiva, flexible, visual, orientada a negocio y que, además, permite automatizar esos procesos con motores a tal efecto (basados en Business Process Execution Language o BPEL), es BPMN.
¿Cómo se debe proceder?
Te propongo que apuestes por una pirámide basada en, de menor a mayor detalle:
- Establecer el alcance, determinando los procesos objeto de tu trabajo (tu inventario de procesos).
- Analizar esos procesos actuales del inventario, haciendo zoom en cada uno, modelando y descomponiéndolos. No debes quedarte en algo muy a alto nivel, que obvia detalles, ni de muy bajo nivel. Deberás encontrar un equilibrio.
- Realizar la reingeniería de esos procesos hasta conformar el estado futuro deseado.
- Obtener los requerimientos de mayor detalle en cada actividad. Apóyate en los casos de uso, por ejemplo, para los requerimientos funcionales; no te olvides de los no funcionales, pues no se capturan vía casos de uso.
Conclusión
No es objeto de este artículo explicarte cómo se modelan procesos de negocio; simplemente abrirte la mente a una forma efectiva, y poco habitual en mi experiencia, de arrancar la toma de requerimientos.
El análisis de procesos va a determinar la manera en que un nuevo software, o uno ya existente, deberá dar soporte al negocio en la ejecución de sus procesos, es decir, determina los requerimientos.
Creo que no hay una técnica mejor que te proporcione esa capacidad de entendimiento global y de contexto. Podríamos usar casos de uso; son un mecanismo de mayor nivel que el simple uso de requerimientos textuales, pero no te aporta todos los beneficios del análisis de procesos.