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
No hay comentarios.:
Publicar un comentario