Hace unos pocos años, en el 2019, cuando empezamos con la ABPMP PERU CHAPTER con Jorge Chaupin y Dr. Paul Villacorta, PMP, MBA, PM4R, SDI, CAL y organizamos el primer BPM Night con el tema “Integración de la Gestión por Procesos (BPM) y Dirección de proyectos (PM)”, llegamos a la conclusión que para implementar gestión por procesos en una organización necesitamos un proyecto y para gestionar un proyecto necesitamos procesos, el clásico yin yang, proyectos y procesos o procesos y proyectos, no importa el orden de los factores lo importante es el producto, discutir qué fue primero es tan productivo como el dilema del huevo y la gallina.
A menudo escucho que con la aparición de la gestión por procesos la visión funcional o los organigramas se deben eliminar de las organizaciones, desde mi punto de vista ambas deben coexistir, si bien es cierto no existe verdad absoluta "podrían" haber casos que no sean necesarios los organigramas o que su aporte sea tan reducido que se pueda obviar. En todo caso tener un punto de apoyo -lo que denomino principios- es importante para construir algo y por eso siempre comparto esta analogía entre organización y equipo de futbol, necesitamos perfiles profesionales para determinados puestos pero es la combinación de las capacidades de todos en un momento específico -el trabajo real- los que logran el resultado, de esa misma forma necesitamos arquero, defensas, volantes y delanteros en un equipo, pero cuando hay un córner defensivo el delantero alto baja a defender y cuando hay un córner ofensivo el defensa alto va a atacar, en algunos casos extremos hasta el arquero, sin importar que el sistema fue 4-3-3, 3-5-2 o 4-4-2, en esa analogía los puestos son las funciones y los córner serían los procesos, lo importante y que no puede cambiar es el objetivo de ganar el partido cumpliendo el "fair play", en una organización debe ser entre otros el crecimiento, la longevidad [1] y cumplir el "fair play" con la sociedad.
¿Por qué todo este preámbulo para una estructura de gestión de proyecto para implementar gestión por procesos? Porque la estructura que les comparto para implementar un proyecto en una organización tomo la estructura de desglose de trabajo (EDT) y la homologo con un organigrama con funciones que la denomino “Vista funcional de gestión de proyecto” (ver figura 1), en este caso el EDT tiene un primer nivel de agrupamiento de 4 etapas principales Plan, Ejecución, Control QA e Implementación de proyecto, luego un segundo nivel de agrupamiento y pasando a más detalle llegan las funciones, un modelo típicamente jerárquico.
Figura 1: Vista funcional de gestión de proyecto
Nota: Elaboración propia
Las funciones del EDT son reordenadas para convertirse en insumos de varios elementos del tipo mapa de procesos de la arquitectura de procesos propuesta en otro post [3], se toman las mismas funciones pero se muestran desde otra perspectiva, son ordenados e interrelacionados y reutilizados con el objetivo lograr un resultado de valor para alguien, normalmente el cliente del proceso. Reusamos el concepto de visión vertical y horizontal pero aplicado al EDT, con esto logramos algo equivalente a un Mapa de Procesos (ver figura 2).
Figura 2: Vista por procesos de gestión de proyecto / mapa de procesos
Nota: Elaboración propia
El mapa de procesos para la gestión de un proyecto de BPM, es finalmente un modelo y como todo modelo a veces sirve a veces no, según G. Box [5], por esta razón se presenta otro nivel denominado cómo cadena de valor con 5 procesos para la ejecución del proyecto (ver figura 3) - recomiendo para cualquier proyecto emplear criterios del manifiesto ágil [4] y la filosofía Kaizen de mejora continua -, básicamente son 3 los procesos orientados a BPM, a continuación, se detallan todos los procesos:
- Proceso inicio proyecto, se realiza una vez y el entregable principal es el contrato con la definición del alcance y cronograma.
- Proceso de entendimiento de BPM, se pueden realizar varias veces, el objetivo es lograr un sentido común sobre BPM en la organización y los entregables son los talleres de capacitación.
- Proceso de desarrollo de arquitectura de proceso, se puede iterar utilizando el concepto de producto mínimo viable, el objetivo es tener una arquitectura de procesos para uso [3] y el entregable es una versión de la arquitectura de procesos que ayude a hacer explicito el conocimiento de la organización.
- Proceso de desarrollo de process driven application (PDA) [2], se puede iterar utilizando el concepto de producto mínimo viable hasta lograr un PDA aprobado por el usuario, pero el objetivo final es tener PDA operativo que automatice y "pokayokize" las actividades, este es el proceso más extenso porque contempla todos los pasos necesarios para desarrollar un PDA, desde el levantamiento de información, desarrollo o configuración de sus componentes, las pruebas en los ambientes de desarrollo y calidad, las aprobaciones por el usuario y el despliegue en el ambiente de producción.
- Proceso cierre del proyecto, se realiza una vez y el entregable principal es la adenda de cierre del contrato con lo entregado, que se acuerda durante la ejecución del proyecto, aquí se aplica la respuesta al cambio sobre seguir el plan, del manifiesto ágil.
Se puede notar que en todas las cadenas de valor se reutiliza el proceso “Actualización de cronograma” cómo un proceso de soporte, esto permite tener un control en vivo del desarrollo del proyecto.
Figura 3: Vista por procesos de gestión de proyecto / cadena de valor
Nota: Elaboración propia
Es importante mencionar que esta propuesta pretende ser un punto de inicio para la ejecución de proyectos de implementación de BPM con el fin de evitar el temor del lienzo blanco, no es prescriptiva y por lo tanto se pueden adicionar o eliminar funciones de acuerdo con lo que se necesite.
[1] Kimura, K. (2019). TPM Volume-9 Mantenimiento Preventivo Total.
[2] Miyagi A., Fundamentos para desarrollar Process Driven Application (PDA), https://acortar.link/mzZEvJ
[3] Miyagi A., Una arquitectura de procesos para uso, https://acortar.link/mzZEvJ
[4] Manifiesto Ágil, Manifiesto por el Desarrollo Ágil de Software, https://agilemanifesto.org/iso/es/manifesto.html
[5], Molina C., Todos los modelos son incorrectos, pero algunos son útiles, https://www.multiversial.es/p/todos-los-modelos-son-incorrectos-pero-algunos-son-utiles
Publicado por
Consultor en Kaizen , Gestión x Procesos & BPMS LowCode, Redactor del Blog MiyagiSensei.comConsultor en Kaizen , Gestión x Procesos & BPMS LowCode, Redactor del Blog MiyagiSensei.com