sábado, 24 de agosto de 2013

BPMaaS - Realidad o Falacia

Resumen

Este artículo tiene por objetivo brindar un acercamiento al concepto de BPMaaS (Business Process Management as a Service) mostrando los beneficios de negocio y el gran desafío de arquitectura de software en la nube al que se puede enfrentar un proyecto con este enfoque. Además, mostraré cómo resolver algunos puntos técnicos a través de algunas tácticas y estrategias de implementación de software.


Antecedentes

Comenzaremos con algunas definiciones de procesos:

"Un proceso es una concatenación lógica de actividades que cumplen un determinado fin, a través del tiempo y lugar, impulsadas por eventos" Bernhard Hitpass.

"Un proceso de negocio es un conjunto de actividades que toman uno o más inputs y crean outputs que son de valor para un cliente"

Un aspecto clave en el modelo de procesos es entender que un proceso es diferente a un proceso de negocio. Un proceso se enfoca en algo específico (un modelo de producción, logístico, de marketing, de servicio al cliente, etc), mientras que un proceso de negocio tiene por objetivo la interacción con un cliente, en donde este produce un (os) estimulo y espera una respuesta en pasos intermedios y al final una entrega de valor.


Ejemplos de procesos de negocio: solicitudes de créditos, préstamos, devoluciones, compra de pasajes, procesos de reclamos, elaboración de ofertas, etc.

Los procesos de negocio se relacionan fuertemente con BPM con el fin de buscar la mejora de la entrega de valor hacia los clientes de una o varias Compañías con un modelo único que permita diferenciar a una Organización de las demás brindando ventaja competitiva. Pero, ¿BPM son las herramientas de automatización?, ¿una moda?, ¿una desviación a la reingeniería de procesos?. 

Para dar respuesta a las preguntas anteriores, voy a comenzar hablando de los antecedentes de los modelos precursores del BPM, iniciando con la reingeniería de procesos.

La reingeniería busca atacar las estructuras jerárquicas funcionales y la alineación a los objetivos de negocio buscando resultados muy buenos a corto plazo apoyándose en la incorporación de tecnologías de la información. La reingeniería es el primer enfoque  end-to-end para la introducción de la gestión por procesos de negocios transversales a las Organizaciones funcionales centradas en las necesidades del cliente y no en las de producción, pero esto no funcionó muy bien pues se ocupó principalmente en proyectos de racionalización de recursos para la disminución de personal, perdiendo el foco de agregación de valor para el cliente.

De igual forma en los 80's aparecieron modelos como el Six Sigma con una guía de calidad total, el mejoramiento continuo a través de Kaizen "hoy mejor que ayer, mañana mejor que hoy", el modelo de producción de LEAN orientado a la optimización del flujo de equipos y elementos que trabajan con un mismo fin buscando eliminar desperdicios o pasos que no agregan valor.

En los 90's los ERP's se vendieron como la salvación para resolver muchos de los problemas de las Organizaciones con el fin de mejorar la eficiencia administrativa y la eficacia en los procesos de negocio. Sin embargo, estas soluciones no generaron lo que se esperaba, ni brindaron valor en cuanto al cliente sino mejoras administrativas y orden en cuanto a datos, pero no en lo relacionado a procesos de negocio pues no brindan una mejora que pueda diferenciar a una Organización de otras.

BPM es una evolución de la ingeniería de procesos (Frederick Taylor 1911), la reingeniería, Six Sigma, a través de la gestión por procesos como disciplina buscando alineación con la estrategia de una Organización.

Otro aspecto importante es entender que no es lo mismo gestión de o por procesos. Cuando nos referimos a gestión de procesos, se entiende  en gestionar un proceso específico para  revisar su operación (análisis, reducción de tiempos, y medición. entre otros), mientras que la gestión por procesos incluye la planificación y el alineamiento a la estrategia de una Organización porque a través de ellos esta se puede habilitar con la integración de tecnología.

