BPM y Scrum
Blog: BPM wasabi
Es la “Ley de Humphrey”, según la cual, los clientes no saben lo que quieren hasta que ven el software que funciona. O sea, demasiado tarde, y esta situación se repite también cuando trabajamos en mejora de procesos o sobre proyectos de BPM (Business Process Management) ya implementados.
La realidad de la gestión por procesos y de los proyectos de BPM, es que los procesos no pueden ser considerados como algo estático e inamovible, pues estos siempre están vivos, sea por los cambios en el entorno organizacional o por el trabajo de mejora continua que realicemos sobre los procesos ya implementados. El entorno de las organizaciones cambia, las estrategias cambian y los procesos en consecuencia también cambian, y las empresas quieren aprovechar las capacidades de cambio de BPM o de las plataformas BPMS, por lo que trabajan más intensivamente en reajustar sus procesos en ciclos de optimización y mejora cada vez más cortos.
- A los individuos y su interacción, por encima de los procesos y las herramientas.
- El software que funciona, por encima de la documentación exhaustiva.
- La colaboración con el cliente, por encima de la negociación contractual.
- La respuesta al cambio, por encima del seguimiento de un plan.
- Adaptabilidad, orientación al cliente, rapidez y agilidad.
- Realizar entregas rápidas en forma de procesos clave implementados. Las entregas funcionales, iterativas e incrementales, realizadas a través de sucesivas interacciones (“Sprints” de Scrum), y que son mostradas al cliente para su valoración, hasta que este da por cerrado el producto, encajan perfectamente dentro de la filosofía de BPM de impulsar la eficiencia en los procesos de la organización, dividiendo los proyectos en partes más pequeñas y priorizando las partes de mayor importancia para el negocio y el ROI del proyecto, en lugar de abordarlo desde la perspectiva de la reingeniería de procesos (BPR) de abandonar el trabajo de mejora de procesos, romper con todo y buscar un cambio radical.
- Mayor innovación y satisfacción del cliente, al recibir este entregas funcionales en periodos cortos de tiempo y poder proponer ideas y cambios sobre el proyecto en tiempo de desarrollo y no poner un muro infranqueable para estos cambios para la protección del proyecto, como sucede con las metodologías de gestión de proyectos tradicionales. En Scrum esto se realiza a través de la Pila de Producto (Product Backlog), como un documento vivo de los requisitos del cliente que evoluciona y crece continuamente, y sobre la cual vamos añadiendo los cambios solicitados que serán implementados en los siguientes Sprints, mediante la adaptación continua a las circunstancias del proyecto.
- Trabajar en la mejora continua de los procesos de negocio, ajustando el proyecto cuando sea necesario y no pretendiendo una entrega completa y final del mismo en base a una exhaustiva planificación.
- El centrarse en las personas y confiar la calidad del resultado al conocimiento explícito de estas sobre los diferentes aspectos del proyecto o del producto, al tiempo que mejoramos el comportamiento y motivación del equipo de desarrollo y reforzamos la necesaria colaboración en el proyecto entre gente de negocio y gente de TI tan fundamental en los proyectos de BPM.
- Ayudarnos a responder de forma más eficiente a las necesidades de cambio continuo, al poder aceptar e integrar los cambios que aparecerán, tanto trabajando en la mejora de los procesos como los que surjan durante la fase de implementación, pues los procesos cambian continuamente del As-Is al To-Be y los requisitos son cambiantes a medida que automatizamos y mejoramos los procesos.
- Permitir las revisiones durante todo el ciclo de vida del proyecto y no sólo a la finalización del mismo, acortando la brecha entre las expectativas del cliente y lo que este realmente necesita.
Leave a Comment
You must be logged in to post a comment.