http://dx.doi.Org/10.14482/inde.33.1.5927.

Hacia un método de integración de procesos de negocio basado en escenarios, niveles arquitectónicos e información contextual

Towards a business process integration method based on scenarios, architectural layers, and contextual information

Jorge Eliécer Giraldo Plaza*

Demetrio Arturo Ovalle Carranza**

Universidad Nacional de Colombia, Sede Medellín (Colombia)

* Ingeniero y M.Sc. en Ingeniería de Sistemas. Profesor Asociado del Politécnico Colombiano Jaime Isaza Cadavid, Medellín Colombia, Bloque P19. Ph.D. (c) en Ingeniería, Sistemas e Informática, Universidad Nacional de Colombia, Medellín. jegiraldp@unal.edu.co

** Ingeniero de Sistemas y Computación, M.Sc. y Ph.D. en Informática, Francia. Profesor titular del Departamento de Ciencias de la Computación y de la Decisión. Universidad Nacional de Colombia, Medellín, Bloque M8A. dovalle@unal.edu.co

Correspondencia: Jorge Giraldo. Fax: 4255214 - 3141002.

Fecha de recepcón: 17 de diciembre de 2013 Fecha de aceptación: 15 de diciembre de 2014

Resumen

El objetivo de este artículo es presentar una propuesta de un método de integración de procesos de negocio, teniendo en cuenta información contextual relacionada con escenarios y niveles arquitectónicos de integración. La aproximación del método propuesto se valida mediante un proceso productivo de tipo industrial, tomado como caso de estudio. A partir del trabajo realizado, se puede concluir que es necesario recopilar la mayor cantidad de información contextual relacionada con el dominio de la aplicación y los procesos involucrados en la integración, con el fin de evitar que se realicen actualizaciones innecesarias sobre procesos y sus variantes.

Palabras clave: integración de procesos de negocio, procesos de negocio, computación sensible al contexto, escenarios, niveles.

Abstract

This paper presents a method of approaching business process integration, by taking into account contextual information related to architectural scenarios and levels of integration. The approach is validated through a case study related to the coffee industry. Based on this work, it can be concluded that the more information related to the context and its relationship to the domain and processes, it is possible to avoid unnecessary updates on processes and their variants are made.

Keywords: business Process Integration; Business Process; context awareness computing; scenarios; levels.

INTRODUCCIÓN

Un proceso de negocio o BP (Business Process) se define como la descripción lógica de la secuencia de actividades relacionadas directamente con el negocio, que al ser modelados y automatizados dan valor agregado a sus productos o servicios que finalmente generan para la empresa aumento en su productividad [1 ].

Durante la ejecución de procesos se presentan situaciones en las que es necesario realizar adaptaciones a los procesos; lo anterior conlleva a que se generen varias versiones del mismo proceso. Un ejemplo es realizar una venta a un cliente corporativo de gran tamaño, cuando la empresa sólo está preparada para hacerlo con pequeñas y medianas empresas. Por lo tanto, se requiere modificar el proceso que implica una variación. Otra situación importante es cuando se presenta la fusión de empresas, para lo cual se requiere que dos versiones diferentes de un mismo proceso trabajen como una sola, como por ejemplo la compra de tiquetes de vuelos para empleados.

Los ejemplos expuestos manifiestan la necesidad de obtener una sola versión del proceso a partir de las distintas variaciones. Esto se resuelve mediante la integración de procesos de negocio o BPI (Business Process Improvement), ya que su principal objetivo es obtener un solo proceso de negocio a partir de sus distintas versiones, ya sea por modificaciones realizadas o por la fusión entre ellos [2 ].

Las aproximaciones en investigación a la BPI enfocan sus esfuerzos principalmente en los siguientes aspectos: 1) el modelado de los procesos basados en roles [3 ] e instancias [4 ]; 2) la identificación de similitudes de tipo sintáctico y semántico [5 ]; 3) el análisis de interacciones, donde se en-fatiza en el análisis y levantamiento de la información que se intercambia entre procesos [6 ]; y 4) el manejo del contexto en los procesos de negocio a integrar, donde aparecen aspectos como flexibilidad e identificación de situaciones [7 ].