La reingeniería es un precursor del BPM pues incluye lo anterior agregándole el cumplimiento de los objetivos de negocio y la alineación con tecnología informática. Jestos y Nelis [JestonNelis08] suministran la siguiente definición: 

BPM es: mas que solo software, mas que solo la mejora o la reingeniería de los procesos, no es solo una moda, es parte integral del management, más que solo levantamiento y modelado de procesos, también es la implementación y ejecución de procesos los cuales requieren ser analizados y mejorados.

BPM tiene los siguientes factores críticos: el logro de la estrategia Organizacional, la organización está alineada con los procesos end-to-end y los objetivos están alineados con la estrategia Organizacional.

Para revisar en detalle más conceptos de BPM se puede ingresar a la Asociación Internacional de Profesionales de PBM (ABPMP). Esta organización incluye el BPM Body of Knowledge que agrupa un modelo formal de conocimiento.


Por último, es fundamental tener claro que automatización no es igual a BPM. Cuando en una Organización se realiza una automatización de un proceso, esta se puede elaborar con plataformas convencionales de desarrollo de software como JEE, .NET o incluso con COBOL, buscando automatizar tareas o actividades que ejecutan humanos. 

Cuando implementamos procesos siguiendo un modelo BPM nos enfrentamos a plataformas que integran un conjunto de herramientas que permiten modelar el proceso en notaciones estandarizadas como el BPMN con el fin de ejecutarlas en motores de ejecución, en sistemas de reglas de negocio BRMS, de monitoreo de actividades de negocio BAM y en general en sistemas creados para la gestión de procesos de negocio BPMS de vendedores de plataforma como IBM, Oracle, Bizagi, Pegasystems, Intalio, Bonitasoft, Appian, entre otros.

Y el BPMaaS ¿cómo juega?

El BPMaaS como servicio permite diseñar procesos de negocio únicos con fines específicos para vincular los sistemas de entrega de valor multi-empresa que en el pasado no era factible que trabajaran juntos a través de un modelo en la nube.
 
 
En fundamental antes de introducirnos más en BPMaaS conocer los niveles de capas en el modelo de la nube para propuesto por el NIST y que se complementa en "Enterprise Cloud Computing", entendiendo que la computación en la nube no es una nueva tecnología, no es una arquitectura y tampoco una nueva metodología. Si usaste Gmail o Google, ya haz tenido interacción con servicios prestados en la nube.

Los niveles propuestos son: IaaS (infraestructura como servicio), PaaS (Plataforma como Servicio), SaaS (Software como servicio), BPMaaS (Gestión de procesos de negocio como servicio) y MCaaS (control y gestión como servicio).


  • IaaS (infraestructura como servicio): incluye la gestión de red (pe, balanceadores de carga, firewalls, etc), recursos de cómputo y de almacenamiento. Un ejemplo de esta capa son los centros de datos en la nube para operar una plataforma que permiten correr diferentes aplicaciones sobre distintos sistemas operacionales.
  • PaaS (plataforma como servicio): en este nivel se incluye los ambientes de desarrollo y pruebas usado para el despliegue de servicios en la nube. Un ejemplo de esta capa son las herramientas de BPMS proporcionadas por fabricantes para el modelamiento, medición e implementación de procesos de negocio automatizados.
  • SaaS (software como servicio): servicios de aplicaciones de software usados por individuos y organizaciones. En este nivel entran aplicaciones o productos de paquete que se ofrecen en la nube bajo modalidades de cobro por licencias o por transacción (por uso) como un ERP, un SCM o un CRM.
  • BPMaaS (BPM como servicio): coreografía y orquestación de servicios para crear y manejar procesos de negocio únicos. Son procesos de negocio que vinculan a una o varias Organizaciones en una entrega de valor al Cliente final.
  • MCaaS (control y gestión como servicio): servicios de gestión se seguridad, gestión de SLAs, políticas distribuidas, autorizaciones basadas en roles, y otros servicios básicos necesarios para todas las capas.
