Este artículo rata sobre la confusión que produce la creciente oferta de Suites de BPM (BPMS), donde todos los fabricantes prometen los mismos beneficios y hablan de lo mism. Este artículo ofrece algunas nociones para poder discernir sobre la oferta y, sobre todo, ayuda a empezar a pensar qué BPM es necesario para cada escenario.
Las mejoras que introduce un BPM a parte de ser buenas, tienen que ser ciertas. El BPM solo no va a traer esas mejoras, si no está bien combinado con una labor de análisis y de documentación orientada a los procesos que se quieren implementar.
Hay BPMs que están muy orientados a la integración de aplicaciones. Aquí encontraremos a los fabricantes clásicos, que además soportan el estándar BPEL y que están apostando por SOA.
Los BPM puros, que son de reciente aparición, no se integran tan fácilmente en un entorno de aplicaciones previo y, para mayor desazon, en muchos caso utilizan sus propias extensiones de XPDL para definir procesos.
Así que debemos reflexionar sobre qué BPM queremos: si el que está basado en documentos, el basado en interacción humana, uno donde los procesos siempre van hacia adelante y además se exige rapidez de ejecución, etc.
Por otro lado, será bueno ver qué estándares soporta el BPM que queremos comprar, o que nos quieren vender. Si con suerte, todos los fabricantes se adhieren a BPMN (BPM Notations), en un futuro igual podremos cambiar de BPM y seguir utilizando los procesos que ya hemos modelado.
Aunque esa es una utopía que la industria informática no sabemos si va a hacer realidad, si nos basamos en los estándares aprobados en el pasado (SQL, por ejemplo) las previsiones pueden ser de que la interoperabilidad al 100% no va a ser.