Con base en la revisión anterior, surge la necesidad de obtener un método robusto de integración de procesos a partir de información contextual y así mejorar la calidad del servicio que ofrece el proceso de negocio generado desde sus elementos. Los principales retos y tendencias del área de la BPI son: 1) modelado de la integración de procesos, 2) inclusión de la adapta-tividad al entorno por medio de flexibilidad y sensibilidad al contexto, 3) manejo de colecciones de modelos de procesos, 4) desarrollo de esquemas de razonamiento y 5) escenarios de integración.

Este artículo presenta inicialmente una conceptualización de la integración de procesos de negocio que facilitará proponer un método robusto con fases y técnicas de solución asociadas. A partir de ello, se propone la representación de información contextual relacionada con los escenarios y niveles arquitectónicos de integración. Luego, en la sección II se presenta un marco conceptual relacionado con la integración de procesos de negocio y su contexto; en la sección III, los trabajos relacionados con los procesos de negocio y la computación sensible al contexto; después, en la sección IV, se describe el método de integración propuesto fase a fase, y en la sección V se valida este método con un caso de estudio relacionado con la producción de café colombiano. Finalmente, en la sección VI se presentan conclusiones y trabajo futuro.

MARCO CONCEPTUAL

En esta sección se presenta una conceptualización de la BPI junto con nociones relacionadas: escenarios y niveles arquitectónicos de integración, sensibilidad al contexto y su relación con los procesos de negocio.

Integración de procesos de negocio

Cuando se presentan distintas versiones de un proceso, conocidas como variantes [8 ], ya sea por circunstancias como modificaciones específicas realizadas o por la fusión de dos empresas, es necesario emplear integración de procesos de negocio. La integración busca específicamente generar un proceso consolidado que sea lo más cercano posible a las variantes, con el fin de emplearlo en futuras ejecuciones.

El resultado de una integración puede ser representado como un modelo de proceso y ser almacenado en repositorios para posterior reutilización, comparación o análisis [9 ]. El modelo de proceso generado debe garantizar que se alcanzan todos los objetivos del conjunto previo de proceso que integró y minimizar el grado de cambio a partir de los procesos integrados, es decir, que sea lo más cercano posible para que los pueda reemplazar.

En la figura 1 se expresa en notación BPMN (Business Process Modeling Notation) un ejemplo de la integración de procesos de negocio, en donde a partir de dos procesos antecedentes (proceso A y proceso B), se pretende generar un tercer proceso (proceso C) capaz de reemplazarlos.

La integración comprende los procesos A (líneas continuas) y B (líneas discontinuas); el primero, compuesto por dos actividades secuenciales y el segundo, por dos actividades separadas por una condición. Así, el proceso generado puede estar compuesto por una actividad del proceso A y por la condición, y una actividad del proceso B. En este caso, las actividades A1 y B2 son seleccionadas, ya que son las más apropiadas para la integración. Adicionalmente, el proceso B contiene un condicional C1 que es seleccionado debido a que enriquece la descripción del modelo de proceso generado.

La BPI tiene dos fases, la similitud y la integración. La primera clasifica objetos a partir de rasgos comunes y su pertenencia a una clase, y determina la similitud de las descripciones de modelos de proceso residentes en repositorios. Esto permite revelar similitudes contextuales y el mapeo de funciones entre los procesos de negocio. Una vez se determina si dos procesos pueden integrarse mediante las técnicas de similitud, se da paso a la fase de integración o combinación. Esta fase fusiona elementos de dos procesos similares para crear uno nuevo que pueda reemplazar los anteriores [10 ].

La BPI se desarrolla dentro de organizaciones compuestas por elementos relacionados con sus tecnologías, estructura y gobierno. Ello hace que la integración sea dependiente de los posibles escenarios de ejecución [11 ]; estos son: 1) escenario técnico, que se encarga de gestionar la información durante la BPI, por medio de canales tecnológicos, 2) escenario organiza-cional, que hace referencia a la estructura de la organización y los procesos que impactan horizontal o verticalmente la cadena de valor y 3) escenario institucional, donde se describen los acuerdos formales e informales que gobiernan las relaciones interorganizacionales. Adicionalmente, se encarga de gestionar las interacciones entre roles y grupos de roles.

Según Weill y Ross [12 ], existen seis arquetipos que representan la distribución de poder en una organización: monarquía de procesos, monarquía de tecnologías, feudal, federal, duopolio de tecnologías y anarquía.

