Como llevar a cabo proyectos de BPM exitosos (revisited)

Pululan en el mercado diversas soluciones de Business Process Managment (BPM) , con distinto grado de prestaciones y mecanismos de licenciamiento, con las cuales se pueden construir proyectos de automatización de procesos, según las preferencias y posibilidades de cada organización.

No obstante esa diversidad, es posible, de acuerdo a mi experiencia en el área, extrapolar una serie de principios, normas y prácticas que ayudan a conseguir una implementación menos traumática.

Primero empecemos por definir que es BPM y que es solución de BPM (BPMS).

SegúnWikipedia “El BPM es el entendimiento, visibilidad, modelado y control de los procesos de negocio de una organización. Un proceso de negocio representa una serie discreta de actividades o pasos de tareas que pueden incluir personas, aplicativos, eventos de negocio, tareas y organizaciones”.

Como vemos, no necesariamente  tiene  que ver con la automatización, sino más bien con una estrategia de visión integral de los modelos de proceso y flujos de trabajo de una organización cualquiera.

“Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de herramientas son llamadas Business Process Management Software(BPMS), y con ellas se construyen aplicaciones BPM. Normalmente siguen una notación común, denominada Business Process Modeling Notation (BPMN). Otras poseen una notación propia y son capaces de generar código”.

Entonces los BPMS son un conjunto de herramientas destinadas a facilitar la implementación de procesos de negocio, generalmente automatizados, y bajo una nomenclatura estándar denominada BPMN.

Dicho esto, vamos a la definición que suelo brindar en los talleres y seminarios donde, algunos valientes, suelen invitarme.

El BPM se refiere al Control. Su propósito es el Control. Sus herramientas y recursos diversos sirven al Control. Y el Control amigos míos, en términos de procesos, busca garantizar que LO QUE DEBA SER HECHO, lo haga QUIEN DEBE HACERLO, CUANDO DEBA HACERLO, y COMO DEBA HACERLO. Así de simple.

El QUE, trata sobre las actividades, pasos y tareas, las obligaciones de acción, que conforman un proceso cualquiera.

El QUIEN, nos habla de los actores, personas o sistemas que se deben encargar de realizar una determinada tarea o actividad.

El CUANDO, nos sumerge en el momento, lapsos, períodos, ciclos y sus derivados relativos al tiempo en que se debe completar una actividad.

El COMO, versa sobre las reglas de negocio, las condiciones y parámetros que se deben validar y cumplir para poder completar una tarea.

Todo esto dentro del marco de la ejecución de un proceso. Es decir, dentro de una instancia, un caso, de un proceso ya definido.

El BPM se refiere al CONTROL. Lo repito. Todo lo demás es puro derivado, refinamiento, complemento, adorno u ornamento que proviene como consecuencia del CONTROL que brinda el BPM y sus herramientas asociadas.

Pasemos entonces a las ya esperadas recomendaciones, que tardan tanto en llegar que se parecen a los dragones de Game Of Thrones jajajajaja.

En primer lugar, aprenda, entienda, comprenda y domine la notación BPMN. No se conforme con el modelado entusiasta y optimista que haya realizado alguien del negocio. Recuerde que es ese modelo o proceso el que al final se debe tomar y modificar para poder ejecutarlo y llevarlo a su implementación. Adquiera, o cuente con alguien que posea, las habilidades y experiencia necesarias para hacer un uso efectivo de los componentes de representación del BPMN. Un proceso modelado pobremente será fuente inagotable de riqueza en dolores de cabeza. Más claro imposible. Acá un enlace de los amigos de Camunda que profundiza en el tema de los elementos de la notación BPMN.

Segundo, no pretenda hacer del BPMS su herramienta de desarrollo de software. NO. No importa que tan impresionante sean las demos de los fabricantes y sus vendedores. Todos los fabricantes le van a hacer una demos donde así, rapidito, facilito, modelamos el flujo, definimos unas variables, agregamos una decisión, par de tareas humanas por aquí y por allá y… LISTO tenemos una Aplicación “READY” para despliegue y producción.

Eso es importante. Es bueno que la herramienta lo posea y lo facilite. Pero es en esencia una mentira con fundamento. En principio el BPM no está concebido como herramienta de desarrollo. Eso es útil para talleres o workshops de levantamiento de procesos, elaboración de prototipos e implementaciones simples. Pero imagine que se requiere automatizar un proceso enorme, donde el todo poderoso usuario espera las interfaces más bellas y llenas de funcionalidades y “facilidades” que se pueda imaginar, o simplemente espera algo parecido a lo que ya conoce. Y resulta que su BPMS ofrece la posibilidad de desarrollar todo eso, ahhh, pero eso si, usando Angular y Javascript. Y resulta que el fuerte de su equipo de desarrollo es de PHP y C#. No vamos a proponer el despido de esos fieles desarrolladores, hábiles y antiguos de nuestro departamento de software y, seguramente, tampoco tenemos presupuesto para  contratar un nuevo ejército de desarrolladores exclusivos para nuestro BPMS. El BPMS debe acomodarse a las buenas prácticas y políticas de desarrollo empresarial de su organización, no al contrario.

Esto nos lleva al Tercer lugar. Escoja una herramienta o solución de BPM que tenga una poderosa API, basada en estándares de la industria, de integración y comunicación. Es requerido una API REST o SOAP amplia y poderosa. Que permita que, prácticamente todo lo que se pueda hacer en forma gráfica, en los editores y simuladores, pueda ser hecho por medio de dicha API. Aprecie los BPMS que facilitan la comunicación con los formularios y las actividades de las que se derivan, por medio de APIs sencillas, estándares y automáticas de ser posible. Así mismo, prefiera soluciones de BPM ligeras y escalables, configurables y flexibles.

