Hola a todos!
Escribo esta entrada para anunciarles que publiqué una ponencia en La Convención y Feria Internacional Informática, en su XIII edición se realizará del 9 al 13 de febrero de 2009, en el Palacio de Convenciones de La Habana y en el recinto ferial Pabexpo, con el lema "Nuevas Tecnologías: desarrollo y soberanía". Pero ya está activo el Salón Virtual, por donde los invito a pasarse, leer y dejar sus apreciaciones en algún comentario dentro de la página del evento. La URL: http://www.informaticahabana.com/?q=es/trabajo&trid=349
jueves, 5 de febrero de 2009
miércoles, 18 de junio de 2008
BRE, BRMS
Motor de Reglas del Negocio, Sistemas de Administración de Reglas de Negocios
Una regla del negocio en el contexto de una solución para la administración de procesos de negocios (BPM, por sus siglas en inglés) está representada por aquellas sentencias que definan restricciones y condiciones en un proceso de negocio. Las reglas del negocio se originan desde cualquier proceso dentro de la organización. Por ejemplo: ¿Qué reglas aplicar cuando se aprueba una transacción? ¿Qué reglas aplicar cuando no se conoce el nivel de contrato de un servicio? Es bastante común que las reglas de negocios cambien más a menudo que la definición de los procesos de negocios. Por ejemplo, la regla de negocio para cuando se apruebe una transacción con un monto determinado en un momento, es pedir la confirmación del gerente si dicho monto sobrepasa un valor determinado, en otro momento puede ser notificar al gerente el monto de la transacción si pasa el valor determinado; la definición del proceso de negocio no cambió (Aprobar Transacción), sin embargo la regla de negocio asociada si.
Dentro de los requerimientos de soluciones BPM se encuentra tener la capacidad de integrarse con un motor de reglas de negocio (BRE, por sus siglas en inglés). Un BRE permite definir reglas de negocio o condiciones basadas en parámetros asociados al proceso de negocio y en función de los resultados de la ejecución de una condición un proceso asociado evolucionará de forma diferente. Como las reglas de negocio pueden variar en el tiempo se anuncia como buena práctica una integración poco acoplada entre el motor de procesos de una aplicación BPM y un BRE, donde se permita cambiar las reglas de negocio de forma independiente a los procesos y el BRE pueda desencadenar acciones en los procesos de negocio.
Un BRE no debe permitir ambigüedad en las reglas de negocio, debe poder ser usado de manera amigable y no requerir una alta curva de aprendizaje, además debe usar algoritmos que minimicen el tiempo de respuestas.
Para algunos negocios donde se requiere agilidad en la toma de decisiones y a la vez rapidez de adaptación en sus sistemas por los cambios constantes del medio, se han desarrollado Sistemas de Gestión de Reglas de Negocio (BRMS, por sus siglas en inglés). Los BRMS facilitan mayoritariamente la comunicación entre los especialistas de la informática y los administradores del negocio, brindando a estos últimos el control de la lógica e incluso del código de definición de la aplicación.
Estas plataformas brindan las siguientes ventajas:
• Los analistas de negocios toman control directo de las reglas que gobiernan como se maneja y comporta la empresa.
• Se pueden hacer alteraciones de las reglas de negocio directamente sin esperar por soporte del área informática.
• Bajos costos de mantenimiento de los sistemas.
• Mayor seguridad que las reglas de negocio están implementadas como la empresa lo desea.
• Conexión directa entre las estrategias de TI y las del Negocio.
Las características que no deben faltar en estos sistemas son:
• Agregar, borrar o aumentar cualquier regla de negocio.
• Capturar y ejecutar las reglas de negocio en tiempo real.
• Transparencia a los usuarios.
• Integración con los negocios existentes.
• Reducción de los costos.
Los BRMS se pueden ver como un sistema de n-capas que contiene una combinación de Servidor Web, Servidor de Aplicaciones y Base de Datos. El BRMS ocupa una cuarta posición en las capas, ver figura 1.
Figura 1. Independencia de las capas de una aplicación. Capas que deben existir y relacionarse para independizar la implementación de las reglas de negocio.
Una regla del negocio en el contexto de una solución para la administración de procesos de negocios (BPM, por sus siglas en inglés) está representada por aquellas sentencias que definan restricciones y condiciones en un proceso de negocio. Las reglas del negocio se originan desde cualquier proceso dentro de la organización. Por ejemplo: ¿Qué reglas aplicar cuando se aprueba una transacción? ¿Qué reglas aplicar cuando no se conoce el nivel de contrato de un servicio? Es bastante común que las reglas de negocios cambien más a menudo que la definición de los procesos de negocios. Por ejemplo, la regla de negocio para cuando se apruebe una transacción con un monto determinado en un momento, es pedir la confirmación del gerente si dicho monto sobrepasa un valor determinado, en otro momento puede ser notificar al gerente el monto de la transacción si pasa el valor determinado; la definición del proceso de negocio no cambió (Aprobar Transacción), sin embargo la regla de negocio asociada si.
Dentro de los requerimientos de soluciones BPM se encuentra tener la capacidad de integrarse con un motor de reglas de negocio (BRE, por sus siglas en inglés). Un BRE permite definir reglas de negocio o condiciones basadas en parámetros asociados al proceso de negocio y en función de los resultados de la ejecución de una condición un proceso asociado evolucionará de forma diferente. Como las reglas de negocio pueden variar en el tiempo se anuncia como buena práctica una integración poco acoplada entre el motor de procesos de una aplicación BPM y un BRE, donde se permita cambiar las reglas de negocio de forma independiente a los procesos y el BRE pueda desencadenar acciones en los procesos de negocio.
Un BRE no debe permitir ambigüedad en las reglas de negocio, debe poder ser usado de manera amigable y no requerir una alta curva de aprendizaje, además debe usar algoritmos que minimicen el tiempo de respuestas.
Para algunos negocios donde se requiere agilidad en la toma de decisiones y a la vez rapidez de adaptación en sus sistemas por los cambios constantes del medio, se han desarrollado Sistemas de Gestión de Reglas de Negocio (BRMS, por sus siglas en inglés). Los BRMS facilitan mayoritariamente la comunicación entre los especialistas de la informática y los administradores del negocio, brindando a estos últimos el control de la lógica e incluso del código de definición de la aplicación.
Estas plataformas brindan las siguientes ventajas:
• Los analistas de negocios toman control directo de las reglas que gobiernan como se maneja y comporta la empresa.
• Se pueden hacer alteraciones de las reglas de negocio directamente sin esperar por soporte del área informática.
• Bajos costos de mantenimiento de los sistemas.
• Mayor seguridad que las reglas de negocio están implementadas como la empresa lo desea.
• Conexión directa entre las estrategias de TI y las del Negocio.
Las características que no deben faltar en estos sistemas son:
• Agregar, borrar o aumentar cualquier regla de negocio.
• Capturar y ejecutar las reglas de negocio en tiempo real.
• Transparencia a los usuarios.
• Integración con los negocios existentes.
• Reducción de los costos.
Los BRMS se pueden ver como un sistema de n-capas que contiene una combinación de Servidor Web, Servidor de Aplicaciones y Base de Datos. El BRMS ocupa una cuarta posición en las capas, ver figura 1.
Figura 1. Independencia de las capas de una aplicación. Capas que deben existir y relacionarse para independizar la implementación de las reglas de negocio.
miércoles, 21 de mayo de 2008
BPM y SOA
En colaboración con el Ing. Fernando García Tosca.
BPM y SOA comparten una visión en la que el desarrollo de nuevos componentes empieza por modelar los procesos y actividades de negocio, y luego traducir cada uno de estos elementos en un componente tecnológico. Mientras SOA aplica esta visión a funciones de negocio atómicas, y por tanto está más relacionado con el desarrollo de aplicaciones y de sus interfaces, BPM aplica la visión de negocio a procesos en general complejos, que impliquen coordinar acciones en varios sistemas o incluso necesiten de acciones manuales. No es por tanto de extrañar que exista una relación muy estrecha entre la implantación de una arquitectura SOA y la adopción de una herramienta BPM.
En un entorno en el que todas las aplicaciones ofrezcan su funcionalidad a través de servicios reutilizables, la implementación de un proceso de negocio se reduce a la composición y orquestación de dichos servicios. En este sentido, una arquitectura SOA favorece la implantación de un BPM, ya que permite definir un proceso de negocio como la composición ordenada de actividades de negocio, cada una de las cuales es proporcionada por un servicio SOA. En la figura 1 se representa un posible escenario (muy simplificado) de gestión de una orden de un cliente para la provisión de un determinado servicio (un crédito financiero, un servicio de telecomunicaciones, un producto ofertado por un portal Web, etc.).
Figura 1: Proceso de negocio como composición de servicios.
Las herramientas gráficas propias de un BPM permiten componer procesos de negocios complejos a partir de servicios de negocio existentes, casi sin necesidad de codificación. Por otro lado, una herramienta BPM puede ser utilizada para la implementación de servicios SOA complejos. En la figura 2 se muestra como la actividad de “Autorizar crédito”, a su vez implica una lógica compleja con acceso a la información de varios sistemas.
Figura 2: Ejemplo de servicio de negocio complejo.
El servicio SOA que realiza esta actividad es, por tanto, susceptible de ser implementado por un BPM. Proporcionar un flujo complejo como un servicio de negocio permite reutilizar esta actividad en varios procesos de negocio de alto nivel. Por ejemplo, el flujo propuesto en la figura 6 podría ser aplicable también a un proceso de recuperación de impagos, a la hora de verificar la fiabilidad del cliente.
Arquitectura Orienta a Servicios (SOA)
SOA consiste en una forma de modularizar los sistemas y aplicaciones en componentes de negocio que pueden combinarse con interfaces bien definidas para responder a las necesidades de la empresa [1]. O sea, representa la forma de ordenar la interacción entre todas las aplicaciones que existen en una empresa utilizando Servicios Web, objetos COM u otros componentes que se comparten en la red. Pero no representa sólo el despliegue de nuevos productos y aplicaciones, sino que supone toda una metodología de diseño capaz de alinear la infraestructura TI con los procesos de negocio.
SOA se basa en el concepto ESB (Enterprise Service Bus), al que se conectan los servicios a través Web Services siendo posible reutilizar componentes y procesos ya desplegados. Utiliza un estilo arquitectónico para crear aplicaciones usando servicios de bajo acoplamiento que hace que una aplicación no tenga que comprender, ni siquiera conocer, los detalles técnicos de un servicio para poder invocarlo. Así, SOA promueve una plataforma independiente y no está ligada a una tecnología específica.
Actualmente, casi ningún programa se escribe desde cero. Por lo general, se inicia con un programa familiar que emula la funcionalidad que se está tratando de crear o que proporciona una uniformidad estructural. El verdadero poder de SOA reside en la capacidad para reutilizar los servicios. Por lo que en las empresas se reduce drásticamente el tiempo de desarrollo, se simplifica mucho el flujo de la lógica del programa y se elimina el esfuerzo de duplicación. Un servicio bien mantenido y probado puede reutilizarse en toda la empresa. Algunos estudios realizados recientemente indican que la capacidad para reutilizar los servicios es el beneficio de SOA más conocido [1]. Esto no debe sorprender, porque el concepto de capacidad de reutilización ha sido la meta perseguida por los grupos de TI desde que se codificaron las sentencias SI…ENTONCES (IF…THEN).
SOA permite que los procesos se suministren como servicios centralizados, lo que hace posible aceptar los cambios en el negocio de forma rápida e inmediata. Cuando SOA se lleva a cabo correctamente, permite que las organizaciones se adapten de forma rápida a los cambios de su entorno.
Existen numerosas formas de diseñar e implementar sistemas de TI de acuerdo a los principios de SOA. Sin embargo, la experiencia ha demostrado que existen siete prácticas que han supuesto el éxito para muchas organizaciones. Los expertos arquitectos de TIBCO Software Inc., líder reconocido en el área de SOA, han observado, documentado y aplicado las mejores prácticas en el transcurso de varios años [2]; las identificadas son:
· Demandar la rentabilidad de la inversión en cada servicio. Se plantea como estrategia ver la implementación de cada servicio como un proceso de negocio que genere rentabilidad de la inversión en la empresa (Return On Investment).
· Definir un comité de gestión de servicios. Este comité debe estar integrado por arquitectos expertos en procesos de negocios y por arquitectos de sistemas. Son los responsables de identificar los escenarios de uso de los servicios potenciales y evaluarlos para saber si su utilización es factible.
· Organizar adecuadamente los comités de gestión. La organización adecuada se refiere a la identificación y evaluación de los servicios de forma que se ajuste a las características de la empresa. Un enfoque factible resulta la centralización de los comités de gestión.
· Crear y especificar tareas y responsabilidades. Resulta de vital importancia definir a los participantes claves y aclarar sus funciones. Hay cinco funciones que no se deben pasar por alto: un gestor de proyectos, un arquitecto de procesos de negocio, un arquitecto de sistemas, un responsable de TI y un responsable de negocio.
· Ir más allá de la solicitud-respuesta. Se trata de crear el nivel de transporte de servicio de forma que pueda satisfacer las necesidades de los procesos de negocio del mundo real con una combinación de servicios dirigidos por solicitudes y eventos.
· Tener en cuenta los estándares emergentes. Si un estándar específico se ha desarrollado y es válido para lo que se está realizando, debe adoptarse.
· Desarrollar para expandir y soportar todas las tecnologías y plataformas. Se debe evitar crear una infraestructura SOA con aplicaciones que limiten sus opciones a plataformas, servidores de aplicación o lenguajes de programación específicos.
Como se explicó, las aplicaciones basadas en SOA utilizan Servicios Web que de conjunto con XML resuelven la mensajería, el acceso, las transacciones y otras actividades. Para ello se apoya en estándares como SOAP, Web Services Description Language (WSDL) y Business Process Execution Language (BPEL), que estandarizan la compartición de información, el modelo de integración de procesos y la cooperación entre aplicaciones.
La flexibilidad que brinda la arquitectura es tal que las empresas pueden conectar sus aplicaciones cuando realmente lo requieren, evitando la necesidad de mantener enlaces permanentes. De ahí, una ventaja añadida es, que reduce el coste de desplegar y personalizar las aplicaciones. La empresa Garther estima que por cada dólar gastado hoy en una licencia de software hay que gastar 5 o 6 para implantarlo, en el 2008, los avances en servicios Web dentro de la plataforma SOA disminuirá esos costos a 2 o 2,5 por cada uno destinado a licencias [1].
Businnes Process Magnament (BPM).
La Administración de Procesos de Negocios es el enfoque que analiza los procesos de una organización desde el principio hasta el final de los mismos, es la convergencia de una serie de tecnologías y metodologías ya existentes [3]. También puede verse como el entorno en el que de forma centralizada se gestionan los procesos y se comunican las necesidades de negocio de la empresa. La figura 3 muestra una idea gráfica del concepto.
Todas las empresas utilizan procesos, ellos hacen que los negocios avancen. Mientras más se entiendan y mejoren, mayores beneficios en el uso de los recursos se obtienen en la empresa. En los procesos se recoge la forma única de operar de cada organización y sin dudas representan el activo más valioso de una empresa.
BPM permite a las organizaciones tener la habilidad de modelar, administrar y optimizar dichos procesos; generando un entorno efectivo para la mejora continua, lo que redunda en ganancias significativas, agrega valor sobre la inversión realizada en las TIC y permite que el área de TI sea más sensible a la demanda de la organización, a un costo menor.
El enfoque BPM se caracteriza por concentrarse en el “cómo” se hacen las cosas y no se olvida de ninguna de las partes que componen a una organización ni de cómo se comunican entre sí. Reconoce que los procesos de una organización son complejos, dinámicos y que están entrelazados, tanto con el interior de la organización, como con el exterior. Además separa las aplicaciones, conexiones y datos, de los procesos que los sustentan, lo cual le permite superar limitaciones de los sistemas organizacionales jerárquicos.
En BPM los procesos de negocio representan una estructura para actuar.
Estructuras Jerárquicas vs. Estructuras de Procesos
La utilización óptima del entorno BPM se alcanza en organizaciones con estructuras organizativas de procesos [3]. Las jerárquicas manifiestan relaciones de poder y responsabilidades, mientras que las de procesos revelan cómo la organización genera valor.
Resulta difícil, en ocasiones imposible, mejorar una estructura jerárquica. Por el contrario, los procesos tienen costo, tiempos, calidades, satisfacción de los clientes, etc., como parámetros mensurables. Por lo que cuando se logran reducir los costos o incrementar la satisfacción del cliente se mejoran los procesos en sí.
Los sistemas de una organización reflejan la filosofía de sus operaciones, las prioridades que tiene y el equilibrio de poder; por lo que es altamente probable que las organizaciones jerárquicas tengan sistemas jerárquicos como reflejo de la estructura [3].
Luego, los sistemas desarrollados en estas empresas están optimizados para procesar la información de un área, lo que simplifica el análisis. Pero dichas aplicaciones no contemplan los requerimientos de los procesos de negocio en su conjunto y requieren de interfaces para la comunicación entre ellas.
Por otro lado, las aplicaciones en empresas con estructura de procesos están concentradas para apoyar la cadena de valor de la organización y no requieren de interfaces para su comunicación porque el proceso completo ya está capturado. Por supuesto, esta forma conlleva a análisis más complejos y cuando cambia el proceso la aplicación debe cambiar de forma inmediata. Este último aspecto no representa hoy una desventaja por la utilización de los Sistemas o Suites de BPM (BPMS), que encierran de manera coherente y ágil el ciclo de modelación, implementación y monitoreo de procesos de negocios en una empresa.
Valga aclarar que las estructuras de procesos no son planas de manera absoluta. Los procesos necesitan dueños definidos de forma clara; y a diferencia de la estructura jerárquica, el poder no radica en el lugar que ocupe una persona en la empresa sino en lo que hace y cómo contribuye a generar valor. Además, hay que mantener como una premisa que los principales motores del cambio en una organización son las personas y la tecnología, por lo que no se podrá lograr la innovación de procesos sin una combinación juiciosa de ambos factores.
Elementos funcionales mínimos de una plataforma BPM
Los BPMS deben permitir:
· La Definición de los procesos de negocio.
· La Gestión de los procesos.
· La integración de las personas, los procesos y las aplicaciones.
· Las interfaces entre usuarios y procesos.
Además de estos requerimientos mínimos, las aplicaciones BPMS existentes han incorporado la funcionalidad de la simulación como herramienta clave para ayudar a mejorar un proceso y decidir la ejecución del cambio a partir de un análisis costo-beneficio.
Ya se mencionó que todas las operaciones de una empresa implican procesos y que ellos son los que mantienen a los negocios funcionando. Pero hay múltiples procesos que ocurren fuera de este ámbito: las comunicaciones internas, el conocimiento de las personas, etc. Por lo que BPM no debe utilizarse solo para resolver problemas mediante la tecnología sino que debe convertirse en un cambio cultural orientado a compartir la información; lo que hace avanzar a los negocios basados en la compartición de la información colectiva. De ahí, que resulte crítico en este entorno la habilidad de capturar, almacenar y localizar información.
Esta idea responde a las últimas tendencias organizativas en las empresas, donde los negocios se están convirtiendo, cada vez más, en horizontales basados en roles (o responsabilidades) y las reglas para las estructuraciones se rigen por cómo las personas interactúan. Las tendencias en el monitoreo de los procesos muestran que clientes, socios, e inclusive interesados internos de la empresa demandan acceso instantáneo a la información sobre el estado de los procesos de una empresa [3].
Los planteamientos anteriores conllevan a resumir que los BPMS deben ser soluciones completamente integradas.
El papel de las TIC en un entorno BPM
Muchas empresas que han mejorado con la incorporación de la tecnología han basado su éxito en grandes cambios en los procesos de negocio a lo que se conoce como Reingeniería de Procesos. Pero estas son una minoría, por el contrario, para la mayoría de las empresas no se corresponden de forma directa los gastos en computación y la rentabilidad de los negocios [3].
Obtener resultados normalmente implica cambiar la manera de hacer las cosas en una organización y eso toma tiempo. Por tanto, y siguiendo la idea del párrafo anterior, las TI en un entorno BPM deben utilizarse como una herramienta de soporte para la innovación de procesos y para gestionar la información dentro de los mismos.
Para facilitar la gestión de la información en los procesos operacionales se debe encaminar hacia procesos estructurados incluyendo la cadena total de valor que genera cada proceso, mejorando las habilidades de las personas para procesar y diseminar la información y trabajando en el incremento de la conciencia sobre la importancia de la memoria organizacional. La mejor tecnología es aquella que se puede utilizar y un acercamiento al éxito es utilizar solo las que se requieren.
Estándares de BPM
La siguiente tabla resume los principales estándares que han emergido en el entorno BPM junto a una breve descripción de su propósito.
| Estándar | Descripción |
| Business Process Execution Languaje (BPEL) | Estándar BPM más popular que sirve para ejecutar procesos de negocio. |
| Business Process Modeling Languaje | Lenguaje XML similar a BPEL |
| Business Process Modeling Notation (BPMN) | Lenguaje gráfico con mapeo a BPEL |
| Workflow Reference Model | Arquitectura de Workflow/BPM |
| Workflow API | API con definiciones en C, IDL y COM. |
| XML Process Defination Languaje (XPDL) | Lenguaje XML orientado a procesos similar a BPEL. |
| Workflow XML (WfXML) | Lenguaje XML para la comunicación con web-services entre ambientes de ejecución workflow. |
| Web Services Coreography Interface (WSCI) | Un XML para coreografía entre web-services. |
| Web Services Coreography Description Languaje (WS-CDL) | Lenguaje official de W3C para coreografía. |
| Business Process Definition Metamodel (BPDM) | Modelo para un lenguaje BPM que use el MDA (Model Driven Architecture) |
| Business Process Runtime Interface (BPRI) | Modelo MDA para una API BPM. |
| XLANG y Web-services Flow Language (WSFL) | Lenguaje de procesos XML |
| Business Process Specification Schema (BPSS) | Lenguaje de procesos para colaboración entre aplicaciones B2B. |
Tabla 1: Relación de estándares y breve descripción de un entorno BPM.
En una arquitectura BPM ideal, los estándares que deberían estar incluidos son: BPEL, BPMN y WS-CDL.
ESB
A menudo se interpreta a SOA como una tecnología (Servicios Web), sin embargo, aunque la adopción de los estándares relacionados con servicios Web favorezca la implantación de una arquitectura orientada a servicios, el concepto de SOA es, por su naturaleza, independiente de la tecnología, y para ello se introduce el concepto de ESB (Enterprise Service Bus).
Se trata de un elemento funcional que garantiza la interconexión entre las distintas aplicaciones de una arquitectura SOA, de forma transparente para las mismas aplicaciones [4].
Gracias al ESB, una aplicación que invoque un servicio no necesita conocer ningún detalle de la implementación, ni siquiera qué sistema brindará la fuente de información. Además, el ESB proporciona aquellos servicios de infraestructura que, sin ser parte de un proceso de negocio, constituyen un elemento indispensable para la ejecución controlada de cualquier proceso. Ejemplos típicos son la gestión de trazas, o las funciones de seguridad.
El ESB puede implementarse en varias tecnologías y según varios estándares. En empresas que hayan adoptado BPM, la responsabilidad del ESB es normalmente realizado por el Servidor de Integración del BPM.
BPMS
Las aplicaciones de tipo CRM y ERP han logrado un lugar importante dentro de las empresas permitiendo integrar tareas, controlar los datos y administrar todo lo que esté a su alcance sin basarse necesariamente en procesos. Por el contrario los Sistemas o Suites BPM automatizan, integran y optimizan los negocios basándose en una serie de procesos determinados por las personan que trabajan dentro de la organización.
Las empresas invierten grandes cantidades de tiempo, dinero y recursos para cumplir con los estándares de calidad. Siempre es difícil, porque las actividades que afectan el control de la calidad están en constante cambio y por otro lado las actividades manuales son difíciles de controlar.
Al contraste con esta situación los BPMS ofrecen: un framework de control interno de calidad para actividades manuales y automatizadas, una infraestructura ágil que permite actualizar rápidamente los procesos y las reglas de negocio y la habilidad de visualizar y monitorear actividades de negocio, seguir las leyes externas, regulaciones, políticas y procedimientos.
Dos de los principales beneficios que ofrecen los BPMS son: interoperabilidad con sistemas dispersos e interacción con el trabajador a través de web services y una adaptación rápida y fácil, debido a que los usuarios no necesitan instalar o aprender ningún software nuevo.
Todos los vendedores de BPMS promocionan los mismos objetivos, pero en realidad cada uno vende un producto diferente, dependiendo de la visión de lo que un BPMS debería hacer. Los principios básicos que deben perseguir son:
· Diseños de procesos y capacidades de administración.
· Capacidades de interacción con los trabajadores.
· Capacidad de integración con los sistemas.
· Capacidades de la máquina de procesos.
· Monitoreo de las actividades (Reportes y Dashboards).
Dichos principios son agrupados por componentes en las distintas implementaciones de BPMS, como muestra la figura 4.
Figura 4: Componentes de un BPMS.
La figura 5 ilustra una posible arquitectura de un BPMS, donde se perciben los elementos claves y algunos elementos de soporte al sistema.
Figura 5: Posible arquitectura de un BPMS.
Se puede pensar en BPMS como en una herramienta que implementa un conjunto de tecnologías de modelización de procesos, integración y workflow [4]. Los BPMS permiten a los analistas de negocio modelar el ciclo completo de un proceso de negocio (tanto los pasos manuales como automáticos), consolidar procesos que abarcan aplicaciones existentes y desplegar procesos de principio a fin con un bajo o nulo esfuerzo en tareas de programación de software. Además, un BPMS gestiona la ejecución de las instancias de proceso con la personalización requerida.
En efecto, un BPMS separa el proceso de negocio de la gestión del software, permitiendo una reconfiguración rápida del proceso si fuese necesario. Por el contrario, las aplicaciones actuales embeben los procesos de manera rígida dentro del código y de las tablas de las bases de datos, haciendo que los cambios sean complejos y costosos. La figura 6 representa un diagrama básico que sería el flujo de actuación para diseñar e implementar procesos de negocios.
Figura 6: Funcionamiento de un BPMS.
Es muy importante la selección de un producto BPMS adecuado. No todos los productos incluyen todos los principios básicos.
Un método recomendado para estar preparado ante la llegada de un BPMS es construir una matriz de requerimientos de acuerdo a los procesos que se llevan a cabo en los negocios [4]. Las características esenciales a ser evaluadas para cada proceso serían: el volumen de instancias del proceso (por horas o por días), la cantidad de pasos que requieran la interacción del ser humano, las interacciones con aplicaciones, las reglas de negocio para ese proceso, la administración del contenido del proceso (soporte de versiones, búsquedas, seguridad) y los eventos y excepciones.
Sin lugar a duda, BPM está teniendo buena aceptación. Una encuesta realizada en diciembre de 2006 sobre BPM a 1700 empresas arrojó como resultado que el 36% de ellas estaban considerando esta tecnología, mientras que el 24% ya la estaban probando, la tenían en producción o incluso la estaban actualizando [4].
De esas empresas que han implementado proyectos BPM se conoce que [4]:
· Los proyectos BPM tienen un retorno promedio del 20% de la inversión.
· Los proyectos BPM considerados exitosos colaboran en alcanzar ventaja competitiva y una alta satisfacción del cliente.
· Los proyectos BPM favorecen directamente la alineación entre el negocio y las TIC.
Aunque también se constató que las empresas que han implementado un proyecto BPM no utilizan la herramienta al máximo. Lo que puede darse por dos razones [4]:
· No lo necesitan para los procesos que desean integrar.
· No tienen suficiente experiencia en el análisis de patrones para la integración.
Los BPMS más difundidos en la actualidad son TIBCO, ARIS, ULTIMUS, AuraPortal y el BPMS de la Suite de Oracle. La figura 7 muestra la interfaz de modelación de procesos del BPMS TIBCO. El área marcada en rojo con líneas discontinuas corresponde al lugar donde se modelan los procesos de negocio con la nomenclatura del estándar BPMN.
Figura 7: Interfaz de usuario para la modelación de procesos en el BPMS TIBCO.
Referencias Bibliográficas
1. Documentos BEA Systems. “Arquitectura SOA”. http://www.computing-es.com/soa.pdf.
(01/11/2007)
2. TIBCO, Sección de anuncios especiales. “Las siete claves del éxito SOA”,
http://www.tibco.com.
(01/11/2007)
3. Zavaleta, Pablo. Expo Business. “Las TICs y el BPM”, Documento digital en formato PDF, noviembre de 2005.
4. Loyola, William. “Maestría en sistemas de información general”, Documento digital en formato PDF, julio de 2006.
Suscribirse a:
Entradas (Atom)
