Cualquier herramienta o solución de BPM de buen nivel ofrece un conjunto loable de funciones que facilitan la gestión de procesos con dichas herramientas.
Una de las opciones infaltables y de las mas promovidas por los consultores y vendedores de soluciones de BPM es la de ZERO CODE, cero codigo; la cual consiste en la habilidad de obtener una aplicación capaz de ejecutar nuestros procesos con apenas unos clicks.
La idea general es que se reduzca el desarrollo de aplicaciones a la medida y la programación global, dejando toda la tarea de la automatización y construcción de aplicaciones sobre los recursos que provee la solución de BPM.
Siendo honestos, esta funcionalidad está muy bien cuando se inicia un proyecto de BPM, en la etapa en la que se modelan los procesos y es necesario validarlos, para lo cual no existe nada mejor que un prototipo rápido que es lo que brindan muchas herramientas de BPM.
Los problemas empiezan cuando se quiere implementar proyectos grandes de BPM con estas herramientas, y es aqui en donde entra el otro elemento del título de esta publicación: los procesos complejos.
Y por complejos me refiero a procesos con mas de 12 tareas humanas y mas de 5 actores con roles diferentes. Así mismo, son procesos que requieren perisistir una gran cantidad de información, integrarse con varias plataformas y consumir uno o mas servicios diversos.
En general el desarrollo de estos procesos sobre las plataformas de BPM habituales redunda en aplicaciones inestables, con una capa de presentación mediocre o poco funcional y con un requerimiento de mantenimiento elevado.
He visto muchos grandes proyectos construidos con grandes herramientas de BPM ir directo al fracaso debido a la mala implementación de la solución realizada completamente sobre el motor de BPM y sus recursos.
En general los motores de BPM son excelentes para la orquetsación de tareas y la asignación de responsabilidades. En otras palabras son inmejorables para garantizar el control: que lo que deba ser realizado sea realizado por quien debe realizarlo cuando deba hacerlo.
Se les considera menos eficientes para producir aplicaciones de gran funcionalidad que trabajen sobre esos procesos. Sencillamente el desarrollo y mantenimiento de aplicaciones no es su fuerte.
Por esta razón cuando me toca evaluar una herramienta de BPM no me dejo seducir por sus deslumbrantes capacidades de modelado y despligue rápido de de aplicaciones. No señor.
Lo que busco es conocer a fondo sus facilidades de integración con diversas plataformas. Escudriñar sus facilidades para trabajar con datos complejos de diversas fuentes. Determinar sus capacidades en cuanto a las distintas APIs y modos integración que ofrecen.
Es en este último tópico en el que centro mi esfuerzo, pues son de las APIs de las que va a depender el grado de control externo que pueda brindarme una solución de BPM cualquiera.
En otras palabras, voy a usar frameworks de trabajo bien conocidos para integrar la solución de BPM con mis aplicaciones nativas y dedicadas.
No construiré un sistema de compras públicas sobre un motor de BPM. Por el contrario, desarrollaré un sistema de compras públicas orquestado e integrado por y con el motor de BPM.
En este desarrollo manejaré los procesos como módulos lo mas independientes y sencillos posibles, para de esta forma poder gestionar con eficiencia esos procesos y sus aplicaciones dependientes.
Nada viene sin un precio, y el desarrollo y el mantenimiento efectivo son el precio que pagamos por un mayor contro y mejores prestaciones sobre nuestras aplicaciones de BPM.
Hasta que las herramientas o soluciones de BPM no evolucionen lo suficiente seguiré promoviendo y prefieriendo el fiel desarrollo eficiente sobre la, para mi, errada política de ZERO CODE y COMPLEX PROCESS.
Comentarios
Publicar un comentario