Posible modelo para la gestión de múltiples aplicaciones EAI hacia BPM (Parte II)

Haciendo referencia al post  “Posible modelo para la gestión de múltiples aplicaciones EAI hacia BPM (Parte I)” hoy me gustaría explicar el siguiente paso Natural para llegar a tener un EAI orientado hacia BPM.

Como ya se explicaba en el primer paso ya tenemos la “integración de sistemas basado en funcionalidades, no en datos”.

Ahora nuestro siguiente paso es automatizar nuestros procesos que hasta el momento lo realizamos de forma manual y poco estructurada, o mejor dicho, cada persona y cada organización tiene sus procesos claros, no diré documentados, porque eso seguro que mas de uno suspende, encima si sumamos que actualmente una compañía puede haber adquirido una o mas compañías, una buena forma de organizar y sobre todo tener claro los procesos críticos de la compañía es la utilización de un BPM y a parte así vamos adelantando trabajo para SolvenciaII.

El paso 2 seria dotar a nuestros sistemas de lógica de negocio. Cuando decimos lógica de negocio entraría directamente relacionado con el BPM, porque dentro de este punto ya entraría el workflow de nuestros procesos, también utilizaríamos el motor de reglas de negocio y facilitaríamos a nuestros usuarios finales las suficientes herramientas de acción sobre el proceso.

Ejemplo: Con el paso 1, podemos tener integrado en un EAI nuestra BBDD y nuestra aplicación y a parte la BBDD de nueva adquisición y también su aplicación, entonces podemos seleccionar un procesos Piloto y desarrollamos un BPM por una capa superior del EAI, así nuestro BPM se nutre de información de todas nuestras BBDD como si fuera un Data global, una vez tenemos toda la información en nuestro proceso ya podemos ejecutar nuestro proceso, por ejemplo las liquidaciones de comisiones, que podría ser un buen ejemplo porque deberíamos ir a una BBDD a buscar todas las ventas y comisiones de un agente y luego deberíamos ir a la segunda BBDD e ir a buscar las ventas y las comisiones del mismo agente.

Hay que tener presente que en un papel todo se aguanta, lo que aquí se escribe puedes parecer sencillo, pero ya puedo asegurar que es un proyecto muy costoso tanto en tiempo como el precio.

En conclusión, dentro de este mundo de compras y uniones de compañías, puede ser una buena solución, primero para poder identificar y tener un modelo único de procesos y lo segundo es para llegar a tener una sinergia entre todos los sistemas de la compañía.

EAI: Herramienta para poder integrar “N” aplicaciones/sistemas

BPM: Gestión de los procesos de negocio.

Workflow: Flujo de trabajo

BBDD: Base de datos

Posible modelo para la gestión de múltiples Aplicaciones EAI hacia BPM (Parte I)

Este año tengo la posibilidad de estar en el congreso nacional de BPM (organizado por club-BPM). Hoy he asistido a una ponencia que la he encontrado muy interesante y lo mejor de todo aplicable a la vida real, es mas, la experiencia que me han explicado era un caso real y añadido a todo el estudio que llevo realizado durante varios meses para conocimiento personal llego a la siguiente conclusión.

Valorando el movimiento de compras y adquisiciones que están apareciendo entre compañías de seguros hay que reconocer que los departamentos de TI de las compañías tienen que estar temblando y sobre todo no saber por donde empezar.

Primero de todo podemos identificar nuestra situación inicial, que nos encontramos :

• Varias soluciones de gestión (ERP)
• Varias soluciones de BBDD
• Varios CRM
• Varias aplicaciones de gestión contable
• Procesos de trabajo diferentes entre usuarios.

Pasos que deberíamos realizar para ir pasando esta red de soluciones punto a punto a un BUS de servicios o llamado también un EAI.

1. Integrar los ERP al bus de servicios
2. Integrar los CRM al bus de servicios
3. Integrar resto de soluciones
4. Traspasar el poder de decisión al bus de servicios que pasaría a ser un BPM(identificar y gestionar los procesos) → se realiza un cambio contextual y pasaría a ser un EAI con una inclinación a ser un BPM

Hoy ligeramente me gustaría comentar el punto 1 (Integrar los ERP) y en los siguiente post iremos comentando los demás puntos.

