BPM y Scrum

A la hora de abordar proyectos de TI, solemos encontrarnos con clientes que tienen una idea clara de qué hacer y de cómo hacerlo, del modelo de negocio que quieren lanzar, pero que necesitan verlo ¡YA! y no disponen todavía en las fases iniciales del proyecto de la capacidad de detallar el producto final, prefiriendo bajar a estos niveles de detalle en tiempo de desarrollo, al tiempo que ven el producto en entregas breves y funcionales.

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 la hora de gestionar estos proyectos de software o de mejora de procesos, el problema que nos encontramos con la gestión de proyectos tradicional y su necesaria fase inicial de planificación, es que trata el proyecto como una actividad predecible, cuando la realidad de muchos de estos proyectos es que no lo es, debido principalmente a componentes asociados tanto al desarrollo software como al de mejora de procesos, como son la innovación y la creatividad, debidos a un trabajo conjunto del equipo de desarrollo con los stakeholders, y que hacen que este proceso productivo, no pueda ser fácilmente predecible y estimado de forma precisa, por lo que estos proyectos necesitan de menos planificación, al no poder contar con un análisis y diseño inicial perfectamente especificado y donde además, los requerimientos de clientes son cambiantes, dificultando todavía más la tarea de poder predecir cual será el resultado final exacto del proyecto software o de mejora de procesos.

Es en este entorno en el que conceptos como Lean, Kaizen y las Metodologías Ágiles, encajan perfectamente con esta filosofía de producir valor en lotes pequeños, agregando funcionalidades de forma incremental y no en una sola entrega final previamente planificada, cuya implementación, difícilmente se ajustará a esa planificación inicial.

Una de las metodologías ágiles, utilizada ampliamente para el desarrollo software y que puede ser de utilidad para los proyectos de BPM es SCRUM, cuyos principios fundamentales son:

• 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.

Estos principios encajan perfectamente con la metodología de BPM, donde los principios de mejora continua, flexibilidad y adaptación al cambio de BPM, precisan del equipo involucrado en el proyecto de una visión compartida hacia la que dirigirse, como si de un equipo de Rugby se tratase, avanzando de forma conjunta, colaborativa y cohesionadamente, hacia los objetivos pretendidos con el proyecto y no tanto de un control y planificación predictiva, a partir de una especificación detallado de los requisitos finales del proyecto y de los procesos, que pueden cambiar y evolucionar durante el transcurso del proyecto.

Una aproximación a este tipo de metodologías ágiles proporcionará a nuestros proyectos de BPM:

• 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.