Analisis y modelado mediante procesos

Introducción 

Los proyectos de tecnología siempre iran enfocados a la mejora, lo que se hace actualmente y como una nueva solución o un cambio a la actual, favorecen que los resultados sean más rápidos, precisos y fiables.

El levantamiento de requerimientos y su traducción a especificaciones técnicas normalmente representa el gran reto para todo consultor en TI. Para poder llevar a cabo esta labor de manera correcta y productiva, el cliente debe indicar CLARAMENTE que es lo que desea mejorar, el tema es que sabe a alto nivel lo que espera: disminuir costos, mejorar el nivel de servicio, disminuir costos mediante el manejo de formularios electrónicos, etc.; el detalle pide que lo veamos con la gente que lo hace, es decir, los que operarán el sistema. Ellos no saben que debe hacer, saben como se hace actualmente y que podría mejorarse.

Entonces, el consultor debe:

1. Entender la visión de mejora global que se tiene.
2. Conocer como se hacen las cosas actualmente.
3. Proponer como se puede hacer "mejor".
4. Documentar como deben ser estos cambios o nuevas funcionalidades.

Muchas metodologías indican que se deben seguir los siguientes pasos a grandes razgos:

1. Solicitar una lista de requerimientos.
2. Priorizar los requerimietos.
3. Establecer sesiones para detallar los requerimientos y documentar la mejora/solicitud a través de un caso de uso.
4. Implementar el caso de uso.
5. Validar su funcionamiento (pruebas).
6. Liberarlo al usuario.

El problema reside en que el usuario de entrada no sabe a detalle lo que desea, por lo tanto el detalle del requerimiento es subjetivo, esta enfocado en lo que quiere hacer más rápido y fácil, no necesariamente que de más valor al negocio. Pero como el consultor no lo sabe, lo asume como correcto. Esto se plasma posteriormente en un caso de uso, unidad aislada de funcionalidad solicitada a través de un requerimiento, y se implementa. Este subproducto es entregado al usuario y empieza a utilizarlo. El problema surge cuando empieza a recibir los bloques "independientes" de funcionalidad y surgen nuevas inquietudes y solicitudes de integrar las funcionalidades, hacer ajustes, compaginar resultados, etc... empiezan los controles de cambio, retrasos, costos adicionales y otro etc.


El modelado de procesos brinda una visión holística del entorno, como es y como debe mejorar de forma integral; por lo que, permite atender estos puntos indispensables para poder llevar a cabo la especificación de los requerimientos, su modelado y posterior el diseño e implementación de manera adecuada ya que:

1. Permite conocer la empresa y sus procesos, con esto, donde aplica la necesidad de mejora y como impacta el funcionamiento actual, permitiendo proponer ajustes en la cadena de procesos que se vea impactada.
2. Permite el entendimiento del proceso de negocio de forma integral, no por funcionalidad.
3. El modelo de caso de uso y el detalle de cada uno, entrada para el diseño e implementación, presenta una mayor coherencia al brindar al análista la visión de lo que se debe atender de manera global, no solo tareas especifícas. 

Aquí menciono caso de uso, aplicable más al proceso unificado (UP), pero puede ser un escenario (SCRUM).

Niveles de proceso 

Para llevar a cabo el modelado del proceso es importante conocer los niveles presentes en una organización y aunque no necesariamente se modelan todos, se debe tener claro en cual de ellos se centra el esfuerzo de análisis y modelado para tener un contexto del alcance de la solución.

1. Nivel 0: Macroprocesos. Brindan el contexto de la organización, que hace (cadena de valor), que áreas hay, que procesos son primarios y cuales secundarios (soporte). 
2. Nivel 1: Procesos. Describen lo que se hace a nivel funcional (áreas).
3. Nivel 2: Subproceso. Indican quien hace que (actividad), que recibe y que entrega. Muestra los roles.
4. Nivel 3: Actividad. Mediante diagramas de flujo, ilustran lo que sería una instrucción de trabajo. Un solo rol la ejecuta.
5. Nivel 4: Tareas (Transacciones). Son atómicas y pueden (no siempre se llega a este nivel), describir funciones, estados, etc.

Los casos de uso o escenarios surgen a partir del nivel 4. El consultor de procesos, con rol de analista, debe entregar al diseñador, consultor de ti, los documentos de caso de uso correspondientes a este nivel con la especificación del caso, modele datos, prototipos, etc.

Procedimiento propuesta

1. Elaborar mapa de procesos.
2. Elaborar el diagrama de cada proceso, las opciones son:
1. Alto nivel de cada proceso (SIPOC).
2. Diagrama de despliegue con BPMN, identificando las áreas involucradas.
3. Por cada subproceso del paso previo, elaborar el diagrama BPMN a nivel Actividad e identificar los roles participantes.
4. Por cada actividad del paso previo, elaborar diagrama de flujo (UML de Actividad),  donde cada bloque es una acción atomica.

La siguiente figura muestra el SIPOC de este procedimiento (v1.0).

Los formatos se pueden generar o encontrar facilmente en internet.