viernes, 1 de noviembre de 2013

Camino a la agilidad para BPM Ágil


Hace algunos años empecé a trabajar con proyectos relacionados con BPM. Sin embargo, debo admitir que nada tenían que ver con ese propósito, con esa meta, pues en realidad su enfoque estaba relacionado con la utilización de BPMS sofisticados en vez de orientarse a los verdaderos objetivos alineados a la operación por procesos para la reducción de costos, desperdicios entre silos en las Organizaciones, mejorar los tiempos para ofrecer nuevos productos "time-to-market", responder a eventos de negocio a través de reglas de negocio, en general, la producción de valor real al Cliente final.


Todo esto sucedía porque la forma como se afrontaron los proyectos estaban orientados desde un enfoque tecnológico y no de negocio. Digo esto, porque en fases de análisis de procesos BPA se capturaban en sí requisitos orientados a la construcción de software con extensas documentaciones que buscaban capturar el comportamiento de interfaces de usuario y de ejecuciones de flujos de trabajo workflow. Era prioritario la especificación de extensos formatos de casos de uso contemplando los diferentes escenarios y de igual forma los equipos de proyecto se enfocaban en la aprobación de un alcance invariable para implementarlo en un tiempo exacto con un control riguroso de riesgos ocasionando definiciones de meses e incluso de años.

Es importante anotar que el negocio en muchos casos fue secundario y lo que se construyó fueron componentes de software que seguían una moda promovida por los fabricantes más reconocidos en el mundo. En sí, se crearon sistemas de información novedosos, con otras interfaces de usuario, con pasos extensos a través de tareas humanas y en algunos casos hasta se produjo software que funcionaba, aunque nada tenía que ver con la mejora contínua de procesos.

Si existía un cambio desde el negocio era muy complicado que los equipos de desarrollo lo aceptaran, porque el riesgo era muy alto. Muchas veces al negocio se le negó la posibilidad de optimizar o de re inventar su operación porque el impacto era difícil de calcular y ocasionaba una negociación interminable de controles de cambio.

Las personas que  intervenían en los proyectos se preocupaban más por las certificaciones de herramientas relacionadas con el BPMS que de conocer en qué consistía un modelo de BPM. Bueno, hoy en día esto sigue vigente y hay muchos profesionales ocupados en obtener una certificación en semanas que lo avale como un "experto".
Conocí proyectos que implementarón hasta más de 30 procesos que nunca evolucionaron, nunca tuvieron mejora contínua, pues simplemente fueron un desarrollo de software a la medida sobre los juguetes de moda de aquella época. En general, se cumplió el desafío técnico (en algunos casos) pero nunca se mejoró el negocio o al menos el ROI no fue el esperado.

Conocí muchas Organizaciones que fracasaron en su intento de implementar "BPM" o más bien, fracasaron en la utilización de tecnologías o en el método como enfrentaron los proyectos. Se ocuparon en la generación de eternas especificaciones cuyo objetivo era conseguir la firma del Cliente para hacer un cierre funcional o en otros casos creyeron que la arquitectura de software a aplicar era la que proporcionaba un BPMS, grave error.

Muchas Organizaciones desecharon o no han considerado enfrentar proyectos con un enfoque BPM debido a grandes fracasos y a la pérdida de credibilidad que se ha generado. Cuidado, no quiero decir que el uso de herramientas BPMS sea innecesario, para nada, pero si pretendo argumentar que para enfrentar un proyecto de BPM lo primero es el negocio, la optimización continua, la gestión del cambio "hacer que las cosas pasen", una arquitectura práctica y agnóstica que de respuesta a lo que una Organización requiere y las herramientas que serán un medio que permitan estructurar e implementar las decisiones y diseños de arquitectura previamente definidos.

En general, se ejecutaron muchos proyectos fallidos con un enfoque pobre de mejoramiento continuo, con software rígido, inmutable, inmóvil y viscoso, que ante el cambio o un nuevo mantenimiento producían comportamientos anormales y reacciones en cadena, da miedo extenderlos o modificarlos.

Por todo lo anterior, en los proyectos de automatización es crítico soportar el cambio constante, porque así son los negocios, las Organizaciones,las personas, nada es inmutable. El cambio es frecuente y por tal motivo es necesario dar respuesta a esa necesidad a través de prácticas y técnicas simples que permitan agilizar la definición y captura de funcionalidades y de igual forma el diseño de arquitecturas sostenibles en el tiempo que puedan ser construidas de forma incremental.

He experimentado en varios proyectos el trabajo con un BPA (análisis de procesos de negocio) ágil enfocado en el mejoramiento continuo y en la captura de un conjunto de funcionalidades asociadas que ayuden a acercarse a la visión del proceso establecido. Aquí se implementan los análisis AS-IS y TO-BE con el diseño de procesos de alto nivel (PHLD) para evitar entrar en detalles innecesarios que se pueden abordar en fases de implementación.