Todos sabemos que un proyecto de esta envergadura es complicado de vender a dirección, lo bueno de las fusiones de compañías es que pasa de ser una mejora a una necesidad, cuando digo mejora es porque cuando llegas a tener N aplicaciones integradas con un bus de servicios y si al final llegas a la transición de utilizar un EAI y un BPM, puedo asegurarte que cualquier modificación operacional que tenga impacto en la estrategia de la compañía tiene un impacto muy leve y se puede realizar en un tiempo muy optimizado y rápido.

Volviendo al punto 1 debe ser el primer paso, porque en el momento que integras las aplicaciones al bus de servicios, aquí tiene un resultado tangible y ya obtienes argumentos para continuar tu proyecto hacia delante.

Un consejo, siempre realizar un pequeño piloto para probar la herramienta y a la vez tenéis que ser autodidactas y aprender muy bien el funcionamiento de vuestra herramienta de integración.

Para finalizar, puedo deciros que hoy en día tanto los EAI como los BPM son herramientas que van cogiendo peso y pueden ayudarnos mucho en nuestras compañías y sobretodo ayudarnos a optimizar y agilizar cambios críticos para nuestra estrategia.

Utopia en las TIC, unificación de leguajes de programación y herramientas

La semana pasada leía un articulo/estadísticas de ICEA (*)“Nivel de dispersión en el uso de tecnologías de las aseguradoras”, donde se plasmaba que las compañías aseguradoras están utilizando una media 3,1 lenguajes para sus diferentes desarrollos. También en el caso de las bases de datos, la media es de 2,8 por entidad y estas diferencias conllevan una falta de homogeneidad y de estandarización, dificultan la obtención de mejoras en el rendimiento y la productividad.

SI! Tienen razón, pero es ASI! En la actualidad, es imposible tener todo un departamento TIC de una compañía de seguros unificado a un lenguaje y con único tipo de BBDD, bueno en la actualidad y SIEMPRE, porque es el ciclo de vida de “LO ACTUAL”, con esto quiero decir que siempre hay una lenguaje de programación que es el mas moderno y que todo el mundo quiere, y siempre hay una BBDD que destaca en algún concepto, y sobre todo, muchas veces los responsable de TIC cuando les viene su jefe y les solicita una solución, lo primero que se hace es mirar como esta el mercado, y el mercado MANDA! Y puede ser que en ese momento lo mejor en .NET, como en otro momento PHP o JAVA o….

Cuando tienes una parte de tu negocio con un leguaje (aunque este desactualizado) que es optimo y rápido y sobre todo seguro, para que lo vas a cambiar! No lo toques! A los hechos me remito, a ver quien toca el COBOL en la parte de banca o un buen sistema con AS400. OJO! Estamos hablando de sistemas que ya llevan muchos años en producción, si hablamos de instalar una nueva aplicación, la perspectiva cambia y CLARO que tenemos que escoger leguajes actuales y óptimos para el usuario.

Volviendo la diversidad de leguajes, lo más claro es un ejemplo, imaginaros:

En una empresa que tiene su CRM para control comercial en un leguaje como php y una Base de datos MySQL, luego tiene toda la parte de contabilidad con SAP y su ERP lo tiene desarrollado una parte con Developer y Oracle y otra parte con JAVA, sin olvidar que tiene una aplicación de consultas realizada con PHP y si queréis rizar un poco mas el rizo, adquieren varias empresas que una tiene su ERP con AS400 y SqlServer y otra adquisición tiene la aplicación de gestión con Visual Basic… ¿ como lo puedes unificar? Muy fácil, no se puede! Lo que si que se puede hacer es INTEGRAR e intentar tener una salida de información unificada, para esto se habla de EAI.

Igualmente el (*)EAI no es un salvador, te facilitara los conectores para cada base de datos que tengas, pero una vez conectados tu tienes que desarrollarte las interfases de uso, bueno no me voy a meter en este tema porque merece tener su propio post.

En conclusión, las compañías de seguros tiene N leguajes y N Bases de datos, porque el mercado ¡es así! Y un solución optima y actual a día de hoy es muy probable que el próximo año ya no lo sea y aparezca un nuevo leguaje o se ponga de moda uno que ya estaba obsoleto… así es el mercado. Y añadir que muchas veces se mantiene los leguajes obsoletos porque las migraciones son muy complicadas y a veces demasiado costosas con un riesgo muy elevado.

(*)http://www.icea.es/

(*)EAI:Enterprise application integration