Las instituciones privadas también se pueden ver afectadas por este problema. Por ejemplo, en muchos países existe un banco central que obliga a las entidades financieras que quieran operar en su jurisdicción a seguir unas determinadas normas en procesos, como la concesión de préstamos a clientes. Dichas normas, que podrían incluir desde los tipos de préstamos que pueden ofrecer o el rango de interés en que se pueden conceder, hasta los plazos de devolución o las actividades que deben realizarse antes de aprobarlo o denegarlo, deben ser adaptadas a la idiosincrasia de cada banco antes de ser aplicadas, pero siempre respetando las restricciones que haya fijado el banco central.

1. Especificación del workflow genérico. En esta etapa, los ingenieros deben especificar el workflow genérico a partir de la normativa general que regula el proceso. Deberá hacerse en un lenguaje que permita especificar las actividades, su orden y sus plazos, los responsables de realizarlas y los datos necesarios. Además, el lenguaje de especificación utilizado deberá permitir el establecimiento de restricciones para la adaptación sobre los elementos anteriores para que sea posible abordar el resto de etapas del problema.
2. Especificación de restricciones de adaptación. En esta etapa, los ingenieros, a partir de la normativa general del proceso, deberán establecer de forma coherente las restricciones de adaptación que permitan indicar si los distintos elementos del workflow son obligatorios o necesarios en cualquier posible adaptación.
3. Adaptación. En esta etapa, a partir de la especificación del workflow adaptable y, teniendo en cuenta las características de cada caso particular, se deberá especificar el workflow adaptado que siempre debe pero respetando las restricciones fijadas.

Propagación. Esta etapa se produce si la normativa que regula el proceso genérico cambia. Esto provoca que sea necesario modificar el workflow adaptable y propagar esos cambios a todos los workflows adaptados a partir de él.

A la vista de estas cuatro etapas, cualquier propuesta que pretenda solucionar el Problema de la Adaptación Jerárquica debería proporcionar los mecanismos necesarios para afrontar todas ellas en su conjunto. Pero, actualmente, los ingenieros responsables de la especificación e implantación de estos workflows no cuentan con ningún método que les permita afrontar este problema con garantías de hacerlo de forma correcta.

En este trabajo se presenta una propuesta para afrontar este problema denominada Método de Adaptación Jerárquica. Este Método se fundamenta en la especificación de los workflows en forma de ontologías. El Método propone una forma de especificar workflows para procesos administrativos y sus restricciones de adaptación junto con las operaciones necesarias para adaptarlos a las características particulares de los entornos donde deban ser aplicados, respetando las restricciones fijadas en el workflow genérico. Además, también proporciona las operaciones necesarias para propagar los cambios que puedan sufrir los workflows genéricos a los workflows adaptados.

Así, en la sección 2 se analiza si las propuestas más conocidas en el campo de especialización y herencia de workflows son aplicables a este problema, en la sección 3 se presenta el Método de Adaptación Jerárquica y, por último, en la sección 4, se presentan los resultados obtenidos en la validación del método por parte de un grupo de Ingenieros de Software.

2. Trabajos Relacionados

Existen propuestas en el campo de herencia y especialización de workflows y procesos que, por sus características, parece el campo de investigación donde los ingenieros pudieran encontrar una forma de afrontar el Problema de la Adaptación Jerárquica.

Una de las primeras propuestas en este campo es la de Wyner y Lee (Wyner & Lee, 1995) en la que defienden que un proceso general sería un tipo de proceso abstracto que contiene todas las posibles variantes, y que las especializaciones realmente restringen el modelo general.

Esta propuesta, aunque interesante a nivel lógico, no es útil si se traslada al Problema de la Adaptación Jerárquica de forma ortodoxa. Esto es debido a que aplicando esta perspectiva de forma estricta, el workflow original debería contener todas las actividades, datos manejados y participantes involucrados de todas las posibles adaptaciones, lo que obligaría a conocer de antemano todos los posibles casos particulares donde va a utilizarse.

La propuesta de herencia de workflows de van der Aalst (Aalst & Basten, 2002), posiblemente la más conocida en este campo, tiene como principal objetivo migrar instancias en ejecución de un workflow modificado. Dado que esta propuesta de especialización sirve para un problema centrado en el nivel de ejecución de los workflows y que el Problema de Adaptación Jerárquica está enfocado en el nivel de definición, no es posible aplicar esta propuesta en este problema.