En el BPA también he ejecutado actividades de arquitectura, con talleres ágiles de atributos de calidad, con la elaboración de decisiones de arquitectura basándose en escenarios y alternativas con el fin de concluir con diseños de alto nivel HLD con un acercamiento guiado por el modelamiento ágil. Me encantaría que el mito de que en los modelos ágiles no se hace arquitecturas quede cerrado, pues es claro que un proceso siempre estará evolucionando y es necesario estructurarlo bien para que en los ciclos de desarrollo se elaboren buenos diseños detallados DLD.

Algo de lo que he experimentado es el enfoque a talleres con el uso del papel y el lápiz como las principales herramientas para involucrar a personas de negocio y  de tecnología. Nada más aburrido que alguien con un laptop capturando ideas, definiciones, comentarios o conceptos ocasionando que el trabajo sea poco divertido, poco creativo, sin un enfoque de gente trabajando para generar procesos para que los utilice gente.

Al finalizar el BPA ágil, una Organización conocerá cómo un proceso podrá evolucionar al definirse una pila con prioridades de ítems funcionales denominada ProcessBacklog. Para llegar a la definición de esta pila se realizan actividades previas de estimación de muy alto nivel, la estructuración de criterios de aceptación y la generación de releases.

Si la Organización cambia, o el negocio crea nuevos productos o si las regulaciones externas cambian no habrá problema, pues el cambio será bienvenido. El dueño del proceso ProcessOwner decidirá las prioridades teniendo en cuenta las necesidades y las oportunidades que el mercado demande "driven-marketing".

Para las fases de implementación se aplican adaptaciones de SCRUM para la ejecución de cada uno de los release definidos en el BPA, produciendo procesos guiados por la disciplina de BPM en tiempos cortos, Sprints de máximo mes y medio que para este tipo de iniciativas es más que aceptable.

Definitivamente para las Organizaciones la agilidad respondiendo con entregas de software funcionando en tiempos cortos es vital, y por eso la utilización de diferentes técnicas ágiles y de un proceso SCRUM adaptado para las implementaciones de acuerdo a las necesidades de cada proyecto es una forma de responder a esas necesidades.

Ante la perdida de credibilidad, una alternativa viable y posible para las Organizaciones es la implementación de procesos en la nube BPMaaS con el fin de no hacer una inversión inicial con riesgos en activos de tecnología. Es importante aclarar que un BPMaaS no son las herramientas proporcionadas por un fabricante en la nube, porque eso sería un PaaS/BoP para procesos sino la implementación de procesos entre empresas con una plataforma común.

En una próxima entrada hablaré un poco de mi experiencia en cómo estructurar un proceso ágil para un proyecto BPM utilizando diferentes técnicas en las fases de BPA y de desarrollo D-BPM: ImpactMapping, Visual Story Mapping, Value Stream Mapping, User Stories Workshops, QaW ágil, criterios de aceptación (Given-When-Then), talleres para la captura de reglas de negocio, estimaciones, releases y artefactos de arquitectura, BTDD, ATDD, TDD, entre otros.

¡Un saludo!

7 comentarios:

  1. Muy cierto! Actualmente trabajo en un sistema BPM asi.

    100 % orientado a la tecnologia y muy poco (o nada orientado al negocio).

    ResponderEliminar
  2. Hola Guido, gracias por tus comentarios .... casi siempre el enfoque es TI y poco se ve una orientación a la gestión por procesos real.....lamentablemente...

    ResponderEliminar
  3. Totalmente de acuerdo con Gabriel.

    En los proyectos de automatización de procesos nada es inmutable y es precisamente por esta razón que considero que las metodologías ágiles “pegan” directamente con los proyectos BPM. Por mi experiencia usando metodologías ágiles en proyectos BPM, puedo afirmar que éstas se adaptan con mayor facilidad este tipo de proyectos, proyectos que generalmente son grandes por ser automatizaciones transversales a toda la organización; las iteraciones y entregas constantes al cliente hacen que poco a poco los involucrados vean plasmado el objetivo del negocio en su proceso BPM tangible, donde la incertidumbre y el riesgo será cada vez menor. Sin embargo, hay paradigmas difíciles de romper cuando se propone al cliente implementar estos frameworks de trabajo ágiles, generalmente los BPMs son comprados por compañías grandes que tienen una estructura muy cerrada y jerarquizada, cambiar esta cultura es difícil pues cuando hablamos de implementar la agilidad esta se debe llevar a toda la organización y no solamente al proyecto BPM.

    ResponderEliminar
    Respuestas
    1. Gracias John por tu comentario. Totalmente de acuerdo!!

      Eliminar
  4. Hola Gabriel, me gustaría conocer más sobre tu experiencia usando la agilidad en proyectos BPM, veo que usas terminología de SCRUM pero enfocados a este tipo de proyectos; me gustaría saber más al respecto.

    Muchas gracias.

    Saludos.

    ResponderEliminar
  5. Hola John, bueno te podría contar un poco acerca de cómo he trabajado en ello. En realidad Scrum va en la fase de desarrollo, pero antes, he utilizado técnicas ágiles para estructurar y definir el alcance de un proceso (visión de proceso) aplicando Impact Mapping, Visual Story Mapping, trade-offs, alineación con el proceso y su arquitectura, etc, etc..... quizás ayude un poco esta imágen: http://www.gauditech.co/#soa&bpm

    ResponderEliminar