La especificación ESTROFA

En la pasada reunión de diciembre de 1995, la Comisión Permanente del Consejo Superior de Informática (CSI), aprobó las especificaciones ESTROFA que serán requeridas por la Administración Pública cuando se trate de contratar aplicaciones relacionadas con el mundo de las aplicaciones workflow.

Las especificaciones ESTROFA siguen la línea iniciada por las aplicadas para los productos software de carácter horizontal como ATRIO (Almacenamiento, Tratamiento y Recuperación de Información de Oficinas" y SICRES (Sistema de Información Común de los Registros administrativos de Entrada y Salida), en las que el grupo de trabajo ad hoc del Consejo Superior de Informática lleva ya una experiencia de dos años en materia de homologación de productos.

El proceso de homologación consiste básicamente en los siguientes pasos:

1. Solicitud formal de la empresa que aspira a homologar productos con el marchamo ESTROFA, dirigida a la secretaría del CSI, indicando que ha estudiado las especificaciones y considera que su producto las cumple en su totalidad.

2. Cumplimentación de un cuestionario ESTROFA elaborado por el grupo de trabajo ad hoc.

3 Realización de pruebas por el grupo de trabajo en el producto workflow sobre un proceso reglamentado y otro semirreglamentado.

4. Informe de homologación, elaborado por el grupo de trabajo, como resultado de los trabajos de revisión del cuestionario y las pruebas efectuadas.

5. Certificación expedida por la secretaría del CSI.

Exposición de motivos

Durante los estudios realizados para la definición de las características de ESTROFA se apreció un importante consenso sobre la necesidad de que su base fuera sustancialmente el esquema de verificación ATRIO. Los requisitos de dicho esquema y sus características de apertura y portabilidad coinciden en líneas generales con las exigencias que los más modernos sistemas de control de flujos de tareas comportan. No obstante, se apreció la necesidad de modificar la calificación de ESTROFA como un módulo de ATRIO, entendido en el sentido de su aplicación a cualquier órgano de la Administración sin ninguna modificación o adaptación.

En efecto, no nos encontramos ante un sistema como SICRES o el seguimiento de expedientes administrativos que son aplicaciones cerradas, con una definición de la mayoría de sus tablas, sino ante una enumeración de requisitos que deberán cumplir los productos candidatos a la homologación ESTROFA. Cumplidos dichos requisitos mínimos, podrá existir una variedad importante de sistemas ESTROFA que ofrezcan soluciones diferentes a los mismos objetivos. Esto quiere decir que ESTROFA es algo más que un módulo de ATRIO, algo más que una aplicación cerrada. Basándose en ATRIO y utilizando sus herramientas, ESTROFA define un marco conceptual en el que podrán encajar diferentes sistemas de control de flujos de tareas. ESTROFA, en consecuencia, es más una nueva capa de ATRIO que un módulo concreto.

Hecha esta imprescindible advertencia, conviene hacer notar que la relativa novedad de la materia exige actuar con cierta cautela. No existen conceptos unánimemente aceptados, la terminología es confusa y dudosa y, desde luego, la normalización está en sus comienzos. Los redactores de ESTROFA han tenido muy en cuenta las iniciativas internacionales en la materia (por ejemplo, los principios de la Workflow Management Coalition) y las opiniones de los principales desarrolladores españoles.

El esfuerzo mayor se ha centrado en precisar la terminología que debe ser aplicada para construir un marco que permita distinguir y homologar los sistemas de verdadero control de flujos de tareas, de una multitud de aplicaciones de distinta naturaleza que aparecen cada día en el mercado. De forma consciente se ha evitado introducir en las especificaciones ESTROFA una referencia expresa a la intercomunicabilidad o interoperabilidad de los sistemas que en el futuro se homologuen como tal. Sin embargo parece claro que el objetivo último de construir un modelo de referencia con una terminología común y unas características básicas similares es conseguir dicha interoperabilidad en un mayor o menor grado. Las futuras versiones de ESTROFA deberán tener muy en cuenta este objetivo último para, en la medida de lo posible, ir introduciendo criterios de interoperabilidad de los distintos sistemas de "Workflow".

Definiciones previas

Competencia.- Condición que define la capacidad de un sujeto para realizar una tarea. Las competencias pueden estar establecidas en un proceso reglamentado o atribuidas en un momento concreto por el sujeto jerárquicamente superior. Puede ser permanente o temporal y puede ser ejercida por delegación.

Datos.- Son los valores que identifican todos los atributos de los procesos y tareas específicos.

Diccionario de tipos.- Repositorios en los que se almacenan para su reutilización los procesos-tipo, las tareas-tipo, los estados, el conjunto de sujetos con sus competencias y las reglas-tipo.

Estados.- Tipos de situación en que puede encontrarse una tarea: ejecutada, en ejecución, en espera, cancelada, etc.

Flujo.- Relación, definida por reglas, entre las tareas de un proceso.

Objetos.- Información asociada a la tarea almacenada en cualquier tipo de soporte -escrito, audio, imagen fija o en movimiento, fichero informático independiente o incluido en una herramienta ofimática, etc.-

Plazo.- Condición que define el tiempo en el que se realiza o debe realizarse una tarea -o un proceso-. Hablaremos de fecha concreta al referirnos a la fecha en que se ha realizado o debe realizarse una tarea. De fecha límite al referirnos a la fecha antes o después de la cual debe realizarse una tarea. De espacio de tiempo al referirnos a un período comprendido entre dos fechas. De fecha recurrente al referirnos a una fecha -primero de mes, lunes de cada semana, etc.- en la que debe realizarse una tarea, bien en dicha fecha o antes o después de ella.

Prioridad.- Escala que establece la preferencia de ejecución de una tarea frente a otras o de un proceso frente a otros.

Proceso.- Conjunto de tareas ordenadas, bien temporalmente, bien cumpliendo condiciones contenidas en reglas, que son realizadas bien por sujetos competentes, bien de forma automatizada (por autorización expresa del sujeto competente). Un proceso puede estar compuesto de uno o varios subprocesos, que a su vez pueden descomponerse en tareas.

Cada una de las ocurrencias de un proceso, se denomina proceso específico (en ocasiones se conoce como expediente, problema o caso).

Proceso abierto o no reglamentado.- Proceso en el que sujetos con competencia o autorizados pueden ordenar tareas, procesos completos predefinidos, asignar reglas e incluso integrar tareas automatizadas, de forma dinámica. Las citadas tareas, procesos y reglas deberán estar catalogadas en los correspondientes diccionarios. Las tareas automatizadas deberán estar disponibles en el sistema y ser lanzadas de forma no automática.

Proceso reglamentado.- Proceso en el que toda la secuencia de tareas o subprocesos, la asignación de reglas y la correspondiente integración de tareas automatizadas tiene un flujograma predeterminado.

Proceso semi-reglamentado.- Proceso reglamentado en el que se prevén excepciones que pueden alterarlo dinámicamente a voluntad de sujetos con competencia o autorizados para ello.

Procesos-tipo.- Procesos reglamentados que pueden ser reutilizados en procesos abiertos o semirreglamentados en la fase de diseño. Deben estar definidos en un diccionario.

Regla.- Conjunto de condiciones que regula el encadenamiento de las tareas.

Reglas-tipo.- Reglas establecidas que pueden ser reutilizadas por los sujetos competentes en la fase de diseño. Deben estar definidas en un diccionario.

Sujeto.- Usuario o grupo