En cambio, existe una extensión de esta propuesta realizada por Wyner y Lee (Wyner & Lee, 2005) que sí es interesante para resolver el Problema de la Adaptación Jerárquica. En concreto, proponen la “congelación” de elementos limitando las posibilidades a la hora de realizar nuevas adicciones al original. Como se verá en la siguiente sección, el Método de Adaptación Jerárquica propuesto extiende y amplia esta idea de manera que, en el diseño del workflow original, puedan fijarse distintos niveles de restricciones a la adaptación. El problema es que para llevar esto a cabo, tal como los propios Wyner y Lee explican al realizar su propuesta, los lenguajes de representación tradicionales de workflow como WF-net restringen mucho las posibilidades de aplicación de estas ideas. Este es uno de los motivos principales por los que el Método de Adaptación Jerárquica se basa en la especificación de los workflows en forma de ontologías.

Hay también una propuesta de especialización de procesos en representación del conocimiento basado en herencia no monótona (Bernstein & Grosof, 2003) (Ferndriger et al., 2008). Este trabajo propone una noción de especialización que permite tanto añadir como borrar, lo que implica que la herencia no será monótona ya que afecta a los conceptos heredados. Como se verá en la siguiente sección, en el Método de Adaptación Jerárquica también se va a aplicar la idea de herencia no monótona aunque dicha herencia no monótona va a estar limitada en función de las restricciones de adaptación que se fijen en cada workflow.

La última propuesta analizada define la especialización en función de las actividades y el orden parcial que forman (Choppy, Desel, & Petrucci, 2011). Según esta propuesta la especialización puede producirse si se añade o elimina información, actividades o características al especializado siempre que se respete el orden parcial de ejecución de actividades en las especializaciones. Como se verá también en la siguiente sección, esta idea también se aplica en el Método de Adaptación Jerárquica pero a nivel de definición y no de ejecución.

Para concluir esta sección, se puede decir que ninguna de las propuestas más conocidas en el campo de especialización y herencia de workflows y procesos es aplicable directamente a solucionar el Problema de la Adaptación Jerárquica. Entre las razones se pueden citar, en primer lugar, que todas las propuestas están demasiado orientadas al comportamiento y, por tanto, a las actividades de los procesos sin considerar qué ocurre con los datos y participantes involucrados. En segundo lugar, porque la mayoría de ellas restringen la especialización a una serie de normas predefinidas que no permiten al diseñador del proceso flexibilizar la especialización en función de la naturaleza particular del proceso gestionado por el workflow. Y, en último lugar pero no menos importante, ninguna de estas propuestas aborda el problema de la propagación de cambios desde los workflows de los procesos genéricos a los workflows de los procesos adaptados.

El Método de Adaptación Jerárquica que se presenta a continuación trata de eliminar estas carencias con el objetivo de proporcionar una solución completa al Problema de la Adaptación Jerárquica.

3. El Método de Adaptación Jerárquica

El Método de Adaptación Jerárquica está fundamentado sobre la especificación de workflows en forma de ontologías. Son varios los motivos para esta elección. En primer lugar, la precisión y completitud de las ontologías para la representación de los elementos de los workflows y su versatilidad para representar no solo las actividades, los participantes y los datos involucrados en el workflow de un proceso, sino también para poder establecer las características particulares de adaptación de cada uno de estos elementos en cada workflow. En segundo lugar, la posibilidad de dividir la especificación de un workflow en dos ontologías, una para los datos y participantes del dominio y, otra para describir las propiedades del proceso que gestiona el workflow, y las actividades que lo componen, van a facilitar tanto la reutilización de los datos y participantes entre los workflows de un mismo dominio como la adaptación de los workflows a los casos particulares. En tercer lugar, el uso de ontologías va a permitir establecer una noción de adaptación más abierta, ya que es el diseñador del workflow del proceso genérico quién establece las restricciones de adaptación concretas de cada workflow. Por último, la especificación de workflows en forma de ontologías, donde cada elemento tiene un propósito perfectamente definido, va a permitir desarrollar el conjunto de operaciones de propagación que se necesitan para que cualquier posible cambio que pueda necesitar el workflow del proceso genérico pueda ser transmitido a todos los adaptados a partir de él.

Sobre esta base, el Método de Adaptación Jerárquica proporciona el conjunto de métodos y operaciones necesarios para afrontar cada una de las cuatro etapas que componen el Problema de la Adaptación Jerárquica y que son resumidas a continuación.

3.1. Primera etapa: especificación del workflow genérico.

Para la primera etapa, en el Método de Adaptación Jerárquica se ha actualizado la propuesta de representación de workflows de procesos administrativos en forma de ontologías que fue propuesta en (Á. E. Prieto & Lozano-Tello, 2009) y reestructurada en (A. E. Prieto & Lozano-Tello, 2012).

Los primeros (Mandatory) se definen sobre el proceso administrativo especificado en OntoWF y sirven para indicar las actividades (Mandatory Activities), tipos de participantes (Mandatory Participants), datos del dominio y propiedades del proceso (Mandatory Data) que siempre deben aparecer en cualquier posible adaptación de un workflow.