Niveles arquitectónicos de integración

Desde hace ya casi una década, las investigaciones relacionadas con la integración de procesos e integración de aplicaciones relacionan fuertemente los procesos con los niveles arquitectónicos de las aplicaciones de software. Los niveles son: 1) de integración visual, el cual se considera el nivel más simple de integración y se caracteriza por alojar la interfaz gráfica de usuario, 2) de integración funcional, que busca integrar el nivel lógico de los procesos mediante capas intermedias o middleware, incluye la integración de flujos y actividades y (3) integración de datos, que define un formato común para la información, teniendo en cuenta fuentes heterogéneas, su codificación y su sistema de almacenamiento. Con lo anterior se brinda apoyo a la toma de decisiones y a la sincronización para consultas o modificación.

Computación sensible al contexto

Básicamente, el uso de la computación sensible al contexto (Computing Awareness Context, CAwC) facilita la adaptación de las aplicaciones a su entorno con base en las situaciones identificadas. Algunos temas abiertos a la investigación sobre la sensibilidad al contexto son: 1) la extracción y uso de conocimiento basado en el entorno de una aplicación, 2) la definición de algoritmos de inferencia que permitan extraer información del usuario y proveerle servicios personalizados, 3) la definición de patrones de diseño propios del análisis de contexto, 4) la gestión apropiada de grandes cantidades de datos contextuales, y 5) el diseño y creación de mecanismos de rendimiento y evaluación del contexto identificado.

Ploesser et al. [13 ] proponen un modelo para el diseño de un proceso de negocio sensible al contexto donde resaltan como áreas relevantes el modelado del contexto, el aprendizaje del contexto, las taxonomías del contexto y operaciones de los procesos asociadas al contexto. Para el caso de los roles, Saidani y Nurcan [14 ] proponen un modelo de contexto para delegar funciones con base en las competencias y experiencia, ya que una operación puede ser ejecutada o no por un rol, dependiendo de los cambios en los requerimientos manifestados por los clientes del proceso.

En relación con las interacciones de los roles, Skopik et al. [15 ] proponen un modelo de contexto colaborativo que permite el descubrimiento de personas en la organización a partir de restricciones de tipo contextual, de perfil y de relaciones personales; de esta manera es posible detectar experiencias con base en cambios en las restricciones. Ghattas et al. [16 ] presentan un modelo para el aprendizaje del contexto; su idea se basa en la ejecución de los modelos de proceso en todos los posibles contextos del negocio. Los elementos tenidos en cuenta son los eventos del ambiente y los casos específicos del negocio.

Ploesser et al. [17 ] presentan una conceptualización de los procesos de negocio como un sistema adaptativo complejo, basado en interacciones de elementos externos al proceso y agentes de uso interno; tiene como elementos principales los objetivos del proceso y su modelo de representación. Con respecto a los elementos externos al proceso, Bernal et al. [18 ] presentan una solución para la descomposición de los modelos de proceso basado en reglas que a su vez definen restricciones. Su modelo de contexto se basa en las restricciones de orden de ejecución e invocación de actividades, transferencia de datos y las relaciones entre actividades.

Tavares et al. [19 ] presentan una aproximación de una arquitectura para el manejo de la flexibilidad de los procesos de negocio, teniendo en cuenta información contextual recolectada del ambiente, que a su vez puede ser controlada en tiempo real. Todo esto con el fin de poder mejorar y automatizar los mecanismos de adaptación. Mattos et al. [20 ] muestran una aproximación formal al contexto en procesos de negocio basada en modelos conceptuales. Dicha formalización busca identificar la situación de una actividad con el fin de soportar la toma de decisiones durante la ejecución de un proceso.

Método propuesto

En la figura 2 se presenta la propuesta de método de integración de procesos de negocio, compuesto por cuatro fases de ejecución secuencial, pero con ciclos de retroalimentación. Un elemento esencial en el método es el repositorio de información contextual, cuya tarea es registrar y almacenar la información relacionada con los procesos y sus elementos, así como historiales de ejecución y eventos.

Es importante señalar que si existe una falla en alguna de las fases, el método se detiene y empieza desde la fase 1, teniendo en cuenta la retroa-limentación de las fallas encontradas anteriormente. Esto se debe a que el método depende de la definición correcta del objetivo de integración, dado en la fase 1. A continuación se detalla cada una de las fases, resaltando las técnicas empleadas.