El BPMaaS representa el nivel más alto de los servicios en la nube porque el MCaaS es un servicio transversal a las demás capas. El BPMaaS a diferencia del BPM tradicional automatizado vincula a las Organizaciones con fines específicos en modelos de negocio que buscan ofrecer una mejor entrega de valor a un Cliente final.

Es importante entender la diferencia entre SaaS y BPMaaS. El SaaS ofrece a las Organizaciones productos o software de paquete (configurable) en fronteras más amplias con un servicio en la línea; mientras que el BPMaaS crea procesos de negocio únicos multi compañía para la entrega de valor al Cliente, incluso usando SaaS en un modelo colaborativo end-to-end. 

Los procesos de negocio sobre BPMaaS ofrecen ventaja competitiva al ofrecer un cableado entre compañías. Con éste modelo las compañías comparten un sistema BPM en la nube integrado a otras Compañías cubriendo el ciclo completo de concepción, diseño, implementación y optimización.

El BPMaaS se diferencia del SOE (service oriented enterprise) porque en el enfoque de procesos se centra en la orquestación entre empresas para la generación de entrega de valor  y no entre silos de departamento o procesos macros de una sola Organización

El BPMaaS debe ser implementado como un BPO (Business Process Outsourcing) con un modelo funcional centrado en una industria en particular. La operación del proceso de negocio se vuelve externa a las Organizaciones y se utilizara principalmente para procesos de negocio que end-to-end que combinen las capacidades de varias Compañías para ofrecerle valor al Cliente.

El BPMaaS puede ser implementado como un BOP (Business Operation Platform) que incluye un BPMS en su interior. Este modelo se parece al PaaS, pero incluye elementos del ciclo de vida de gestión de procesos como el modelamiento BPMN, la formulación de reglas de negocio y el monitoreo de actividades de negocio BAM.

Cuando se defina la implementación de un proceso con el enfoque BPMaaS se debe contemplar el análisis de escenarios empresariales en dónde se va a aplicar: 
  • End User to Cloud: aplicaciones corriendo en la nube y accedidas por usuarios finales.
  • Enterprise to Cloud to End User: aplicaciones corriendo en una nube pública y accedida por empleados y clientes.
  • Enterprise to Cloud:  aplicaciones en la nube integradas con capacidades de TI interna.
  • Enterprise to Cloud to Enterprise: aplicaciones en la nube corriendo en una nube pública y operada con socios de aplicaciones (por ejemplo socios de cadena de abastecimiento).
  • Private Cloud: una nube colocada (hosted) por una Organización dentro del firewall de la DMZ.
  • Hybrid Cloud: múltiples nubes trabajando juntas, frecuentemente coordinadas por un broker de nubes que federa datos, aplicaciones, identidad de usuarios, seguridad, etc.

Entre los beneficios que ofrece BPMaaS se encuentra el de flexibilidad al poder realizar despliegues continuos y cambios en tiempo de ejecución brindando mejor oportunidad al negocio de las Compañías relacionadas y la reducción de capital en las inversiones en TI permitiéndoles operar en  un enfoque bajo demanda.


Otro aspecto importante es la reducción de desperdicios por la interacción entre Compañías ahorrando tiempo y recursos para la entrega de valor al Cliente. También se reduce el riesgo de innovación que las compañías asumen cuando invierten en nuevas iniciativas para promover nuevas líneas de negocio.

Las compañías operan con una plataforma de procesos bajo demanda que puede ser cambiada incluso en tiempo real o en vuelo. Se pueden implementar nuevas ideas más rápido al brindar una plataforma en la nube con el fin de generar nuevos negocio (productos o servicios).