El segundo tipo de elementos (Rigid) se define sobre las actividades y sirven para indicar que no se permite ningún cambio en las actividades inmediatamente anteriores e inmediatamente posteriores a la actividad en cuestión (Rigid Before and Rigid After), en los tipos de participante que pueden realizarla (Rigid Participants), en los datos del dominio y propiedades del proceso que utiliza (Rigid Updateable Data and Rigid Viewable Data) y en los plazos de tiempo para comenzar y finalizar la actividad (Rigid Days Time Frame and Rigid Days Before Beginning). De este modo, si en el workflow adaptado alguna actividad no puede satisfacer estas restricciones, es obligatorio eliminar dicha actividad del workflow adaptado.

El tercer tipo de elementos (Required) se define sobre las actividades pero en este caso se utilizan para indicar las restricciones mínimas en cuanto a qué actividades deben realizarse antes y después de una actividad (Required Before and Required After), qué tipos de participante deben estar al menos disponibles para realizarla (Required Participants) y qué datos del dominio y propiedades del proceso deben ser utilizados como mínimo en la actividad (Required Updateable Data and Required Viewable Data) pero permitiendo que, en todos los casos, puedan añadirse nuevos elementos de alguno de estos tipos. Al igual que con el segundo tipo de elementos, si alguna actividad no es capaz de satisfacer los requisitos fijados, será obligatorio eliminar dicha actividad del adaptado.

A partir de estos elementos de adaptación, en esta etapa del Método de Adaptación Jerárquica se establece que un workflow adaptable será aquel workflow correctamente especificado usando OntoMetaWorkflow y que toma valores en algunos de los elementos de adaptación cumpliendo siempre la siguiente restricción: el workflow compuesto exclusivamente de las actividades, datos del dominio, propiedades del proceso y participantes del workflow afectados por los elementos de adaptación del tipo obligatorio debe especificar por sí solo un workflow correctamente especificado usando OntoMetaWorkflow. Esta definición implica que para que un workflow sea adaptable no es suficiente con que tome cualquier valor en alguno de los elementos de adaptación sino que es necesario que esos valores estén fijados de forma coherente. Para facilitar la especificación correcta de workflows adaptables, el Método de Adaptación Jerárquica proporciona el método para especificar un workflow adaptable que ayuda a fijar los valores en estos elementos de adaptación en un workflow correctamente especificado usando OntoMetaWorkflow y que comprende los siguientes pasos:

1. Indicar qué actividades son obligatorias en cualquier adaptación jerárquica del workflow incluyendo dichas actividades en la relación Mandatory Activities. Al menos deben serlo la actividad inicial y una actividad final.
2. A continuación hay que fijar los requisitos de adaptabilidad en lo que a la ubicación de las actividades se refiere. Para ello hay que realizar los siguientes pasos:
   1. Para cada actividad en la ontología OntoWF, empezando por la actividad inicial, siguiendo todos los posibles caminos y el orden en que están situadas las actividades y terminando en las actividades finales, indicar si las actividades inmediatamente posteriores (las incluidas en la relación After) de la actividad tratada siempre deben ser las mismas usando el atributo Rigid After. Si la actividad está incluida en la relación Mandatory Activities del workflow, solo debe indicarse este atributo a verdadero si todas las actividades afectadas también lo están.
   2. Para cada actividad en la ontología OntoWF, empezando por la actividades finales, siguiendo todos los posibles caminos y el orden inverso en que están situadas las actividades y terminando en la actividad inicial, indicar si las actividades inmediatamente anteriores (las incluidas en la relación Before) de la actividad tratada siempre deben ser las mismas usando el atributo Rigid Before. Hay que tener en cuenta que si hay algún Rigid After situado en una actividad que es inicio de bifurcación entonces la actividad que es final de bifurcación también debe tener a verdadero el atributo Rigid Before. Además, si la actividad está incluida en la relación Mandatory Activities del workflow, solo debe indicarse este atributo a verdadero si todas las actividades afectadas también lo están.
   3. Para cada actividad en la ontología OntoWF, empezando por la actividad inicial, siguiendo todos los posibles caminos y el orden en que están situadas las actividades y terminando en las actividades inmediatamente anteriores a las actividades finales, incluir en la relación Required After de cada actividad aquellas actividades posteriores que, como mínimo, deben aparecer con posterioridad a la actividad en el workflow. Si la actividad está incluida en la relación Mandatory Activities del workflow, solo deben incluirse en esta relación a actividades que también lo estén.
   4. Para cada actividad en la ontología OntoWF, empezando por la actividades finales, siguiendo todos los posibles caminos y el orden inverso en que están situadas las actividades y terminando en las actividades inmediatamente posteriores a la actividad inicial, incluir en la relación Required Before de cada actividad aquellas actividades anteriores que, como mínimo, deben aparecer con anterioridad a la actividad en el workflow. Si la actividad está incluida en la relación Mandatory Activities del workflow, solo deben incluirse en esta relación a actividades que también lo estén.
