Uso de BPMS en desarrollo de Software

Como primera aproximación de lo que considero un muy buen artículo para esta oportunidad transcribo algo que leí hace un tiempo:

BPM aplicado al Desarrollo de Software.
Publicado en la revista Software Guru de Julio del 2005.

Uno de los errores más comunes dentro del entendimiento de lo que significa BPM, consiste en la creencia entre los desarrolladores de que Business Process Management se refiere a herramientas específicas, productos o metodologías orientadas al desarrollo tecnológico y de
software.

Es cierto que J2EE (la plataforma de moda) nos proporciona herramientas para implementar estrategias BPM, y también es cierto que existen varios productos “Out of the Box” que nos permiten modelar nuestros procesos de negocios, y llevar su seguimiento.
Lo que es esencial entender, es que BPM es una estrategia de negocios, no tecnológica, y que se sirve de la tecnología para alcanzar sus metas. BPM es el resultado en una tendencia mundial hacia la claridad y transparencia dentro de los procesos, aportando flexibilidad al mismo tiempo, y acabando con los órdenes monolíticos dentro de los flujos de trabajo, que hacen imposible a la empresa el adaptarse rápidamente a las condiciones eternamente cambiantes del mercado.

En una empresa que gira en torno a la tecnología y al desarrollo de software, también existen procesos de negocio, flujos de trabajo que deberían estar definidos, materia difusa e intangible para la mayoría, y que solo vive en la cabeza del Arquitecto o del Lider de proyecto.

La gran mayoría de las personas que representan los roles en un entorno de desarrollo, a pesar de su alta necesidad de conectividad, interacción y retroalimentación por parte de sus compañeros, hacen esfuerzos heroicos para adivinar exactamente cual es el tipo de información que se requerirá para los siguientes pasos del flujo de desarrollo, y a la vez, ruegan todos los días por que los artefactos que lleguen a sus manos, provenientes de fases anteriores, contengan
toda la información necesaria.
Claro, existen metodologías estructuradas, como RUP, que nos dicen lo que entra y lo que sale de cada una de las etapas de nuestro proyecto, pero de ninguna manera estas son soluciones definitivas a los problemas de workflow, puesto que al final, el proyecto mismo es quien
decide la estrategia que se ha de tomar. A veces los artefactos escogidos no son los adecuados, a veces los requerimientos reptan mas allá de nuestras esperanzadas iteraciones, y a veces también, la gente se da cuenta de que “El sistema” no es la piedra clave, y que el sistema se deberá adaptar al negocio de cierta sutil manera, (la manera que el cliente decide), sin importar si la metodología dice tal o cual cosa.

También en el desarrollo de sistemas, los procesos de negocio deben de ser mesurables, colaborativos, finitos (de manera indispensable), y eficientes.

La implementación de CMM tiene como resultado la eficientización de los procesos, identificando las áreas clave, cuellos de botella, y a la vez atajando uno a uno los riesgos y minimizándolos. ¿Es esto una solución total? ¿CMM nos da la flexibilidad para sobreponernos a cualquier problema? Si esto fuera cierto, pudiéramos pensar que la existencia de proyectos excedidos en presupuesto, con funcionalidad defectuosa y entregados después de la fecha límite, es una historia de
terror del pasado. La triste y a la vez prometedora realidad, es que aún tenemos mucho trabajo que hacer, y precisamente parte de este trabajo es el empleo de metodologías BPM dentro del desarrollo de software, y a la vez, valga la redundancia, el desarrollo de herramientas que nos permitan mapear, seguir de cerca y medir los procesos de desarrollo, así como comunicar y reutilizar el conocimiento generado dentro de estos.

Las metodologías actuales de flujo de trabajo para el desarrollo de software se centran en la documentación extensa y el modelado, siendo el modelado una extensión misma de la documentación. El modelo es el sistema, la documentación es el sistema, y por supuesto el código es el sistema, en una representación que varía en su grado de granularidad de acuerdo a la fase de desarrollo en que nos encontremos.

