POR QUÉ BPMN: ORIGEN Y RAZONES PARA SU ADOPCIÓN

En la actualidad BPMN (Business Process Model and Notation) es el enfoque más sólido para modelar los procesos de negocio de una organización. Como lenguaje de modelado, es hoy el estándar de la industria informática, en particular adoptado por las industrias de bancos, seguros y telcos. Cuando nace un nuevo paradigma como BPMN, no nace porque sí. Existe un contexto fértil de demandas y necesidades por satisfacer. Para BPMN ese contexto incluye no sólo a analistas o recursos involucrados en IT, sino también sectores gerenciales y administrativos a lo largo de toda la organización.

El nicho existe

Esencialmente faltaba una notación unificada, eficaz y simple que pudiera servir como medio de comunicación entre todos los actores involucrados, ya mencionados. Los problemas que acarreaba esta situación no eran menores: la necesidad de traducir los requerimientos de un sector a otro, errores en la comunicación y traslado de directivas, falta de eficiencia en la realización de tareas y actividades, escaso control del avance de los procesos de negocio. Dichos problemas implicaban menor productividad, y un mal aprovechamiento de recursos, tiempo y dinero.

Muchas empresas y organizaciones atacaron parcialmente estos problemas de alguna manera “ad-hoc”, introduciendo algún esquema interno de comunicación. Pero muchas veces, en organizaciones grandes, tales esquemas variaban entre los distintos departamentos, lo cual seguía generando confusión. Incluso cuando se generaba un mismo esquema para un determinado proceso, a lo largo de la organización, el mismo podía ser desconocido tanto por los mismos empleados que debían aplicarlo, como por terceras partes, lo cual afectaba negativamente tanto la productividad de dichos empleados, como la interacción con otras empresas y proveedores de servicios.

Caldo de cultivo

Supongamos que dentro de una compañía enfocada en el desarrollo de software la gerencia decide mejorar el proceso de testing con el objetivo de evitar errores aún más costosos en producción. El primer paso consiste, entonces, en citar a la persona encargada del testing dentro de la empresa. Resulta fundamental que dicha persona pueda transmitir fehacientemente, y de manera clara y entendible todo el proceso para que pueda ser entendido desde el sector gerencial. Dicha comunicación debe evitar detalles técnicos (por ejemplo, nombrar la palabra CVS o commit) y enfocarse en actividades de alto nivel (por ejemplo, que “se introducen ciertos puntos de control dentro del proceso”). Si la comunicación resulta efectiva, desde la gerencia podrán crear el marco para que surjan potenciales mejoras al proceso de testing.

Soluciones anteriores a BPMN

Una opción adoptada por diversas empresas fue la adopción de marcos de comunicación propios de la empresa o algunos de sus sectores. Continuando el ejemplo anterior, el sector de Testing puede proveer una solución para comunicar su proceso de testing a través de ciertos gráficos, asignándole significado a los elementos involucrados.
De esta manera, podrán difundir y explicar el proceso de testing ayudados por dicho “lenguaje”, que generalmente es excelente desde el punto de vista de la representación gráfica, (léase muy vistoso), pero carece de sintaxis y de semántica.

Otra alternativa posible era adoptar algún lenguaje ya conocido del momento en vez de utilizar uno propio. Una vez que la gerencia es capaz de aprender este nuevo lenguaje, la comunicación se acelera, tornándose al mismo tiempo más efectiva, sabiendo que el ciclo de correcciones se redacta con el mismo lenguaje adoptado.

Sin embargo, así como el sector de Testing puede haber resuelto de esta manera ad-hoc este problema, lo mismo puede pasar en los sectores de Ventas, Mantenimiento, Desarrollo, etc. Si desde la gerencia de la compañía se decide ahora revisar procesos de negocio que involucren más de un sector, es posible se retorne al problema inicial. Por ejemplo, antes del release de una nueva versión de un producto, se debe contar con el OK del sector de Testing, la aprobación de Marketing, de Desarrollo y de Finanzas, dependiendo de la estructura jerárquica de la compañía.
Cambios en estas políticas lleva indudablemente a que todos los sectores mencionados se comuniquen. Si cada sector desarrolló su propio lenguaje, la reunión con todos los actores involucrados resultará en un collage de flechas y gráficos difíciles de entender por todos los involucrados. Además, se debe tener en cuenta que la gerencia debe “aprender” los lenguajes de cada sector. Claramente, no es esquema razonable.

Sin embargo, podemos suponer que los distintos sectores en vez de desarrollar su propio lenguaje, deciden aprender y utilizar el primer lenguaje creado desde el sector de Testing. Bajo este esquema es posible la comunicación entre todos los sectores, y la posibilidad de modelar todos los procesos de negocio e introducir mejoras, incluso en aquellos que son transversales a toda la organización, lo cual es cada vez más frecuente. Dando un paso más, la empresa podría encarar el desarrollo de herramientas propias para automatizar el modelado. Si bien podría pensarse como algo costoso, en organizaciones medianas y grandes tendría un gran impacto y un rápido retorno de la inversión. Esta herramienta podría detectar rápidamente posibles “cuellos de botella” en el proceso de negocio que modela el lanzamiento de un nuevo release.

Bruno van Dam
Más información en www.bpmcyt.com