Otro aspecto a revisar el la forma como se cobra bajo este modelo, pues se habla siempre del pago por uso (pay by use), pero también se pueden tener modalidades de venta de licencias o incluso de arrendamiento en un modelo bajo demanda (si suben las transacciones o se incrementa el recurso de cómputo, el almacenamiento, etc. subirá el valor).




Qué retos tecnológicos implica implementar BPMaaS

El BPMaaS está en un nivel de madurez básico y por tal motivo es necesario revisar un conjunto de atributos de calidad que ayuden a mitigar el riesgo de enfrentar este tipo de proyectos. El énfasis del análisis se centra en los requisitos no funcionales NFR.

El primer elemento a revisar es la autonomía, pues la dependencia con sistemas o servicios externos es crítica; si algún sistema participante de alguna Compañía falla implicará que el proceso de negocio multi-compañía falle. Este es quizás el atributo de calidad más importante para un modelo BPMaaS porque traspasa las barreras de la Organizaciones involucrando acceso a recursos de cómputo y de infraestructura. ¿Cómo garantizar la autonomía en un proceso de negocio multi-Compañía?


Otro atributo importante y que se relaciona con la autonomía es el acoplamiento ¿Cómo diseñar un proceso con un nivel de acoplamiento bajo que haga más estable una solución?. Para esto es fundamental revisar los principios diseño y un enfoque hacia la programación por contrato para depender de abstracciones y no de componentes detallados que puedan ocasionar reacciones en cadena ante un cambio generando un grado alto de inestabilidad.


Otro reto es garantizar que los servicios o aplicaciones involucradas con el proceso de negocio cumplan con acuerdos de servicio SLA; los SLAs no son propiamente las interrupciones a hilos de ejecución con un timer específico, sino la estrategia de acuerdos entre los componentes e interfaces involucrados en dónde se estipule los tiempos máximos de espera antes de generar excepciones del tipo TimeOutException. En un proceso de negocio end-to-end es fundamental definir los acuerdos para manejar adecuadamente el uso del recurso de cómputo concurrente y los acuerdos que se fijen en seguridad.




tn = tn+1 + Δn
La flexibilidad es otro aspecto fundamental y está relacionado con la mejora continua de un proceso de negocio, ocasionando cambios frecuentes en el transcurso  del tiempo. Ésto, es un aspecto importante que una solución de BPMaaS debe contemplar para evolucionar de acuerdo al ritmo del negocio y de la tecnología.


La idempotencia es un atributo clave de un proceso en la nube para el manejo transaccional, pues los modelos clásicos de un two-phase-commit (transacciones coordinadas) son en realidad utópicos por su complejidad ante la diversidad de posibles participantes. El modelo de compensaciones es demasiado costoso para el tratamiento de flujos alternos anómalos en un proceso de negocio en la nube y por tal motivo es necesario fijar acuerdos para que los sistemas o servicios destino soporten el concepto de idempotencia.

El soporte de integración continua y de pruebas automatizadas es clave para la correcta gestión y control de software. El reto consiste en soportar un ambiente de desarrollo en la nube que soporte pruebas automáticas que evite al máximo la invocación o el contacto con sistemas externos para evitar el uso de mocks o dummies engañosos aunque sigan un enfoque de programación por contrato.

El acceso desde dispositivos móviles a procesos en la nube es un gran desafío, pues es claro que se debe evitar al máximo los accesos en línea (online) para atacar los riesgos que tiene una computación totalmente en la nube. Aunque se usen protocolos de comunicación o estilos arquitecturales como REST o alguna otra mensajería liviana es necesario tomar decisiones de arquitectura adecuadas que garanticen la prestación del servicio.

De los puntos anteriores se sugiere el atributo de disponibilidad para soportar niveles altos cercanos al 100% de prestación del servicio. Es un rato máximo porque supone niveles de alta disponibilidad y de recuperación de fallos durante los 365 días del año.