¿Ahora, en que consiste una solución de BPM?
La tecnología detrás de los sistemas BPM es el software que automatiza y hace más directos y eficientes los procesos. Típicamente, la solución debe incluir una herramienta gráfica de diseño y navegación de procesos, herramientas de modelado y simulación, software de integración y middleware, así como capacidades de monitoreo y reporteo de cada uno de los procesos. Las herramientas más avanzadas en este sentido proveen lenguajes de definición de procesos basados en XML, que hace que sean entendibles tanto como por el personal de IT que
implementará la tecnología que soporta el proceso, como por los administradores y gerentes que lo supervisan. Estas herramientas también nos proveen formas de implementar los procesos de acuerdo a una arquitectura orientada a servicio (SOA).
Queda claro a partir de esta definición, y de lo anteriormente discutido, que BPM es un enfoque que puede ser de gran ayuda para hacer mucho más eficientes los procesos dentro del desarrollo de software.

Los procesos del desarrollo de software, comúnmente se definen a partir de los diferentes milestones o hitos a los que va llegando el proyecto, y estos a su vez se definen a partir de los soportes documentales o artefactos programados para cada fase. La realidad, es que en el desarrollo de software los procesos se entrelazan de maneras inesperadas, y muy al pesar de los metodólogos, aún dependen del heroísmo personal de los participantes del proyecto.
La visión documento-céntrica y asociada a roles del RUP, es muy útil en el sentido de la estandarización de procesos, y como un checklist probado de patrones de organización de proyectos en base a los entregables que se deben de conseguir. Lo que el RUP no toma en
cuenta, es la interacción humana, y el alto grado de entropía en los proyectos, donde los artefactos se transforman, cambian hasta sus raíces y finalmente son usados para propósitos diferentes a los de su concepción.

Los encargados de la administración de los proyectos se basan en un enfoque jerarquizado que les permite mantener un cierto control de la información basado en la restricción de los roles y artefactos, sin tomar en cuenta las oportunidades y la eficiencia.
La eficiencia de los procesos en el desarrollo de software queda incompleta aún implementándola dentro del marco de las mejores prácticas de desarrollo y hasta de procesos de negocio. Lo que se necesita es una solución más completa, y que sea capaz de armonizar los conceptos de BPM con las metodologías formales de desarrollo como XP o RUP, todo esto dentro de un marco de colaboración en capas, indistinto de organigramas y que permita aislar y atacar las
oportunidades y sinergias no solo en cuanto a los roles dentro de los procesos, sino en cuanto a las competencias de cada individuo, sus habilidades, intereses y hasta sus metas particulares.

BPM es un esfuerzo encaminado a la flexibilidad y el tiempo de respuesta ante condiciones cambiantes. Las condiciones cambiantes en un megaproyecto de desarrollo son una realidad que va más allá del simple cambio de requerimientos, y que tienen que ver más con la falta de unificación de criterios de negocio que nos permiten conocer las necesidades reales de los clientes externos (los compradores del sistema) y nuestros clientes internos (las personas trabajando en
otros módulos o fases del desarrollo del sistema).

¿Qué pasa si a la mitad del análisis nos damos cuenta que uno de los artefactos simplemente no tiene relevancia de acuerdo al problema atacado? ¿Quién se da cuenta de esto? Obviamente no es el arquitecto, ni el líder de proyecto, ambos encerrados en sus actividades de control. ¿Qué uso se le da a la información que no generó utilidad inmediata o esperada? Los verdaderos poseedores de la información y los que perciben de manera instantánea sus incongruencias son los que trabajan directamente con ella: analistas, programadores, testers y demás, por tanto en ellos debe de recaer (de manera colectiva y no personal) el mantenimiento de una base de conocimientos común que permita el intercambio sin fronteras de la información hacia adentro.
El mantenimiento de los vínculos para la fluidez de esta información, es responsabilidad de los arquitectos, administradores de la configuración, y en última instancia del líder de proyecto, que además debe facilitar estos mismos vínculos a los “stakeholders”, usuarios y consultores de negocio de los proyectos, para cerrar el ciclo de comunicación.