Su solución de BPM debe ser capaz de manejar altos volúmenes de instancias, escalamiento horizontal y multi-tenance, pero al mismo tiempo debe ser posible el poder usar dicho bpm-engine como un producto embebido dentro de nuestras aplicaciones y servicios. 

Cuarto. Keep It Simple Stupid (KISS) & You Aint Gonna Need It (YAGNI), deben ser sus máximas de diseño y construcción. Nada de complacer a los usuarios en todo. Olvídese de preparase para cambios que ocurren cada 30 años. No sobre diseñe. No sobre especialice. Haga lo que se requiere y hágalo bien, bajo estándares y con flexibilidad. Pero sin caer en refinamientos absurdos y exquisiteces innecesarias.  No todo lo automático y nuevo es mejor necesariamente. Use el menos común de los sentidos, el sentido común.

No modele procesos que tiendan a traspasar o transgredir las fronteras de negocio. Haga procesos atómicos y en lo posible re-utilizables. Por atómicos me refiero a que cada proceso debe corresponder a la tarea específica, del área de negocio que se desea automatizar. Es un error frecuente el modelar procesos en apariencia simples, pero que involucran y mezclan a muchas áreas de negocio en un solo flujo, cuando la norma debería ser el tener varios procesos trabajando al unisono para atender el caso de negocio determinado, pero sin mezclar las responsabilidades ni los flujos o diagramas. 

Quinto lugar.  Sólo declare y use aquellas variables del proceso que son parte de la toma de decisiones y de las reglas de negocio. Nada más. Nada menos. Imagine que tiene un proceso para la gestión de órdenes de compras. Donde el elemento primordial es la solicitud de compra. Dicha solicitud lleva un sin número de variables referentes a quien hace la compra, la fecha, los artículos que se quieren comprar, y un largo etc. Pero para decidir cómo clasificar la solicitud y autorizarla sólo se necesita el Monto de la solicitud, la unidad solicitante, y el identificador del proveedor. Son estos últimos los datos que deberá modelar en su BPMS con vías a tomar las decisiones adecuadas y aplicar las reglas correspondientes. 

Poco o nada va a realizar con los demás valores que, si bien son importantes, forman parte del sistema de Compras y la Solicitud más que del proceso de compras en si mismo. Si modela todo en el BPMS se verá pronto abrumado por un gran número de variables, modelos de datos complejos, configuraciones diversas e, incluso, servicios de acceso a datos y bases de datos, flujos mezclados y areas de negocio solapadas, por decir lo mínimo. 

Y, la verdad, todos esos elementos son requeridos tan solo para hacer una representación correcta de la instancia de la solicitud de compra con que se trabaja, orientados a satisfacer alguna pantalla o formulario complejo, pero con nulo aporte al proceso de toma de decisiones y reglas de negocio.

Es mejor estrategia construir los formularios, con todos sus datos y servicios requeridos, fuera del  BPMS en una aplicación dedicada o sistema de compras, y que al momento de completar la solicitud, o cualquier otra tarea, dichas pantallas o formularios pasen sus datos y valores de entrada al BPMS, por medio de la API. Esto garantiza que las responsabilidades están separadas y que es mas fácil mantener los servicios, aplicaciones y procesos.

Esto nos permite, además, tener los datos de las solicitudes de compras y demás elementos relacionados, a buen resguardo en nuestros propios sistemas de bases de datos, y no en los esquemas del BPMS como sucedería de mantener todas las variables declaradas y manejadas en el BPMS. De esta forma nuestras políticas de seguridad y mecanismos de reportes se pueden aplicar con facilidad y en forma independiente de los mecanismos o recursos propios del BPMS. Imagine tener que realizar un reporte a punta de llamadas a la API del BPMS tan sólo para obtener los datos necesarios. Como dije, NO IMPORTA LO QUE DIGA EL FABRICANTE.

Sexto lugar. Zapatero a sus zapatos y pastelero a sus pasteles. Deje que el BPMS se encargue de lo que mejor hace. Las notificaciones, correos, señales, mensajes, selección y discriminación de actores, roles y grupos, candidatos a tareas, suspensión e inicio de actividades y procesos, registro de indicadores de procesos y negocio, mantenimiento y aplicación de las reglas de negocio, son todas tareas y actividades que debe desempeñar el BPMS y nadie mejor que el para hacerlas.

Deje que el negocio sea dueño de sus procesos. Sea Ud. dueño de las automatizaciones.

Por otro lado, la Integración de sistemas, la orquestación de sistemas, la transformación de datos, la gestión documental, la gestión de usuarios, y la gestión de mecanismos de autenticación y autorización, son todas tareas y actividades fuera del alcance del BPMS y, por lo tanto, no se debe buscar que este las realice o las reemplace. Cuando mucho el BPMS usará esas herramientas y recursos para poder hacer un mejor trabajo. 

Al Cesar lo que es del Cesar. No asuma, ni crea, que la gente de negocio quiere, puede, o sabe como modelar procesos funcionales que sean fácilmente trasladables a unidades automatizadas. Eso es una mentira. Recuerde. Nada de Zero Code.

Séptimo y último lugar. Implemente BPM como parte de su estrategia en SOA (SOAP-REST). En lo posible. Se lo ruego. Se lo ordeno. Haga que sus proyectos de BPM sean parte de su proceso integral y empresarial de SOA. Nada del síndrome de las Isla verticales, los nidos de tecnología, los sistemas enclaustrados y las plataformas aisladas de gestión. Haga que SOA y BPM trabajen para su negocio. Verá como la “Transformación Digital” y todas esas “modas” de gestión, son cosa de niños cuando se encuentran enmarcados dentro de una cultura, metodología y filosofía integral de arquitectura empresarial.


Hasta la próxima.