Fase 1. Especificación del objetivo de integración: para realizar una BPI es necesario plasmar claramente el proceso integrado que se quiere obtener. En su descripción se definen las actividades, roles, restricciones propias de cada actividad y el orden de integración representado por el flujo.

Las restricciones de los elementos están dadas en términos de los escenarios de integración y los niveles arquitectónicos involucrados, con el fin de garantizar la identificación de elementos contextuales que faciliten actividades de razonamiento en el proceso.

Para la especificación del objetivo de integración se emplea una representación basada en un modelo de proceso mediante notaciones apropiadas como XML. De esta manera se facilita la búsqueda de los procesos apropiados para la integración. Un trabajo representativo es el realizado por Ghose et al. [21 ].

Cada objetivo, sea principal o temporal, está compuesto por una o varias actividades. Cada actividad se asocia con una de las restricciones definidas y se compone de eventos externos o internos. Los eventos se asocian directamente con los niveles arquitectónicos de integración y con los escenarios. Pueden existir eventos que afecten la lógica del proceso, los datos o la interfaz de visualización, según sea el caso.

El bloque de declaración de restricciones se relaciona con los escenarios de integración, para los cuales se definen los siguientes elementos: 1) roles con sus habilidades para el escenario organizacional, 2) datos y su formato de codificación para el escenario técnico y 3) leyes dadas en términos de reglas de negocio.

Fase 2. Búsqueda y recuperación de procesos: el elemento principal sobre el cual trabaja esta fase es el repositorio; sus elementos fundamentales son una arquitectura de referencia y el sistema de gestión [22 ]. Mediante la arquitectura se definen las capas de procesamiento y visualización, además es posible incluir la adquisición de conocimiento a partir de información contextual. Por su parte, el sistema de gestión facilita el almacenamiento, indexación, procesamiento de consultas e interacción con los usuarios.

La representación de procesos de negocio se da en términos de BPEL (Business Process Execution Language), ya que facilita su análisis y ejecución mediante servicios web. Una vez representados los procesos, se realiza la indexación, que facilitará su manipulación mediante técnicas de bases de datos.

Existen distintas técnicas para determinar la similitud entre procesos, entre ellas [23 ]: métricas basadas en correspondencia de nodos y relaciones, métricas basadas en distancia de arcos de grafos de nodos, métricas que analizan dependencias causales entre actividades y aquéllas que comparan las bitácoras de un conjunto de relaciones teniendo en cuenta historial de eventos.

En la figura 3 se presenta el repositorio para la integración de procesos, el cual se compone de un sistema de gestión y tres capas, a saber: capa de representación e indexación, capa de búsqueda y recuperación y capa de adquisición de conocimiento. Tener información contextual almacenada facilita que durante la integración se identifiquen elementos que pueden ser impactados durante la integración y de esta manera se pueda mejorar la descripción del proceso integrado.

Un trabajo representativo de esta fase es el de Jin etal. [24 ], quienes proponen índices de velocidad que permiten la adaptación de modelos de procesos más que la creación desde cero. Para su solución emplean similitud semántica de etiquetas de procesos.

Fase 3. Integración y regresión: tanto para la integración como para la regresión se emplean métricas de similitud, ya que facilitan determinar si existe alineación entre dos procesos para su posterior unión o integración. La figura 4 presenta el esquema general de las etapas que comprenden la fase 3 del método propuesto. A partir de dos o más procesos seleccionados desde el repositorio, se procede a realizar una alineación empleando una ontología de dominio.

Es recomendable realizar la alineación mediante ontologías de dominio, tal como lo sugiere Jung [25 ]. Básicamente, consiste en analizar las relaciones semánticas entre conceptos para generar una descripción consistente que pueda alinear los niveles de detalle.

Una vez se obtiene el nivel de abstracción consistente entre los procesos seleccionados, se procede a integrarlos. Esta etapa se realiza empleando una capa intermedia encargada de identificar patrones comunes entre los procesos, mediante técnicas de similitud. En esta etapa se toma como base el trabajo realizado por La Rosa et al. [26 ], quienes presentan un método de unión de procesos a través de un modelo de unión basado en reglas.