La comunicación es, por mucho, el activo más valioso dentro del desarrollo de sistemas, solo comparable en importancia con nuestros recursos humanos calificados. Es por esto que toda implementación que planee hacer uso de las herramientas de BPM en el ámbito del desarrollo de sistemas, dependerá primordialmente del nivel de soporte a las comunicaciones inteligentes y la transferencia del conocimiento entre diversos “keyplayers” en diferentes áreas.
Lo ideal, en el sentido de la comunicación, serían herramientas que fueran independientes del organigrama en el sentido del intercambio positivo de la información no clasificada, y que además fuese sensible a estas mismas estructuras organizacionales para poder intercambiar de manera segura la información confidencial que no es de interés para todos los miembros del equipo. La herramienta, deberá ser sensible socialmente a las relaciones mantenidas por parte de los diferentes miembros de los equipos, para poder aprovechar los canales de comunicación mas eficientes, y que no deben de fallar a causa de las altas tasas de rotación de personal, ni a las condiciones cambiantes de movilidad organizacional. Nuestras herramientas y conocimiento,
deben de estar a la mano de quien lo necesita, independientemente de si el dueño de la información dejó de trabajar en la empresa, recibió un ascenso, cambió su rol o cambió de proyecto. El manejo del conocimiento debe de ser contextual e hipervinculado, así como
modificable por cada uno de los miembros que posea la información necesaria para hacer aportaciones positivas, aún y cuando aparentemente su área de responsabilidad no sea congruente. Siempre habrá posibilidad de que el administrador de la configuración reciba un reporte de incongruencias en la edición de un documento, y simplemente aplique un Rollback a la última versión estable de la documentación.

La organización en células de trabajo cohesivas internamente y modulares hacia el exterior, nos permitirá hacer un intercambio dinámico de recursos, independientemente de si el proceso actual o requerimiento, dicta que primero llevemos a cabo el análisis y luego simulaciones, o viceversa. Nuestras herramientas flexibles de BPM deberán permitir el acoplamiento de nuestros flujos de trabajo a situaciones variadas en las que los procesos puedan tomar formas
iterativas, en cascada, aleatorias y hasta caóticas, pero siempre sin perder de vista el alto grado de comunicación necesaria y el mantenimiento de los estándares documentales que nos permitirán obtener retornos sobre cada una de las fases de nuestros proyectos. La comunicación deberá de ser sensible a las personas y sus maneras naturales de agruparse en cuanto a intereses, habilidades, conocimientos y hasta amistades, y no solamente en cuanto a células de
trabajo bien estructuradas, dado que sabemos que el trabajo en desarrollo de sistemas no permite que estas células sean persistentes en el tiempo, en cambio el conocimiento permanece ahí, en esa área gris representada por los vínculos sociales entre las personas.
Nuestros recursos humanos podrán aprovechar conocimientos generados en diferentes células y hacerlo con el menor costo posible en términos de comunicación organizacional, y sin tener que pasar por muchos eslabones redundantes que únicamente fiscalizan el proceso sin aportar
nuevos conocimientos o valor.

Los elementos necesarios mínimos que debe de incluir una solución BPM para el modelo de negocios de desarrollo de software son los siguientes, sin un orden particular de importancia:

Definición y administración dinámica de procesos, independiente
de metodologías formales (se deberá poder implementar cualquier
metodología, según se considere conveniente).
Enfoque de producción basado en documentación estandarizada.
Formación de equipos de trabajo cohesivos internamente y modulares
hacia fuera, con un enfoque particular en sus procesos propios,
pero permitiendo la participación en los procesos ajenos.
Herramientas de modelado y definición de procesos, incluyendo una
interfaz gráfica.
Herramientas de reporteo y seguimiento de los procesos en tiempo real.
Middleware que permita conectar las diferentes partes, sistemas, y
equipos de trabajo, con un enfoque orientado a procesos
dinámicos.
Herramientas de comunicación colaborativa sensibles a la competencia,
habilidades y relaciones sociales de los recursos humanos del
proyecto.
Herramientas colaborativas inteligentes de administración del
conocimiento, que permitan el flujo de información seguro y a la
vez transparente, independiente de organigramas, y que busquen la
participación indistinta de las personas que poseen el
conocimiento.

--
Axel Nissim S.
CEO entrempresarios.com