3. Por último, es necesario fijar los requisitos de adaptabilidad en cuanto a las características de cada actividad se refiere. Para ello hay que realizar para cada actividad en la ontología OntoWF, empezando por la actividad inicial y terminando en las actividades finales y siguiendo todos los posibles caminos y el orden en que están situadas las actividades, las siguientes acciones:
   1. Indicar si los participantes disponibles para realizar la actividad siempre deben ser los indicados en la relación Is Performed By fijando el atributo Rigid Participants a verdadero. Si la actividad está incluida en la relación Mandatory Activities del workflow entonces debe incluirse a todos los participantes afectados en la relación Mandatory Participants si no lo estaban previamente.
   2. Dado que una de las características de un workflow correctamente especificado usando OntoMetaWorkflow es que todas las actividades deben incluir, al menos, un Workflow Participant en la relación Is Performed By, es necesario incluir alguno de los participantes indicados en la relación Is Performed By en la relación Required Participants. Además, si la actividad está incluida en la relación Mandatory Activities del workflow entonces debe incluirse a todos los participantes afectados en la relación Mandatory Participants si no lo estaban previamente.
   3. Indicar si los datos del dominio seleccionables y las propiedades del proceso modificables siempre deben ser los mismos usando el atributo Rigid Updateable Data. Si la actividad está incluida en la relación Mandatory Activities del workflow entonces debe incluirse a todos los datos y propiedades afectados en el atributo Mandatory Data si no lo estaban previamente.
   4. Dado que una de las características de un workflow correctamente especificado usando OntoMetaWorkflow es que todas las actividades deben incluir, al menos, una operación de selección sobre datos del dominio o una operación de modificación sobre propiedades del proceso, es necesario incluir alguno de los datos del dominio indicados en los atributos del dominio Select Class Of Domain Data o Select Instance Of Domain Data o a alguna de las propiedades del proceso indicadas en el atributo Fill In Instance Attributes of Process en el atributo Required Updateable Data. Además, si la actividad está incluida en la relación Mandatory Activities del workflow entonces debe incluirse a todos los datos y propiedades afectados en el atributo Mandatory Data si no lo estaban previamente.
   5. Indicar si los datos del dominio y las propiedades del proceso visualizables siempre deben ser los mismos usando el atributo Rigid Viewable Data. Este atributo debe tratarse con precaución porque podría darse el caso de que alguno de los elementos que se debe visualizar no esté en el workflow adaptado porque la actividad donde se seleccionaba o modificaba no está disponible en el workflow adaptado. Por este motivo, este atributo solo debe fijarse a verdadero si todos los datos que visualiza la actividad están incluidos en el atributo Mandatory Data y, además, están incluidos en el atributo Required Updateable Data de actividades obligatorias anteriores o son manipulados en actividades obligatorias anteriores que tengan fijado a verdadero el atributo Rigid Updateable Data.
   6. Si alguno de los datos del dominio o de las propiedades del proceso siempre debe poder visualizarse en la actividad, incluir en al atributo Required Viewable Data dichos datos del dominio o propiedades del proceso. Al igual que en el paso anterior, este atributo también debe tratarse con precaución porque podría darse el caso de que alguno de los elementos que se debe visualizar no esté en el workflow adaptado porque la actividad donde se seleccionaba o modificaba no está disponible en el workflow adaptado. Por este motivo, en este atributo solo deben incluirse aquellos datos o propiedades que estén incluidos en el atributo Mandatory Data y, además, están incluidos en el atributo Required Updateable Data de actividades obligatorias anteriores o son manipulados en actividades obligatorias anteriores que tengan fijado a verdadero el atributo Rigid Updateable Data.
   7. Indicar si el número máximo de días para realizar la actividad es fijo o puede reducirse usando el atributo Rigid Days Time Frame.
   8. Indicar si es el número mínimo de días antes de comenzar la actividad es fijo o puede ampliarse usando el atributo Rigid Days Before Beginning.

Además, hay que indicar que, aunque los elementos de adaptación se especifican en la ontología OntoWF, también afectan a la ontología OntoDD de dos formas. Por un lado es obligatorio que los participantes afectados por la relación Mandatory Participants deban aparecer en la ontología OntoDD que use el workflow adaptado. Por otro lado, también es obligatorio que los Domain Data afectados por el atributo Mandatory Data también deban aparecer en la ontología OntoDD. Del mismo modo, las propiedades que el proceso adaptado tenga especificadas en la ontología OntoWF al menos deben ser las que están afectadas en el adaptable por el atributo Mandatory Data.

3.3. Tercera etapa: adaptación