Fase 4. Ejecución de la integración: una vez obtenido el modelo de proceso resultante de la integración, es necesario ejecutarlo, pero basado en un ambiente de simulación; de esta manera se detectan las inconsistencias entre el modelo generado y las variantes. De acuerdo con lo anterior, es posible identificar errores ocurridos durante las fases previas.

La ejecución busca la validación del proceso integrado, midiendo su varianza de cambio. Así se determina si es posible reemplazar o no los procesos que intervinieron en la integración. La varianza de cambio está dada en términos del grado de similitud entre el proceso generado y sus antecesores. También se mide el rendimiento en tiempo de ejecución del proceso.

En la fase de ejecución del proceso, el análisis de proceso de negocio se basa en información contextual [27 ]. Dicha información se obtiene a partir del registro de eventos, haciendo uso de técnicas de minería de procesos y análisis estadísticos.

3. VALIDACIÓN DEL MÉTODO MEDIANTE UN CASO DE ESTUDIO

Para realizar la validación del método propuesto se define un caso de estudio relacionado con la producción de café colombiano. En esta sección, inicialmente se realiza una descripción de un proceso junto con su contexto y las circunstancias que implican la necesidad de integración. Posteriormente se realiza la aplicación del método con el fin de obtener datos que permitan su ulterior análisis.

Descripción del proceso de producción de café

Actividad 1- Recolección de café: es una actividad totalmente manual, la cual depende de las habilidades y compromisos de los trabajadores contratados. Esta actividad no puede demorar más de 2 semanas, ya que el café puede llegar a secarse.

Actividad 2- Despulpado: se debe realizar máximo 6 horas después de la recolección. Aquí se quita la pulpa dulce de la semilla de café; la actividad depende de manera importante de la calibración de la máquina con que se realiza.

Actividad 3- Proceso de beneficiado: se realiza un lavado de la semilla. El resultado de esta actividad se conoce como café pergamino.

Actividad 4- Beneficiado seco: se realiza un día después del beneficiado húmedo. En esta actividad se le quita la cascarilla a la semilla del café, que luego debe ponerse a secar aproximadamente 40 horas. El secado puede ser de tipo manual (con el sol) o mecánico (hornos especiales).

Actividad 5- Encostalado: el café es almacenado en costales para su posterior transporte al centro de tostado.

Actividad 6- Recepción de café: durante esta actividad se realiza el pesaje de las cargas de café y se almacenan en un lugar libre de olores.

Actividad 7- Análisis de calidad: con el fin de determinar si el café es de tipo exportación o comercial, se evalúa y realizan pruebas. Los criterios que se tienen en cuenta son: humedad, identificación de defectos, ausencia de insectos, olor y el resultado de la prueba de taza.

Actividad 8- Molienda: esta actividad incluye la limpieza del grano con el fin eliminar impurezas no detectadas por el caficultor. La molienda se realiza en máquinas y es un flujo alterno del proceso, ya que si la carga de café se considera de tipo exportación no se ingresa a la molienda, sino que simplemente se empaca.

Actividad 9- Empacado y almacenamiento: El café ya sea de exportación o comercial se empaca y se almacena en espera de su distribución.

En la figura 5 se presenta en notación BPMN el proceso de producción de café descrito.

Necesidad de integración

El caso de integración -considerado para la validación por medio del caso de estudio- surge cuando se tienen distintas variantes de un mismo proceso y se requiere obtener una sola descripción.

Variante 1: la actividad de beneficiado seco (Actividad 4- Caficultor) puede realizarse de manera manual o mecánica, ya que depende principalmente del clima en la región: en clima templado se emplea el secado mecánico y en clima cálido, el manual.

Variante 2: la actividad de análisis de calidad (Actividad 2- Despulpado) depende de los criterios emitidos por las entidades responsables del café de cada país. Por ejemplo, para países en regiones húmedas, el porcentaje máximo de humedad permitido es de 11%. Para el caso de países con clima seco, es 12%.

Elementos contextuales

La descripción de los elementos contextuales tiene como base el trabajo realizado por Wan [28 ]: un conjunto de entidades, un conjunto finito de propiedades para cada entidad y las relaciones existente entre dichas propiedades.