El desempeño es vital, porque la carga a soportar debe ser aislada por proceso de negocio con el fin de ecualizar los los atributos de calidad porque la exigencia para throughput, latencia y datos es de un nivel alto. Por esto es claro que las estrategias y tácticas de arquitectura a aplicar deben ser muy audaces para luego adaptarse a la flexibilidad que el negocio requiere.

La escalabilidad es otro elementos que aparece, con el fin de hacer cumplir la promesa de uso bajo demanda a través del escalamiento horizontal, permitiendo que un proceso de negocio pueda incrementar la capacidad de cómputo de acuerdo a la exigencia del negocio.

La elasticidad de la plataforma para soportar cambios de configuración de escalamiento en caliente de forma automática es clave. Las tecnologías y herramientas que soporten un proceso de negocio en la nube deben incluir dichas características.

La seguridad de la información es un aspecto fundamental porque muchas Organizaciones tienes políticas o siguen regulaciones que impiden el manejo distribuido de datos o el compartimiento de datos de Clientes, así como los niveles de seguridad de confidencialidad, integridad, no repudio, autenticación, autorización e identidad. Es claro que se deben seguir estándares de industria en seguridad para poder resolver este punto y la definición de aislamiento y autonomía teniendo en cuenta que de acuerdo a la ubicación geográfica o a las regulaciones de cada país esto varía.

¿Cómo monitorizar los sistemas involucrados en un proceso en la nube? es un gran problema a resolver, porque implementar la capa de MCaaS no es simple. Esto refuerza el concepto de autonomía de toda la plataforma involucrada en la solución.

La resolución del problema de integración con los distintos sistemas de información de cada compañía que participa en un proceso de negocio en la nube BPMaaS es un gran desafió. Cómo integrarse sin acoplarse a los sistemas destino estableciendo reglas de juego claras que permitan garantizar la construcción de componentes de integración estables que desacoplen a los participantes y oculten la dependencia con los backends, son un reto a resolver bajo este modelo.

La colocación de la plataforma en la nube debe analizarse  en los distintos modelos: nube privada, nube comunitaria, nube pública y nube híbrida. Para cada proceso de negocio habilitado en el enfoque BPMaaS se debe determinar cómo será el despliegue y la colocación teniendo en cuenta los requisitos de negocio y las regulaciones vigentes.

Cómo solucionarlo con algunas decisiones de arquitectura respecto a BPMaaS


Una buena manera de solucionar el problema planteado de autonomía es la implementación de una táctica de datos maestros (MDM) y datos operacionales (ODS) con el fin de desacoplar los datos del proceso de negocio y los sistemas backend de las Organizaciones. 


El uso de un modelo de datos maestros permite al proceso de negocio realizar accesos en un modelo de mensajería y de datos canónico desacoplando el acceso a clasificaciones (parámetros generales) y evitando el consumo en línea (online) de los sistemas destino backends de las Compañías que intervienen en el proceso de negocio. La sincronización de datos desde los sistemas de información se puede realizar a través de ETLs con un procesamiento en batch y a través de eventos (event sourcing) o con técnicas de polling periódicas utilizando patrones de integración.


Al implementar el modelo de datos maestros se pueden desarrollar ontologías que ayuden a definir abstracciones y modelos canónicos de información que permitan el alojamiento de datos en entidades que soporten distintos negocios y que ayuden a disminuir el esfuerzo de mapeo de dominios de datos entre los sistema de información backends. 


El modelo operacional permite mantener datos en un periodo de tiempo definido con el fin de integrar, limpiar, evitar redundancia de los datos expuestos hacia el el proceso de negocio. Además, permite manejar un volumen de datos controlado en un periodo de tiempo para mantener niveles de desempeño aceptables en acceso a datos separando los modelos históricos.

Al utilizar un modelo de datos maestros se disminuye considerablemente las integraciones en línea con los sistemas backend limitando solamente a lo necesario y que se requiere por definiciones de negocio.

