BPM es «un tren» al que se quieren subir fabricantes de:
– servidores de aplicaciones
– soluciones EAI
– workflows basados en formularios
– workflows basados en documentos
– aplicaciones empaquetadas
– proveedores de BPMs puros
Sin embargo, a pesar de las cifras «mágicas» que siempre se manejan, basadas en mejoras de productividad, de tiempo, de flexibilidad…, las empresas se muestran reticentes y cautas a la hora de optar por las Suites de BPM: aún hace falta visibilizar esas mejoras y los procesos de negocio son tan críticos, que si fallan las consecuencias pueden ser nefastas.
El autor apuesta por que las compañías aprendan a distinguir entre los sistemas que son transaccionales y los que no lo son. El reto de los nuevos BPMs está en el primero de los casos.
Lo novedoso es la confluencia de estos diversos sistemas transaccionales y los BPMs. El quiz de la cuestión es comunicar las diversas transacciones e integrarlas en el proceso global, el autor cree que la gestión de transacciones de J2EE sirve bien para este propósito.
El beneficio teórico es muy atractivo: una nueva forma de optimizar y hacer más rentable las operaciones de una empresa; detectando, definiendo y monitorizando los procesos que intervienen. Y además una mejor convivencia entre los responsables de informática y los de operaciones, finanzas, administración.. vamos lo que tiene que ver en sí con el negocio.
Se está asistiendo a un cambio de paradigma, se deja atrás las aplicaciones monolíticas basadas en Gestores de Bases de Datos Relacionales a los BPMs, preferiblemente como parte de una Arquitectura basada en Servicios (SOA). Parece que estos hagan obsoletos a los «rigidos»
ERPs, pero es evidente que las inversiones en ERPs se van a proteger, así que los BPMs van a tener que hacerse su hueco y colaborar.
El autor adelanta que los BPMs serán rápidamente comoditizados y el valor estará en el conocimiento del negocio y sus procesos.