Para el caso de estudio de la producción del café, se tendrán en cuenta los siguientes elementos contextuales: porcentaje de humedad, roles del proceso y técnica de secado. Es importante señalar que un elemento contextual no siempre se relaciona con todos los niveles y escenarios de integración, lo cual se debe a la misma naturales del elemento. Por ejemplo, el elemento porcentaje de humedad se relaciona directamente con la lógica del negocio, por tanto si varía la humedad, se puede o no ejecutar una actividad.

La tabla 1 presenta la identificación de los elementos contextuales, de acuerdo con el nivel o escenario al cual pertenecen. También se determina el tipo de evento (externo o interno) y la actividad a la cual pertenece. Las convenciones empleadas en la tabla son: Eo = Escenario organizacional, Et =escenario técnico y Ei=escenario institucional, Nv = nivel de vista, Nl =ni-vel lógico y Nd=nivel de datos; Eventos: 1 para internos y 2 para externos.

RESULTADOS Y DISCUSIÓN

Con base en el caso de estudio del proceso de producción de café, se presenta a continuación un caso de estudio aplicado a la aproximación metodológica propuesta.

Objetivo de integración

El objetivo de integración se representa a través de un archivo XML, el cual contiene información de los objetivos (goals) principales para la integración y aquellos secundarios (temporal goals). Los objetivos principales determinan la(s) actividad(es) que finaliza(n) el proceso, mientras los objetivos temporales son aquéllos que se permiten alcanzar el objetivo general.

En la figura 6 se presenta un segmento de una instancia de la plantilla definida para esta fase, con el caso de la producción de café.

La figura presenta la instancia de la actividad de Beneficiado, que se relaciona con información en el nivel lógico y éste, a su vez, es de tipo externo. Los datos definidos en el objetivo de integración permitirán realizar una búsqueda sobre el repositorio de procesos, teniendo en cuenta procesos que contengan dichas actividades.

Búsqueda y recuperación de procesos

Como supuestos, los modelos de proceso están descritos en lenguaje XPDL. Los nombres de las actividades son iguales en las variantes del proceso y en la descripción del objetivo de integración. En el repositorio existen 10 variantes en total.

La métrica utilizada es la correspondencia semántica, aplicada entre nodos y relaciones. Para ello se procede a la conformación de grupos de posibles candidatos, mediante el algoritmo de K-Means. Los resultados obtenidos, después del agrupamiento y eliminación de falsos positivos mediante la métrica de correspondencia semántica, se presentan en la tabla 2:

Integración y regresión

Para esta fase se parte del supuesto de que los procesos seleccionados tienen un mismo nivel de abstracción, lo que evita realizar la tarea de alineación. Se empleó un intérprete de documentos XPDL, con el fin de identificar actividades relacionadas al contexto y posibles cambios generados en la creación de sus variantes.

El procedimiento realizado por el intérprete tiene como base el trabajo realizado por La Rosa et al. [26 ], quienes presentan un método de unión de procesos a través de un modelo de unión basado en reglas. Debido a que se parte del hecho de que existe alineación semántica entre los procesos, la regresión es apropiada y no ocasiona que se mida nuevamente la correspondencia entre el proceso generado y las variantes del original.

Ejecución de la integración

La magnitud de cambio del proceso integrado respecto a sus antecesores está dada en términos del grado de similitud y el tiempo de ejecución. En (1) se presenta la descripción del cálculo de la magnitud.

Donde:

P= proceso generado a partir de la integración

Vi= las variantes del proceso original

Sim(P,Vi)= similitud entre proceso generado y cada una de las variantes del proceso original. Los valores de medición son: 1 cuando existe similitud, 0 cuando no existe y 0,5 cuando existe similitud parcial.

prom∑TP(x)= promedio de la sumatoria de tiempo de ejecución de cada una de las instancias del proceso. Su medida es en milisegundos.

Para el caso de estudio, las medidas tomadas fueron las siguientes:

Sim(P,V1)=1 (similitud del proceso con variante 1)

Sim(P,V2)=1 (similitud del proceso con variante 2)

prom∑TP(x)= de un total de 5 instancias se obtuvo un promedio de tiempo de ejecución de 3 milisegundos.

Por lo tanto:

M(P,V1)=3

M(P,V2)=3

La magnitud definida para el proceso generado y dos variantes del proceso original tienen un promedio de 3.