Una buena táctica para soportar la flexibilidad es el uso de reglas de negocio para desacoplar a los procesos de esta lógica. Para esto, se puede hacer uso de un motor de reglas BRMS que permita estructurar árboles y tablas de decisión y un lenguaje de definición de reglas, así como la generación de eventos de negocio y modelos de aprendizaje.

Al usar reglas de negocio se ofrecerá a los procesos de negocio contratos a través de esquemas canónicos desacoplándolos y brindando un grado de flexibilidad alto, soportando cambios en procesos de orquestaciones diferentes a los procesos en notación de negocio BPMN.


Defina un ESB local para los procesos de negocio que soporten el modelo BPMaaS para manejar una conectividad orientada a aspectos que soporte la mayoría de ítems no funcionales: logging, auditoría, manejo de excepciones, control de SLAs, gateways de seguridad y enrutamiento, reenvío de mensajes, soporte de múltiples protocolos de comunicación para un mismo servicio y el soporte de virtualización, transparencia de localización y versionamiento de servicios.


Recuerde que el ESB es una definición de arquitectura y no un producto que ofrece un vendedor, aunque los vendedores de herramientas lo hagan ver así, pues es una estrategia comercial. El ESB es la definición de un conjunto de componentes que habiliten una capa de integración que puede ser instanciada tantas veces se requiera de acuerdo a las cargas transaccionales o a los modelos de escalamiento planteados y probablemente controlados a través de buses federados, pues no hay que olvidar que por definición es stateless. Nunca cree orquestaciones en esta capa y guíe la construcción de componentes de servicio hacia el máximo desempeño.


Con el ESB se desacopla los servicios en línea que se requieran a través del manejo de contratos que siguen una aplicación de un patrón de esquema canónico. De esta manera los procesos de negocio conocerán el contrato y no la localización y mucho menos el protocolo o el sistema backend proveedor del servicio.


El cumplimiento y la definición de SLAs se puede alcanzar con la implementación de la capa de integración ESB al configurarse meta-data de los servicios en repositorio para tal fin, permitiendo en ejecución (runtime) controlar los tiempos máximos de espera para el control de los recursos de cómputo configurados en la infraestructura en la nube.


Para el manejo de aplicaciones móviles (canales) es recomendable no acceder en línea a los procesos de negocio y si a través de  paquetes asincrónicos con una probable implementación del patrón de integración splitter y con notificaciones de eventos desde el proceso a través de la implementación de un patrón publicador/suscriptor.

Aunque el modelo tenga un foco en la nube, no debemos olvidar los principios clásicos de diseño básicos del modelo orientado a objetos guiados por el acoplamiento (eferente / aferente) y la cohesión. Es recomendable utilizar el principio de abstracciones estables, el de cierre común, el de reuso común, entre otros.


Para mejorar la flexibilidad y la entrega de valor constante al Cliente, se sugiere la utilización de modelos ágiles que permitan acortar ciclos y que promuevan la reducción de desperdicios enfocándose en la producción de software que permita alcanzar la visión del proceso de negocio establecido en una fase de análisis de procesos de negocio BPA. Este será otro bloq que próximamente escribiré "BPM Ágil".

Es claro que para iniciativas de BPMaaS la definición de arquitecturas de software empresarial es fundamental y que las decisiones de arquitectura para elaborar rationales teniendo en cuenta en conjunto de alternativas, así como la gestión de atributos de calidad deben manejarse con el máximo profesionalismo, debido a que cualquier decisión o diseño que se formalice debe probarse con pruebas de concepto PoC y con pruebas de telemetría.

En un próximo blog tocaré el tema de Social BPM y de cómo esta alternativa entra como un habilitador de nuevas funcionalidades y modelos para la gestión de procesos de negocio. ¿Qué tal el envío de un formulario de solicitud de crédito desde Facebook? ¿Un manejo de verificación de referencias a través de redes sociales? .......

Gabriel Morris S.
@GabrielMorrisS

No hay comentarios.:

Publicar un comentario