4. CONCLUSIONES Y TRABAJO FUTURO

Con la aproximación a un método de integración de procesos, es posible brindar mayor información relacionada con el contexto, ya que se tienen en cuenta los escenarios y niveles arquitectónicos de integración. Así mismo, la descomposición de objetivos facilita la asociación de información relacionada con eventos externos e internos. Por su parte, el uso de un repositorio de información contextual y eventos históricos es de gran importancia, ya que se facilita el análisis basado en casos, por lo que es factible emplear técnicas provenientes de la inteligencia computacional para un posterior razonamiento automático. Cabe señalar que la identificación de elementos contextuales es dependiente de sus situaciones. A partir de ellas es posible caracterizar situaciones relacionadas a los escenarios y niveles arquitectónicos de la integración. Respecto a la alineación y correspondencia entre procesos, la creación de ontologías desempeña un papel esencial, ya que evitan las ambigüedades entre elementos de los procesos. Lo anterior impacta la información relacionada con los niveles y escenarios de integración.

Por medio del método propuesto, es posible garantizar que los procesos empleados para la integración sean los apropiados, ya que la selección emplea métricas de similitud que facilitan la identificación de falsos positivos. Sin embargo, el método presenta algunas debilidades, las cuales se pretenden abordar con los siguientes trabajos de investigación futuros:

Diseñar un prototipo funcional que permita la representación interactiva y automática del objetivo de integración y las variantes de los procesos.

Formalizar el modelo contextual que soporte información relacionada con escenarios y niveles arquitectónicos de integración.

Realizar un estudio comparativo de las métricas de similitud, con el fin de definir aquéllas apropiadas para el manejo del contexto.

Definir los rangos de valores asociados a la regresión y validación que permitan determinar si un proceso generado puede o no reemplazar las variantes del proceso original.

Agradecimientos

Esta investigación fue financiada parcialmente por el proyecto de investigación: "Método de integración inteligente de procesos de negocio sensible y adaptado al contexto" de la convocatoria del programa nacional de apoyo a estudiantes de posgrado para el fortalecimiento de la investigación, creación e innovación de la Universidad Nacional de Colombia del 2014, con código Quipu 20000001S72S.

REFERENCIAS

[1 ] M. Weske, Business Process Management: Concepts, Languages, Architectures,2nd Ed. Springer, pp. I-XV, 2012.         [ Links ]

[2 ] E. Morrison, A. Menzies, G. Koliadis, and A. K. Ghose, "Business Process Integration: Method and Analysis," Proc. Sixth Asia-Pacific Conference on Conceptual Modelling, 2009.         [ Links ]

[3 ] D. Nedbal, "A Process Model to guide the Integration of Business Processes and Services within and across Organizations," International Journal of Services, Economics and Management, vol. 5, no. 1, pp. 154-177, 201S.         [ Links ]

[4 ] M. Böhm, D. Habich, S. Preissler, and W. Lehner, "Cost-based vectorization of instance-based integration processes," Inf. Syst. vol. 36, no. 1, pp. 3-29, 2011.         [ Links ]

[5 ] J. Gao and L. Zhang, "On Measuring Semantic Similarity of Business Process Models," International Conference on Interoperability for Enterprise Software and Applications, China, 2009, pp. 289-293.         [ Links ]

[6 ] M. Weidlich, J. Mendling, and M. Weske. "Propagating Changes between Aligned Process Models," Journal of Systems and Software, Vol. 85, no. 8, pp. 1SS5-1S9, August 2012. doi:10.1016/j.jss.2012.02.044        [ Links ]

[7 ] D. Machado, R. Mendes, F. Santoro, and G. Pena, "Defining context in a business process collaborative elicitation approach," Computer Supported Cooperative Work in Design (CSCWD), 2012 IEEE 16th International Conference. ISBN 978-1-4673-1211-0. pp. 861-868.         [ Links ]

[8 ] A. Kumar and W. Yao, "Design and Management of Flexible Process Variants using Templates and Rules," Computer in Industry (Special Issue on Managing Large Collections of Business Process Models), vol. 63, no. 2, pp. 112-130, 2012.         [ Links ]

[9 ] Y. Zhiqiang, M. Remco, and P. Dijkman, "Business process model repositories - Framework and survey". Information & Software Technology, vol. 54, no. 4. pp. 3S0-395, 2012. doi:10.1016/j.infsof.2011.11.005        [ Links ]

[10 ] M. La Rosa, M. Dumas, R. Uba, and R. Dijkman, "Merging Business Process Models," Proceedings of the 18th International Conference on Cooperative Information Systems, Springer, vol. 6426, pp. 96-113, 2010.         [ Links ]

[11 ] F. Norbert and S. Petra, "A Maturity Model for B2B Integration (BIMM)", Proceedings of the 24th International Bled eConference, Bled, Slovenia, June, 2011.         [ Links ]

[12 ] P. Weill and J. Ross, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Boston: Harvard Business Press, 2004.         [ Links ]

[13 ] K. Ploesser, M. Peleg, P. Soffer, M. Rosemann, and J. Recker, "Learning from Context to Improve Business Processes," BPTrends, Jan. 2009.         [ Links ]

[14 ] O. Saidani and S. Nurcan, "Context-Awareness for Adequate Business Process Modelling," Proceedings of the Third IEEE International Conference on Research Challenges in Information Science, 2009, pp. 177-186.         [ Links ]

[15 ] F. Skopik, D. Schall, S. Dustdar, and M. Sesana, "Context-Aware Interaction Models in Cross-Organizational Processes" Fifth International Conference on Internet and Web Applications and Services, 2010, pp. 85-90.         [ Links ]

[16 ] J. Ghattas, P. Soffer, and M. Peleg, "A Formal Model for Process Context Learning," Business Process Management Workshops, pp. 140-157, 2009.         [ Links ]

[17 ] K. Ploesser, J. Recker, and M. Rosemann, "Building a Methodology for Context-Aware Business Processes. Insights from an Exploratory Case Study," 18th European Conference on Information Systems, 2010.         [ Links ]

[18 ] J. Bernal, P. Falcarin, and M. Morisio, "Dynamic Context-Aware Business Process: A Rule-Based Approach Supported by Pattern Identification," Proceedings of the 2010 ACM Symposium on Applied Computing. Sierre, Switzerland, March, 2010, pp. 470-474.         [ Links ]

[19 ] V. Tavares, C. Lima, and F. Santoro, "Dynamic process adaptation: A context-aware approach," CSCWD 11 - (International Conference on Computer Supported Cooperative Work in Design), 2011.         [ Links ]

[20 ] T. Mattos, F. Santoro, K. Revoredo, and V. Tavares, "Formalizing the situation of a business process activity," CSCWD 11 - (International Conference on Computer Supported Cooperative Work in Design), 2012, pp. 128-134.         [ Links ]

[21 ] A. Ghose, N. Narendra, K. Ponnalagu, A. Panda, and A. Gohad, "Goal-driven business process derivation," International Conf. on Service-Oriented Computing, Springer LNCS, Short Paper, 2011.         [ Links ]

[22 ] Z. Yan, M. Remco, M. Dijkman, and P. Grefen, "Business process model repositories - Framework and survey," Information & Software Technology, vol. 54, no. 4, pp. 380-395, 2012.         [ Links ]

[23 ] M. Becker and R. Laue, "A comparative survey of business process similarity measures," Computers in Industry, vol. 63, no. 2, pp. 148-167, Febr. 2012. doi:10.1016/j.compind.2011.11.003        [ Links ]

[24 ] T. Jin, J. Wang, M. La Rosa, A. ter Hofstede, and L. Wen, "Efficient querying of large process model repositories," Computers in Industry, vol. 64, no. 1, pp.41-19, 2013        [ Links ]

[25 ] J. Jung, "Semantic business process integration based on ontology alignment," Expert Systems with Applications, vol. 36, no. 8, pp. 11013-11020, Oct. 2009.         [ Links ]

[26 ] M. La Rosa, M. Dumas, R. Uba, and R. Dijkman, "Business Process Model Merging: An Approach to Business Process Consolidation," ACM Transactions on Software Engineering and Methodology, vol 22, no. 2, 2013.         [ Links ]

[27 ] M. Leyer, "Towards A Context-Aware Analysis Of Business Process Performance," Pacific Asia Conference on Information Systems, 2011.         [ Links ]

[28 ] K. Wan, "A brief history of context", International Journal of Computer Science Issues, vol. 6, no. 2, 2009.         [ Links ]