universidad dr. josé matías delgado facultad de economía...
TRANSCRIPT
Universidad Dr. José Matías Delgado Facultad de Economía
Dr. Santiago I. Barberena Carrera Computación
Tesis: Metodología para el análisis y diseño de sistemas
de información para automatizar procesos administrativos internos, utilizando workflow
Presentada por: José Roberto Mendoza Pérez
Nelly Gabriela Hazle Serrano Serrano
Asesor: Lic. Ricardo Nosthas
Antiguo Cuscatlán 06, de diciembre de 2003.
2
Índice
ÍNDICE .................................................................................................................................................................... 1
1 ASPECTOS TEÓRICOS FUNDAMENTALES ......................................................................... 5
1.1 ORIGEN DE LA INFORMACIÓN ........................................................................................................... 5 1.2 CONCEPTO DE INFORMÁTICA ........................................................................................................... 5 1.3 TECNOLOGÍA DE INFORMACIÓN ....................................................................................................... 6 1.3.1 CONCEPTO ........................................................................................................................................... 6 1.3.2 GESTIÓN ............................................................................................................................................... 7 1.3.3 ARQUITECTURA ................................................................................................................................... 8 1.4 SISTEMAS DE INFORMACIÓN ............................................................................................................. 9 1.4.1 CONCEPTO ........................................................................................................................................... 9 1.4.2 TIPOS .................................................................................................................................................... 9 1.4.3 CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN ........................................................................ 13 1.4.3.1 Modelo de cascada ............................................................................................................................ 13 1.4.3.2 Modelo de construcción de prototipos ............................................................................................. 16 1.4.3.3 Modelo evolutivo .............................................................................................................................. 17 1.4.3.4 Modelo de desarrollo rápido de aplicaciones ................................................................................... 19 1.4.3.5 Modelo de métodos formales ........................................................................................................... 20 1.4.4 UML .................................................................................................................................................. 21 1.4.4.1 Concepto ............................................................................................................................................ 21 1.4.4.2 Origen ................................................................................................................................................ 22 1.4.4.3 Utilización ......................................................................................................................................... 22 1.4.4.4 Principales diagramas ....................................................................................................................... 23 1.4.5 ANÁLISIS DE SISTEMAS ...................................................................................................................... 24 1.4.6 DISEÑO DE SISTEMAS ......................................................................................................................... 25 1.5 WORKFLOW Y LA INFORMÁTICA ................................................................................................... 26
2 TECNOLOGÍA DE WORKFLOW ............................................................................................ 28
2.1 ANTECEDENTES ................................................................................................................................ 28 2.2 CONCEPTO DE WORKFLOW............................................................................................................. 29 2.3 BENEFICIOS DE IMPLANTAR WORKFLOW ...................................................................................... 30 2.4 COMPONENTES DE UN WORKFLOW ................................................................................................ 31 2.5 SISTEMAS DE ADMINISTRACIÓN DE WORKFLOW .......................................................................... 33 2.5.1 CONCEPTO ......................................................................................................................................... 33 2.5.2 CARACTERÍSTICAS ............................................................................................................................. 33 2.5.3 MODELO DE REFERENCIA DE WORKFLOW ........................................................................................ 35 2.5.4 EJECUCIÓN DE UN WORKFLOW .......................................................................................................... 36 2.5.4.1 Tratamiento de los procesos ............................................................................................................. 36 2.5.4.2 Tratamiento de la organización ........................................................................................................ 38 2.5.5 TIPOS DE WORKFLOW ........................................................................................................................ 41 2.5.5.1 Según su alcance ............................................................................................................................... 41 2.5.5.2 Según el tipo de proceso o estructura de las tareas .......................................................................... 41 2.5.5.3 Según la tecnología que lo soporta ................................................................................................... 43 2.6 RELACIÓN DE WORKFLOW CON OTRAS TECNOLOGÍAS ............................................................... 44
3
3 ANÁLISIS DE WORKFLOW ..................................................................................................... 47
3.1 FUNDAMENTOS ................................................................................................................................. 47 3.2 METODOLOGÍA ................................................................................................................................ 48 3.2.1 ESTUDIO PRELIMINAR ........................................................................................................................ 49 3.2.1.1 Presentación de la organización ....................................................................................................... 50 3.2.1.2 Descripción del entorno .................................................................................................................... 51 3.2.1.3 Definición de las métricas ................................................................................................................. 53 3.2.2 MODELADO DE PROCESOS ................................................................................................................. 57 3.2.2.1 Selección del método ........................................................................................................................ 57 3.2.2.2 Modelado del proceso actual ............................................................................................................ 60 3.2.2.3 Modelado del proceso meta .............................................................................................................. 61 3.2.3 VALIDACIÓN ...................................................................................................................................... 62 3.2.3.1 Métodos de validación ...................................................................................................................... 63 3.2.3.2 Validación del proceso actual ........................................................................................................... 64 3.2.3.3 Validación del proceso meta ............................................................................................................. 65 3.3 INSTRUMENTOS ................................................................................................................................ 65 3.3.1 DIAGRAMA DE ENTORNO ................................................................................................................... 65 3.3.2 DIAGRAMA DE PROCESO .................................................................................................................... 67 3.4 CASO PRÁCTICO: MODELADO BÁSICO .......................................................................................... 74 3.4.1 PRESENTACIÓN DE LA ORGANIZACIÓN ............................................................................................. 75 3.4.2 DESCRIPCIÓN DEL ENTORNO ............................................................................................................. 77 3.4.3 DEFINICIÓN DE MÉTRICAS ................................................................................................................. 78 3.4.4 DIAGRAMACIÓN DEL PROCESO ......................................................................................................... 78 3.4.5 VALIDACIÓN ...................................................................................................................................... 86 3.5 CASO PRÁCTICO: MODELADO AVANZADO .................................................................................... 86 3.6 CASO PRÁCTICO: VALIDACIÓN AUTOMATIZADA ......................................................................... 93 3.7 PRUEBAS DE CALIDAD ...................................................................................................................... 95 3.8 DOCUMENTACIÓN ............................................................................................................................ 99 3.8.1 ESTUDIO PRELIMINAR ........................................................................................................................ 99 3.8.2 PROCESO ACTUAL ............................................................................................................................ 100 3.8.3 PROCESO META ................................................................................................................................ 102 3.9 LISTA DE VERIFICACIÓN PARA EL ANALISTA .............................................................................. 104 3.10 FACTORES DE ÉXITO PARA EL ANÁLISIS ...................................................................................... 108
4 DISEÑO DEL SISTEMA ............................................................................................................ 110
4.1 FUNDAMENTOS .............................................................................................................................. 110 4.2 METODOLOGÍA .............................................................................................................................. 114 4.2.1 MODELADO DEL FLUJO DE TRABAJO ............................................................................................... 115 4.2.1.1 Patrones de sincronización.............................................................................................................. 117 4.2.1.1.1 Discriminador .................................................................................................................................. 117 4.2.1.1.2 Uniones N-de-M ............................................................................................................................. 121 4.2.1.1.3 Múltiples instancias de una actividad ............................................................................................. 124 4.2.1.2 Patrones basados en estado ............................................................................................................. 127 4.2.1.2.1 Selección diferida ............................................................................................................................ 127 4.2.1.2.2 Encaminamiento paralelo alternado ............................................................................................... 131 4.2.1.3 Patrones productor-consumidor ..................................................................................................... 134 4.2.1.3.1 Productor-consumidor con actividad de terminación .................................................................... 135 4.2.1.3.2 Productor-consumidor con cola saturada ....................................................................................... 139 4.2.2 MODELADO DE LOS ROLES .............................................................................................................. 142 4.2.3 MODELADO DE LAS SALIDAS REUTILIZABLES ................................................................................ 143
4
4.2.3.1 Diagramación de los estados .......................................................................................................... 143 4.2.3.2 Diagramación de las transiciones ................................................................................................... 145 4.2.4 MODELADO DE LOS PROCEDIMIENTOS ............................................................................................ 151 4.3 PRUEBAS DE CALIDAD .................................................................................................................... 155 4.4 DOCUMENTACIÓN .......................................................................................................................... 156 4.5 LISTA DE VERIFICACIÓN PARA EL DISEÑADOR ............................................................................ 159 4.6 FACTORES DE ÉXITO PARA EL DISEÑO ......................................................................................... 160
5 CONSIDERACIONES Y RECOMENDACIONES ............................................................... 163
5.1 INTEGRACIÓN DEL EQUIPO DE ANÁLISIS Y DISEÑO ..................................................................... 163 5.2 UTILIZACIÓN DE HERRAMIENTAS CASE .................................................................................... 166 5.2.1 IBM HOLOSOFX .............................................................................................................................. 166 5.2.2 LOTUS WORKFLOW ......................................................................................................................... 169 5.3 VARIACIONES AL MODELO DE ANÁLISIS Y DISEÑO ..................................................................... 178 5.3.1 BPM ................................................................................................................................................. 178 5.3.2 DIAGRAMA DE ESTADO – ACTIVIDAD (DEA) ................................................................................ 182 5.3.2.1 Concepto .......................................................................................................................................... 182 5.3.2.2 Ejemplo ............................................................................................................................................ 189
GLOSARIO ............................................................................................................................................................. 192
ANEXOS .................................................................................................................................................................. 199
NOTACIÓN BÁSICA DE UML ................................................................................................................................... 199
BIBLIOGRAFÍA .................................................................................................................................................... 213
5
1 Aspectos teóricos fundamentales
1.1 Origen de la información
En el ámbito de la informática, el origen o fuente de la información es el dato ,
representación formalizada de un hechos que puede considerarse en forma
aislada. Aunque de manera aislada portan un significado, generalmente no son
de utilidad por sí solos; Por ejemplo; el número de horas laboradas por cada
empleado de la compañía y los montos que estos devengan por hora.
La información consiste en datos organizados o procesados con el propósito de
generar un significado. Por ejemplo, al multiplicar las horas que cada empleado
trabaja por el sueldo que recibe por hora, se obtienen sus ingresos brutos. La
sumatoria de estos permite obtener el importe total de la nómina de la compañía,
monto que es considerado información por el dueño de la empresa.
1.2 Concepto de informática
Es la ciencia del tratamiento automático y racional de la información considerada
como soporte de los conocimientos y las comunicaciones, en los dominios
técnicos, económicos y sociales. Actualmente, comprende las siguientes áreas:
6
� Algoritmos y estructuras de datos.
� Lenguajes de programación.
� Arquitecturas computacionales.
� Computación numérica y simbólica.
� Ingeniería de software.
� Bases de datos y recuperación de información.
� Inteligencia artificial y robótica.
� Interacción hombre-computadora.
1.3 Tecnología de información
1.3.1 Concepto
Se refiere al uso de componentes orientados a apoyar la construcción y
operación de los sistemas de información, aplicados de manera conjunta con
procesos, métodos y conocimiento que permiten llevar a cabo tareas especificas.
7
Entre los componentes utilizados se encuentran las redes de datos, satélites,
fibra óptica, discos compactos, fax, conmutadores, pasarelas, concentradores,
módems, programas, unidades de almacenamiento de datos, servicios de
mensajería electrónica, tarjetas inteligentes y similares.
1.3.2 Gestión
Garantiza la selección adecuada, despliegue, operación, mantenimiento y
actualización de las tecnologías de información. Se ha convertido en una
actividad estratégica para la organización, ya que determina la interacción de los
usuarios con los activos de información en cuanto a:
Accesibilidad.
Distribución.
Maniobrabilidad.
La accesibilidad especifica quien puede usar la información, desde dónde, con
qué seguridad, por qué interfases y a través de qué medios. Toma en cuenta la
ubicación física de los usuarios y su posición dentro de la cadena de valor de la
organización (proveedor, consumidor, socio estratégico y similares).
La distribución se concentra en definir las formas y estructuras donde se
pondrá a disposición de los usuarios la información (archivos planos, base de
8
datos de texto, bases de datos multimedia, mensajes, bases de datos
descentralizada, entre otras).
La maniobrabilidad define las opciones disponibles para alterar las
configuraciones de equipo y aplicaciones sobre las cuales se mueven los
recursos de información. Aspectos importantes de esta son la portabilidad, la
escalabilidad, la adherencia a estándares y modularidad.
1.3.3 Arquitectura
A la disposición de las tecnologías de información en una organización se le
conoce con el nombre de “arquitectura de tecnologías de información” y puede
comprender:
Componentes físicos (hardware). Corresponde al equipo, medios y
dispositivos periféricos que se usan en un sistema de computadora o redes de
comunicación.
• Programas (software). Es un conjunto de instrucciones, escritas con
ayuda de un lenguaje de programación, que manipula el hardware.
• Soluciones de conectividad (middleware). Es un subconjunto del
software que permite que los usuarios de una aplicación accedan a datos
en otra aplicación, ocultando los componentes subyacentes; es decir, los
9
usuarios y programadores pueden utilizar y desarrollar aplicaciones sin
necesidad de preocuparse por los detalles técnicos del entorno sobre el
que estas se ejecutarán.
1.4 Sistemas de información
1.4.1 Concepto
De acuerdo con la ANSI1, “son aquellos sistemas utilizados para analizar,
controlar o distribuir información, llevando a cabo las funciones de captura,
procesamiento, almacenamiento, transmisión y presentación. El formato de la
información puede incluir palabras impresas, señales análogas y digitales”.
1.4.2 Tipos
Según el nivel organizacional al cual brindan soporte, los sistemas de
información pueden clasificarse en:
• Procesamiento de Transacciones: registran las operaciones rutinarias
del negocio. Brindan velocidad y exactitud; además se pueden programar
para seguir rutinas sin ninguna variación.
A manera de ejemplo, entre estos sistemas se pueden mencionar los
sistemas bancarios de cuentas corrientes, sistemas de administración de
1 American National Standards Institute (Instituto Americano de Estándares Nacionales).
10
inventarios, sistemas de contabilidad financiera, sistemas de
administración de recursos humanos o sistemas de escritorio de servicio.
• Automatización de Oficina: dan soporte a los trabajadores de datos,
quienes, por lo general, no crean un nuevo conocimiento, sino que usan
la información para analizarla y transformar datos, o para manejarla en
alguna forma y luego compartirla o diseminarla formalmente por toda la
organización y, algunas veces, más allá de ella. Estos comprenden
procesadores de palabra, hojas de cálculo, editor de publicaciones,
calendarización electrónica, comunicación mediante correo de voz e
intercambio electrónico de documentos.
• Gestión de Conocimiento: dan soporte a los trabajadores
profesionales, tales como científicos, ingenieros y doctores; les ayudan a
crear un nuevo conocimiento que contribuye a la organización o a toda la
sociedad. Consiguen la información precisa para la persona apropiada
en el instante oportuno, proporcionando herramientas para el análisis de
esa información y la capacidad para responder a las ideas que se obtiene
a partir de esa información.
Entre estos sistemas es posible mencionar los escritorios digitales, los
sistemas de administración de contenidos, las bibliotecas virtuales, las
bases de conocimiento de soporte o los foros de preguntas y respuestas.
11
• Información Gerencial: están al nivel de gestión de las organizaciones,
y apoyan las funciones de planificación y control para proveer informes
de resumen y de excepción; dependen de los datos proporcionados por
los sistemas de procesamiento de transacciones. Estos sistemas son
elaborados ad-hoc para cada empresa.
• Apoyo a las Decisiones: están al nivel de gestión de las
organizaciones, y combinan datos y modelos analíticos sofisticados para
apoyar el proceso de decisión.
Son distintos a los sistemas de información gerencial, que se concentran
en proporcionar a los gerentes información especificada con anterioridad
y que puede utilizarse para tipos de decisiones estructuradas.
• Información Ejecutiva: son sistemas de información gerencial
adaptados a las necesidades estratégicas de información de la alta
gerencia. Los ejecutivos obtienen la información que necesitan de
muchas fuentes, incluidas cartas, memorandos, publicaciones periódicas
e informes generados manualmente, y también mediante sistemas
computacionales. Otras fuentes de información ejecutivas son las
reuniones las llamadas telefónicas y las actividades sociales.
12
Su meta consiste en proporcionar a la alta gerencia un acceso inmediato
y fácil a información selectiva sobre factores clave que son fundamentales
para el logro de los objetivos estratégicos de una empresa.
• Colaboración o Trabajo en Grupo: dan soporte a las personas que
trabajan juntas en la organización. Aprovecha la sinergia potencial y el
poder disponible a través de las computadoras en red. Pueden ayudar a
los miembros del grupo a calendarizar y asistir a reuniones, compartir
datos, crear y analizar documentos, comunicarse en formas no
estructuradas con otros por medio de correo electrónico, realizar
conferencias en grupo, hacer administración de imagen a nivel
departamental y manejar y monitorear el flujo de trabajo.
• Inteligencia Artificial o Expertos: usan los enfoques del razonamiento
de la inteligencia artificial para resolver los problemas que les planteen
los usuarios de negocios. Captura en forma efectiva el conocimiento de
un experto y lo usa para resolver un problema particular experimentado
en una organización.
Son utilizados en muchos campos, incluyendo medicina, ingeniería, las
ciencias físicas y la empresa. Entre algunos de los más utilizados se
encuentran los sistemas de manufactura CAD CAM, los sistemas de
minería de datos o los sistemas médicos de diagnostico digital.
13
1.4.3 Ciclo de vida de los sistemas de información
El ciclo de vida del desarrollo de sistemas (CVDS2) es un proceso por el cual los
analistas de sistemas, los ingenieros de software, los programadores y los
usuarios finales elaboran sistemas de información y aplicaciones informáticas. Es
una herramienta de gestión de proyectos que planea, ejecuta y controla los
proyectos de desarrollo de sistemas.
Muchos son los modelos que se han propuesto en el tiempo para estructurar las
etapas del ciclo de vida de un sistema. Entre los más conocidos están:
• Modelo de cascada.
• Modelo de construcción de prototipos.
• Modelos evolutivos.
• Modelo de desarrollo rápido de aplicaciones.
• Modelo de métodos formales.
1.4.3.1 Modelo de cascada
Es el más básico de todos los modelos de ciclo de vida y sirve de base para
otros modelos. Fue originalmente documentado por Winston Royce en el año
1970. Ve el desarrollo de un sistema como una secuencia simple de fases en
2 Del ingles, “software life cycle –SWLC”.
14
donde cada fase tiene un conjunto de objetivos bien definidos y crea un resultado
que sirve como insumo para la siguiente fase (ver Figura 1.1). Si dicho resultado
es rechazado, la fase completa debe repetirse.
Figura 1.1: Productos e insumos de las fases en un ciclo de vida de cascada3
El diagrama inicial propuesto con el modelo es mostrado en la Figura 1.2:
3 Desarrollo y gestión de Proyectos Informaticos, Steve McConnell, Microsoft Press, McGraw-Hill, primera edición, 1996.
Documentosy productosde entrada
Documentosy productosde entrada
Documentosy productosde salida
Documentosy productosde salida
Tareas propiasde cada fase
Validación del trabajo
Replanificación y/oretroalimentación
Tareas propiasde cada fase
Validación del trabajo
Replanificación y/oretroalimentación
Procedende de lafase anterior A la fase posterior
Experienciaacumulada
15
Figura 1.2: Ciclo de vida de cascada4
Aunque el modelo es fácil de entender presenta los siguientes inconvenientes:
• El cambio de requerimientos durante el desarrollo de un sistema es difícil de
manejar, pues el modelo no provee mecanismos que permitan retroceder a
fases anteriores.
• El usuario tiene la posibilidad de involucrarse únicamente durante la
especificación de requerimiento, una de las fases mas tempranas del modelo.
• Debido al enfoque secuencial, la concurrencia de actividades no es soportada,
ocasionando que se extienda la duración de los proyectos.
• No proporciona resultados tangibles en forma de aplicación (software) hasta el
final del ciclo de vida. Será hasta el final del ciclo que el usuario podrá
comprobar si alguno de los requerimientos no esta o ha sido incorrecto.
4 Desarrollo y gestión de Proyectos Informaticos, Steve McConnell, Microsoft Press, McGraw-Hill, primera edición, 1996.
16
1.4.3.2 Modelo de construcción de prototipos
El objetivo del modelo es realizar un sistema provisorio con el conjunto inicial de
necesidades para implantarlas rápidamente con la intención de ir
expandiéndolas y refinándolas gradualmente, al ir comprendiendo el sistema el
usuario y quien lo desarrolla. Es un proceso que cuenta con tres actividades bien
definidas (ver Figura 1.3), al final de las cuales el usuario deberá evaluar el
producto para decidir si es necesaria someterlo a una nueva iteración, con el
objetivo de obtener un producto con funcionalidad adicional.
Figura 1.3: Modelo de ciclo de vida de prototipos5
Resulta útil cuando los requerimientos cambian con rapidez, cuando el cliente no
tiene la capacidad de brindar las especificaciones completas del producto que
espera recibir, cuando no se tiene claro el alcance de la aplicación o cuando los
desarrolladores no están seguros de la arquitectura o los algoritmos adecuados a
utilizar. Estas situaciones podrían hacer que el riesgo de un proyecto se
5 Desarrollo y gestión de Proyectos Informaticos, Steve McConnell, Microsoft Press, McGraw-Hill, primera edición, 1996.
Toma derequerimientosElaboración y
revisión delprototipo
Prueba de prototipo
Toma derequerimientosElaboración y
revisión delprototipo
Prueba de prototipo
17
incremente lo suficiente como para desistir de la idea de llevarlo a cabo. Si se
divide un proyecto de alto riesgo en un conjunto de proyectos de menor alcance,
el usuario tendrá la oportunidad de reducir los riesgos y analizarlos únicamente al
inicio de un nuevo proceso de prototipado.
1.4.3.3 Modelo evolutivo
Este modelo se considera una combinación del ciclo de vida en cascada y el
ciclo de vida de prototipos, con un énfasis particular en el manejo del riesgo. Fue
propuesto inicialmente con el nombre de espiral, en el año de 1986. Este nombre
fue utilizado posteriormente por la IEEE6, en 1988.
En este modelo, el sistema no debe definirse completamente al inicio. Los
desarrolladores deberán definir únicamente las características de más alta
prioridad. Estas se implantarán y presentarán a los usuarios para obtener
retroalimentación. Con el conocimiento adquirido del usuario, se reinicia el
proceso de definir e implantar más características.
El diagrama propuesto para el modelo se muestra en la figura 1.4:
6 Institute of Electrical and Electronics Engineers, Inc.
18
Figura 1.4: Modelo de ciclo de vida evolutivo.7
Las actividades numeradas en el diagrama son las siguientes:
• Análisis de riesgos.
• Diversos prototipos.
• Simulación y modelos.
• Concepto de operación.
• Requerimientos de software.
• Diseño, validación y verificación de software.
7 Desarrollo y gestión de Proyectos Informaticos, Steve McConnell, Microsoft Press, McGraw-Hill, primera edición, 1996.
19
• Detalles de diseño.
• Implantación del código.
• Diversas pruebas.
• Planeación.
1.4.3.4 Modelo de desarrollo rápido de aplicaciones
Es un enfoque que ha sido diseñado para acelerar el desarrollo de sistemas de
información, con una calidad superior a los resultados que es posible esperar
con los modelos tradicionales.
Se basa en el reconocimiento de que los sistemas de información del negocio
involucran la actividad humana, lo que hace que los procesos de desarrollo sean
menos predecibles que lo esperado.
Existen cuatro grandes principios inherentes al enfoque:
• Incrementar la velocidad del desarrollo de sistemas, utilizando herramientas y
técnicas adecuadas para la organización del negocio y su entorno competitivo.
• Utilizar un enfoque de prototipos iterativo para el desarrollo de sistemas.
20
• Concentrar el énfasis en la participación de los usuarios durante todo el proceso
de desarrollo, a través de sesiones de trabajo y talleres estructurados.
• Utilizar un número herramientas y técnicas conocidas, traslapadas para formar
el entorno de recursos.
Las fases documentadas para este modelo son:
• Planeamiento de requerimientos
• Diseño del sistema
• Construcción
• Implantación
1.4.3.5 Modelo de métodos formales
Consiste de técnicas matemáticas para describir propiedades de un sistema e
incluye una notación precisa para la construcción de modelos de un sistema, la
cual se utiliza para especificar el sistema requerido y es concerniente a "lo que"
es hecho por un sistema no tanto "cómo" es hecho.
21
1.4.4 UML8
1.4.4.1 Concepto
Es un lenguaje visual estándar de la industria, de propósito general, con un
ámbito amplio de aplicación y soportado por un número importante de
herramientas en el mercado.
Permite modelar sistemas y comunicarlos, a través de diagramas e información
textual. Como lenguaje, brinda un medio para especificar, visualizar, construir y
documentar los componentes de un sistema. La especificación se refiere a la
concepción de un modelo, la visualización a la creación de diagramas, la
construcción al uso de las descripciones visuales para desarrollar el sistema y la
documentación a los modelos y diagramas para capturar el conocimiento del
sistema durante un ciclo de desarrollo.
La palabra Modeling enfatiza la capacidad que brinda el lenguaje para generar
modelos. De acuerdo con la OMG (Object Management Group), “un modelo
captura un conjunto de ideas acerca de un área de tema, las cuales son
conocidas como abstracciones”. La palabra Unified se debe a la estandarización
del lenguaje.
8 Unified Modeling Language.
22
1.4.4.2 Origen
UML se deriva de tres metodologías de desarrollo orientadas a objetos:
Booch ’93. Método propuesto por Grady Booch en 1991, enfocado en el diseño
y construcción de software.
OMT (Object Modeling Technique9). Método propuesto por James Rumbaugh,
enfocado en el análisis de sistemas.
OOSE (Object-Oriented Software Engineering10). Método propuesto por Ivan
Jacobson, enfocado en la ingeniería de negocios y análisis de requerimientos.
La especificación UML 1.0 surge a mediados de los 90’s, bajo la responsabilidad
de la OMG. La revisión actual del estándar ha sido denominada UML 2.0.
1.4.4.3 Utilización
UML es independiente del proceso de desarrollo. Por esta razón, es posible
utilizarlo tanto para sistemas que se desarrollan con un ciclo de vida de cascada
u otros modelos más sofisticados. Los autores del lenguaje proponen su uso en
los ciclos de vida iterativos e incrementales. A diferencia de otras metodologías
(DFD, OMT y similares), proporciona herramientas para una tarea previa al
9 Técnica para el modelado de objetos. 10 Ingeniería de aplicaciones orientada a aplicaciones.
23
desarrollo de un sistema: la toma de requerimientos, también conocido como el
proceso de “levantamiento11 de requerimientos”. Adicionalmente, cuenta con
herramientas que pueden utilizarse para el análisis, diseño, implantación y
prueba.
1.4.4.4 Principales diagramas
UML esta compuesto por diferentes elementos gráficos que se combinan para
conformar diagramas. Su finalidad es presentar diversas perspectivas de un
sistema, a las cuales se les conoce como modelo. Los diagramas más utilizados
son:
Clases.
Objetos.
Casos de uso.
Estados.
Secuencias.
Actividades.
Colaboraciones.
Componentes.
11 Del inglés elicitation, que quiere decir “recolectar”.
24
Distribución.
Es importante mencionar que en un modelo UML de un sistema no es necesario
que aparezcan todos los diagramas.
La metodología de diseño propuesta en este trabajo se basa en el uso de
herramientas UML. La literatura oficial del lenguaje puede ser consultada en
www.omg.org; sin embargo, como material de apoyo para quienes no han tenido
contacto previo con los diagramas utilizados, se ha incluido una introducción en
el Anexo A: “Notación básica de UML”.
1.4.5 Análisis de sistemas
El aspecto fundamental de esta fase del ciclo de vida de un sistema de
información es comprender todas las facetas importantes del proceso de la
empresa que se encuentra bajo estudio. Describe lo que un sistema debería
hacer para satisfacer las necesidades de información de los usuarios. Los
responsables de su ejecución trabajan con los usuarios para dar respuesta a
preguntas clave, tales como:
¿Qué es lo que se hace?
¿Cómo se hace?
¿Con qué frecuencia?
25
¿Qué tan grande es el volumen de transacciones?
¿Qué decisiones se toman en el proceso?
¿Cuál es el grado de eficiencia con que se efectúan las tareas?
¿Existe algún problema, qué tan serio es y qué lo origina?
El resultado del análisis de esta fase es un documento conocido como la
“especificación formal del sistema” y es un insumo para las actividades de
diseño.
1.4.6 Diseño de sistemas
Produce los detalles técnicos que establecen la forma en la que el sistema
cumplirá con el modelo identificado durante la fase de análisis. Da como
resultado especificaciones de:
Interfaz de usuario. Se centra en las interacciones entre los usuarios y las
aplicaciones, para garantizar la creación de entradas y salidas. No forma parte
del dominio de una solución de workflow.
Estructuras de almacenamiento. Consiste en el modelado de bases de datos y
archivos utilizados por el sistema. Workflow no restringe este aspecto en el
diseño de un sistema.
26
Algoritmos de procesamiento y control. Define los pasos a seguir para procesar
los datos de un sistema y generar la información requerida por los usuarios.
Constituyen el área principal de interés de un sistema workflow. Actualmente, se
clasifican en tres distintos grupos:
Servicios de usuario. Requeridos para el diseño de los procesos que se
comunican con las interfaces de captura o presentación de información.
Servicios de aplicación. Establecen las reglas empresariales, transforman
información y administran transacciones.
Servicios de datos. Definen la interacción con los repositorios de
almacenamiento.
1.5 Workflow y la informática
Antes de iniciar la exposición de workflow, en el siguiente capitulo, es importante
comprender que:
Es una tecnología de información, aplicable en el área de la ingeniería de
software, para la construcción de sistemas de colaboración.
Suele encontrarse inmerso en modelos de procesos de negocio elaborados por
un analista, integrando componentes de un sistema.
27
La utilización de workflow es independiente de los ciclos de vida de sistemas.
Sin embargo, la utilización de UML para la fase de diseño hace adecuado el uso
de un modelo iterativo, ya sea el de prototipos o el evolutivo.
28
2 Tecnología de workflow
2.1 Antecedentes
Hace más de dos décadas, las aplicaciones eran altamente dependientes de la
organización de los datos en un disco. Un cambio en las estructuras de
almacenamiento obligaba a actualizar el código de los programas afectados.
Para superar esta dependencia, surgieron los sistemas de gestión de base de
datos.
De igual manera, muchas aplicaciones en las empresas no permiten la fácil
modificación de los procesos, pues se encuentran inmersos en el código
programado. Por esta razón, un cambio en la forma de operar del negocio
conlleva un mantenimiento a los programas existentes.
El uso de la tecnología de workflow hace posible que la tarea de distribuir el
trabajo sea desmembrada de los programas, dando como resultado aplicaciones
más flexibles y menos vulnerables a los cambios del negocio. Una aplicación
independiente de los procesos consiste de una definición del flujo del trabajo y un
conjunto de programas que proveen los servicios de usuario y datos.
29
2.2 Concepto de workflow
En 1993, con la misión de promover y desarrollar el uso de workflow a través del
establecimiento de estándares para la terminología de los sistemas,
interoperabilidad y conectividad, se fundó la Coalición de Administración de
Workflow (Workflow Management Coalition). Actualmente está integrada por
más de doscientos ochenta y cinco miembros12, distribuidos en todo el mundo.
La Coalición se ha convertido rápidamente en un cuerpo primario para
estándares del mercado creciente de sistemas de workflow. Comercialmente, es
conocida por el acrónimo WfMC. Sus investigaciones y estándares son
publicados periódicamente en un manual de trabajo conocido como “Workflow
Handbook” (Manual de Workflow).
La WfMC define workflow como ”la automatización de un proceso de negocios,
durante el cual se trasladan documentos, información o tareas de un participante
a otro a la espera que se realicé una actividad, de acuerdo a un conjunto de
reglas.”
Los participantes pueden ser personas, que interactúan a través de estaciones
de trabajo, u otros sistemas, a través redes de comunicación.
12 Entre los miembros se encuentran empresas de renombre, tales como: BEA Systems, Fujitsu Software Corporation, Hitachi Ltd Software División, IBM, Lucent Technologies, Microsoft Corporation, Oracle, SAP AG, Sun Microsystems y Toshiba Corp como miembros completos. Como miembros asociados y académicos se encuentran empresas como: ACER Softech (Shanghai) Inc., Andersen Consulting, ATI Technologies Inc., Corel, Gartner Group, Intel Corporation, J D Edwards & Company, KPMG Consulting Inc., Object Management Group (OMG), PricewaterhouseCoopers LLP, Unisys Corporation y Versata.
30
Aunque el workflow podría estar organizado manualmente, la WfMC aclara que
su definición debe ser considerada en el contexto de un sistema de información
computarizado.
2.3 Beneficios de implantar workflow
Para determinar los principales beneficios de implantar la tecnología workflow, la
WfMC lleva a cabo investigaciones periódicas, en las que participan usuarios y
proveedores de soluciones tal como aparecen publicadas en el portal de
workflow patrocinado por la coalición13 estos son:
Incremento de la eficiencia. La automatización de varios procesos de negocios
resulta en la eliminación de pasos innecesarios.
Mejor control de los procesos. La administración de los procesos de negocio se
facilita a través de la estandarización de los métodos de trabajo y la
disponibilidad de pistas de auditoria.
Mejora en el servicio al cliente. La consistencia en los procesos conlleva una
mayor capacidad de predicción en los niveles de respuesta.
Flexibilidad. Se posibilita el rediseño de los procesos sobre la marcha, a medida
que cambian las necesidades del negocio.
13 Los beneficios han sido transcritos directamente de www.e-workflow.org
31
Mejores procesos de negocio. Se fomenta la agilidad y simplicidad de estos.
2.4 Componentes de un workflow
Un workflow esta integrado por:
• Procesos de negocio. Es un conjunto de uno o más procedimientos o
actividades enlazadas, que permiten alcanzar un objetivo de negocio.
Puede estar contenido dentro de una sola unidad organizacional o puede
recorrer diferentes organizaciones, como seria el caso de la relación
cliente-proveedor.
Durante su modelación es necesario definir las condiciones que lo
iniciaran y las salidas que entregará al finalizar. Su duración es variable y
las actividades pueden ser automatizadas o manuales, encontrándose
estas últimas fuera del alcance de la administración de workflow.
Para referirse a la modelación, la WfMC sugiere el termino “Definición del
Proceso”, la cual consiste en un conjunto de actividades, relaciones,
criterios de inicio y fin e información propia de cada actividad.
• Información. Contenido que es trasladado por el sistema de workflow.
Esta se compone de datos que pueden clasificarse como:
32
o Datos de control. Son administrados por el sistema de
workflow y utilizados para identificar los estados de los
procesos, actividades o cualquier otro recurso del sistema.
o Datos relevantes al flujo. Son utilizados para determinar las
condiciones de transición entre las distintas actividades. Estos
se encuentran accesibles para el sistema de administración
del flujo de trabajo.
o Datos aplicativos. Estos no se encuentran accesibles para el
sistema de administración de flujo de trabajo, pues son
específicos de la aplicación y son relevantes únicamente para
el desarrollo de las actividades del usuario o de los procesos
aplicativos.
• Organización. Como parte de la definición del flujo de trabajo, los
procesos establecen qué personas llevan a cabo las tareas individuales,
describiendo sus relaciones, las funciones que desempeñan y los roles
que pueden asumir. Esta información incluye aspectos normativos, tales
como políticas, reglas del negocio y calendarios de trabajo.
Un modelo organizativo representa la estructura de la empresa en
términos de empleados, puestos, unidades, funciones y autoridades. Las
33
unidades son un conjunto de puestos con tareas comunes o relacionadas,
entre las cuales puede existir una relación jerárquica.
2.5 Sistemas de administración de workflow
2.5.1 Concepto
Al sistema que define, crea y administra la ejecución de un workflow a través
del uso de software se le llama Workflow Management System (WfMS
Sistema de Administración de Workflow). Es aquí donde se interpretan los
procesos definidos para convertirlos en unidades de software que se ejecutan
en memoria, coordinando la interacción de los participantes y la invocación
de los recursos disponibles en el entorno.
2.5.2 Características
Independientemente del tipo de sistema que se trate, todos los WfMS exhiben
características comunes que brindan la base de integración e interoperabilidad
con el entorno existente, el cual se explicará más adelante con ayuda del Modelo
de Referencia propuesto por la WfMC.
Desde una perspectiva de alto nivel, todos los WfMS deben soportar tres áreas
funcionales:
34
Funciones de tiempo de construcción. Relacionadas con la definición y
modelado del proceso de workflow y las actividades constituyentes.
Funciones de tiempo de ejecución. Se dividen en dos grandes grupos:
Instanciación y control. Relacionadas con la administración de un workflow en
un entorno operativo, coordinando la secuenciación de las diversas actividades
que han sido definidas como parte de cada proceso.
Interacción. Relacionadas con las interacciones de los usuarios y las
aplicaciones existentes, necesarias para procesar los distintos pasos del flujo de
trabajo.
Las tareas de instanciación y control están a cargo de un módulo de software
llamado “servicio de promulgación de workflow” (workflow enactment service,
WES), diseñado para dar soporte a la ejecución de procesos, a través de uno o
más componentes internos llamados “motores de workflow”, y mantener el
control de los datos centralizado o distribuido en diversos WfMS, incluyendo
información útil para recuperarse ante la presencia de condiciones de falla.
35
Las áreas funcionales anteriores pueden representarse con ayuda de la Figura
2.1:
Figura 2.1: Características de un sistema de workflow.14
2.5.3 Modelo de referencia de workflow
Es la denominación utilizada por la WfMC para el entorno completo de un WfMS.
Su objetivo es identificar los componentes e interfaces existentes en un entorno
de aplicación de workflow.
Las interfaces hacia los componentes externos son implantadas con ayuda de la
WAPI (Workflow API), que consiste en un conjunto de funciones a través de las
cuales los servicios de un sistema de workflow pueden ser accesados y tiene por
14 Workflow Handbook 2001, John Wiley & Sons LTD with the Workflow Management Coalition, 2001.
Tiempo deconstrucción
Tiempo deejecución
Definición delproceso
Análisis de Proceso de Negocio,Modelado y Herramientas de Definición
Definición y diseñodel proceso
Servicio de promulgacióndel workflow
Instanciacióny controldel proceso
Interaccióncon usuarios yaplicaciones
Aplicacionesy herramientas
Cambios alproceso
Tiempo deconstrucción
Tiempo deejecución
Definición delproceso
Análisis de Proceso de Negocio,Modelado y Herramientas de Definición
Definición y diseñodel proceso
Servicio de promulgacióndel workflow
Instanciacióny controldel proceso
Interaccióncon usuarios yaplicaciones
Aplicacionesy herramientas
Cambios alproceso
36
objetivo permitir que las aplicaciones de workflow puedan comunicarse o
adaptarse a diferentes WfMS, de manera estandarizada. Aunque la WfMC la
define utilizando el lenguaje de programación C, no se hace ninguna asunción
respecto a la implantación de las funciones con ayuda de un lenguake en
particular.
El modelo de referencia puede representarse con ayuda de la Figura 2.2:
Figura 2.2: Modelo de referencia de workflow – componentes e interfaces.15
2.5.4 Ejecución de un workflow
2.5.4.1 Tratamiento de los procesos
Pueden ejecutarse muchas veces, en diferentes momentos o de manera
simultanea. A cada caso se le conoce con el nombre de instancia de
15 Workflow Handbook 2001, John Wiley & Sons LTD with the Workflow Management Coalition, 2001.
Interface 5
Interface 4
Interface 3Interface 2
Interface 1
Workflow Enactment Services
Process Defination Tools
Workflow API and Interchage formats
Workflow Engine(s)
Administration & Monitoring tools
Workflow Engine(s)
Invoked Applications
Workflow Client Applications
Process Defination Tools
Interface 5
Interface 4
Interface 3Interface 2
Interface 1
Workflow Enactment Services
Process Defination Tools
Workflow API and Interchage formats
Workflow Engine(s)
Administration & Monitoring tools
Workflow Engine(s)
Invoked Applications
Workflow Client Applications
Process Defination Tools
37
proceso , la cual, a la vez, está compuesta por instancias de actividades ,
cada una independiente a efecto de control y auditoria, exhibiendo cualquiera
de los siguientes estados:
Activa. Ha sido asignada a un participante para que este realice el trabajo
especificado.
Inactiva. La instancia de la actividad ha sido creada pero no cuenta con trabajo
asociado.
Suspendida. No existe trabajo en progreso y este se reanudará hasta que se
cumplan las condiciones indicadas en la definición de la actividad. Es posible que
algunas actividades se les restringa este estado.
Terminada. El participante ha desarrollado todo el trabajo asociado con la
actividad.
La ejecución, da lugar al concepto de trabajo , que es el aporte de los
usuarios a un proceso ejecutándose en el negocio. Una actividad puede
generar una o más unidades de trabajo y juntas constituyen la
responsabilidad asumida por el usuario cuando se le asigna. Los elementos
de trabajo son presentados a los participantes por medio de una lista, que
ayuda a controlar su progreso y estado.
38
Figura 2.3: Diferencia entre “proceso” y “trabajo”. 16
2.5.4.2 Tratamiento de la organización
La comunicación y cooperación entre los empleados de una empresa se
basa en reglas organizativas que un sistema de administración de workflow
debe ser capaz de entender y seguir.
Los empleados participan como individuos, unidades organizativas, equipos
de trabajo o roles. Los grupos de trabajo son mucho más flexibles que las
unidades organizativas, ya que una persona puede formar parte de más de
uno a la vez, mientras que solamente puede pertenecer a un departamento.
A los distintos participantes se les llama “actores”.
16 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
39
La organización es una estructura dinámica. Los empleados cambian
continuamente y, por consiguiente, los integrantes de los grupos de trabajo y
las unidades. Un workflow debe ser capaz de responder a esta realidad y
evitar que un cambio en el modelo organizativo conlleve su reconstrucción.
A quien asume la responsabilidad de llevar a cabo una actividad se le
denomina “propietario de la actividad” y puede estar relacionado con
múltiples actividades.
Para evitar las dependencias entre procesos y actores, la asociación puede
establecerse a través del concepto rol , un “contenedor” cuyo propósito es
brindar una abstracción para el actor y que especifica un conjunto de
candidatos como ejecutores potenciales, que pueden llevar a cabo el trabajo
asociado con una actividad.
Toda instancia de una actividad tiene que estar asignada a un actor,
utilizando una estrategia activa o pasiva, según se requiera.
La estrategia activa permite que el WfMS seleccione uno de los posibles
candidatos y le coloque el trabajo en su lista, notificándole automáticamente
justo después de la asignación.
40
En la estrategia pasiva, el WfMS añade el elemento de trabajo a una lista
compartida, accesible por todos los posibles candidatos. Uno de estos
escogerá, eventualmente, la actividad. Los roles se utilizan como un distintivo
que el usuario toma para realizar el trabajo (ver Figura 2.4).
Figura 2.4: Estrategia de asignación pasiva.17
Más allá del “propietario de la actividad” existe el “propietario del trabajo”,
que consiste en una persona o grupo de personas que tienen el control
general sobre la ejecución de un proceso. Mientras las instancias en
ejecución no encuentran problemas, es probable que no se involucre; sin
embargo, cuando surgen errores o comportamientos no previstos, debe
intervenir para brindar una solución. La autoridad que posee es la suficiente
como para reasignar actividades, cambiar el flujo del proceso o modificar los
elementos que ocasionan el problema. Esto último implica este debe tener
un conocimiento detallado del proceso, aunque no sea responsable de
17 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
41
ejecutar sus actividades día a día. Normalmente, por las decisiones y
funciones que realiza, el propietario puede ser el gerente de la unidad
organizativa o el empleado involucrado con mayor experiencia.
2.5.5 Tipos de workflow
2.5.5.1 Según su alcance
De acuerdo con su alcance o ámbito de soporte, las aplicaciones administradas
por un WfMS pueden clasificarse en:
Intra-organizacional. Cuando las actividades de los procesos se realizan por
entidades internas a la organización.
Inter-organizacional. Cuando las actividades de los procesos involucran
interacciones con entidades externas a la organización.
2.5.5.2 Según el tipo de proceso o estructura de las tareas
Aunque existen muchos parámetros que pueden considerarse, esta clasificación
busca similitudes en los procesos de negocios, tomando como criterios las
relaciones entre la complejidad de las tareas y su estructura, así como la relación
entre el valor de las tareas para el negocio y sus patrones de ejecución (tareas
excepcionales o repetitivas).
42
Al aplicar las relaciones anteriores, los tipos de workflow pueden agruparse en
las siguientes categorías:
Workflow administrativo. Se refiere a procesos con patrones llamados
burocráticos, en los cuales los pasos a seguir se encuentran claramente
establecidos y existe un conjunto de reglas conocidas por los participantes.
Workflow ad-hoc. Es similar al administrativo, excepto que son creados para
manejar excepciones o situaciones únicas.
Workflow colaborativo. Se caracteriza principalmente por el número de
participantes involucrados y la interacción entre ellos. A diferencia de otros tipos
de workflow, que se basan en la premisa de que siempre existe un progreso, un
workflow colaborativo puede involucrar múltiples iteraciones en un mismo paso
hasta que se haya alcanzado un acuerdo. Si dicho acuerdo no es posible, un
workflow colaborativo podría incluso permitir el retorno a etapas previas.
Workflow de producción. Es el workflow de más alto nivel. Puede
caracterizarse como la implantación de un proceso crítico del negocio, es decir,
aquellos relacionados directamente con la misión de la empresa. Al implantar un
workflow de producción deberán considerarse entornos de ejecución
heterogéneos, complejos y de gran escala.
43
2.5.5.3 Según la tecnología que lo soporta
Otra clasificación encontrada frecuentemente en la literatura de workflow es la
relacionada con la tecnología que soporta su implantación, distinguiendo entre
las siguientes categorías:
• Basado en mensajes. Utilizan principalmente las herramientas de
correo electrónico y se encuentran estrechamente asociados con el
workflow colaborativo y el ad-hoc. Este tipo de workflow no es
recomendado para workflow de producción o en entornos donde existan
grandes cantidades de procesos.
• Basado en documentos. Utilizan el concepto de trasladar documentos
por diversas rutas y son adecuados para las soluciones de workflow
administrativo que se apoyan principalmente en formularios. Su habilidad
para interactuar con otras aplicaciones es limitada.
• Basado en procesos. Generalmente implantan sus propios
mecanismos de comunicación, se construyen sobre las bases de datos y
proporcionan una amplia variedad de interfaces que permiten la
interacción tanto con los sistemas heredados como con los nuevos. Este
tipo de workflow es utilizado por los modelos de producción.
44
2.6 Relación de workflow con otras tecnologías
Las tecnologías que se relacionan con un sistema de workflow son cambiantes,
pues básicamente todas aquellas que promuevan la cooperación de usuarios e
integración de recursos de información, son candidatas a integrarse a un
workflow. Una clasificación de las tecnologías disponibles podría incluir las
siguientes categorías:
Ingeniería de procesos y automatización. Las aplicaciones basadas en
workflow, no son creadas mejorando las aplicaciones existentes. Son el
resultado de un reingeniería de negocios, “la revisión y rediseño radical de los
procesos del negocio, para alcanzar mejoras dramáticas en los parámetros
actuales de rendimiento, tales como costo, calidad, servicio y rapidez”. El
resultado de una reingeniería de negocios es un proceso documentado de
manera adecuada, el cual puede implantarse posteriormente, utilizando un
sistema de administración de workflow (WfMS).
Administradores de transacciones. La mayor parte de sistemas de workflow
integran aplicaciones disponibles en un entorno distribuido. Esto implica el uso
de un programa que tenga la capacidad de dar seguimiento a las actividades de
una transacción para garantizar la integridad de la información.
45
Bases de datos. Normalmente, los componentes de un workflow son descritos
por información almacenada en bases de datos.
Sistemas de administración de redes. Conocidos como NMS (Network
Management Systems). Aplicaciones que permiten dar seguimiento a los
recursos distribuidos en una red, para garantizar la disponibilidad y adecuado
consumo de recursos. Otros elementos que pueden controlarse son la seguridad
y la acumulación de estadísticas.
Desarrollo de aplicaciones. Lo más común es que las empresas utilicen
métodos formales para el análisis y diseño, recurriendo a las tecnologías CASE
disponibles para workflow.
Computación móvil. La implantación de un sistema de workflow conlleva un
incremento en la eficiencia de distribución de información e interfaces de captura
de datos. El uso de equipos móviles, tales como computadoras de mano,
computadoras portátiles, teléfonos celulares, agendas, y similares.
Internet. Ya sea que se trate de un sistema de workflow disponible únicamente
para los empleados de una organización o de un sistema abierto a proveedores
y clientes, Internet se convierte en una herramienta para integrar equipos de
trabajo distribuidos geográficamente.
46
Middleware de integración. Responsable de permitir que dos aplicaciones
distintas se comuniquen entre sí, ya sea de manera sincrónica o asincrónica.
Administración de documentos. Los sistemas de administración de
documentos son generalmente un producto que acompaña las soluciones de
workflow. Un sistema de administración de documentos brinda acceso
controlado y transparente a la documentación de la organización, incluyendo
distintos formatos, tales como: imágenes, archivos de procesadores de palabra,
gráficos, hipertextos, formularios electrónicos, correos electrónicos, archivos de
video y archivos de audio. La administración misma de los documentos puede
someterse a un workflow, automatizando el ciclo de vida de estos: creación,
edición, revisión, publicación y archivado.
Administración de proyectos. Estas herramientas son normalmente utilizadas
para controlar tiempos, costos y entregas. Utilizando las herramientas de
proyección propias de un sistema de administración de proyectos, los gerentes
de proyectos podrán realizar pronósticos respecto a la manera en que
evolucionarán los plazos y presupuestos de un proyecto, según las tendencias
mostradas por el flujo de proyecto establecido para realizar las tareas del plan de
proyecto.
47
AnálisisAnálisis
DiseñoDiseño
AdministraciónAdministración
AutomatizaciónAutomatización
3 Análisis de workflow
3.1 Fundamentos
En un sistema basado en workflow, el análisis es la primera fase del ciclo de
vida, el cual se encuentra estructurado en cuatro grandes fases, representadas
con la ayuda de la Figura 3.1:
Figura 3.1: Modelo de ciclo de vida de workflow
El análisis y el diseño son el objeto de estudio del presente trabajo. La
automatización consiste en convertir el proceso diseñado a una aplicación, la
cual podrá crearse a partir de cero o para integrar los aplicativos existentes a
alguna herramienta de administración de workflow. La administración consiste en
el monitoreo continuo del flujo de trabajo automatizado, para capturar
estadísticas en tiempo real y realizar modificaciones que le permitan adaptarse a
nuevos requerimientos de la organización.
1
2
3
4
48
3.2 Metodología
La metodología de análisis propuesta en este trabajo puede representarse con
ayuda del siguiente diagrama:
Figura 3.2: Fases para la conducción del análisis
Las actividades listadas en cada fase pueden utilizarse como guía para el trabajo
a realizar. El detalle de cada una de ellas se expone en las siguientes secciones.
El estudio preliminar se presenta en el orden sugerido en la Figura 3.2; sin
embargo, para los procesos actual y meta se ha seguido un esquema de
presentación diferente, ya que tienen actividades en común, basadas en los
mismos procedimientos aunque con objetivos diferentes. Los temas se
desarrollan de acuerdo con el siguiente esquema:
Estudio preliminar
Presentación de la organización
Descripción del entorno
Definición de métricas
Estudio preliminar- Presentación dela organización
- Descripción delentorno
- Definición delas métricas
Procesoactual- Modelado- Validación
Procesometa- Modelado- Validación
Estudio preliminar- Presentación dela organización
- Descripción delentorno
- Definición delas métricas
Procesoactual- Modelado- Validación
Procesometa- Modelado- Validación
49
Modelado
Selección del método
Proceso actual
Proceso meta
Validación
Cálculo de promedios ponderados
Simulación del proceso
Proceso actual
Proceso meta
3.2.1 Estudio preliminar
Está orientado a conocer el entorno dentro del cual se ejecutan los procesos de
negocio. Ayuda a establecer un marco de referencia que evita la implantación de
soluciones no alineadas con las estrategias propuestas por la dirección.
El tiempo aproximado para terminar estas actividades es de dos semanas,
dependiendo de los recursos asignados para la investigación, el tamaño de la
organización, su distribución geográfica y la disponibilidad de los usuarios.
50
En esta fase, el equipo de trabajo debería estar integrado por:
Analistas de negocio. Conocen los objetivos, normativa, estructura, recursos y
operaciones de la organización. Son los responsables de exponer las iniciativas
de cambio, derivadas de nuevas oportunidades de negocio o problemas
existentes. Brindan las especificaciones de los procesos que se desean
automatizar y las alternativas de mejora o rediseño a validar. Su participación se
hace viable a través de los lenguajes de modelado gráfico.
Analistas de sistemas. Son responsables de elaborar los modelos de
procesos, actual y esperado. Cuentan con un conocimiento amplio de las
tecnologías de información, particularmente workflow. Su capacidad para
comprender aspectos técnicos les permite leer una abstracción de alto o de bajo
nivel.
Por lo general, las herramientas requeridas durante esta etapa consisten en
aplicaciones de oficina. Si la empresa cuenta con los recursos suficientes, se
recomienda la utilización de un modelador de procesos.
3.2.1.1 Presentación de la organización
El objetivo de esta actividad es describir los elementos de la organización que se
encuentran relacionados con el proceso que se desea modelar, incluyendo:
51
Unidades de negocio. Debe enumerarse el tipo de unidad, sus relaciones
jerárquicas, las funciones que tiene a cargo y los puestos que agrupa.
Calendario de trabajo. Establece las turnos, vacaciones, feriados, las horas y
días laborales en una semana regular.
Entidades externas. Individuos u organizaciones que existen fuera del dominio
del proceso y que interactúan con este para aportar o consumir información.
Políticas. Enumera las directivas de carácter general que afectan la ejecución
del proceso a modelar.
Reglas de negocio. Enumera las directivas de carácter específico que afectan
la ejecución de algunas tareas del proceso a modelar.
No existe un instrumento único para obtener esta información. Puede recurrirse a
la recopilación de documentos, entrevistas con los participantes del proceso y
encuestas.
3.2.1.2 Descripción del entorno
Ningún proceso opera de manera aislada dentro de la organización. En general,
cuando estos se analizan, es posible darse cuenta que en algún punto se
encuentran vitalmente conectados a otros.
52
Para evitar que el analista intente abarcar todos los procesos dentro de la
organización, resulta importante que se establezcan sus fronteras. Debe quedar
establecido el punto único de inicio y las condiciones de entrada que lo disparan,
así como los puntos de finalización, según se cumplan condiciones de parada.
El entorno puede resumirse con ayuda de los siguientes elementos:
Clientes. Receptores internos o externos de un resultado del proceso.
Ejecutores. Personas o sistemas que llevan a cabo las tareas del proceso. A
efecto de clarificar el análisis podrán distinguirse entre ejecutores internos y
externos.
Entrada. Acción o condición que sirve de estímulo para iniciar el proceso.
Salida. Producto que se espera generar y que se entrega a los clientes del
proceso.
Subproceso. Subconjunto de tareas que han sido agrupadas basándose en
criterios como la distribución geográfica de los ejecutores, unidad organizativa
que las realiza, puestos de trabajo u objetivo que persiguen. Su uso es opcional,
ya que la secuencia de tareas que lo integran puede trasladarse de manera
directa al flujo de trabajo del proceso que lo contiene.
53
Entre los instrumentos a utilizar para llevar a cabo esta actividad se encuentran
los diagramas sinópticos y de bloque. Si la empresa decide utilizar otro tipo de
diagrama, deberá procurar que cada uno de los elementos quede claramente
representado.
3.2.1.3 Definición de las métricas
Son indicadores de desempeño que permiten a los analistas de negocio validar
el esfuerzo de mejora e impacto del mismo. Si estas no se establecen, es difícil
evaluar el éxito del proyecto, una vez diseñado el nuevo proceso.
Adicionalmente, se utilizan para monitorear el desempeño del workflow, una vez
que este ha sido implantado. Pueden clasificarse en cualquiera de las siguientes
categorías:
Cantidad. Contabilizan ocurrencias de eventos en un proceso; el resultado
puede presentarse de manera directa o relacionado con otras métricas. Entre
estas se pueden mencionar:
Frecuencia (por ejemplo, solicitudes de crédito evaluadas en una semana).
Proporción de resultados (por ejemplo, número de solicitudes de crédito
aprobadas contra rechazadas).
54
Proporción de alternativas de acción (por ejemplo, número de créditos
aprobados directamente contra los aprobados por junta).
Proporción de diferentes motivadores (por ejemplo, número de nuevos créditos
contra ampliaciones).
Tiempo . Ayuda a controlar plazos relacionados con la ejecución de un flujo de
trabajo. Existen formas distintas de especificarlo:
Tiempo de ciclo. Es el transcurrido desde el inicio hasta la finalización del
proceso. También puede llamársele tiempo calendario o tiempo de reloj, cuando
se trata de ciclos cortos que pueden medirse en días u horas.
Tiempo de trabajo. Es el que corresponde al trabajo efectivo; es decir, excluye
cualquier espera.
Tiempo laborado. Contabiliza las horas acumuladas por todos los que trabajan
en el proceso. Equivale al total de horas que se paga a los trabajadores.
Tiempo de ocio. Representa las horas invertidas esperando a que suceda un
evento. Puede ocurrir por la manera en que se ha diseñado un proceso.
55
Tiempo de tránsito. Es el que se requiere para trasladar el trabajo de una etapa
a otra.
Tiempo de cola. El que debe esperarse antes de iniciar la siguiente actividad de
proceso. La unidad de trabajo se encuentra lista para la siguiente actividad, pero
debe esperar a que se despachen otras unidades que llegaron previamente.
Tiempo de configuración. Es el necesario para preparar los recursos que se
utilizarán para iniciar el trabajo.
Involucrados. El número de unidades, ubicaciones y personas que participan
en la ejecución del proceso. Normalmente se intentan listar los siguientes
elementos:
Personas.
Puestos de trabajo.
Departamentos.
Lugares.
Lenguajes.
Países.
56
Eficiencia. Permiten determinar el aprovechamiento de los recursos. Estas
pueden incluir:
Porcentaje de retrabajo.
Porcentaje de errores.
Etapa en que ocurren los errores.
Rapidez con que se descubren los errores.
Iteraciones necesarias para corregir el error.
Costo. Desembolsos registrados durante la ejecución del proceso. Si se desea
una clasificación exacta, podrían segregarse los gastos para incluirlos en otra
categoría. Entre los que resultan útiles para el análisis se encuentran:
Costos por ejecución.
Costos por errores.
Costos de retrabajo.
Costos de oportunidad.
57
3.2.2 Modelado de procesos
La metodología propone la diagramación de los procesos actual y meta.
Idealmente el analista de negocio proporcionará las especificaciones para que el
analista de sistemas las represente utilizando un lenguaje gráfico de carácter
técnico, tal como el que se expone en la sección “3.3 Instrumentos” de este
capitulo.
Esta actividad es normalmente un esfuerzo cooperativo, debido a que los
procesos suelen ser complejos y la totalidad del conocimiento podría no estar
concentrada en un solo usuario. La agilidad en la recolección de información y
elaboración del proceso asociado resultan de valor para la organización.
3.2.2.1 Selección del método
Un analista puede realizar el modelado utilizando cualquiera de los siguientes
enfoques:
Descomposición
Incremental
Combinado
La descomposición consiste en dividir el proceso en partes de menor tamaño,
llamada subprocesos. Varios analistas o equipos de trabajo pueden modelarlos
58
de manera simultanea. Al finalizar, se integran los modelos de cada subproceso
en uno que resultará más complejo y que satisface las necesidades del negocio.
Se recomienda utilizar este enfoque cuando:
El trabajo fluye a través de limites bien definidos (por ejemplo, funciones o
unidades organizativas diferentes).
Los expertos que participan en el proceso cuentan con un conocimiento
profundo y especializado de la parte que desempeñan.
Los empleados involucrados se encuentran distribuidos en diferentes
ubicaciones.
Se dificulta juntar a todos los usuarios interesados en las reuniones de trabajo.
El enfoque incremental resulta útil cuando solo es posible identificar las
actividades principales de un flujo de trabajo, dificultándose la especificación de
otras intermedias. La idea consiste en elaborar un esqueleto alrededor de dichas
actividades, para ir añadiendo información a medida que esta se obtiene o
confirma.
Resulta adecuado utilizarlo en los siguientes casos:
59
Las funciones de los participantes se encuentran estrechamente integrados,
generando la ausencia de fronteras claras para la asignación de las actividades.
No existen usuarios con el conocimiento completo y detallado de todo el
proceso.
Existen participantes que cuentan con una idea principal del proceso.
La mayor parte de los empleados que participan se encuentran en la misma
ubicación.
Es relativamente fácil juntar a los usuarios expertos en las reuniones.
Los enfoques anteriores representan situaciones extremas; sin embargo, la labor
de modelar un proceso puede llevarse a cabo en un entorno con características
de ambos, de manera que estos podrían aplicarse simultáneamente o en
distintos momentos, según se requiera. A este enfoque se le llama combinado .
Por ejemplo, la representación de alto nivel podría aplicarse para dividir un
proceso en subprocesos, aquellos cuyo flujo se desconozca de manera exacta,
deberán modelarse de manera incremental.
60
3.2.2.2 Modelado del proceso actual
Consiste en una representación grafica del proceso tal como existe en la
organización; es decir, antes de aplicar cualquier idea de mejora o rediseño,
incluyendo:
Las actividades o trabajo requerido para completarlo.
Los recursos utilizados.
La información consultada, modificada, creada y borrada.
Las decisiones que ocasionan variaciones en el flujo de trabajo.
Métricas necesarias para estimar el nivel de desempeño, tomando en cuenta
tiempo y costo.
Su creación brinda el conocimiento y fundamento que permiten validar, más
adelante, la necesidad de mejora o rediseño.
Capturar el proceso actual en un modelo para conducir el análisis permite:
Reflejar el conocimiento de la organización.
61
Facilitar la identificación de las áreas de problema.
Generar consenso entre los analistas y los gerentes acerca de las necesidades
de cambio en el proceso actual.
Estimular nuevas ideas para nuevos diseños del proceso.
Facilitar la identificación de las fuentes de información.
Proveer una línea de referencia para medir las mejoras en un proceso
rediseñado.
Proveer un instrumento para la discusión del proceso, sus problemas y
oportunidades de mejoras.
El tiempo requerido puede ser de una a dos semanas, dependiendo del alcance.
3.2.2.3 Modelado del proceso meta
Consiste en una representación grafica del proceso como se desea implantar en
la organización; es decir, después de aplicar las ideas de mejora o rediseño.
La presentación del diagrama del futuro proceso permite:
62
Generar consenso entre miembros de equipo de análisis y los usuarios sobre la
necesidad de cambiar el proceso existente.
Verificar el cumplimiento de los objetivos de desempeño deseados.
Comparar diferentes escenarios hasta determinar la solución óptima.
Tener un instrumento para la discusión y divulgación de los cambios
implantados.
Si esta actividad no es completada, el peligro consistiría en que la organización
podría permanecer estancada en el entorno actual. Es importante para que los
usuarios entiendan los cambios y las razones por las que fueron desechados
aquellos que se consideraron fuente de problemas.
El tiempo requerido puede oscilar entre las dos y cuatro semanas, dependiendo
de los alcances y objetivos del proyecto.
3.2.3 Validación
Es un paso importante del análisis. Durante la implantación de workflow es
necesario que los usuarios confirmen que la tecnología aportará los beneficios
esperados, generalmente en términos de tiempos, costo y productividad. Esta
63
última esta asociada a relaciones como el número de ordenes de venta por día,
transacciones en caja por hora y similares.
Aunque la validación podría llevarse a cabo en forma manual, en procesos
grandes o complejos, el tiempo requerido para cada ciclo podría durar más de lo
deseado. Limitar la cantidad de cálculos para estimar tendencias, disminuye la
exactitud. Por esta razón el uso de herramientas puede simplificar esta actividad
e incrementar la capacidad del analista de sistemas para apoyar a los usuarios
en el sondeo de diversos puntos de impacto.
3.2.3.1 Métodos de validación
El analista debe utilizar dos diferentes métodos:
Cálculo de promedios ponderados
Simulación de procesos
El primero ayuda a las organizaciones a entender las métricas de costo y tiempo.
La combinación de decisiones y alternativas crean un conjunto de rutas a través
de las cuales se traslada y transforma la información, estas son conocidas con el
nombre de casos . Pueden evaluarse de manera individual ya que suelen existir
variaciones en la cantidad o tipo de recursos consumidos. La ponderación
consiste en relacionar cada caso con su probabilidad de ocurrencia, para que el
64
usuario pueda estimar las demandas de un proceso dentro de un plazo
especifico.
El segundo se refiere a las pruebas que ayudarán a los usuarios a determinar
qué proceso es el más eficiente, de un conjunto de modelos propuestos. Esto es
posible a través de la generación de escenarios del tipo “¿qué pasaría sí?”,
donde se varían parámetros para comparar resultados, tales como la tasa de
trabajos de entradas, número de recursos de un departamento y similares.
A diferencia de los promedios ponderados, que brindan una visión estática de los
resultados que se espera obtener, la simulación se considera un análisis de tipo
dinámico, que permite manipular distintos aspectos del proceso para crear
escenarios que reflejan las distintas oportunidades de mejora de manera
individual o conjunta.
3.2.3.2 Validación del proceso actual
Durante esta fase del análisis, el cálculo de promedios ponderados genera
información de interés, ya que permite establecer líneas de referencia que
cuantifiquen el impacto de las mejoras propuestas por los procesos meta.
El analista de negocio es quien determina el indicador de desempeño de mayor
importancia para la organización o la prioridad, cuando exista más de uno.
65
La simulación pude utilizarse por los analistas de negocio para confirmar las
deficiencias identificadas en un proceso o detectar debilidades que pasan
desapercibidas durante la observación en los distintos puestos de trabajo.
3.2.3.3 Validación del proceso meta
Para cada escenario de solución propuesto, el analista debe proyectar las
mejoras de tiempo, costo o productividad, por lo que deberá realizar él calculo de
promedios ponderados. Adicionalmente es necesario verificar la ausencia de
irregularidades en los nuevos procesos, tales como cuellos de botella, tiempos
muertos y terminaciones prematuras, entre otras. La simulación facilita a los
usuarios la comprensión de los efectos que sus recomendaciones tienen cuando
llevan a cabo la mejora o rediseño de proceso con el analista de negocio.
3.3 Instrumentos
3.3.1 Diagrama de entorno
Este instrumento puede utilizarse durante el estudio preliminar y constituye un
apoyo para el analista al momento de:
Identificar a todos los individuos y organizaciones externas que generan
entradas, reciben resultados o brindan cualquier otro tipo de soporte para la
realización del proceso.
66
Organizar la agenda de reuniones con todos los involucrados, para validar,
ampliar o reducir las fronteras establecidas al inicio del proyecto.
El proceso puede representarse como un solo elemento o dividido en sus
subprocesos, dependiendo del enfoque utilizado (ver 3.2.2.1) documentación de
procesos. La plantilla propuesta se presenta en la Figura 3.3.
67
Figura 3.3: Plantilla de fronteras de procesos
3.3.2 Diagrama de proceso
Para diagramar el proceso (actual o meta) se sugiere utilizar el lenguaje gráfico
propuesto por la empresa Holosofx18. Una vez finalizada esta actividad, el
modelo debe validarse en talleres o entrevistas con los usuarios.
Los símbolos con ayuda de los cuales se elabora el modelo del proceso se
encuentran resumidos en la siguiente tabla:
18 HOLOSOFX . Fue fundada en 1990. Lanzando el Workflow BPR Versión 1 en 1994. La versión 2 del mismo software fue liberada en 1996, incorporando al Workflow interfaces de integración con WFMS comerciales, tales como IBM MQSeries Workflow. La versión 3 fue liberada en 1998. En 2001 HOLOSOFX introdujo su Suite BPM 4.1. BPM Suite comprende BPM Workbench, BPM Monitor, y el BPM Server.
Clientes del procesoClientes del proceso
Eventos iniciadores/entradas del
proceso
Eventos iniciadores/entradas del
proceso
Entregables/Salidas del proceso
Entregables/Salidas del proceso
Entidades externas (Involucradas en el
proceso)
Entidades externas (Involucradas en el
proceso)
SubprocesoSubproceso
Unidades organizativas (Involucradas en el proceso)
Unidades organizativas (Involucradas en el proceso)
68
Símbolo Descripción
OBJETOS DE TRABAJO
Tarea
Representa la actividad de más bajo nivel que
puede llevar a cabo una persona o sistema.
Tiene un costo y duración asociados. Consume
recursos de la organización.
Las siguientes recomendaciones deberían
atenderse al momento de seleccionar el nombre:
Utilice verbos activos que reflejen el trabajo
realizado.
Evite las palabras “proceso” y “tarea”.
Inicie las palabras con una mayúscula.
Mantenga los nombres cortos.
Utilice nombres generalmente aceptados.
Mantenga los nombres consistentes.
69
Proceso
Representa una agrupación de alto nivel de las
tareas que integran un proceso del negocio. Puede
contener símbolos de Tarea o Proceso
(subprocesos) creando una jerarquía.
Son nombrados utilizando frases de acción que
reflejan el trabajo realizado.
Tanto los procesos como actividades pueden
relacionarse únicamente a través de las Salidas
Reutilizables.
OBJETOS DE DECISIÓN
Decisión
Existen dos tipos: binarias y múltiples. Las binarias
tienen como salida "si" y "no". Las múltiples tienen
como salida dos o más opciones.
Debe ser descrita a manera de pregunta.
Opción
Debe seleccionarse para determinar la tarea que
continúa. Son los posibles resultados de una
Decisión.
70
OBJETOS DE FLUJO
Salidas Reutilizables
Fluye de entre las Tareas y Procesos de un modelo
de proceso. Es representada por la letra fi (φ) del
alfabeto griego. Por definición, es la salida de una
actividad que es utilizada como la entrada para otra.
A efecto de facilitar la lectura de un diagrama,
puede reemplazarse por una figura que sugiera el
tipo de salida (carta, fax, correo electrónico, etc.).
Conector
Actúa como medio de transporte (correo
electrónico, fax o teléfono) para llevar una Salida
Reutilizable de una actividad a la siguiente.
Cuenta con atributos adicionales al medio, tal como
el tiempo de duración de la transferencia.
Fusión
Representa la incorporación de salidas reutilizables
entregadas por distintas rutas. La complejidad de
análisis se deriva de la forma en que se integran
múltiples salidas en una sola para trasladarla a la
siguiente actividad del proceso.
71
Ir a
Ayudan a representar avances o retrocesos en el
proceso, para obviar o repetir actividades.
Si se utiliza una figura en forma de estrella se está
indicando un avance en el proceso, hacia una
actividad que se encuentra mucho más adelante
que la siguiente actividad. Añade claridad en la
lectura.
Si se utiliza un triángulo se indica re-trabajo; es
decir, repetición de tareas ya finalizadas. Es una
manera de representar iteraciones.
ELEMENTOS EXTERNOS
Entidad Externa
Se encuentra fuera de la organización y participa en
el proceso, como origen de las entradas o
destinatario de las salidas.
Proceso Externo
Es un grupo de una o más actividades realizadas
por una Entidad Externa.
Final
Representa una ruta del proceso que ha llegado a
su fin. Un proceso puede estar constituido de
múltiples rutas, algunas de las cuales terminarán
antes que otras.
72
La diagramación puede iniciar con un modelo que contenga los subprocesos
principales y las salidas reutilizables que se requieren para relacionarlos. A esta
representación se le conoce con el nombre de “diagrama de primer nivel”.
A medida que este se desglosa en otras actividades y subprocesos, se forma
una jerarquía que no debería superar los cinco niveles, para poder mantener
controlado el nivel de complejidad.
En adición a la notación propuesta, deben tomarse en cuenta los siguientes
aspectos:
Una tarea tiene asociada unidades organizativas, roles, tiempos y recursos.
Los roles se deben asignar a actores, los cuales deben quedar especificados,
aunque pueden sufrir modificaciones en el tiempo.
Todo rol y consumo de recursos tienen un costo asociado. La recolección de
estos datos resulta útil en las tareas de validación.
Las salidas reutilizables tienen un contenido; aunque durante el modelado del
proceso actual no es indispensable detallarlo, es necesario que se incluya como
parte del proceso meta, pues constituyen una especificación de implantación.
73
Las decisiones se llevan a cabo en base a datos y cálculos sobre las salidas
reutilizables o elementos del entorno.
Todo conector se encuentra asociado a un medio de transferencia, el cual
implica un tiempo y un costo.
Todo proceso y tarea deben contar con un propietario al momento de su
ejecución.
Los procesos externos no pueden ser controlados por la empresa. Sin embargo,
tienen una duración asociada, la cual incide en el tiempo de ejecución del
proceso.
Las bifurcaciones, derivadas de las DECISIONES, y FUSIONES presentan una
dificultad adicional, pues es necesario identificar las implicaciones que tienen en
el flujo de trabajo. La WfMC distingue los siguientes casos, al abordar el tema de
la secuencialidad y paralelismo:
Elemento
Clase Bifurcación Fusión
AND Un punto en el cual el workflow se divide en dos o más hilos de
Un punto en el workflow en el cual convergen dos o más hilos de
74
control que deben ejecutarse simultáneamente.
control que se ejecutan en paralelo. Se requiere establecer las reglas de sincronización para las salidas reutilizables.
OR Un punto en el cual el workflow debe decidir entre múltiples hilos de control que es posible ejecutar, basándose en una condición.
Un punto en el cual el workflow en el cual convergen hilos de control alternativos; es decir, que no pudieron haberse ejecutado en paralelo.
Modalidades de bifurcación y fusión propuestas por la WfMC.
Debido a que los elementos de modelado no permiten establecer diferencias
para cada una de las situaciones anteriores y que en la practica podrían
presentarse variaciones o combinaciones, es importante incluir este detalle al
elaborar la documentación.
3.4 Caso práctico: Modelado básico
Para ilustrar la aplicación de los instrumentos expuestos en las secciones
anteriores, se ha escogido una empresa ficticia. El objetivo es aplicar los
conceptos, no evaluar su uso en distintos entornos de producción. La empresa
se dedica a fabricar bicicletas para deportistas profesionales y los distribuye a
través de detallistas o de manera directa. Durante su tiempo de permanencia, la
empresa ha logrado convertirse en proveedor de partes para otros
manufactureros.
75
3.4.1 Presentación de la organización
Las unidades organizativas que participan en la ejecución del proceso “Ordenes
de Venta” son:
Contabilidad y administración
Procesamiento de órdenes
Despacho
El calendario laboral de la empresa consiste de 52 semanas anuales, cada una
de ellas compuesta de 5 días hábiles, comenzando a las 8:00 horas y
terminando a las 17:00 horas, con un tiempo de descanso de 75:00 minutos,
contados a partir de las 12:00 horas. Se consideran días no laborales aquellos
establecidos por la ley, sin tomar en cuenta el período de vacaciones anual de
cada empleado, pues son autorizados de manera que no exista una interrupción
en el servicio a los clientes.
El proceso opera con el siguiente conjunto de reglas de negocio:
Las órdenes de venta son recibidas por teléfono durante las horas laborales y
por los sistemas B2C y B2B implantados en la empresa, el resto del tiempo.
76
Solamente el personal de venta autorizado puede recibir órdenes de venta o
modificaciones a las mimas.
Solamente un empleado autorizado puede verificar la información de las
órdenes.
Todas las ventas que involucran clientes que no tienen líneas de crédito y que
tienen un nivel de riesgo medio, tienen que ser revisadas por el Gerente de
Contabilidad, quien es responsable de verificar el beneficio del crédito,
independientemente del valor de la orden.
Se enviarán copias de las órdenes aprobadas y rechazadas a Cuentas por
Cobrar y al Gerente de Contabilidad.
Las órdenes de alto riesgo son enviadas a Cuentas por Cobrar, donde se emite
una notificación al cliente.
Las órdenes deben conservarse en archivo durante diste años, después de
recibida la original.
Las copias de todas las órdenes aprobadas y rechazadas, informes de crédito,
notas de denegación y órdenes de trabajo deben conservarse en archivo durante
77
siete años, después de que las órdenes asociadas hayan sido entregadas o
rechazadas.
3.4.2 Descripción del entorno
El procesamiento de órdenes de venta, puede dividirse en tres grandes
subprocesos:
Orden del cliente.
Obtención de la información de crédito.
Revisión del crédito.
Como primer paso del análisis se debe identificar las fronteras del proceso:
Figura 3.4: Plantilla de fronteras del proceso “caso de análisis”.
A
2. Empleados
1. Clientes Externos
Procesos de Cliente
2. Empleados
1. Clientes Externos
Procesos de Cliente
2. Ordenes de Venta
1. Ordenes de Cliente
Disparadores/Entradas de procesos
2. Ordenes de Venta
1. Ordenes de Cliente
Disparadores/Entradas de procesos
2. Notificación de Rechazo
1. Orden de Trabajo
Entregables/Salidas de Procesos
2. Notificación de Rechazo
1. Orden de Trabajo
Entregables/Salidas de Procesos
2. Agencia de Créditos
1. Cliente
Entidades Externas (Involucradas con el
proceso)
2. Agencia de Créditos
1. Cliente
Entidades Externas (Involucradas con el
proceso)
3. Revisión de Crédito
2. Obtener Info. de Crédito
1. Ordenes de Cliente
Subprocesos
3. Revisión de Crédito
2. Obtener Info. de Crédito
1. Ordenes de Cliente
Subprocesos
3. Compras
2. Ventas
1. Contabilidad y Administración
Unidades Organizativas (Involucradas en el proceso)
3. Compras
2. Ventas
1. Contabilidad y Administración
Unidades Organizativas (Involucradas en el proceso)
78
3.4.3 Definición de métricas
De acuerdo con lo requerido por los directores de la empresa, se espera tener la
posibilidad de controlar el número, costos y tiempo de ejecución de los siguientes
casos:
Ordenes aceptadas con crédito pre-aprobado.
Ordenes de bajo riesgo aceptadas.
Ordenes de mediano riesgo aceptadas con aprobación ulterior.
Ordenes de mediano riesgo rechazadas.
Ordenes de alto riesgo rechazadas.
3.4.4 Diagramación del proceso
El flujo de trabajo inicia con la ejecución del SUBPROCESO “Preparar Orden de
Cliente”. La SALIDA REUTILIZABLE “Orden de Venta” contiene la información
necesaria para evaluar la decisión “¿Línea de Crédito Disponible?”. Los
porcentajes de probabilidad que el flujo de trabajo siga alguna de las opciones
disponibles se indican utilizado números enteros.
79
Figura 3.5: Modelo del proceso “Órdenes de Venta – Alto Nivel”
Si la respuesta es afirmativa, se ejecuta la ACTIVIDAD “Emitir Orden de Trabajo”
que dará como resultado final la “Orden de Trabajo”. Para el caso contrario, se
procede a obtener la información de crédito y se traslada la “Orden de Venta”,
con el estado “Completa”, para que sea sometida a una revisión de crédito, que
tiene como fin evaluar la elegibilidad del cliente para recibir el financiamiento. Las
SALIDAS REUTILIZABLES dependen de las condiciones que se hayan establecido en
el subproceso, las cuales reflejan las políticas y reglas del negocio.
Preparar Orden de Cliente
Orden de Trabajo
Notificación de Cliente
Orden de Venta
Línea de Crédito
Disponible?
Si 80No 20 Orden de
Venta
Rechazar Orden de Venta
Revisar Crédito
Orden de Ventas
Obtener Info. de Crédito
Emitir Orden de Compra
Aceptada
Aceptada
Rechazada
Rechazada
Orden de Venta 1
Orden de Venta 2
Orden de Venta 3
Preparar Orden de Cliente
Orden de Trabajo
Notificación de Cliente
Orden de Venta
Línea de Crédito
Disponible?
Si 80No 20 Orden de
Venta
Rechazar Orden de Venta
Revisar Crédito
Orden de Ventas
Obtener Info. de Crédito
Emitir Orden de Compra
Aceptada
Aceptada
Rechazada
Rechazada
Orden de Venta 1
Orden de Venta 2
Orden de Venta 3
Orden de Venta
Línea de Crédito
Disponible?
Si 80No 20 Orden de
Venta
Rechazar Orden de Venta
Revisar Crédito
Orden de Ventas
Obtener Info. de Crédito
Emitir Orden de Compra
Aceptada
Aceptada
Rechazada
Rechazada
Orden de Venta 1
Orden de Venta 2
Orden de Venta 3
80
Las órdenes rechazadas deben ser notificadas a los clientes, para luego finalizar
el proceso. Este diagrama constituye el “Modelo de Orden de Ventas de Primer
Nivel” (ver Figura 3.5).
Los niveles siguientes incluyen el detalle de los subprocesos utilizados
anteriormente. La entidad externa “Cliente” aparece como el generador del
evento que es capaz de poner en marcha el proceso. Debido a que las opciones
para la colocación de la orden son diversas, es necesario introducir un elemento
de decisión múltiple desde el comienzo, pues durante la ejecución, cada uno de
estos dara lugar a un caso que podrá evaluarse de manera independiente y con
distintas probabilidades de ocurrencia, indicadas con un número entero.
Figura 3.6: Proceso “Preparar Orden de Cliente”
cliente
Tipo de
Orden? Teléfono
Orden Telefónica
Crear Orden de Cliente
Orden de Venta
Orden de Venta
Orden de Venta
Orden de Trabajo
Emitir Orden de Trabajo
B2B
Orden B2B
Registrar Orden de Cliente
B2C
Orden B2C
Traducir Orden de Cliente
cliente
Tipo de
Orden? Teléfono
Orden Telefónica
Crear Orden de Cliente
Orden de Venta
Orden de Venta
Orden de Venta
Orden de Trabajo
Emitir Orden de Trabajo
B2B
Orden B2B
Registrar Orden de Cliente
B2C
Orden B2C
Traducir Orden de Cliente
81
Los simbolos seleccionados para denotar las salidas reutilizables dan una idea
rápida a los analistas de negocio y usuarios a cerca de los medios con que se
encuentran relacionadas. El teléfono corresponde a las llamadas telefónicas, el
mundo con algún formulario disponible a través de la web y el mundo con las
computadoras en red hacen pensar en dos sistemas de negocio que
intercambian datos de manera automatizada. (Ver Figura 3.6).
La necesidad de representar los tres casos por separado se hace evidente
cuando observamos el trabajo demandado por cada uno. En el primero, el
trabajo es realizado completamente por la empresa, a través de personal de
atención teléfonica que entrevista al cliente y llena el formulario diseñado para
este proposito. La cantidad de ordenes que pueden recibirse de manera
simultanea depende del número de líneas teléfonicas que hayan sido destinadas
para este fin. Cuando se trata de un acceso web denominado B2C19, parte del
trabajo es realizado por el cliente y parte por la empresa. Sin embargo, la
capacidad de atención se ha incrementado significativamente, pues el número
de ordenes que se registran concurrentemente excede por un margen elevado al
del caso anterior. Adicionalmente, el horario de disponibilidad se ha extendido
para dar servicio 7 días a la semana, las 24 horas del día. La modalidad B2B20
supone automatización en ambos extremos de la relación, pues la orden es
19 Busines to Customer. Concepto utilizado en comercio electrónico para denominar a aquellas aplicaciones que están orientadas a realizar negocios con los consumidores finales, a través del World Wide Web. 20 Business to Business. Concepto utilizado en comercio electrónico para denominar a aquellas aplicaciones que están orientadas a interconectar dos o más empresas, a efecto de automatizar las operaciones de negocio a través de las cuales se relacionan.
82
colocada y recibida utilizando programas orientados a la codificación y
decodificación de mensajes comerciales, tales como EDI21 o XML22.
Los segundo subprocesos a desglozar en un diagrama de segundo nivel es el
que hemos denominado “Obtener Información de Crédito”. Este inicia con la
SALIDA REUTILIZABLE “Orden de Venta” necesaria para la creación de la solicitud
de información sobre créditos, que es enviada a una entidad externa
especializada en suministrar información de este tipo (ver Figura 3.7).
Figura 3.7: Proceso “Obtener Información de Crédito”
El proceso que ejecuta la empresa dedicada a consultar la referencia crediticia
de los clientes no es de interés para la empresa. Ya sea que se trate de un flujo
de trabajo manual o automatizado, el único valor para el modelo es la salida
entregada, cuya información permite actualizar la orden de venta.
Finalmente se detallan las actividades comprendidas en la “Revisión de Crédito”.
Surgen aquí tres casos adicionales, derivados de la regla del negocio que dicta
lo que es necesario hacer dependiendo del riego que conlleva la operación de
crédito. A diferencia del primer subproceso, cada caso genera su propia salida,
21 Electronic Data Intechange – Intercambio Electrónico de Datos. 22 Extensible Markup Language – Lenguaje de Composición Ampliable.
Orden de Venta
Reporte de Crédito
Preparar reporte de crédito
Agencia de Crédito
Solicitud de crédito
Crear solicitud de Info. de Creditos
Orden de Venta
Actualizar Orden de Venta
83
pues no converge con los demás en alguna actividad común (ver Figura 3.8). En
el diagrama de primer nivel deben unirse aquellas que corresponden a salidas
reutilizables con el mismo estado y se conectan a la actividad que espera
recibirlas.
Figura 3.8: Proceso “Revisión de Crédito”
Las tareas del proceso han sido descritas con ayuda de la siguiente tabla:
Tarea Unidad
Organizacional Rol
Duración Total
Trabajo Efectivo
Crear Orden de Cliente
Ventas Procesador de ordenes
10.0000min. 3.0000min.
Registrar Orden de Cliente
Ventas Sistema 1.0000min. 11.0000s.
Traducir Orden de Cliente
Ventas Sistema 1.0000min. 11.0000s.
Emitir Orden de Trabajo
Despacho Despachador 10.0000min. 5.0000min.
Crear Solicitud de Info. de Créditos
Ventas Procesador de Ordenes
5.0000hs. 1.0000min.
Orden de Venta
Aprueba Crédito?
Si 50No 50
Revisar Perfil de Cliente
Bajo Riesgo
Mediano Riesgo
Alto Riesgo
20
60
20
Valuo de Crédito?
Orden de Venta
Aceptada
Aceptada
Rechazada
Rechazada
Orden de Venta
Orden de Venta
Orden de Venta
Orden de Venta
Aprueba Crédito?
Si 50No 50
Revisar Perfil de Cliente
Bajo Riesgo
Mediano Riesgo
Alto Riesgo
20
60
20
Valuo de Crédito?
Orden de Venta
Aceptada
Aceptada
Rechazada
Rechazada
Orden de Venta
Orden de Venta
Orden de Venta
84
Actualizar Orden de Ventas
Ventas Procesador de Ordenes
10.0000min. 5.0000min.
Revisar Perfil de Cliente
Contabilidad y Administración
Gerente Contable
3.0000h. 30.0000min.
Rechazar Orden de Venta
Despacho Despachador 3.0000min. 1.0000min.
Especificaciones de las tareas del proceso “Ordenes de Ventas”
En cuanto a los elementos de decisión, los únicos datos requeridos son la
probabilidad de incidencia de cada opción:
Decisión /Opción
Incidencia (%)
Bajo Riesgo 20 Mediano Riesgo
60
Alto Riesgo 20 teléfono 25 B2B 45 B2C 30 Línea de crédito disponible?
80% (Si) 20% (No)
Esta aprobado el crédito?
50% (Si) 50% (No)
Especificaciones de las opciones del proceso “Ordenes de Venta”
Las salidas reutilizables incluyen información extendida por los usuarios; la
categoría está relacionada con el medio físico en el que se encuentra la
información y el tipo corresponde a una clasificación interna. La información
extendida queda a criterio del Analista de Sistemas y se identificará según el
entorno para el cual se desea implantar una solución de workflow.
85
Salida reutilizable (phi) Categoria Tipo Orden de ventas Documento en
paple Forma en papel
Orden de Trabajo Documento en paple
Forma en papel
Solicitud de crédito Fax Fax Reporte de crédito Fax Fax Orden de trabajo Documento en
paple Forma en papel
Notificación cliente Documento en paple
Correo Electrónico
Especificaciones de las salidas reutilizables del proceso “Ordenes de Venta”
Parte La información de los conectores puede ser generada de manera
automática cuando se cuenta con un modelador de procesos, pues estos son
utilizados para relacionar elementos en un flujo, el tiempo de transferencia se
encuentra asociado con los medios que se utilicen y suelen ser estándares para
cada uno de estos. Se recomienda que el analista recolecte estos datos antes de
tabularlos. A continuación se presenta ejemplos de especificación:
Objeto Origen Objeto Destino Medio Duración Cliente Teléfono Teléfono 1.0000m Crear Orden de Cliente Emitir Orden de Trabajo Correo Interno de
Oficina 4.0000h
Actualizar Orden de Venta Revisar Perfil de Cliente Correo Interno de Oficina
4.0000h
Especificaciones de los medios del proceso “Ordenes de Venta”
86
3.4.5 Validación
A efecto de demostrar los beneficios del nuevo proceso23, la empresa recurrió al
uso de un programa analizador, adquirido de un proveedor de aplicaciones, para
calcular promedios ponderados y generar simulaciones. Lo siguientes hallazgos
fueron comunicados a los analistas de negocio y usuarios:
El tiempo de ciclo del proceso se redujo de 25.34 horas a 4.01 horas – un
impacto del 84.17%.
El costo del ciclo de proceso se redujo de $6.87 a $1.89.
El trabajo requerido se redujo del 100% (inicial) a un 40%.
El nivel de procesamiento electrónico incrementó del 0% al 98%.24
3.5 Caso práctico: Modelado avanzado
El modelo presentado hasta este momento se pude clasificar como simple,
partiendo del hecho que no considera paralelismos (bifurcaciones y fusiones) ni
recurrencias (retornos).
23 El ejemplo parte del supuesto que el proceso modelado se utilizará para reemplazar el que actualmente utiliza la empresa y que no ha sido incluido como parte de la explicación. 24 Este caso se presenta cuando las empresas parten de procesos completamente manuales a procesos mecanizados. Queda claro que la reducción del costo del ciclo de procesos va acompañada de una inversión en tecnología. Debería realizarse un estudio de inversión para determinar si el ahorro es fuente suficiente para el retorno de la misma. Podría también presentarse la situación de que a pesar de obtener condiciones favorables de retorno, el monto a invertir sea lo suficientemente grande como para que el proyecto de automatización no sea factible.
87
Para analizar otras posibles situaciones que se presentan en entornos de
producción real, se considera el caso de una empresa que, conociendo su
situación actual, desea diagramar el proceso meta25.
El escenario trata de una empresa que ha iniciado la automatización de las
solicitudes de sus clientes, derivadas de los productos y servicios que se ofrecen.
Algunas de estas pueden solucionarse de manera simple y directa, en base a
información existente derivada de manuales o casos similares, mientras que
otras requerirán de una investigación detallada.
Para poder tramitarlas y darles seguimiento, la empresa realiza las siguientes
actividades:
Creación de la solicitud de cliente. Este documento debe contener la
información general y detallada del cliente.
Investigación de aspectos de desarrollo y mercadeo relacionados con la
solicitud del cliente, la cual podrá afectar la respuesta.
Creación de la respuesta para el cliente. La respuesta debe contar con el
resultado de la investigación a cargo de los departamento de Desarrollo y
25 El objetivo de este ejemplo es mostrar nuevas posibilidades de modelación, no volver a aplicar la metodología desde el inicio.
88
Mercadeo, en los casos que se requiera, así como la conclusión para el cliente,
que será llamada “redacción de la respuesta”.
Los responsables de su ejecución son personas o grupos de trabajo que forman
parte de los siguientes departamentos de la organización:
Servicio al Cliente . Todos los miembros de este Departamento son
considerados actores principales del proceso de solicitud de cliente. Ellos son los
que crean las solicitudes y las respuestas que se envían posteriormente a los
mismos.
Mercadeo . Algunos miembros de este departamento participan regularmente en
el proceso, investigando detalles de mercadeo relacionados con la solicitud del
cliente. Otros miembros del departamento asisten ocasionalmente en el proceso
de requisiciones.
Desarrollo . Al Igual que Mercadeo, algunos de los miembros de este
departamento tienen una participación regular en el proceso, con el objetivo de
investigar detalles de Desarrollo relacionados con la solicitud. Otros miembros
del departamento participan ocasionalmente en el procesamiento de la solicitud.
Personas de diferentes departamentos pueden pertenecer al mismo grupo de
trabajo; en este caso se integran dos grupos, uno para cada departamento:
89
Grupo de Investigación de Mercadeo.
Grupo de Investigación de Desarrollo.
Todos los miembros del Departamento del Servicio al Cliente pueden participar
en el proceso a través de los siguientes roles:
“Supervisor” – las personas con este rol son los supervisores de todo el trabajo
del personal novato. Este rol es el propietario de todas las solicitudes de cliente
que se están procesando.
“Asistente”. Las respuestas que ellos elaboren a los clientes deben ser
revisadas y aprobadas por un supervisor antes que puedan ser enviadas.
Figura 3.9: Proceso Solicitudes de Clientes (Reclamos). 26
El Departamento de Servicio al cliente lleva a cabo la TAREA “Crear Solicitud”,
en la cual llena un formulario con los datos generales del cliente y el detalle de
la solicitud, para completar la “Solicitud del Cliente”.
26 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
Crear Solicitud
Solicitud del cliente
Investigar Solicitud
Solicitud de Cliente Investigada
Crear Respuesta Respuesta
para Cliente
Revisar Respuesta
Respuesta para Cliente Revisada
Crear Solicitud
Solicitud del cliente
Investigar Solicitud
Solicitud de Cliente Investigada
Crear Respuesta Respuesta
para Cliente
Revisar Respuesta
Respuesta para Cliente Revisada
90
Esta información es enviada por medio de un correo electrónico a los
departamentos de Mercadeo y Desarrollo para que sea investigada. Cada uno
de los grupos revisa la solicitud y agrega sus comentarios.
El miembro del Departamento de Servicio al Cliente que generó la solicitud del
cliente es notificado, de manera automatizada, cuando la investigación ha
terminado, para que este pueda redactar la respuesta. Se revisan los
comentarios y se prepara la correspondencia que será enviada al cliente.
La “Revisión de Respuestas” está a cargo del “Supervisor” del área. Se llevan a
cabo las correcciones necesarias y se envía al cliente.
La descripción anterior es el modelo más simple. Cuando se recibe una
solicitud en el departamento de Servicio al Cliente, el empleado tiene la
capacidad de distinguir qué tipo de investigación es necesaria:
Investigación de mercadeo.
Investigación de Desarrollo.
Ambas investigaciones.
91
Hasta este punto se ha asumido que cada opción de la decisión es excluyente;
es decir, se ejecuta una sola ruta, pues un flujo no cumplir dos condiciones
simultáneamente. Sin embargo, en este ejemplo carece de sentido que un
departamento tenga que esperar hasta que otro haya terminado la
investigación, ya que el ámbito de estas es independiente.
Cuando la ejecución concurrente es posible, todas las actividades que siguen a
una decisión, y que hayan cumplido con la comparación, deben recibir una
copia idéntica de la solicitud. Esto se resuelve fácilmente, a través de una
duplicación del documento.La segunda consideración es más compleja, pues
una vez terminadas las investigaciones de cada departamento, las salidas
reutilizables deben combinarse en una sola. Esto debe llevarse a cabo a través
de una actividad del sistema, que el modelo de diagramación se representa
como una FUSIÓN. La salida puede ser simple, una consolidación de datos en
otra SALIDA REUTILIZABLE, o compuesta, que permite diferenciar en su contenido
las SALIDAS REUTILIZABLES originales. En ambos casos la nueva salida se
llamará “Investigación Consolidada” y será enviada al Departamento de
Servicio al Cliente. (ver Figura 3.10).
92
Figura 3.10: Modelo de fusiones – “Integración de Investigaciones”.27
La tercera opción, que no conlleva paralelismo, es cuando no se requiere de
investigación y el mismo departamento de Servicio al Cliente puede generar la
respuesta para el cliente. La única tarea adicional es completar la solicitud del
cliente con la información disponible y someterla a revisión.
Finalmente, debe considerarse el caso en el cual los supervisores revisan las
respuestas elaboradas por los asistentes y las regresan a estos por presentar
errores que darán lugares a un retrabajo por correcciones. Este ciclo se repetirá
27 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
Crear Solicitud
Solicitud del cliente
Integración Consolidada
Crear Respuesta
Respuesta para
Cliente
Revisar Respuesta
Respuesta para Cliente Revisada
Investigación Necesaria
Investigación de Desarrollo
Investigación de Mercadeo
FIntegración de Investigaciones
Solicitud de Cliente
Investigada
Solicitud de Cliente
Investigada
Crear Respuesta con Información Disponible
Respuesta para
Cliente
Investigación no Necesaria
Crear Solicitud
Solicitud del cliente
Integración Consolidada
Crear Respuesta
Respuesta para
Cliente
Revisar Respuesta
Respuesta para Cliente Revisada
Investigación Necesaria
Investigación de Desarrollo
Investigación de Mercadeo
FIntegración de Investigaciones
Solicitud de Cliente
Investigada
Solicitud de Cliente
Investigada
Crear Respuesta con Información Disponible
Respuesta para
Cliente
Investigación no Necesaria
93
hasta que el supervisor dé el visto bueno a la respuesta redactada (ver Figura
3.11).
Figura 3.11: Depuración del proceso Solicitudes de Cliente (Reclamos).28
3.6 Caso práctico: Validación automatizada
Para demostrar los resultados que es posible obtener utilizando una
herramienta de validación, se seleccionó un proceso simple, el cual contaba
únicamente con dos actividades y una validación, tal como se muestra en la
Figura 3.12:
28 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
Crear Solicitud
Solicitud del cliente
Integración Consolidada
Crear Respuesta
Respuesta para
Cliente
Revisar Respuesta
Respuesta para Cliente Revisada
Investigación Necesaria
Investigación de Desarrollo
Investigación de Mercadeo
FIntegración de Investigaciones
Solicitud de Cliente
Investigada
Solicitud de Cliente
Investigada
Crear Respuesta con Información Disponible
Respuesta para
Cliente
Investigación no Necesaria
No
Si
Respuesta para Cliente
Corregir Respuesta
Crear Solicitud
Solicitud del cliente
Integración Consolidada
Crear Respuesta
Respuesta para
Cliente
Revisar Respuesta
Respuesta para Cliente Revisada
Investigación Necesaria
Investigación de Desarrollo
Investigación de Mercadeo
FIntegración de Investigaciones
Solicitud de Cliente
Investigada
Solicitud de Cliente
Investigada
Crear Respuesta con Información Disponible
Respuesta para
Cliente
Investigación no Necesaria
No
Si
Respuesta para Cliente
Corregir Respuesta
94
Figura 3.12: Proceso “Empaque de Ordenes de Trabajos”.
Las actividades representadas fueron documentadas con los siguientes
datos:
Figura 3.13: Unidades Organizativas que participan en el proceso.
Días de duración corresponde al tiempo total transcurrido en la actividad y
días trabajados al tiempo efectivo invertido. La decisión da lugar a dos
Casos, cada uno de los cuales tiene asociado un tiempo total de ejecución.
El informe resultante de promedios ponderado de tiempos que se generó
para el modelo anterior fue el siguiente:
Actividad Unidad Organizativa Puesto Días de DíasDuración Trabajados
Determinar Tipo de Empaque Bodega Asistente de Bodega 0.00083 0.00021 Empaque (cartón) Empacado Asistente de Bodega 0.01250 0.00208 Ensamblar (caja de madera) Empacado Asistente de Bodega 0.02083 0.01875
95
Figura 3.14: Informe de promedios ponderados de tiempo.
Si se añaden a las actividades los costos derivados de los recursos
asociados, es posible obtener un reporte que permite evaluar los costos de
cada caso y el total derivado del promedio ponderado.
3.7 Pruebas de calidad
Durante la fase de análisis es importante conducir pruebas que garanticen la
calidad del producto. Aunque esta actividad no añade valor, el tiempo y
recurso invertido compensa el impacto que tendría descubrir una falla de
análisis en fases subsiguientes del ciclo de vida de un workflow.
Las diversas pruebas que pueden llevarse a cabo pueden clasificarse en dos
grandes grupos:
a. Pertinentes a la metodología de modelado. Estas pruebas
podrían entenderse como validaciones sintácticas, orientadas a
garantizar que se respetarán las reglas para el uso e interconexión
de los elementos utilizados para construir los diagramas de
Nombre de Caso del Proceso
PorcentajeTiempo de Proceso
Tiempo de Transferencia
Tiempo de Espera
Tiempo de Trabajo
Caso 1 70.00 0.15d 0.08d 0.06d 0.01dCaso 2 30.00 0.15d 0.04d 0.01d 0.09dPromedio Ponderado 100.00 0.15d 0.07d 0.04d 0.04d
Tesis \ Reporte: Tiempos de Casos del Proceso
96
procesos. Estas pruebas se encuentran íntimamente relacionadas
con la metodología de modelado utilizada y no existe garantía
alguna de su universalidad.
El responsable de este control debería ser un analista distinto del
que elaboró el modelo.
b. Pertinentes al proceso modelado. Estas pruebas servirán para
evidenciar que el proceso cumple consistentemente con las metas
propuestas por el negocio. Existen varias herramientas
estadísticas que pueden utilizarse como parte de esta validación.
Una herramienta particularmente útil para realizar la validación es la
conocida como FMEA (Failure Modes and Effects Analysis, análisis
de tipos y efectos de falla). Consiste en listar los problemas
potenciales o tipos de falla y evaluar sus riesgos en términos de
severidad, probabilidad de ocurrencia y facilidad de detección.
Donde existen riesgos potenciales, la FMEA puede ser utilizada para
documentar las fallas encontradas. El resultado final es un plan de
control, donde cada oportunidad de falla se encuentra asociada con
herramientas de análisis estadístico.
97
Uno de los problemas frecuentes es el de variación, situación en
donde cada uno de los resultados del proceso difiere levemente de
los otros resultados. Estos cambios pueden caracterizarse tomando
una muestra de los resultados y distribuyéndolos en un histograma.
Por ejemplo, una empresa determina que el llenado de una orden de
venta no debe durar más de 100 segundos. La tolerancia es 100
más 5 segundos. Cuando los analistas toman una muestra de 12
ordenes y simulan el proceso, obtienen los siguientes resultados:
98.7, 99.3, 100.4, 97.6, 101.4, 102.0, 100.2, 96.4, 103.4, 102.0, 98.0
y 100.5. El siguiente histograma muestra los resultados obtenidos:
Figura 3.15: Histograma de mediciones de tiempo
Tomar más de una muestra en el tiempo seria una segunda prueba
el objetivo es verificar que el promedio no se encuentre
L Límite inferior
especificado Límite superior especificado
98
trasladándose hacia arriba o abajo. De suceder esto, diremos que el
proceso diseñado es inestable y su diseño deberá revisarse para
detectar las actividades (subproceso o ciclos) que producen la
inestabilidad.
El estudio de capacidad es otra prueba que permite evaluar la
capacidad de un proceso para generar productos buenos, de
manera consistente. Si el flujo de trabajo lleva implícito la
transformación de un documento, utilizando un histograma de
variaciones se puede determinar en qué medida los documentos
administrados por el proceso son entregados con la información
requerida por el usuario.
La variación de la salida podría tener sus causas en las entradas;
por ejemplo, la ausencia de documentación del cliente podría
generar solicitudes de crédito que no es posible evaluar o que
conllevan otorgamientos de créditos de alto riesgo. Este impacto
puede anticiparse utilizando una técnica llamada “Trasmisión de la
Variación”, en la cual el analista tratará de relacionar distintas
calidades de entrada y salida.
Si el equipo de análisis carece de herramientas de simulación, las
pruebas serán difíciles de conducir. En este caso, se recomienda
99
que esta fase se aproveche para su diseño, para ejecutar las
pruebas durante el prototipado del sistema, en la fase de desarrollo,
o implantación.
3.8 Documentación
3.8.1 Estudio preliminar
El formato de redacción es libre. Se considera importante lo claro y conciso que
se expone cada elemento investigado. Debe evitarse la redacción extensa, pues
únicamente se resume lo expuesto en los documentos de planeación de la
empresa o los resultados de las entrevistas o encuestas.
Para introducir el proyecto, se incluye más información que la obtenida como
parte de la metodología, para que los usuarios puedan asociar el workflow a
implantar con las necesidades de la empresa que lo impulsaron.
La siguiente tabla sugiere la estructura a utilizar:
Documento: ESPECIFICACIONES DE SISTEMA
El título del documento debe incluir el nombre del proceso al cual se aplicará la tecnología de workflow.
Capítulo 1: INTRODUCCION
Sección 1.1: Antecedentes Objetivo
Esta sección contiene los objetivos y metas del proyecto. Deben presentarse tal como se encuentren especificados en los documentos
Establecer un marco de referencia
100
que se utilizaron para formular la iniciativa de automatización o cualquier otro instrumento en el que se basó la formulación del proyecto.
En esta sección deberán enumerarse los factores que la empresa considera relevantes para el éxito del proyecto.
Responsable
Analista de Negocio
Sección 1.2: Motivadores de cambio Objetivo
Ordenados y clasificados según su área de impacto. Establecer un marco de referencia
Responsable
Analista de Negocio
Sección 1.3: Delimitación del proceso Objetivo
Se puede utilizar el diagrama de entorno para representar al proceso, sus clientes, entradas, salidas, entidades organizativas internas y entidades organizativas externas.
Las políticas y reglas de negocio que afectan el proceso deberán listarse y explicarse. Esta información ayuda a que los usuarios evalúen la vigencia de las mismas con el nuevo modelo de proceso a implantar.
Establecer un marco de referencia
Responsable
Analista de Sistema
3.8.2 Proceso actual
La información presentada recurre al lenguaje visual utilizado para construir los
diagramas y la información generada durante las validaciones. Se recomienda
que al momento de ser entregada se induzca de manera rápida a los usuarios,
para evitar interpretaciones erróneas, por desconocimiento de los elementos
sintácticos, y generar la retroalimentación deseada.
La siguiente tabla sugiere la estructura a utilizar:
101
Capítulo 2: PROCESO ACTUAL
Sección 2.1: Modelo Objetivo
Diagrama del proceso tal como se encuentra implantado en la organización. Es necesario que cada elemento representado incluya los siguientes datos:
Elemento Especificaciones
Tarea Nombre
Unidad organizativa
Roles
Duración
Trabajo efectivo
Espera
Recursos utilizados
Salida reutilizable Nombre
Estado
Conector Medio que representa
Tiempo de transferencia
Actividad origen
Actividad destino
Decisión Nombre
Tipo (binaria, múltiple)
Modalidad de bifurcación
Opción Nombre
Oportunidad de selección (%)
Fusión Nombre
Modalidad de fusión
Ir a Tarea destino
Descripción
Presentar el proceso a través de un lenguaje visual
Responsable
Analista de Sistemas
102
Entidad externa Nombre
Proceso externo Nombre
Entidad externa
Duración
Sección 2.2: Validación Objetivo
Incluye las tablas que contienen los promedios ponderados de tiempo y costo para cada caso del proceso, así como el total que es posible esperar en un entorno de producción real.
Para el caso de las simulaciones, deberán entregarse los resultados para los indicadores de desempeño sugeridos por los usuarios.
Presentar los promedios obtenidos y los resultados de las simulaciones
Responsable
Analista de Sistemas
3.8.3 Proceso meta
Esta documentación es relevante para los usuarios, analistas de negocio y
diseñadores. Estos últimos necesitan el modelo al momento de crear las
especificaciones de implantación. La estructura del contenido es similar a la
utilizada para describir el proceso actual y se presenta en la siguiente tabla:
Capítulo 3: PROCESO META
Sección 3.1: Modelo Objetivo
Diagrama del proceso tal como se espera implantar en la organización. Es necesario que cada elemento representado incluya los siguientes datos:
Presentar el proceso a través de un lenguaje visual
Documentar las especificaciones para el diseño del workflow
103
Elemento Especificaciones
Tarea Nombre
Unidad organizativa
Roles
Duración
Trabajo efectivo
Espera
Recursos utilizados
Las actividades de un proceso que estén reguladas por un procedimiento deben documentarse, utilizando los siguientes datos.
Salida reutilizable Nombre
Estado
Datos que contiene
Conector Medio que representa
Tiempo de transferencia
Actividad origen
Actividad destino
Decisión Nombre
Tipo (binaria, múltiple)
Datos utilizados
Fórmulas de evaluación
Modalidad de bifurcación
Opción Nombre
Oportunidad de selección (%)
Fusión Nombre
Modalidad de fusión
Ir a Tarea destino
Descripción
Responsable
Analista de Sistemas
104
Entidad externa Nombre
Proceso externo Nombre
Entidad externa
Duración
Sección 3.2: Validación Objetivo
Incluye las tablas que contienen los promedios ponderados de tiempo y costo para cada caso del proceso, así como el total que es posible esperar en un entorno de producción real.
Para el caso de las simulaciones, cada una debe ser descrita utilizando la siguiente información:
Característica Detalle
Entradas Indica el contenido de las distintas entradas que se utilizarán en el escenario.
Recursos Enumera cada una de las tareas que constituyen el proceso con los recursos que se le asignarán.
Tiempos Especifica las duraciones, trabajo efectivo y espera de las distintas actividades.
Medios Lista los conectores del modelo y los medios que utilizarán para transferir la información, incluyendo su impacto en tiempo.
Cada escenario debe ir acompañado de los resultados de ejecución.
Presentar los promedios obtenidos y los resultados de las simulaciones
Responsable
Analista de Sistemas
3.9 Lista de verificación para el analista
La metodología propuesta no debe considerarse como un conjunto rígido de
elementos a aplicar. Las actividades propuestas para cada una de las fases
podría variar, dependiendo de la magnitud del proyecto, el tipo de empresa, la
naturaleza del proceso y el grado de automatización de las organizaciones.
105
En la siguiente tabla se presenta una lista de actividades que puede servir como
referencia para la elaboración del plan de trabajo definitivo. Las actividades de
inicio y cierre han sido incluidas para enmarcar las distintas fases del análisis en
el contexto de un plan general de trabajo.
Actividad: Presentación de proyecto Instrumentos
Reunión de trabajo en la que los Analistas de Negocio exponen el proyecto a los Analistas de Sistemas, incluyendo los problemas detectados y las oportunidades de mejora.
Se recomienda la participación de:
Directores que brindan el apoyo al proyecto
Gerentes involucrados en el proceso
Usuarios expertos en la ejecución del proceso
Analistas de Negocio
Analistas de Sistemas
Sesión de grupo
Herramientas
Aplicaciones de oficina
Entregable
Integración del equipo de trabajo que será responsable del análisis
ESTUDIO PRELIMINAR
Actividad: Presentación de la organización Instrumentos
El objetivo es levantar los datos de la organización que se consideran necesarios para modelar el flujo de trabajo a automatizar. Parte de esta información debería estar disponible en los documentos referenciados por el Analista de Negocio al momento de presentar el proyecto.
Entrevistas
Encuestas
Recolección de documentos
Herramientas
Aplicaciones de oficina
Entregable
Perfil de la empresa
Actividad: Descripción del entorno Instrumentos
El Analista de Sistemas buscará delimitar el proceso en el cual se trabajará, estableciendo fronteras de inicio y finalización.
Diagrama de entorno
Herramientas
106
Aplicaciones de oficina
Entregable
Diagrama de entorno
Actividad: Definición de métricas Instrumentos
El negocio debe decidir qué indicadores de desempeño le interesa controlar y los niveles máximos y mínimos que está dispuesto a tolerar durante las ejecuciones de un proceso.
No aplica
Herramientas
Aplicaciones de oficina
Entregable
Lista de indicadores y niveles esperados
ANÁLISIS DEL PROCESO ACTUAL
Actividad: Modelado Instrumentos
Elaboración de un diagrama que ayude a representar la estructura del proceso que se utiliza en la organización antes de iniciar el estudio. El analista deberá decidir qué enfoque utilizar:
Descomposición
Incremental
Combinado
Lenguaje de modelado
Herramientas
Aplicaciones de oficina
Modelador de procesos
Entregable
Diagrama de proceso
Control de calidad
Verificación sintáctica
Actividad: Validación Instrumentos
El modelo de proceso terminado debe presentarse a los usuarios con los siguientes objetivos:
Estar seguro que el diagrama refleja la realidad
Establecer una línea de rendimiento para los indicadores de
desempeño que se desea monitorear
Confirmar las debilidades detectadas e incluir otras que no hayan
Promedios ponderados
Simulación
Histograma de variación
Herramientas
Aplicaciones de oficina
Modelador de procesos
107
sido consideradas Entregable
Diagrama de proceso
Líneas de referencia para el desempeño
Control de calidad
Variación de ejecución
Consistencia de las salidas
ANÁLISIS DEL PROCESO META
Actividad: Modelado Instrumentos
Elaboración de un diagrama que ayude a representar la estructura del proceso tal como los Analistas de Negocio sugieren que debería ser. Debido a que el proceso ya se encuentra documentado, el único trabajo a realizar es su conversión a un lenguaje visual técnico.
Lenguaje de modelado
Herramientas
Aplicaciones de oficina
Modelador de procesos
Entregable
Diagrama de proceso
Control de calidad
Verificación sintáctica
Actividad: Validación Instrumentos
El modelo de proceso terminado debe presentarse a los usuarios con los siguientes objetivos:
Verificar que el proceso cumple con las metas estipuladas
Lograr un consenso respecto a las mejoras que se implantarán
Simular distintos escenarios para analizar su impacto
Promedios ponderados
Simulación
Histograma de variación
Herramientas
Aplicaciones de oficina
Modelador de procesos
Entregable
108
Diagrama de proceso
Mediciones de los indicadores solicitados por el negocio
Control de calidad
Variación de ejecución
Consistencia de las salidas
3.10 Factores de éxito para el análisis
Existen diversas áreas en las que una organización debe enfocarse para
garantizar que el workflow sea analizado de manera adecuada:
La organización debe tener funciones claramente definidas y asignadas. Si esta
información no se encuentra documentada y aprobada por la dirección, se
dificultará la asignación de roles y propietarios.
Los empleados responsables de la ejecución deben participar al momento del
modelado de los procesos. Cuando se trata del proceso actual, muchas veces
los manuales disponibles en la organización no corresponden con las actividades
que se llevan a cabo. Para el caso de los modelos propuesto, es necesario
conocer si existen restricciones para aplicar el flujo como se desea, tales como
disponibilidad de equipos, medios de comunicación, horarios y personas.
109
Aunque los modelos no deben encontrarse diseñados pensando en
componentes técnicos (lenguajes de programación, sistemas operativos,
protocolos, etc.), es posible hacer referencia a soluciones existentes en la
empresa. Los procesos no pueden existir al margen de las estrategias de IS/IT
adoptadas por el negocio.
Cuando se interactúe con sistemas de información del negocio, es preferible
que el flujo de trabajo se adecue a la forma de operación de estas, evitando que
sean utilizadas en modelos para los cuales no fueron diseñadas.
Los analistas deben tener acceso a toda la información relacionada con los
actores y recursos que participan. Las validaciones propuestas son útiles en la
medida que se encuentran basadas en datos que correspondan con la realidad
del negocio.
Los analistas responsables de modelar los procesos deben ser capacitados en
el uso de los instrumentos y herramientas.
110
4 Diseño del sistema
4.1 Fundamentos
El propósito de la fase de diseño es brindar modelos de bajo nivel para el flujo de
trabajo que se desea automatizar, orientados a la incorporación de los procesos
en un WFMS e integración de las aplicaciones que participarán.
El modelado, en esta fase, consiste en relacionar las especificaciones de análisis
con aspectos técnicos de implantación. Los instrumentos que se utilizan deben
facilitar la comunicación con analistas, programadores, probadores e
implantadores. Aunque algunos usuarios tengan interés en participar las
actividades de diseño, debe tenerse en mente que los instrumentos pueden
resultar complejos.
Entre los temas actuales que más frecuentemente se discuten en el ámbito de
las soluciones de workflow se encuentran la arquitectura cliente/servidor de tres
capas y UML. Aunque existen avances individuales, adoptados e impulsados por
distintas empresas y discutidos sobre una amplia variedad de plataformas, son
pocos los intentos realizados para integrar estos conceptos en una sola teoría
unificadora con un ámbito de aplicación amplio.
111
Este capítulo aborda un primer paso en esta dirección, el diseño de sistemas,
respondiendo a la pregunta de cómo pueden modelarse los procesos de negocio
basados en workflow – independientemente de las herramientas que la empresa
decida utilizar para administrarlos. Los instrumentos expuestos han sido
extraídos de UML. De todos los diagramas utilizados como parte de la notación
gráfica sugerida por este estándar, los de actividad y estado son los que
justifican su adopción, como se demostrará más adelante.
El tema de Cliente/Servidor cobra importancia al momento de la implantación.
Las siguientes consideraciones han sido incluidas en este capítulo para que el
diseñador comprenda el ámbito de su labor y evite invertir esfuerzos en la
creación de especificaciones que existen fuera del alcance de la solución,
aunque constituyen elementos de apoyo fundamentales.
El modelo se basa en la diferenciación y distribución de las funciones de un
sistema en capas, tal como se muestra en la siguiente figura:
112
Figura 4.1 Arquitectura Cliente/Servidor de tres capas.29
En la capa inferior, llamada de persistencia, se encuentran ubicados todos los
datos que necesita la aplicación. En la segunda capa, se encuentra la lógica de
las aplicaciones de negocio, adoptando la forma de Objetos de Negocio (BO,
Business Objects). Es en esta capa que se implantarán las especificaciones de
diseño, a manera de Objetos de Proceso (PO, Process Objects), responsables
de describir los elementos que constituyen los flujos de trabajo (ver Figura 4.2).
El sistema de administración de workflow contiene dichos objetos y define la
secuencia de las actividades sobre los Objetos del Negocio.
29 “Business Objects, Workflow und die UML”, OBJEKTSpectrum, Número 3, 1999, SIGS-DATACOM Alemania.
113
Figura 4.2 Arquitectura sugerida para un sistema basado en workflow
Las herramientas requeridas en esta fase suelen ser aplicaciones de modelado.
Se consideran necesarias para las soluciones de gran escala, pues las
metodologías actuales de diseño, tales como UML, son lo suficientemente
complejas como para exigir los ingenieros de sistemas que se elaboren los
diagramas en forma manual. Muchas de estas herramientas tienen la capacidad
de exportar el diseño a código de implantación, lo que ayudaría a reducir
significativamente el esfuerzo en las siguientes actividades del ciclo de
desarrollo30.
Para completar esta fase se suelen requerir entre cuatro y diez semanas,
dependiendo de la experiencia del equipo de trabajo, las herramientas de
modelado disponibles y el alcance de la aplicación.
30 Estas herramientas suelen considerarse dentro de la categoría de aplicaciones CASE y, por lo general, su costo tiende a ser excesivamente alto. Un rango de precios común suele ser entre los US$10,000.00 y US$75,000.00, dependiendo si generan modelos propietarios o estándares, siendo estas ultimas las más caras.
Aplicaciones
Objetos de
ProcesoObjetos de
Negocio
Persistencia
Aplicaciones
Objetos de
ProcesoObjetos de
Negocio
Persistencia
114
Normalmente, en esta actividad participan los analistas de negocios, brindando
descripciones para los componentes del flujo y validando la secuencia de las
actividades en los diagramas, y los analistas de sistemas (ingenieros de
desarrollo o programadores), cuyo rol será garantizar que el modelo generado
cumpla con los requerimientos establecidos por el estándar utilizado.
4.2 Metodología
La metodología de análisis propuesta en este trabajo puede representarse con
ayuda del siguiente diagrama:
Figura 4.3 Fases para la conducción del diseño
Cada una de las actividades listadas para las distintas fases demandan
conocimiento de UML y experiencia en su aplicación. El contenido se enfoca en
el uso del lenguaje para resolver situaciones de workflow y no en la
diagramación completa de los procesos.
A efecto de facilitar la lectura de los conceptos presentados, la metodología,
instrumentos y ejemplos han sido incluidos en una sola sección, siguiendo el
Modeladodel flujo detrabajo- Identificaciónde patrones
- Diagramación deactividades
Modeladode los roles- Diagramación de“swimlanes”
Modeladode las salidasreutilizables- Diagramaciónde estados
- Diagramaciónde transiciones
Modeladode losprocedimientos- Diagramación desecuencias
Modeladodel flujo detrabajo- Identificaciónde patrones
- Diagramación deactividades
Modeladode los roles- Diagramación de“swimlanes”
Modeladode las salidasreutilizables- Diagramaciónde estados
- Diagramaciónde transiciones
Modeladode losprocedimientos- Diagramación desecuencias
115
orden indicado. Estos últimos están estructurados en modelos pequeños, con
alcance limitado, generalmente orientados a la solución que se desea explicar,
debido a que resulta difícil forzar un caso de estudio que contenga todas las
posibles variantes.
Al igual que en el análisis, el control de calidad se expone en una sección
independiente, aunque no se considera una fase de la metodología, sino una
actividad inherente a todas.
4.2.1 Modelado del flujo de trabajo
Actualmente, no existe un lenguaje grafico estándar para modelar workflow.
Recientemente los diagramas de actividad UML han surgido como un estándar
de-facto para el modelado de los flujos de trabajo. Su objetivo es representar qué
participante realiza cuál actividad y en qué momento.
Esta sección busca justificar el uso de los diagramas de actividad para
representar un sistema de workflow, comprobando sistemáticamente la
capacidad de estos para modelar un conjunto de patrones de workflow31,
definidos como “formas abstractas de situaciones recurrentes relacionadas con
31 La aplicación de esta noción en el ámbito de workflow fue presentada por primera vez por W. M. P. van der Aalst en la “Quinta Conferencia Internacional sobre Sistemas de Información Cooperativos”, en Eilat, Israel, el mes de septiembre de 2000 y analizada en marzo de 2001 por el BETA Research Institute. Consultar http://tmitwww.tm.tue.nl/research/patterns. Entre los evaluadores de estos patrones se encuentra prestigiosas casas de software o consultoria, tales como: COSA, FLOWer, Domino Workflow, Eastman, Visual Workflow, Forte Conductor, Meteor, Mobile, MQSeries/Workflow, Staffware, Verve Workflow, I-Flow, InConcert, Changengine y SAP R/3 Workflow.
116
el orden de las actividades en un flujo de trabajo y las interacciones entre ellas”.
De acuerdo con la funcionalidad que soportan, estos pueden clasificarse en:
Patrones de sincronización.
Patrones basados en estado.
Patrones productor-consumidor.
El contenido de las siguientes secciones ha sido estructurado de la siguiente
forma:
Descripción del patrón.
Caso en que podría utilizarse.
Soporte disponible en los WFMS.
Diagrama de actividad.
Ejemplo.
Para el último punto se recurre al modelo de investigación de solicitudes utilizado
en el capítulo anterior (ver Sección 3.5: “Caso práctico: Modelado avanzado”).
Las actividades de interés se adaptan de acuerdo con el tema a tratar y el
resultado se presenta en una tabla con los siguientes apartados:
117
Modificaciones necesarias para aplicar el patrón.
Modelo UML asociado.
4.2.1.1 Patrones de sincronización
Corresponden a situaciones en las cuales una o varias actividades simultáneas
necesitan ser completadas antes que otra actividad sea iniciada. Se consideran
dentro de esta categoría los siguientes casos:
Discriminador.
Unión N-de-M.
Múltiples instancias de una actividad.
4.2.1.1.1 Discriminador
Es un punto dentro de un workflow compuesto por múltiples hilos de ejecución,
en el que se espera a que uno termine antes de activar la siguiente actividad del
flujo. Cuando los restantes finalizan son “ignorados”, pero no se aceptarán
nuevas ejecuciones hasta que la última rama entrante termine.
Un ejemplo podría ser una consulta compleja que es enviada a dos diferentes
bases de datos a través de Internet (ver Figura 4.4). Tan pronto como una
118
entrega el resultado la ejecución del flujo continua. El segundo resultado es
ignorado.
Figura 4.4: Consulta por internet utilizando un patrón discriminador32.
En la mayoría de los WFMS, el discriminador no puede ser modelado a nivel
conceptual33. Una excepción notable es Verve34, que ofrece un constructo35
específico para este patrón. En el workflow de SAP R/336 es posible indicar
cuántas de las ramas iniciadas por una bifurcación deben ser esperadas por una
unión. A diferencia de la especificación anterior, el producto marca las ramas
como “lógicamente borradas”, una vez que la primera ha terminado. Para el caso
de Lotus Workflow cuando el hilo de control primario finaliza, el resto queda
suspendido; es decir, no disponibles para los usuarios aunque presentes en
memoria.
32 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002. 33 W.M.P. Van Der Aalst, A.H.M ter Hofstede, B. Kiepuszewski, and A. Barros. Workflow patterns. Technical Report WP 47, BETA Research Institute, 2000. Accessed March 2001 from http://tmitwww.tm.tue.nl/research/patterns. 34 ver sitio http//www.verve.com ó http://www.versata.com. 35 Elemento sintáctico para la creación de modelos. 36 ver sitio http://www.sap.com
InternetInternetBase de datos
Consulta consulta
ResultadoResultado
Base de datos
InternetInternetBase de datos
Consulta consulta
ResultadoResultado
Base de datos
119
En UML el discriminador se representa como un conjunto de regiones de una
actividad, las cuales se comunican a través de señales y que contienen los hilos
de ejecución entrantes y saliente. Cuando la actividad se inicia, las regiones
correspondientes a las ramas entrantes del discriminador son ejecutadas
simultáneamente, mientras que la región correspondiente a la rama de salida se
encuentra en estado de espera. Cuando una de estas termina, se produce una
señal (e) que permite a la rama saliente continuar con su ejecución (Ver Figura
4.5).
Figura 4.5: Diagrama de actividad para representar un discriminador.37
La representación anterior no corresponde completamente con la definición del
discriminador. Considere, por ejemplo, la situación descrita en la Figura 4.6. El
modelo obliga a una sincronización no deseada entre las actividades B, C y D;
específicamente, si B finaliza antes que C, D es iniciada. Ahora, si D finaliza
antes que C y la condición guarda ([cond]) se cumple, la actividad A no puede
37 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
120
ejecutar inmediatamente, ya que debe esperar a que termine la actividad C.
Esta restricción no es impuesta por la semántica del discriminador.
Figura 4.6: Patrón discriminador como parte de un ciclo.38
A continuación se muestra la manera en que el patrón podría aplicarse al
ejemplo de investigación de solicitudes del capítulo anterior:
Modificaciones necesarias para aplicar el patrón
Para redactar la respuesta al cliente basta con tener los resultados de una de
las investigaciones.
Ambas investigaciones tienen la misma validez para la empresa.
38 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
Discriminador
(a) Descripción Informal (b) Expresado como un diagrama de actividad de UML
Discriminador
(a) Descripción Informal (b) Expresado como un diagrama de actividad de UML
121
Modelo UML asociado
Figura 4.7: Utilización del discriminador para representar la creación de una respuesta que depende de un solo informe.
4.2.1.1.2 Uniones N-de-M
También es conocida con el nombre de Unión Parcial39. Este tipo de situación en
un workflow sucede cuando M ramas en paralelo deben converger en una sola.
La rama saliente debe iniciar una vez que N ramas entrantes hayan terminado.
La terminación de las restantes debe ser ignorada. El discriminador puede
considerarse una unión del tipo 1 de N.
39 F. Casati, S. Ceri, B. Pernici, and G. Pozzi. Conceptual modeling of workflows. In Proc. of the 14th International Object-Oriented and Entity-Relationship Modelling Conference (OOER'95), pages 341-354. Springer Verlag, December 1995.
Solicitud de cliente
Investigación de Mercadeo
Investigación de Desarrollo
Informe de Mercadeo
Informe de Mercadeo
/enviar informe
/enviar informe
Esperar investigación Crear respuestainforme
Respuesta
122
Un ejemplo de unión parcial es cuando un documento tiene que ser enviado a
tres revisores externos. Una vez que se hayan recibido dos revisiones, el
documento puede ser procesado. La tercer revisión puede ignorarse (Ver Figura
4.8).
Figura 4.8 Documento con revisores externos – Patrón uniones N-de-M.40
Los WFMS comerciales lo tratan de manera similar al discriminador, excepto que
se introduce un contador que permite dar seguimiento al número de señales
enviadas por las ramas entrantes.
40 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
reviewer Areviewer Areviewer Areviewer A reviewer Breviewer Breviewer Breviewer B reviewer Creviewer Creviewer Creviewer C
paperpaperpaperpaper
reviewer Areviewer Areviewer Areviewer A reviewer Breviewer Breviewer Breviewer B reviewer Creviewer Creviewer Creviewer C
paperpaperpaperpaper
reviewer Areviewer Areviewer Areviewer A reviewer Breviewer Breviewer Breviewer B reviewer Creviewer Creviewer Creviewer C
paperpaperpaperpaper
Documento
Revisor A
Revisor B
Revisor C
123
Bajo el esquema de la Figura 4.9, la rama de salida es iniciada cuando llega la
señal de terminación N - 1. Cuando la unión N-de-M es parte de un ciclo, la
solución de los diagramas de actividad se encuentra con la misma limitante que
el patrón del discriminador.
Figura 4.9: Diagrama de actividad para representar un patrón uniones N-de-M.41
A continuación se muestra la manera en que el patrón podría aplicarse al
ejemplo de investigación de solicitudes del capítulo anterior:
Modificaciones necesarias para aplicar el patrón
El número de investigaciones a realizar tiene que ser mayor que dos.
La respuesta requiere de los resultados de dos investigaciones.
Modelo UML asociado
41 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
124
Figura 4.10: Utilización del N-de-M para representar la creación de una respuesta que
depende de dos de las tres investigaciones posibles.
4.2.1.1.3 Múltiples instancias de una actividad
Es un punto en un workflow donde una actividad A se activa varias veces, de
manera simultánea, y es necesario que todas hayan finalizado para poder
continuar con la actividad B. El número de instancias que necesitan ejecutarse
se conoce cuando se llega a dicha actividad.
Este puede ser el caso de una requisición de N artículos hacia M ubicaciones
distintas y la cual podrá cerrarse hasta que todos las entregas hayan sido
cumplidas (ver Figura 4.11). Muchos WFMS no dan soporte a este concepto.
Solicitud de cliente
Investigación Mercadeo
Informe de Mercadeo
/enviar informe
Esperar investigación Crear respuestainforme
[i < (N - 1)]
Respuesta
Investigación Ventas
Informe de Ventas
/enviar informe
N := 2i := 0
informe[i < (N - 1)]/i := i + 1
Investigación Desarrollo
Informe de Desarrollo
/enviar informe
125
Figura 4.11 Requisición de Computadoras – Patrón “múltiples instancias de una actividad”.42
Dentro de un diagrama de actividad, es posible indicar que múltiples
invocaciones de una actividad se ejecutarán simultáneamente; característica
conocida con el nombre de invocación dinámica. La multiplicidad dinámica de un
estado es el máximo número permitido de invocaciones y se indica con un
numeral en la esquina superior derecha de la tarea (representando con un
asterisco la ausencia de limites). Este estado se abandonará cuando todas las
invocaciones asociadas sean completadas. Si una de estas es abortada por un
evento externo, todas las invocaciones se abortaran también. La diagramación
de una invocación dinámica se representa en siguiente figura:
42 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
…
100 solicitantes
…
EnvEnvEnvEnvíos concurrentesos concurrentesos concurrentesos concurrentes
…
100 solicitantes
…
EnvEnvEnvEnvíos concurrentesos concurrentesos concurrentesos concurrentes
…
100 solicitantes
…
EnvEnvEnvEnvíos concurrentesos concurrentesos concurrentesos concurrentes
126
Figura 4.12 Diagrama de actividad para representar una invocación dinámica.43
A continuación se muestra la manera en que el patrón podría aplicarse al
ejemplo de investigación de solicitudes del capítulo anterior:
Modificaciones necesarias para aplicar el patrón
Un cliente puede presentar varias solicitudes en una transacción.
Las respuestas deben presentarse en un solo informe.
Modelo UML asociado
Figura 4.13: Utilización del discriminador para representar la creación de una respuesta que depende de un solo informe.
43 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
Solicitud deinvestigacióndel cliente
*Respuesta
127
4.2.1.2 Patrones basados en estado
Corresponden a situaciones en donde los recursos humanos o materiales no se
encuentran disponibles y las actividades pasan por estados de espera antes de
su procesamiento. Se consideran dentro de esta categoría los siguientes casos:
Selección diferida.
Encaminamiento paralelo alternado.
4.2.1.2.1 Selección diferida
Consiste en un punto del workflow donde una de muchas ramas es escogida
basándose en alguna información externa, la cual no necesariamente estará
disponible cuando este punto se alcance. Esto difiere de la selección normal, en
que no es hecha de manera explicita (basada en datos existentes), sino que
múltiples alternativas son presentadas al entorno y la selección de estas es
diferida o aplazada hasta que se recibe una señal externa.
Utilizando la terminología de los WFMS, esto significa que las actividades
alternativas son colocadas en listas de trabajo, pero tan pronto como una de
estas inicia su ejecución, las otras son descartadas.
128
Un ejemplo de esto podría ser la finalización de un contrato, el cual debe ser
firmado ya sea por el director o por el director adjunto y la secretaria, quienquiera
que se encuentre disponible primero, como se muestra en la siguiente figura:
Figura 4.14 Contrato con firmas de responsable disponible – Patrón Selección Diferida44.
En algunos WFMS la selección diferida es manejada al nivel de implantación
utilizando mensajes de cancelación, pero esta solución no funcionara siempre
debido a problemas de concurrencia.
44 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
contrato
OROROROR
directordirectordirectordirector secretarsecretarsecretarsecretariaiaiaia director adjuntodirector adjuntodirector adjuntodirector adjunto
Firmado Firmado
++++
contrato
OROROROR
directordirectordirectordirector secretarsecretarsecretarsecretariaiaiaia director adjuntodirector adjuntodirector adjuntodirector adjunto
Firmado Firmado
++++
129
Figura 4.15 Diagrama de actividad para representar la selección diferida.45
Utilizando diagramas de actividad, la selección diferida puede ser expresada
como un estado normal que espera la ocurrencia de un evento en el entorno y
selecciona una de las ramas salientes según el evento. Tal como se muestra en
la Figura 4.15.
A continuación se muestra la manera en que el patrón podría aplicarse al
ejemplo de investigación de solicitudes del capítulo anterior:
Modificaciones necesarias para aplicar el patrón
Las solicitudes de investigación esperan en una bandeja de entrada.
Cada departamento decide qué solicitud investigar.
Las solicitudes que no necesitan investigación deben evaluarse en forma
manual.
45 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
130
Modelo UML asociado
Figura 4.16: Modelo para la decisión de investigaciones a realizar utilizando el patrón de selección diferida.
En la práctica esta selección podría estar asociada con un “menú de selección
del usuario”: (a) no conducir investigación, (b) conducir ambas investigaciones,
(c) conducir solamente una investigación de Mercadeo y (d) conducir solamente
una investigación de Desarrollo. La decisión dejaría de ser diferida si a partir de
los datos de la solicitud del cliente el sistema puede decidir de manera
automática la ruta a seguir en el diagrama de actividad.
Investigación de Desarrollo
investigación de Desarrollo
investigación de Mercadeo
Seleccionar investigación
Crear respuesta con información disponible
Investigación de Mercadeo
sin investigación
Analizar solicitud
131
4.2.1.2.2 Encaminamiento paralelo alternado
En este patrón un conjunto de actividades {A1, A2..., An} necesitan ejecutarse en
un orden arbitrario y cada una se ejecuta una sola vez. El orden a seguir es
decidido en tiempo de ejecución; hasta que una actividad es completada se toma
la decisión sobre cual se ejecutará a continuación. En cualquier caso, no
existirán dos ejecuciones simultáneas.
Lo anterior podría aplicar al caso de una empresa en la que un candidato para
un puesto de trabajo necesita realizar tres pruebas: una óptica, una medica y una
mental. Estas pueden realizarse en cualquier orden aunque, por razones obvias,
no al mismo tiempo. Cuando se termina una prueba, la decisión sobre cuál
realizar a continuación se toma en base a la disponibilidad de los médicos.
Muchos WFMS pueden soportar este patrón a nivel conceptual. A nivel de
implantación, puede ser programado introduciendo un recurso compartido por
todas las actividades. Este recurso actúa como un semáforo, obligando la
serialización.
En UML el patrón puede ser expresado en términos de una selección diferida,
realizada entre n ramas, de manera que la i-ésima inicie con la actividad Ai (1 < i
> n). En la rama que conduce a la actividad A1, otra selección diferida es
realizada (después de que A1 ha sido ejecutada) entre n -1 ramas, iniciando con
132
A2...,An. Este proceso de selecciones diferidas anidadas es recursivamente
repetido hasta que todas las permutaciones de A1...,An sean completadas.
Una mejor opción es obligar la alternabilidad de las actividades, colocando cada
una de ellas en una región concurrente independiente y bloqueando su ejecución
a través de estados de sincronización que emanan de una sola “región de
bloqueo”, generalmente la de más a la izquierda. Una estafeta es insertada en el
estado de sincronización para bloquear una actividad Ai hasta que se presente el
evento que habilita la ejecución de la misma. Cuando Ai inicia su ejecución, la
región de bloqueo entra en un estado que difiere las ocurrencias de eventos que
pueden desbloquear la ejecución de las otras actividades. Por ejemplo, en la
Figura 4.17, los eventos s1, s2 y s3 son utilizados para indicar que las
actividades A1, A2 y A3 pueden ser ejecutadas, respectivamente. Si uno de esos
eventos ocurre mientras una de las actividades está en ejecución, el
procesamiento de esta ocurrencia es diferido hasta que la ejecución de la
actividad disparada ha completado.
133
Figura 4.17: Patrón encaminamiento paralelo alternado.46
A continuación se muestra la manera en que el patrón podría aplicarse al
ejemplo de investigación de solicitudes del capítulo anterior:
Modificaciones necesarias para aplicar el patrón
La solicitud del cliente se relaciona con un artículo que debe pasar por
distintas pruebas en varios laboratorios.
Todas las pruebas deben ser aplicadas al artículo antes de poder dar una
respuesta al cliente.
46 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
134
Modelo UML asociado
Figura 4.18: Utilización del encaminamiento paralelo alternado para representar de una respuesta
4.2.1.3 Patrones productor-consumidor
Son propios de los sistemas distribuidos y corresponden a situaciones donde
múltiples instancias de una actividad A (el productor) son ejecutadas
secuencialmente y la terminación de cada una de estas instancias desencadena
la ejecución de una instancia de otra actividad B (el consumidor). A y B se
ejecutan simultáneamente, aunque existe una interdependencia entre ellas (B es
ocasionada por A). Se consideran dentro de esta categoría los siguientes casos:
Productor-consumidor con actividad de terminación
PruebaLaboratorio 1
/enviar informe
Esperar solicitudde prueba
s1/diferirs2/diferir
PruebaLaboratorio 2
/enviar informe
i := 3
informe[i >1]/i := i - 1
s1
s2
informe[i = 1]
135
Productor-consumidor con cola saturada
4.2.1.3.1 Productor-consumidor con actividad de terminación
Involucra tres actividades (A, B y C) y el proceso inicia con la ejecución de una
instancia de A. Cuando esta termina, una de B es habilitada. Simultáneamente,
una segunda de A puede ser iniciada, para activar otra instancia de B cuando
haya terminado. El proceso continúa, de manera que en cualquier punto del
tiempo las siguientes condiciones se mantienen:
Al menos una instancia de A estará corriendo.
La ejecución de la i-ésima de B no iniciará antes de que la i-ésima instancia de
A haya finalizado.
Cuando todas las instancias de A hayan finalizado, el sistema continuará
ejecutando instancias de B hasta que el número de las ejecuciones finalizadas
de B sea igual a las de A, momento en que se ejecuta la instancia de C.
Un ejemplo es la compra en una sucursal virtual (ver Figura 4.19). Cada vez que
el cliente ordena un artículo, el sistema debe contactar al proveedor adecuado
para verificar la disponibilidad del artículo y el tiempo estimado de entrega. Una
vez que el cliente establece que no desea ningún otro artículo, y que las
136
disponibilidades han sido verificadas, se envía un correo con la lista de todos los
productos disponibles y su tiempo de entrega.
Figura 4.19: Compra en una sucursal virtual – Patrón productor-consumidor.47
Suele estar disponible en aquellos WFMS que dan soporte a "múltiples
instancias con sincronización". Sin embargo, es posible limitar la descripción de
este patrón a un caso donde a lo sumo una instancia de B estará ejecutándose a
la vez, para poder diagramarlo en términos de discriminador, ciclos y contadores.
De hecho, este es el enfoque que se adopta para poder representar el patrón
con UML.
En el diagrama de actividad (ver Figura 4.20), las instancias de la actividad A y B
corren en dos regiones concurrentes de otra actividad compuesta. Cada vez que
47 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
V1 V2 V3 V4
< Correo electrónico >
customercustomercustomercustomer
OrdeOrdeOrdeOrden de n de n de n de V3V3V3V3’artartartartículosculosculosculos
comprobar disponibilidad de artcomprobar disponibilidad de artcomprobar disponibilidad de artcomprobar disponibilidad de artículoculoculoculoplazo de entrega esperadoplazo de entrega esperadoplazo de entrega esperadoplazo de entrega esperado
No desea otro artNo desea otro artNo desea otro artNo desea otro artículoculoculoculo
Lista de productos disponiblesLista de productos disponiblesLista de productos disponiblesLista de productos disponiblesTiempo de entrega de productosTiempo de entrega de productosTiempo de entrega de productosTiempo de entrega de productos
V1 V2 V3 V4
< Correo electrónico >
customercustomercustomercustomer
OrdeOrdeOrdeOrden de n de n de n de V3V3V3V3’artartartartículosculosculosculos
comprobar disponibilidad de artcomprobar disponibilidad de artcomprobar disponibilidad de artcomprobar disponibilidad de artículoculoculoculoplazo de entrega esperadoplazo de entrega esperadoplazo de entrega esperadoplazo de entrega esperado
No desea otro artNo desea otro artNo desea otro artNo desea otro artículoculoculoculo
Lista de productos disponiblesLista de productos disponiblesLista de productos disponiblesLista de productos disponiblesTiempo de entrega de productosTiempo de entrega de productosTiempo de entrega de productosTiempo de entrega de productos
137
una instancia de A es completada, esta establece una estafeta en estado de
sincronización e incrementa un contador i. Cada una de las estafetas generadas
por la terminación de una instancia de A activan una transición que conlleva la
ejecución de una instancia de la actividad B. Cuando una instancia de la
actividad B ha terminado, una segunda estafeta es colocada en estado de
sincronización. Una vez que todas las instancias de A han finalizado, las
estafetas de este segundo estado de sincronización son “consumidas” una tras
otra, decrementando el contador i. Cuando el valor del contador llega a cero,
significa que B fue ejecutada tantas veces como A. El estado compuesto es
abandonado y C es ejecutada una sola vez.
Figura 4.20: Diagrama de actividad para representar un patrón productor-consumidor con
actividad de terminación.48
48 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
138
Esta solución ha sido diseñada de manera que en cualquier punto del tiempo, a
lo sumo una instancia de B estará corriendo.
A continuación se muestra la manera en que el patrón podría aplicarse al
ejemplo de investigación de solicitudes del capítulo anterior:
Modificaciones necesarias para aplicar el patrón
El cliente puede presentar múltiples solicitudes.
Las solicitudes pueden ocurrir en cualquier momento.
No es necesario que una investigación haya terminado para iniciar con otra.
Hasta que se hayan procesado todas las solicitudes e investigaciones se
creará una respuesta.
139
Modelo UML asociado
Figura 4.21: Modelo para el procesamiento de solicitudes utilizando el patrón productor-consumidor con actividad de terminación.
4.2.1.3.2 Productor-consumidor con cola saturada
Es similar al anterior, excepto que en cualquier momento, la diferencia entre el
número ejecuciones de la actividad A y B es limitada por un número entero
llamado tamaño de la cola.
Crear solicitud
Investigarsolicitud
Esperar solicitud
Esperar informe
Crearrespuesta
140
Un ejemplo es la obtención de una tarjeta de identificación de estudiante en una
universidad (Ver figura 4.22), en la cual el solicitante debe llenar un formulario y
presentarlo a un supervisor para su verificación. Una vez que este ha sido
revisado, la solicitud es enviada al área de fotografía. Sin embargo, la cola que
conduce desde el mostrador del supervisor hasta el área de fotografía no puede
contener más de cinco personas. Si llegara a este nivel, se dejarían de recibir
solicitudes hasta que una de las personas sea atendida por el área de fotografía.
Figura 4.22: Obtención de identificación de estudiante – Patrón productor-consumidor con cola
saturada.49
El diagrama de actividad debe modificarse de manera que se lleve control sobre
dos contadores (ver Figura 4.23): uno para las ejecuciones de A y otro para las
de B. Cada vez que la actividad A es finalizada, si la variable booleana "más” es
verdadera, un estado de espera es iniciado, el cual podrá ser abandonado
solamente cuando “contador de A – Contador de B < tamaño de la cola”.
49 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
5 5 5 5 sillassillassillassillas
aplicanteaplicanteaplicanteaplicante
fotfotfotfotógrafografografografo
Staff de oficinaStaff de oficinaStaff de oficinaStaff de oficina
5 5 5 5 sillassillassillassillas
aplicanteaplicanteaplicanteaplicante
fotfotfotfotógrafografografografo
Staff de oficinaStaff de oficinaStaff de oficinaStaff de oficina
141
Figura 4.23: Diagrama de actividad para representar un patrón productor-consumidor con cola saturada.50
A continuación se muestra la manera en que el patrón podría aplicarse al
ejemplo de investigación de solicitudes del capítulo anterior:
Modificaciones necesarias para aplicar el patrón
Por la naturaleza del servicio ofrecido en el caso de estudio, no es posible
implantar este modelo en un entorno de producción real, pues esto implicaría
que:
La empresa no asume la responsabilidad de dar soporte a sus clientes
cuando existen más de cinco solicitudes en cola.
50 UML Activity Diagrams as a Workflow Specification Language, Marlon Dumas and Arthur H.M., University of Tecnology, Australia. 2002.
142
4.2.2 Modelado de los roles
Una vez terminada la modelación del flujo de trabajo podemos convertirlo a un
Swimlane, propuesto por UML para indicar el responsable de ejecutar las
actividades. Este diagrama es mostrado como un conjunto de regiones
separadas de las vecinas por líneas verticales sólidas y etiquetas en la parte
superior con los nombres de los roles, tal como se muestra a continuación:
Figura 4.24: Diagrama de actividad swimlane.51
No existe una regla que obligue a utilizar el nombre del rol, pues siendo un
diagrama UML su semántica es independiente de cualquier implantación. Si
observamos “Cliente”, “Ventas” y “Bodega” son actores, siendo el primero una
persona y los otros dos unidades organizativas.
51 http://etna.int-evry.fr/COURS/UML/notation/notation10.html.
Cliente Ventas Bodega
Solicitudes
Pago
Tomar orden
Llenar orden
Entregar orden
Reunir Orden
143
4.2.3 Modelado de las salidas reutilizables
Aunque el flujo de trabajo puede modelarse estrictamente en términos de un
diagrama de actividad, no es posible representar los estados por los que pasa
(evoluciona) la información. Esto se debe a que los diagramas de actividad
resaltan lo que se hace dentro del proceso.
Para modelar los procesos como un conjunto de estados por donde pasa la
información sobre la cual se trabaja en las distintas actividades, resaltando sobre
que se trabaja dentro del proceso, es necesario recurrir a dos instrumentos
adicionales:
Diagrama de estados.
Diagrama de transiciones.
4.2.3.1 Diagramación de los estados
Describen la evolución que sufre la información a lo largo de un flujo de trabajo.
Se preocupan por representar el ciclo de vida de un elemento, en el cual este es
creado, conoce, hace y comunica algo a otros elementos, atiende solicitudes y
es destruido. Se entenderá como estado una condición o situación específica de
un elemento.
144
En workflow cuando se habla de documento se hace referencia a cualquier
conjunto de datos en una instancia de un proceso, agrupados con independencia
de su estructura de almacenamiento o de la forma de acceso a ellos. Si
tomamos como ejemplo las fases por las que pasa una orden de venta, el
diagrama de estado resultante sería:
Figura 4.25: Procesamiento de una orden de venta.52
No es posible hacer una correspondencia directa entre los diagramas de estado
y los diagramas de actividad, aunque existen elementos que puedan
relacionarse.
52 UML A Beginner’s Guide, Jason T. Roff, primera edición 2003, Mc Graw Hill, USA.
Vacía Validada
En ProcesoCancelada
Procesada
Pago exitoso
Pago presentado
Método de pago
falló
Ítem agregado
Cancelada
Procesada
Pago exitoso
Pago presentado
Método de pago
falló
Ítem agregado
Debitada aInventario
145
4.2.3.2 Diagramación de las transiciones
Una dificultad adicional que es relacionar las salidas reutilizables con las
actividades que las generan y las consumen. UML proporciona dos mecanismos
para representar las transiciones:
Flujo de control
Flujo de objetos
El primero es el utilizado por los diagramas de actividad, para indicar el sentido
del avance, utilizando líneas sólidas del origen al destino. Son conocidas con los
nombres de transiciones por omisión o transiciones automáticas, por no estar
etiquetadas y dispararse tan pronto como el estado de acción origen termina su
procesamiento.
El segundo tipo se utiliza para indicar los objetos que entran o salen de los
estados de acción. Es representado con flechas punteadas que van del origen al
objeto que conforma el flujo y de este objeto al estado de acción destino (ver
Figura 4.26). Si una transición de flujo de objeto indica el orden de los estados de
acción, la transición de flujo de control puede omitirse.
146
Como podemos ver, una transición de flujo de objeto puede utilizarse para
modelar “salidas reutilizables”, lo que facilita representar un concepto del dominio
del problema en el dominio de la solución.
Figura 4.26: Transición de flujo de objeto.53
Aplicando los aspectos de diseño expuestos y retomando el modelo de proceso
para atención de ordenes de venta utilizado en el capítulo anterior para exponer
la metodología de análisis, el diagrama de actividad del proceso sería:
53 Learning UML, Communicating Software Design Graphically, Sinan Si Alhir, O’Reilly, primera edición, julio 2003.
Ingresar solicitud de materiales
Autorizar solicitud de materiales
Crear orden de compra
Solicitud de materiales
Solicitud de materiales autorizada
Ingresar solicitud de materiales
Autorizar solicitud de materiales
Crear orden de compra
Solicitud de materiales
Solicitud de materiales autorizada
147
Figura 4.27: Diagrama de actividad para el procesamiento de una orden de venta.
Orden
Procesar orden de cliente
Orden de venta
Procesar orden de empresa Digitar orden del cliente
[Orden telefónica]
[Orden B2C]
[Orden B2B]
Obtener información del crédito (subproceso)
Rechazar orden de venta
Emitir orden de trabajo
Orden de venta
Revisar crédito(subproceso)
Orden de venta
Orden de trabajo
Notificación de rechazo
[Crédito aprobado]
[Crédito rechazado]
[Línea de crédito no existe]
[Línea de crédito existe]
Revisar disponibilidad de crédito
Orden de venta
148
El ejemplo anterior muestra únicamente patrones simples de workflow. Las
decisiones (representadas con ayuda de rombos) son elementos de modelado
opcionales que añaden legibilidad al diagrama; UML soporta las bifurcaciones
con opción sin necesidad de “decisiones”, ya que son las guardas
(representadas entre corchetes) las que determinan el flujo a seguir.
Durante la exposición de la metodología de análisis se abordó el estudio de un
proceso en el cual un cliente presenta un reclamo respecto a un producto que ha
comprado y que genera un proceso de investigación en la empresa para dar
respuesta al cliente, este proceso permite utilizar el concepto de sincronización
en el modelado, tal como se muestra en la Figura 4.28.
149
Figura 4.28: Diagrama de secuencia para la tramitación de un reclamo de cliente.
Reclamo
Crear solicitud
Solicitud de cliente
Investigación de Desarrollo
Informe de Dearrollo
[Investigación de Desarrollo]
[Investigación de Mercadeo]
Analizar solicitud
Solicitud de cliente
Crear respuesta con información disponible
Investigación de Mercadeo
[Investigación no necesaria]
Informe de Mercadeo
Consolidar investigaciones
Investigación
Respuesta
Revisar respuesta
Respuesta
Crear respuesta con resultados de investigación
Solicitud de cliente Respuesta
150
En el caso anterior, el paralelismo puede o no presentarse, dependiendo del
resultado del estado de la actividad “Analizar solicitud”. Si las reglas del negocio
exigieran la conducción de ambas investigaciones, la siguiente modificación seria
necesaria:
Figura 4.29: Diagrama de secuencia parcial para representar investigaciones simultaneas.
Investigación de Desarrollo
Informe de Dearrollo
[Investigación necesaria]
Investigación de Mercadeo
Informe de Mercadeo
Consolidar investigaciones
Solicitud de cliente
151
4.2.4 Modelado de los procedimientos
Con los diagramas anteriores se ha logrado representar la funcionalidad del
negocio. Sin embargo, ninguno ha brindado información suficiente a los
programadores respecto a las micro actividades que es necesario implantar para
que el sistema desarrollado se comporte de acuerdo a lo esperado por los
usuarios. Por ejemplo, no es posible deducir en qué momento realizar la
autenticación, autorización, verificación, codificación, almacenamiento, creación
de estructuras temporales, actualización de bitácoras o procedimientos similares.
Para modelar las interacciones entre los objetos y actores de un sistema es
recomendable utilizar los diagramas de secuencia: “podría argumentarse que
cualquier diagrama de secuencia podría ser modelado como un diagrama de
actividad y viceversa. Sin embargo, dependiendo del modelo, podría encontrarse
una técnica de diagramación más adecuada que la otra. Mientras que los dos
diagramas aparentan brindar la misma información, la forma de expresarla es
completamente diferente. Un diagrama de secuencia se enfoca más en los
objetos y actores involucrados en un sistema y como estos interactúan entre sí.
Un diagrama de actividad, por otro lado, se enfoca en la funcionalidad y los
pasos de una actividad a otra” 54.
54 UML A Beginner’s Guide, Jason T. Roff, , Mc Graw Hill USA, primera edición 2003.
152
Para demostrar la utilidad de los diagramas de secuencia en el diseño de un
workflow, puede tomarse en cuenta el procedimiento detallado para la creación
de una orden de venta, presentado en el capítulo anterior (ver Sección 3.4:
“Caso práctico: Modelado básico”):
Obtener los datos generales del cliente. El sistema exige que toda orden de
venta se pueda asociar con un cliente. Si el cliente no existe, este deberá poder
registrarse durante la toma del pedido (ver Figura 4.30).
153
Figura 4.30: Diagrama de secuencia para la obtención de los datos generales de un cliente.
Obtener el pedido del cliente. El vendedor debe registrar cada uno de los
artículos que el cliente desea adquirir, introducir la cantidad, registrar los precios
unitario, estimar el total y calcular los impuestos (ver Figura 4.32).
Devolver datos de cliente
Vendedor
Interfaz manual
Digitar código de cliente
[orden telefónica]
Catálogo de clientes
Buscar cliente
[clienteexiste]
Inicializarorden deventa condatos declientedevueltos
Solicitar datos al cliente
Devolver código de nuevo cliente
Registrar cliente
Inicializarorden deventa condatos declientedevueltos
154
Figura 4.31: Diagrama de secuencia para la obtención de los datos de pedido de un cliente.
Los mensajes que están condicionados a espacios de tiempo (por ejemplo,
escalar una solicitud de crédito a un Gerente después de tres días de no haber
sido atendida por el analista de créditos) se representan entre llaves, junto a
cada mensaje a la izquierda de la línea de vida o a través de una flecha vertical
descendente desde la primera hasta la ultima actividad de un grupo que debe
Cargar losdatos delartículo enla orden de venta
Devolver datos de artículo
Vendedor
Interfaz manual
Digitar código de artículo
Inventario
Buscar artículo
[artículo sinexistencias]Solicitar datos al cliente
«crear»
Notificar al usuario
Cuadro de Mensajes
Buscar artículossustitutos conexistencias
Devolver artículos
Mostrar artículos sustitutos
Seleccionar artículo sustituto
X«destruir»
Cargar losdatos delartículo sustituto en la orden de venta
* [mientras más artículos pedidos]Totalizar la orden de venta
Ordenes
Guardar la orden de venta
155
ejecutarse en un tiempo no mayor al especificado. Combinando las restricciones
con las iteraciones es posible modelar un procedimiento de notificación
periódico, hasta cierto límite de tiempo. La iteración se terminará tan pronto como
se presente una condición (en nuestro caso, revisar la solicitud de crédito) o
cuando caduque el tiempo estipulado.
4.3 Pruebas de calidad
Se propone clasificar las pruebas de diseño en dos grandes grupos:
Pertinentes a la metodología de modelado. Tal y como se explicó para el
control de calidad del análisis, estas pruebas podrían entenderse como
validaciones sintácticas. Para el caso de este trabajo, deberían estar orientadas
a verificar la aplicación correcta de la metodología propuesta por la OMG para
UML. El responsable de este control debería ser un diseñador distinto del que
elaboró el modelo.
Pertinentes al proceso modelado. En este caso buscaremos garantizar que
las especificaciones del dominio del problema han sido representadas en el
dominio de la solución, de manera completa. Se proponen dos tareas para
validar que las especificaciones de diseño correspondan con los requerimientos
del usuario:
156
Construir una tabla cruzada. En las filas deben listarse las especificaciones de
análisis y en las de diseño. Las intersecciones indicarán qué característica(s) de
diseño corresponde(n) a qué característica(s) de análisis.
Un déficit de especificaciones de diseño seguramente no podrá
satisfacer la necesidad del usuario. Un superávit de especificaciones,
por otro lado, es arriesgado; si nadie puede dar una justificación real
de su inclusión, debe ser considerada como excedente. La reacción
del usuario ante dicho exceso de funcionalidad es impredecible, por
lo que es recomendable que se excluya.
Una vez validada la correspondencia de especificaciones, deberá analizarse la
“completitud” de la correspondencia; es decir, que la(s) especificación(es) de
diseño satisfagan totalmente lo indicado en las especificaciones de análisis.
4.4 Documentación
El resultado de la fase de diseño es un documento que será utilizado por los
responsables de la automatización del workflow para convertir el modelo de
especificaciones del proceso a uno de ejecución. Su contenido está basado en
diagramas.
La estructura sugerida se presenta en la siguiente tabla:
157
Documento: ESPECIFICACIONES DE AUTOMATIZACIÓN
El título del documento debe incluir el nombre del proceso para el cual se presentan los diagramas de especificaciones técnicas.
Capítulo 1: Modelado del flujo de trabajo
Sección 1.1: Diagramas de actividad
Muestra los pasos y puntos de decisión que suceden dentro de un proceso de negocio. Ayudan a entender cómo funcionará el workflow implantado.
Es necesario incluir los siguientes datos:
Elemento Especificaciones
Actividad Nombre
Descripción
Diagrama de secuencia asociado
Transición Eventos
Variables
Guardas
Responsable
Ingeniero de sistemas
Capítulo 2: Modelado de Roles
Sección 2.1: Diagramas de “swimlanes” Responsable
Estructura del diagrama de actividades que permite segregar sus componentes de acuerdo con los responsables de su ejecución.
Es necesario incluir los siguientes datos:
Elemento Especificaciones
Rol Nombre
Descripción
Actores potenciales
Ingeniero de sistemas
158
Capítulo 3: Diagramación de Salidas Reutilizables
Sección 3.1: Diagramas de Estado Responsable
Muestra la evolución que sigue un documento durante la ejecución del flujo de trabajo.
Es necesario incluir los siguientes datos:
Elemento Especificaciones
Estado Nombre
Descripción
Evento de transición
Ingeniero de sistemas
Sección 3.2: Diagramas de Transición Responsable
Modalidad de los diagramas de actividades que incorpora las transiciones de objetos para representar los insumos y productos de las actividades.
Es necesario incluir los siguientes datos:
Elemento Especificaciones
Transición de objeto
Nombre
Atributos
Actividad de origen
Actividad de destino
Ingeniero de sistemas
Capítulo 4: Diagramación de Procedimientos
Sección 4.1: Diagramación Secuencia Responsable
159
Especificación de los procedimientos utilizados por las actividades.
Es necesario incluir los siguientes datos:
Elemento Especificaciones
Mensaje Correlativo
Descripción
Estructura
Tipo
Actor/Objeto origen
Actor/Objeto destino
Ingeniero de sistemas
4.5 Lista de verificación para el diseñador
En la siguiente tabla se presenta una lista de actividades que puede servir como
referencia para la elaboración del plan de trabajo para el diseño del sistema. La
actividad inicial ha sido incluida para entrelazar esta fase con los resultados de la
previa:
Actividad: Presentación del análisis Instrumentos
Reunión de trabajo en la que los Analistas de Negocio exponen el proyecto y los Analistas de Sistemas exponen el documento de especificaciones elaborado.
Se recomienda la participación de:
Gerente de proyecto
Analistas de Negocio
Analistas de Sistemas
Ingenieros de Sistemas
Sesión de grupo
Herramientas
Aplicaciones de oficina
Modelador de procesos
Entregable
Integración del equipo de desarrollo
160
MODELADO DEL SISTEMA
Actividad: Creación de las especificaciones Instrumentos
Conversión de los modelos presentados por los analistas a modelos que puedan ser utilizados para la automatización de los flujos de trabajo. Los siguientes aspectos deben ser considerados:
Flujo de actividades
Roles
Salidas reutilizables
Procedimientos
Diagramas UML:
Actividad
Swimlane
Estado
Transición
Secuencia
Herramientas
Modelador UML
Entregable
Diagramas UML
Control de calidad
Funcionalidad
Completitud
4.6 Factores de éxito para el diseño
Entre los elementos que deben tomarse en cuenta para garantizar que el diseño
será realizado de manera adecuada se encuentran:
Capacitación del equipo de desarrollo. El personal responsable de esta fase
debe ser inducido de manera formal tanto a la tecnología workflow como a las
instrumentos de modelado proporcionados por UML.
161
Uso de herramientas de modelado. La extensión y complejidad de los
diagramas de diseño hacen que estos sean propensos a fallas. Es
recomendable que la validación sintáctica sea dejada a una aplicación
especializada. Adicionalmente, el entorno de trabajo permite simplificar la
construcción, extensión y modificación de modelos, reducir el tiempo requerido.
Considerar el entorno de automatización. Como se comentó durante la
exposición de la metodología, no todos los WfMS brindan soporte a la totalidad
de patrones que suelen presentarse en un workflow. El diseñador no puede
elaborar sus modelos al margen de las facilidades que brinde la herramienta de
implantación.
El primero se refiere al grupo de trabajo, debiendo ser personal altamente
técnico capaz de traducir las necesidades de negocio a soluciones de
información. Además de tener amplio conocimiento sobre la herramienta base
para la metodología, UML.
El segundo factor se refiere a las características del equipo y herramientas que
tengan como recurso los diseñadores, ya que de estos depende gran parte de la
calidad, preescisión y rapidez con que se entreguen resultados.
162
Por ultimo tenemos detalles que no son directamente manejados por el grupo,
pero marcan una diferencia en el que y como se hace el trabajo, ya que de estos
depende la calidad de datos que se están procesando.
163
5 Consideraciones y recomendaciones
5.1 Integración del equipo de análisis y diseño
Un proyecto de implantación de workflow debe estar integrado por participantes
que cumplan los siguientes roles:
Especialistas de negocio. Estas personas comprenden los procesos de la
organización y sus reglas, velan por el contenido de los documentos y
comprenden su valor para el negocio.
Especialista en colaboración. Están familiarizados con estándares y
protocolos de esta área. Su capacidad para comprender aspectos técnicos les
permite leer una abstracción de alto o de bajo nivel de un proceso de negocio.
Especialistas en tecnología. Suelen integrarse durante el diseño de las
aplicaciones, aunque no es raro que participen durante el análisis para evaluar la
factibilidad de algunas soluciones o para exponer aspectos técnicos que faciliten
la estructuración de las mismas. Cuentan con la capacidad para implantar un
proceso, ejecutarlo y monitorearlo.
164
Durante los capítulos anteriores se ha sugerido el nombramiento de Analistas de
Negocio, Analistas de Sistemas e Ingenieros de Sistemas, cumpliendo los roles
de especialistas de negocio, colaboración y tecnología, respectivamente. Sin
embargo, es posible que los puestos mencionados no existan de igual manera
en una empresa, por lo que la afinidad con los roles podría servir como un criterio
de selección para los miembros del equipo.
Es inevitable que durante el modelado de los sistemas existan brechas de
oportunidad para que se presenten inconsistencias entre lo requerido por el
usuario y lo entregado por los diseñadores al equipo de programación. El papel
de los especialistas en colaboración es fundamental durante todo el proceso,
pues son los únicos que conocen tanto la terminología del negocio como la
relacionada con los aspectos técnicos.
Existen otras personas que podrían participar, dependiendo de la complejidad
del problema y de los recursos disponibles en la empresa. Entre ellas se
encuentran:
Los administradores de proyecto.
Los documentadores de sistemas.
Los auditores de calidad.
165
No existe una formula universal para deducir el número de especialistas de cada
tipo. Los factores que impactan esta decisión incluyen la extensión del sistema,
el tiempo de entrega, la experiencia previa del personal, el presupuesto
asignado y las herramientas que se utilizarán para modelar y construir el
sistema. Jim McCarthy, Jefe de Desarrollo de Microsoft Visual C++, en su obra
“Dynamics of Software Development”55, publicada por Microsoft Press, comenta:
“un error común de muchos Gerentes de Desarrollo, es contratar solo
programadores o contratarlos en números desproporcionados con respecto al
resto del equipo. [...] en mi grupo, la proporción es normalmente algo como seis
programadores, dos o tres personas de control de calidad, un jefe de
programación y dos técnicos de documentación. La proporción varía a lo largo
de toda Microsoft y probablemente será diferente a la de su equipo. Pero resulta
poco probable que se logren resultados aceptables con algo más que dos
programadores por cada persona de control de calidad”.
Si revisamos la estructura del equipo de Microsoft para adaptarla a un proyecto
de implantación de workflow concluiremos que:
Es recomendable segregar la función del analista, pues su enfoque se
encuentra mucho más orientado a aspectos de negocio que técnicos.
55 Primera edición, 1995.
166
Las funciones de diseño y programación podrían ser desempeñadas por un
mismo técnico, ya que dependiendo de lo sofisticado de las herramientas de
modelado su labor podría verse reducida.
El control de calidad debe ser realizados por personas distintas a los
programadores.
5.2 Utilización de herramientas CASE
En el contexto de workflow, una herramienta CASE tiene por objetivo reducir la
brecha que existe entre los modelos de procesos de negocio en el dominio del
problema y el dominio de la solución. Las organizaciones necesitan de una
herramienta que permita reduzca las barreras de comunicación entre los
lenguajes de negocio y técnico. Existen varias opciones disponibles en el
mercado; en esta sección se presentan dos alternativas para mostrar la utilidad
que brindan en el ciclo de vida de workflow: IBM Holosofx56 y Lotus Workflow.
5.2.1 IBM Holosofx
Atiende la necesidad de facilitar la comunicación entre usuarios y técnicos,
proporcionando un espacio de trabajo común que permite a las empresas
transformar el contenido de negocio a IT y viceversa (ver Figura 5.1).
56 Durante la elaboración del trabajo IBM liberó el producto con el nombre WebSphere Business Integration Modeler.
167
Figura 5.1: Área de trabajo común para los expertos del negocio y profesionales IT.
El entorno consiste de tres componentes interdependientes:
Workbench . Utilizado para la modelación de procesos de negocio. Incluye una
herramienta para la conversión a UML.
Monitor. Utilizado para supervisar los procesos implantados en tiempo real a
través de simulaciones.
Server. Utilizado para compartir la información de procesos a través de Internet.
168
Se basa en una metodología denominada CBPM57, concepto que consiste en
continuamente analizar y mejorar un proceso de negocio. El análisis y diseño
propuestos en el presente se basa en este ciclo de vida.
El enlace entre IT y el negocio, es una de las características más importantes de
la herramienta. Utiliza UML para modelar los sistemas, sus elementos y
componentes. Los modelos de negocio son resueltos utilizando BPM58, enfoque
para el diseño de procesos que será explicado más adelante. Al momento de
generar las “transformaciones”, el CASE trabaja de manera transparente para el
diseñador.
A partir del modelo UML, se permite su exportación a MQSeries Workflow59, un
sistema de administración de flujos de trabajo (WfMS) que también ha sido
desarrollado por IBM. El workflow es exportado utilizando FDL60, a partir del cual
puede iniciarse la ejecución, durante la cual se asignan las tareas individuales a
las personas indicadas y se inician las interacciones con las aplicaciones del
negocio.
57 Continuous Business Process Management. 58 Business Process Management. 59 Durante la redacción de este documento, IBM anunció el nuevo nombre comercial de esta herramienta como WebSphere MQ Workflow. 60 Flowmark Definition Language. Flowmark es el WFMS predecessor de MQSeries Workflow. Este mismo formato de exportación es utilizado por IBM Holosofx para BPM al preparar el workflow que será publicado en MQSeries Workflow.
169
Figura 5.2: Fases de requeridas por MQSeries Workflow.61
Las soluciones IBM Holosofx y MQSeries Workflow se encuentra basada tanto
en estándares62 de la industria y como en tecnologías propietarias.
5.2.2 Lotus Workflow
Esta herramienta ha sido diseñada como un conjunto de bases de datos de
Lotus Domino® y programas para entornos Microsoft Windows, que permiten a
las organizaciones planificar, programar, controlar, supervisar un proceso de
negocio.
El producto se basa en la transportación de portafolios (ver Figura 5.3),
contenedor lógico compuesto por:
61 MQSeries Workflow for Windows NT for Beginners, Dieter Wackerow, International Technical Support Organization, primera edición 2002. 62 IBM es patrocinador de la WfMC.
170
Una cubierta, que contiene información general a cerca del trabajo que sé esta
transfiriendo.
Un documento principal, que contiene la información relevante para el workflow.
Documentos opcionales, con información relacionada al documento principal y
que ayuda a comprender mejor el trabajo.
Figura 5.3: Estructura de un portafolio.63
Las actividades (ver Figura 5.4) son aquellas por las cuales se desplazan los
documentos que forman parte del portafolio, cuentan con un propietario y
pueden estar comprendidas por una o varias tareas, que describen el trabajo que
debe de realizarse sobre los documentos.
63 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
Cubierta
Carpeta
Documento principal
Contenido principal del caso de negocio
Documentos de carpeta
Contenido adicional
Información relacionada con
workflow
Cubierta
Carpeta
Documento principal
Contenido principal del caso de negocio
Documentos de carpeta
Contenido adicional
Información relacionada con
workflow
Portafolio
171
Figura 5.4: Actividades y tareas.64
Los documentos fluyen a través de transiciones (ver Figura 5.5), las cuales
definen el camino que deben seguir, y pueden ser:
Obligatorias. Siempre se deberá ejecutar la actividad subsiguiente.
Condicionales. Existen caminos alternos que dependen de ciertas
características de los documentos.
64 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
Actividad A
Actividad B
Actividad C
Tarea XTarea YTarea Z
Tarea QTarea RTarea S
Tarea KTarea LTarea M
Persona A
Persona B
Persona C
Actividad A
Actividad B
Actividad C
Tarea XTarea YTarea Z
Tarea QTarea RTarea S
Tarea KTarea LTarea M
Persona A
Persona B
Persona C
172
De opciones múltiples. Cuando el usuario es libre de seleccionar el camino que
puede seguir y cuenta con más de dos posibilidades.
De opciones exclusivas. Cuando solo existen dos caminos a seguir y es el
usuario el que toma la decisión.
Figura 5.5: Transiciones entre actividades.65
La herramienta cuenta con tres componentes esenciales:
Arquitect. Este es un programa de Windows en el cual se diseñan los procesos
y se indica como parte del diagrama de workflow:
Las actividades
Relaciones de transferencia
Puntos de decisión
El trabajo que debe realizarse en los documentos
65 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
173
Engine. Este esta integrado por cuatro bases de datos principales que
constituyen el mecanismo de operaciones. Estas son las que están activas
cuando se realizan los trabajos.
Figura 5.6: Base de datos que componene el motor de Lotus Workflow.66
La de aplicación es la que se encuentra de cara a los usuarios, por lo
tanto, es la que se utiliza para crear los trabajos, ejecutar tareas, ver los
estados y progreso, etc. La del directorio, es en la que se almacena una
estructura de la empresa que estará involucrada en el workflow. Se
organiza en departamentos, jefes, empleados, personal de staff, grupos
de empleados, roles, sustitutos, relaciones y propiedades del trabajo. La
de Almacén, es donde se guardan todos los procesos para poder ser
llamados a ejecución o por el contrario guardarlos como parte de una
bitácora histórica
66 Using Domino Workflow, Soren Peter Nielsen, IBM Corporation ITSO, Primera edición 2000.
ApplicationApplication DirectoryDirectory
DesignDesign ProcessProcess
Aplicación
Diseño
Directorio
Procesos
ApplicationApplication DirectoryDirectory
DesignDesign ProcessProcess
Aplicación
Diseño
Directorio
Procesos
174
Viewer (Visor de Lotus Workflow). Es una aplicación que ofrece una
representación gráfica global de las actividades anteriores, actuales y posteriores
de un trabajo. Lotus workflow también cuenta con el “Lotus Workflow Web
Viewer”, que es una versión para Web del mismo, con la mayoría de sus
funciones.
Lotus workflow tiene bases de datos que son opcionales, estas son:
Base de datos de archivado. Se almacena toda la información referente a los
trabajos que han sido finalizados.
Base de datos de registro. Se almacena información referente a todas las
acciones que se presentaron durante la ejecución de las actividades.
Para ayudar a comprender metodología propuesta (Ver siguiente Tabla), se
presenta a continuación un recorrido de alto nivel del proceso que debe seguirse
para la creación de un workflow.
Fase 1. Modelado de la organización
Descripción: Esta actividad se lleva a cabo en la base de datos de directorio, a través de una interfase de alto nivel en la cual se define la organización por medio de definiciones de personas, departamentos y grupos.
175
En los documentos de definición de personas o participantes se determinan los datos siguientes:
Nombre. Usuario que tiene una participación activa dentro del workflow.
Departamento. Nombre del departamento al que pertenece el involucrado.
Grupos. Nombre de los grupos de los que forma parte el usuario.
Roles. Nombre de las tareas que puede ejecutar el usuario.
En los documentos departamento se define los datos:
Nombre del departamento.
Director del departamento. Este usuario es el receptor de todas las notificaciones relacionadas al grupo.
Jerarquía. Posición que ocupa el Departamento en la organización.
Miembros. Conjunto de usuarios que forman parte de cada una de las unidades organizativas.
En los documentos de grupo se puede definir esta información:
Director. Al igual que en los departamentos, es la persona que recibe todos los mensajes con relación al grupo.
Miembros. Lista de usuarios que ya tiene su documento como personas. A diferencia de los departamentos, una persona puede pertenecer a más de un grupo.
Sustitutos. Lista de usuarios o grupos que pueden realizar las mismas funciones que los usuarios titulares del grupo, pero solo entran en función cuando uno de los miembros no puede ejecutar las tareas asignadas.
Actividad 2. Modelado del entorno de trabajo
Descripción: En este modelo se genera un documento denominado: “calendario”. Este documento contiene la siguiente información:
176
Día festivo. Fecha exacta del día festivo.
Horario de trabajo. Horario de atención a los usuarios para los días ordinarios.
Días de la semana. Espeficación de que días que se labora dentro de la organización.
Actividad 3. Modelado del proceso
Descripción: En la interfase de alto nivel del Lotus Workflow Architect, se modela el workflow que se desea programar con ayuda de elementos de diagramación, tales como: actividades, actividades automatizadas, conectores, decisiones, etc.
Cada uno de los elementos diagramados, contiene documentación y configuración.
Por ejemplo, la documentación y configuración que puede ser integrada como parte de una actividad tenemos:
Para las actividades que forman parte del workflow, las propiedades que pueden ser configuradas son:
Nombre. Indentificador de la actividad.
Propietario. Nombre del usuario que puede administrar la actividad.
Tareas. Listado de las tareas que deben de realizarse antes de dar por finalizada la actividad.
Formulario. Documento que contiene la información que se desea por parte del usuario para que sea completada o lo ayude para una toma de decisiones.
Intervalo. Periodo de tiempo que debe durar esta actividad (puede expresarse en minutos, horaso en días).
Descripción. Sumario que explica la actividad, sus
177
objetivos y metas.
Actividad 4. Prueba y activación de proceso
Descripción: Una vez terminado el proceso, se puede generar una prueba para comprobar la eficiencia del mismo o tratar de identificar las fallas.
La activación del proceso se realiza desde el Lotus Workflow Architect, aunque el proceso activado se almacenará en la base de datos de procesos luego de haber comprobado que el worklfow esta funcionando correctamente, de lo contrario la empresa deberá considerar la revisión a cada uno de los procesos dañados.
Actividad 5. Iniciación de trabajos
Descripción: Los trabajos que se desean generar dentro del workflow, se deben activar desde la interfase para usuario final que se encuentra en la base de datos de la aplicación. La activación de un workflow puede ser de alguno de estos tipos: manual, automática, por procesos o eventos externos.
AplicaciónAplicaciónAplicaciónAplicaciónAplicaciónAplicación
178
5.3 Variaciones al modelo de análisis y diseño
5.3.1 BPM67
Ya la filosofía de Holosofx se resumió en la Sección 5.2 de este capítulo.
Básicamente, la formula propuesta es BPM + UML. Ambos conceptos
constituyen estándares de la industria y son adecuados para el modelado de
soluciones de workflow. Aunque no ha sido necesario entender BPM para
exponer la metodología de análisis propuesta en este trabajo, se considera
importante ampliar su concepto.
En un artículo publicado en eAI Journal, en noviembre de 2002, titulado
“Business Process Modeling Language (BPML): Automating Business
Relationships”68, se define BPM como “un paradigma que permite separar la
descripción lógica de un proceso de los detalles de su implantación. […] BPM
parte del análisis de los procesos a través de los cuales una empresa hace
negocios. Una vez que el diseño subyacente a estos procesos se ha
comprendido, las empresas pueden tomar acciones para depurarlo y mejorarlo,
o aplicar tecnología para automatizarlo”. En términos de BPM, un proceso “se
refiere a múltiples actividades separadas pero relacionadas. Este automatizado
cuentan con una interfaz a sistemas que permiten llevar a cabo muchas de sus
tareas de manera rápida, al tiempo que se reducen los errores”.
67 Business Process Management – Administración de Procesos de Negocio. 68 Jeanne Baker, página 27.
179
“Workflow hace referencia únicamente al subconjunto de BPM en la que se
involucra la colaboración humana, roles, actividades basadas en la organización
y procesos de larga duración”.
La BPMI.org69, responsable de coordinar la liberación de estándares para BPM,
propone una notación gráfica (BPMN70) para expresar procesos de negocio en
un diagrama (BPD71), incluyendo la posibilidad de representar eventos, tareas,
subprocesos, decisiones, flujos, mensajes y swimlanes. Existen elementos
orientados a facilitar el modelado de un workflow, entre los cuales se encuentran
los desencadenadores, responsables de dar inicio a un proceso.
Por ejemplo, si una persona debe resumir el resultado de una discusión en un
foro siete días después de iniciado, la porción del BPD que representa dicha
situación sería:
69 Business Process Management Initiative – Iniciativa para la Administración de Procesos de Negocio, 70 Business Process Modeling Notation – Notación para el Modelado de Procesos de Negocio. 71 Business Process Diagram – Diagrama de Proceso de Negocio.
180
Figura 5.7:Diagramación de una actividad con temporizador72
Otro aspecto interesante es que el manejo de decisiones puede basarse en
datos o eventos. Las primeras son las más comunes y son conocidas solamente
por el nombre de Decisión. Las basadas en eventos esperan a que suceda
alguno que haya sido especificado para continuar, tal como se muestra:
Figura 5.8: Bifurcación basada en eventos.73
Finalmente, las estructuras para agrupación de tareas en subprocesos permite la
modelación de situaciones inusuales, tales como los procesos ad-hoc, en los
72 Business Process Modeling Notation Working Draft (0.9), Stephen A. White, Business Process Management Initiative (BPMI), primera edición 2002. 73 Business Process Modeling Notation Working Draft (0.9), Stephen A. White, Business Process Management Initiative (BPMI), primera edición 2002.
Mensaje C
Mensaje D
1 Día
Revisar discusión
Moderar correos de discusión
181
cuales el orden de ejecución de las tareas no es relevante y dependerá
completamente de los participantes, ya que no existe forma alguna de predecir la
secuencia.
Un proceso ad-hoc colapsado se representaría como una “actividad” más del
diagrama, utilizando la siguiente notación:
Figura 5.9: Porceso ad-hoc colapsado.74
Al expandir el proceso se vería un conjunto de actividades separadas, sin
relaciones de dependencia entre sí:
Figura 5.10: Proceso ad-hoc expandido.75
El modelo resultante es exportado a un lenguaje que es parte de las
especificaciones propuestas y proporciona un modelo abstracto para expresar
procesos de negocio ejecutables.
74 Business Process Modeling Notation Working Draft (0.9), Stephen A. White, Business Process Management Initiative (BPMI), primera edición 2002.
75 Business Process Modeling Notation Working Draft (0.9), Stephen A. White, Business Process Management Initiative (BPMI), primera edición 2002.
182
Los equipos de análisis y diseño deben tomar en cuenta el soporte que brindan
las herramientas de modelado a los estándares propuestos por la BPMI.org.
Debido a que la especificación publicada actualmente se encuentra en su
primera versión, es posible que no sea un factor determinante el que estas se
apeguen completamente. Sin embargo, en la medida que las metodologías
utilizadas se orienten a los conceptos presentados por el enfoque de BPM, el
proceso por incorporar sus beneficios se agilizará.
5.3.2 Diagrama de Estado – Actividad (DEA)
5.3.2.1 Concepto
Esta propuesta no constituye una metodología, sino un instrumento para el
diseño de procesos. Es respaldada por la empresa Lithium Software76 y se
encuentra basada en conceptos de UML, aunque no debe considerarse una
extensión aprobada del estándar. El objetivo de exponerlo es brindar a los
diseñadores de una opción de modelado para proyectos de pequeña escala.
La siguiente tabla muestra las consideraciones y recomendaciones que deben
tenerse en cuenta al momento de utilizarla:
76 Lithium Software es una empresa uruguaya dedicada a la consultoría y desarrollo de sistemas informáticos, especializada en sistemas de workflow y bases de datos documentales fundada en el año 2001. Entre los productos fabricados por esta empresa se encuentra el Sistema de Administración de Workflow (WFMS) llamado DocFlow 2.1, orientada a la automatización de los procesos de negocios (flujos de aprobación, toma de decisiones, administración de documentos, etc.). La herramienta brinda la capacidad de monitorear los procesos de negocio, administrarlos, obtener estadísticas importantes y detectar cuellos de botella para realizar estudios más profundos para su optimización.
183
Metodología Consideraciones Recomendaciones
UML Ampliamente documentada
Apoyo a la mayoría de
patrones de workflow
Estándar de la industria
Múltiples opciones de CASE y
herramientas de modelado
Curva de aprendizaje baja a
media
Considerarla como la primera
alternativa de solución
Utilizarla para proyectos de
mediana a gran escala
DEA Documentación limitada
Apoyo restringido a pocos
patrones de workflow
Propietario (Lithium Software)
Opción única de CASE
(Lithium Software DocFlow)
Curva de aprendizaje baja
Aunque los modelos
resultantes no son reconocidos
por las herramientas
estándares, la simplicidad y
facilidad de uso lo hacen ideal
para proyectos pequeños
Consideraciones y recomendaciones para la selección de la metodología de diseño.
La propuesta consiste en utilizar los siguientes elementos para la modelación de
los procesos:
Elemento Descripción
Actividad Representa el trabajo a ser realizado por un
participante dentro de un proceso.
184
Estado
Representa los datos del sistema conjuntamente
con la condición de los mismos.
Es importante que al habla de Documento se
hace referencia a cualquier tipo de datos de un
proceso, y no solamente a aquellos almacenados
de forma documental. La segunda parte del
nombre de este elemento (state) hace referencia
al estado de los datos representados por el
documento.
Participante
Representa a los involucrados en un proceso de
workflow. Se distinguen dos tipos de ellos:
Participante Usuario: Recurso humano definido
con acceso al sistema, es decir un usuario.
Participante Sistema: Recurso no humano que
participa. Es importante aclarar que para sea
considerado un participante en un proceso, éste
debe realizar alguna actividad en el mismo, es
decir, debe tener un papel activo.
Conectores
Los conectores representan las transiciones de un
proceso, en los diagramas de actividad
representan el pasaje del hilo de ejecución de una
actividad finalizada (actividad de salida) hacia la
próxima a efectuarse (actividad de llegada). En
los diagramas de estados representan el pasaje
de parte o toda la información de la instancia del
185
proceso de un estado a otro.
Conectores automáticos
(conectores de tiempo)
Representan transiciones dentro un proceso y
son aquellos en los cuales la condición lógica es
exclusivamente una condición temporales
evalúen variables de tiempo.
Ejes de flujo
Representan las bifurcaciones (split) y las uniones
(join) del proceso. Los mismos son usados en
combinación con los conectores.
Elementos de los diagramas estados - actividad (DEA)77.
En adición a los elementos de diagramación de la tabla anterior, se utilizan las
siguientes relaciones de construcción78:
Relación de construcción (Eje de
flujo)
Descripción
77 Definiciones transcritas literalmente de las propuestas por Lithium Software para la creación de un DEA. 78 Definiciones transcritas literalmente de las propuestas por Lithium Software para la creación de un DEA.
186
AND Bifurcación
Se utiliza para señalar un sentido de
totalidad, es decir el proceso sigue en
paralelo por todas las transiciones que
sigan al AND.
AND Unión
Se utiliza para señalar un sentido de
totalidad, es decir, el proceso sigue
luego del AND si y solo si todas las
transiciones anteriores han sido
ejecutadas.
OR Bifurcación Se utiliza para señalar un sentido de
unicidad, es decir el proceso sigue por
una y solo una de las opciones que
siguen al OR. Junto a cada bifurcación
que se deriva del OR deberá indicarse
la condición a satisfacer.
OR Unión
Se utiliza para señalar un sentido de
unicidad, es decir, el proceso sigue
luego del OR si cualquiera de las
transiciones anteriores es ejecutada.
187
AND Exclusivo
Se utiliza para señalar un sentido de
totalidad y posterior seguimiento
exclusivo. Esto significa que el
proceso, en principio, sigue en
paralelo por todas las transiciones
salientes del AND/E, pero después de
que alguna haya terminado el resto
son anuladas.
OR Exclusivo
Se utiliza para señalar un sentido de
unicidad y posterior exclusividad, es
decir, el proceso sigue luego del OR/E
si cualquiera de las transiciones
anteriores es ejecutada y a todas las
restantes transiciones que llegan al
OR/E se les anula el hilo de ejecución
una vez ejecutada la transición.
Fin de Hilo de Ejecución
Este elemento que un hilo de
ejecución ha terminado dentro de la
instancia de un proceso.
Relaciones de Construcción para los DEA79.
En términos de un diagrama de actividad, una bifurcación permite que inicie un
proceso paralelo y una unión permite que los procesos paralelos se consoliden
en un flujo de proceso único. Cuando una bifurcación es encontrada cada rama
79 Definiciones transcritas literalmente de las propuestas por Lithium Software para la creación de un DEA.
188
es, en esencia, un diagrama de actividad independiente. Ninguno de los flujos de
control debe esperar por el otro al menos antes de llegar a una unión.
Tanto las bifurcaciones como las uniones son representadas con una línea
gruesa negra. Las primeras tienen una transición entrante y dos o más salientes.
Las segundas, por otro lado, tienen dos o más transiciones entrantes y una sola
transición saliente. El diagrama DEA cambia la línea negra por operadores
lógicos de bifurcación / unión, logrando el siguiente efecto:
Eje de flujo DEA Diagrama de actividad
AND Bifurcación Bifurcación
AND Unión Unión
OR Bifurcación Decisión/[guarda]80
OR Unión No existe solución posible
AND Exclusivo Encaminamiento paralelo alternado
OR Exclusivo Discriminador
No existe solución posible Unión N-de-M
No existe solución posible Múltiples instancias que requieren sincronización
No existe solución posible Selección diferida
No existe solución posible Productor-Consumidor con actividad de terminación
80 Indica la condición que debe satisfacerse para seguir con una transición.
189
No existe solución posible Productor-Consumidor con cola saturada
Relación entre los DEA y los diagramas de actividad.
Como podrá verse, aunque la idea de combinar los diagramas de actividad con
los de estado es atractiva, debido a la falta de soporte para la totalidad de
patrones de workflow, los DEA no pueden convertirse en la herramienta única de
diagramación. Lamentablemente, se ha sacrificado la funcionalidad por hacer un
énfasis excesivo en la simplicidad. Aparentemente se olvida que el diagrama se
desarrolla en el ámbito de las funciones del diseño de sistemas, donde la mayor
parte de involucrados son especialistas en informática, y no como parte de las
funciones de análisis, donde la participación de los usuarios finales es clave.
5.3.2.2 Ejemplo
Para demostrar el uso de los DEA, se modela un pequeño flujo de trabajo,
orientado a la compra de insumos, en el cual:
Un empleado hace una solicitud de materiales por varios artículos.
La solicitud debe ser autorizada por la Gerencia.
Los artículos deben ser buscados primero en los inventarios de la empresa y, de
no haber existencias, podrán ser comprados a un proveedor.
190
Durante las distintas actividades la solicitud de materiales (SM) sufre
transformaciones, producto de los datos que se van incorporando en cada
actividad. El diagrama seria:
Figura 5.11: Integración de actividades, participantes y estados-de-documento.81 .
Si quisiéramos seguir utilizando los constructos disponibles para los diagramas
de actividad, el diagrama resultante sería:
Figura 5.16: Diagrama DEA utilizando consturctos.82
Aunque la incorporación de los roles dentro de la actividad facilita la lectura, no
compensa la facilidad de agrupar funciones presentada por un Swinmane, por lo
81 Arquitectura de procesos para modelos de Workflow, Pablo Morales, Lithium Software, Montevideo – Uruguay, primera edición 1993. 82 Arquitectura de procesos para modelos de Workflow, Pablo Morales, Lithium Software, Montevideo – Uruguay, primera edición 1993.
191
que puede modificarse la forma de presentar esta información. Una ventaja de
los DEA es el espacio requerido para la diagramación.
192
Glosario
C
CASE. Acrónimo de Computer Aided Sofware Engineering (Ingeniería de
Software Asistida por Ordenador). Herramienta de ingeniería de software que
abarca todas las etapas del ciclo de vida de un sistema de información.
Confiabilidad. Es la probabilidad de que un sistema de software no causara la
falla del sistema durante un tiempo especificado bajo condiciones especificadas.
Corrección. Ver correctitud.
Correctitud. El Glosario Estándar de IEEE de la Terminología de Ingeniería de
Software define correctitud en términos de estar libre de fallas, de satisfacer los
requisitos especificados y satisfacer las necesidades y expectativas del usuario.
Bertrand Meyer, en su libro “Construcción de Software Orientado a Objetos”,
llama a este término corrección, definiéndolo como “la capacidad de los
productos de software para realizar con exactitud sus tareas, tal y como se
definen en las especificaciones”.
193
D
Defecto. Es la causa mecánica o algorítmica de un error.
Dinámica organizacional. La dinámica organizacional explica y relaciona los
procesos por los cuales las organizaciones producen y regulan sus actividades
dentro y fuera de las mismas, pensando el dentro y el afuera con un cierto grado
de indeterminación, en concordancia con la permeabilidad y difusión de los
límites organizacionales e interorganizacionales, que caracterizan a los sistemas
abiertos.
E
Error. Significa que el sistema esta en un estado tal que el procesamiento
adicional del sistema conducirá a una falla.
F
Falla. Es cualquier desviación del comportamiento observado con respecto al
especificado.
H
Hardware. La Academia recomienda "equipo(s)". En general se puede usar
"equipamiento". Se propuso en tiempos "soporte físico", pero el término es
194
probablemente inerradicable, pues ninguna de las traducciones es totalmente
satisfactoria.
I
IEEE. (Institute of Electrical and Electronics Engineers, Inc., Instituto de
Ingenieros en Electricidad y Electrónica, Inc.) Es una sociedad profesional con
membresía en todo el mundo. Se empeña en actividades técnicas educacionales
y profesionales que promueven la teoría y la practica de la electro tecnología
para el desarrollo personal y profesional de sus miembros. Fomenta el
conocimiento y los avances científicos y tecnológicos, los cuales, miembros del
IEEE transforman en productos prácticos y seguros y en procedimientos que
engrandecen la calidad de vida.
Integridad. Es la capacidad de los sistemas de software para proteger sus
diversos componentes contra modificaciones no autorizadas.
M
Middleware. Es el software de conectividad que consiste en un conjunto de
servicios habilitadores que permiten interactuar a múltiples procesos que se
ejecutan en distintas maquinas a través de la red.
195
Desde hace tiempo el termino Middleware se escucha dentro del mundo de la
Informática y con mayor fuerza dentro del campo de las Tecnologías de la
Información, sin embargo, el mismo no ha tenido un significado concreto.
Las arquitecturas Cliente/Servidor clásicas están dejando paso a nuevas
infraestructuras en las cuales aparecen nuevos conceptos como la distribución
en n-capas, en las que los diferentes Middleware han tomado una importancia
vital.
Tanto es así que en las aplicaciones actuales, la comunicación de datos se han
convertido en un factor crítico.
Los Middleware representan dentro de las arquitecturas Cliente/Servidor un
nuevo enfoque de las mismas, permitiendo la interconexión de aplicaciones entre
muy diversos entornos y a través de diferentes lenguajes de programación.
De igual modo proporcionan la posibilidad de la incorporación de los nuevos
conceptos de escalabilidad y seguridad, dentro de arquitecturas abiertas,
basadas en diferentes estándares, todo ello desde el punto de vista del
paradigma de la Orientación a Objetos.
196
Dentro de este mundo, cada fabricante ofrece diferentes soluciones de
interconexión, algunos ejemplos de las mismas pueden ser CORBA soportado
directamente por la OMG, RMI de Sun Microsystems, etc.
Modelización. Acto de elaborar una o más representaciones gráficas de un
sistema. La Figura resultante representa las necesidades planteadas por los
usuarios en cuanto a datos, procesos y redes desde un punto de vista de
empresa.
O
Objeto de negocio. En el entorno de la solución, es una analogía para los
objetos que se encuentran en el entorno del problema. Tienen ciertos atributos y
determinados comportamientos. Un ejemplo puede ser la cuenta de un cliente en
la empresa, representada por un saldo y sujeta a depósitos y aplicación de
intereses.
P
Pre-condición. Una expresión lógica que es evaluada por un WFMS para
decidir si una instancia de un proceso o actividad es iniciada cuando una
instancia de un proceso es iniciada.
197
Post-condición. Una expresión lógica que es evaluada por un WFMS para
decidir si una instancia de un proceso o actividad es iniciada cuando una
instancia de un proceso es terminada.
Procedimiento. Forma específica de desempeñar una actividad.
Proceso. Serie de recursos y actividades interrelacionadas que transforman
entradas en salidas.
R
Robustez. Es la capacidad de los sistemas de software para reaccionar
apropiadamente ante condiciones inesperadas (excepciones).
S
Seguridad. Es la capacidad de los sistemas de software para proteger sus
diversos componentes contra accesos no autorizados.
Sistema. Grupo de elementos que se integran con el propósito común de lograr
un objetivo.
Software. La Academia recomienda "programa(s)" o "programación". Se
propuso en tiempos "soporte lógico", pero el término es probablemente
inerradicable pues ninguna de las traducciones es totalmente satisfactoria.
198
T
Transacción. Cualquier suceso o actividad que afecta a toda la organización
(facturación, entrega de mercancía, pago a empleados, depósito de cheques y
otras). Los tipos de transacciones cambian en cada una de las diferentes
organizaciones.
199
Anexos
Notación básica de UML
La siguiente información constituye una guía rápida que ayuda a conocer los
conceptos básicos de diagramación de UML, con el objetivo de asistir en la
lectura de los diagramas incluidos en este trabajo. Si se desea conocer la
especificación completa, se recomienda visitar el sitio Web http://www.uml.org, a
cargo del Object Managemet Group, un consorcio sin fines de lucro que da
mantenimiento a esta y otras especificaciones de dominio publico.
El resumen presentado también se encuentra disponible en
http://www.cs.ualberta.ca/~pfiguero/soo/uml/. De la información disponible la
siguiente resulta pertinente a este trabajo:
Diagramas de Casos de Uso. Un diagrama de Casos de Uso muestra las
distintas operaciones que se esperan de una aplicación o sistema y cómo se
relaciona con su entorno (usuarios u otras aplicaciones). Se muestra como
ilustración los casos de uso de la máquina de café.
200
Caso de uso
Se representa en el diagrama por una elipse, denota un requerimiento
solucionado por el sistema. Cada caso de uso es una operación completa
desarrollada por los actores y por el sistema en un diálogo. El conjunto de
casos de uso representa la totalidad de operaciones desarrolladas por el
sistema. Va acompañado de un nombre significativo. En el caso del
ejemplo se tienen como casos de uso de la cafetera RecibirDinero,
PedirAzucar, PedirProducto, DarVueltas y Cancelar.
Actor
Es un usuario del sistema, que necesita o usa algunos de los casos de
uso. Se representa mediante un, acompañado de un nombre significativo,
si es necesario.
201
Relaciones en un diagrama de casos de uso
Entre los elementos de un diagrama de Casos de uso se pueden
presentar tres tipos de relaciones, representadas por líneas dirigidas entre
ellos (del elemento dependiente al independiente).
Communica (communicates). Relación entre un actor y un caso de uso,
denota la participación del actor en el caso de uso determinado. En el
diagrama de ejemplo todas las líneas que salen del actor denotan este
tipo de relación.
Usa (uses). Relación entre dos casos de uso, denota la inclusión del
comportamiento de un escenario en otro. En el caso del ejemplo el caso
de uso Cancelar incluye en su comportamiento DarVueltas; y
PedirProducto incluye también DarVueltas
Extiende (extends). Relación entre dos casos de uso, denota cuando un
caso de uso es una especialización de otro. Por ejemplo, podría tenerse
un caso de uso que extienda la forma de pedir azúcar, parta que permita
escoger el tipo de azúcar (normal, dietético moreno) y además la cantidad
en las unidades adecuadas para cada caso (cucharaditas, bolsitas o
cucharaditas, respectivamente). Un posible diagrama se muestra a
continuación.
202
Diagrama de secuencia. Un diagrama de secuencia muestra la interacción de
un conjunto de objetos en una aplicación a través del tiempo. Esta descripción es
importante porque puede dar detalle a los casos de uso, aclarándolos al nivel de
mensajes de los objetos existentes, como también muestra el uso de los
mensajes de las clases diseñadas en el contexto de una operación.
A continuación se muestra un ejemplo de diagrama de secuencia, que da
detalle al caso de uso PedirProducto del ejemplo de la cafetera.
Línea de vida de un objeto
203
Un objeto se representa como una línea vertical punteada con un
rectángulo de encabezado y con rectángulos a través de la línea principal
que denotan la ejecución de métodos (véase activación). El rectángulo de
encabezado contiene el nombre del objeto y el de su clase, en un formato
nombreObjeto: nombreClase. Por ejemplo, el objeto m, instancia de la
clase MaquinaCafe envía dos mensajes seguidos para dar respuesta a la
operación PedirProducto: Servir al objeto p de la clase Producto y
DarVueltas a sí mismo.
Activación
Muestra el periodo de tiempo en el cual el objeto se encuentra
desarrollando alguna operación, bien sea por sí mismo o por medio de
delegación a alguno de sus atributos. Se denota como un rectángulo
delgado sobre la línea de vida del objeto. En el ejemplo anterior el objeto
_ingredientes se encuentra activado mientras ejecuta el método
correspondiente al mensaje Servir; el objeto p se encuentra activo
mientras se ejecuta su método Servir (que ejecuta _ingredientes.Servir) y
el objeto m se encuentra activo mientras se ejecuta p.Servir y DarVueltas.
Mensaje
204
El envío de mensajes entre objetos se denota mediante una línea sólida
dirigida, desde el objeto que emite el mensaje hacia el objeto que lo
ejecuta. En el ejemplo anterior el objeto m envía el mensaje Servir al
objeto p y un poco más adelante en el tiempo el objeto m se envía a sí
mismo el mensaje DarVueltas.
Diagramas de estados. Muestra el conjunto de estados por los cuales pasa un
objeto durante su vida en una aplicación, junto con los cambios que permiten
pasar de un estado a otro. Un ejemplo en el caso de la cafetera son los estados
posibles para la clase MaquinaCafe:
205
Estado
Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el
objeto esta esperando alguna operación, tiene cierto estado característico
o puede recibir cierto tipo de estímulos. Se representa mediante un
rectángulo con los bordes redondeados, que puede tener tres
compartimientos: uno para el nombre, otro para el valor característico de
los atributos del objeto en ese estado y otro para las acciones que se
realizan al entrar, salir o estar en un estado (entry, exit o do,
respectivamente). En el caso del ejemplo anterior, se tienen cuatro
estados (EnFuncionamiento, SinCambio, SinIngredientes,
MalFuncionamiento) , en los cuales se desarrollan ciertas acciones al
entrar; por ejemplo, al entrar al estado SinIngredientes se debe realizar la
accion "Indicador SinIngredientes en On".
Se marcan también los estados iniciales y finales mediante los símbolos
de circulo relleno y circulo relleno con circulo concéntrico vació.
Eventos
Es una ocurrencia que puede causar la transición de un estado a otro de
un objeto. Esta ocurrencia puede ser una de varias cosas:
206
Condición que toma el valor de verdadero o falso
Recepción de una señal de otro objeto en el modelo
Recepción de un mensaje
Paso de cierto período de tiempo, después de entrar al estado o de cierta
hora y fecha particular.
El nombre de un evento tiene alcance dentro del paquete en el cual está
definido, no es local a la clase que lo nombre.
En el caso del ejemplo anterior se encuentra nombrado en varias
transiciones el evento userInput, que recibe como parámetro un Button,
para indicar el botón que ha sido presionado por el usuario de la máquina
de café.
Envío de mensajes
Además de mostrar y transición de estados por medio de eventos, puede
representarse el momento en el cual se envían mensajes a otros objetos.
Esto se realiza mediante una línea punteada dirigida al diagrama de
estados del objeto receptor del mensaje. Si tomamos como ejemplo un
207
control remoto que puede enviar órdenes de encender o apagar al
televisor o a la videograbadora se puede obtener un diagrama de estados
como el siguiente:
Los tres aparatos tienen diagramas de estados separados y algunas de
las transiciones del control remoto causan el envío de mensajes
(togglePower) a los otros aparatos.
208
Transición simple
Una transición simple es una relación entre dos estados que indica que
un objeto en el primer estado puede entrar al segundo estado y ejecutar
ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son
satisfechas. Se representa como una línea sólida entre dos estados, que
puede venir acompañada de un texto con el siguiente formato:
event-signature ‘[’ guard-condition] ‘/’ action-expression ‘ ’̂ send-clause
event-signature es la descripción del evento que da a lugar la transición,
guard-condition son las condiciones adicionales al evento necesarias para
que la transición ocurra, action-expression es un mensaje al objeto o a
otro objeto que se ejecuta como resultado de la transición y el cambio de
estado y send-clause son acciones adicionales que se ejecutan con el
cambio de estado, por ejemplo, el envío de eventos a otros paquetes o
clases.
En el caso del ejemplo inicial de esta hoja se tiene una transición entre los
estados IntroduciendoMoneda y SeleccionadoAzucaryProducto que tiene
una transición con el siguiente detalle:
209
userInput( Button ) | [TodoOk=true} / MostrarNivelAzucar,
MostrarProducto
El evento que dispara el cambio de estado es userInput( Button). Se
requiere como condición adicional que no se haya detectado ninguna falla
(TodoOk = true) y se ejecuta MostrarNivelAzucar y MostrarProducto, que
deberían ser ejecutables por el objeto al cual pertenece el diagrama.
Transición interna
Es una transición que permanece en el mismo estado, en vez de
involucrar dos estados distintos. Representa un evento que no causa
cambio de estado. Se denota como una cadena adicional en el
compartimiento de acciones del estado.
Supongamos el estado de una interfaz pidiendo password al usuario. En
este caso puede tenerse una transición interna que muestre una ayuda al
usuario. Esta transición se muestra en el siguiente diagrama con la
cadena "help / display help " dentro del cuerpo del estado.
210
Diagramas de actividades. Un diagrama de actividades es un caso especial de
un diagrama de estados en el cual casi todos los estados son estados de acción
(identifican que acción se ejecuta al estar en él) y casi todas las transiciones son
enviadas al terminar la acción ejecutada en el estado anterior. Puede dar detalle
a un caso de uso, un objeto o un mensaje en un objeto. Sirven para representar
transiciones internas, sin hacer mucho énfasis en transiciones o eventos
externos. Se presenta a continuación un ejemplo de diagrama de actividades
para un mensaje de un objeto. Generalmente modelan los pasos de un
algoritmo.
211
212
Estado de acción
Representa un estado con acción interna, con por lo menos una transición
que identifica la culminación de la acción (por medio de un evento
implícito). No deben tener transiciones internas ni transiciones basadas en
eventos (Si este es el caso, represéntelo en un diagrama de estados).
Permite modelar un paso dentro del algoritmo.
Se representan por un rectángulo con bordes redondeados.
Transiciones
Las flechas entre estados representan transiciones con evento implícito.
Pueden tener una condición en el caso de decisiones.
Decisiones
Se representa mediante una transición múltiple que sale de un estado,
donde cada camino tiene un label distinto. Se representa mediante un
diamante al cual llega la transición del estado inicial y del cual salen las
múltiples transiciones de los estados finales. Un ejemplo se ve en la figura
cuando no hay cafe y se toma una decisión entre hay cola o no hay cola.
213
Bibliografía
Análisis y Diseño de Sistemas
KENDALL, Kenneth
Tercera Edición, 1997
Prentice Hall Hispanoamérica
Análisis y Diseño de Sistemas de Información
WHITTEN, Jeffrey
Tercera Edición, 1997
McGraw-Hill
Arquitectura de procesos para modelos de Workflow
MORALES, Pablo
primera edición, 1993
Lithium Software, Montevideo – Uruguay
Así es la Gestión del Conocimiento
HONEYCUTT, Jerry
Primera Edición en Español, 2001
Microsoft, McGraw-Hill
214
Business Objects, Workflow und die UML
PETERS, Ralf
OBJEKTSpectrum, Número 3, 1999
SIGS-DATACOM Alemania
Business Process Implementation – Building Workflow Systems
JACKSON, Michael
Primera Edición, 1997
Segunda Reimpresión, 1999
Addison-Wesley, USA
ACM Press, USA
Business process management with IBM Holosofx
WALKER, Natalie
Primera edición, 2003
Casaflora Communications, USA
Business Process Modeling Notation Working Draft (0 .9)
WHITE, Stephen A.
Primera Edición, 2002
Business Process Management Initiative (BPMI)
215
Business Process Reengineering and Beyond
HELTON, Allan
Primera Edición, 1995
IBM Corporation, ITSO
Conceptual modeling of workflows
CASATI, F.
Of the 14th International Object-Oriented and Entity-Relationship Modelling
Conference (OOER'95)
Springer Verlag, December 1995
Continuous Business Process Management with HOLOSOF X BPM Suite
and IBM MQSeries Workflow
DEBORIN, Eugene
Primera edición, 2002
IBM International Technical Support Organization
Desarrollo y gestión de Proyectos Informáticos
McCONNELL, Steve
Microsoft Press
216
Primera Edición en Español, 1996
McGraw-Hill, USA
Guía de Redes de Área Extensa
PARNELL, Terè
Primera Edición en Español, 1997
LAN Times, McGraw-Hill
IBM TXSeries for AIX
Documentación de producto para la versión 4.2
IBM Corporation 1997, Transarc Corporation 1997
Information Systems Process Improvement
CASSIDY, Anita
Primera edición, 2001
St. Lucie Press, USA
Ingeniería de Software
SOMMERVILLE, Ian
Sexta Edición, 2002
Pearson Educación México
217
Ingeniería del Software: Un Enfoque Práctico
PRESSMAN, Roger
Cuarta Edición, 1997
McGraw-Hill
ISO 9000, QS 9000, ISO 14000: Normas internacionale s de administración de calidad, sistemas de calidad y sistemas ambienta les
GONZALEZ, Carlos
Primera Edición, 1998
McGraw-Hill
Learning UML – Communicating Software Design Graphi cally
ALHIR, Sinan Si
Primera Edición, 2003
O’Reilly USA
Sistemas de Información Gerencial
McLEOD Jr., Raymond
Séptima Edición, 2000
Prentice Hall
Sistemas de Información Gerencial
218
O’BRIEN, James A.
cuarta Edición, 2001
Irwin McGraw Hill
Tecnologías de Información para la Administración
TURBAN, Efraim
Primera Edición en Español, 2001
CECSA
Tecnologías de la Información y su Uso en Gestión: Una Visión Moderna de los Sistemas de Información
BARROS, Oscar
Primera Edición, 1998
McGraw-Hill
UML Activity Diagrams as a Workflow Specification L anguage
MARLON, Dumas
Primera edición, 2002
University of Tecnology, Australia
UML A Beginner’s Guide
219
ROOF, Jason T.
primera edición, 2003
Mc Graw Hill, USA.
Using Domino Workflow
NIELSEN, Soren Peter
Primera Edición, 2000
IBM Corporation, ITSO
The Workflow Reference Model
HOLLINGSWWORTH, David
Primera Edición, 1995
WFMC
WD, Guide for ISO/IEC 12207 (Software Life Cycle Pr ocess)
ISO/IEC JTC1/SC7, Software Engineering, Secretariat: CANADA (SCC)
Primera edición 1995
Workflow Handbook 2001
220
WILEY, John & Sons
LTD with the Workflow Management Coalition
Primera edición, 2001
Workflow Modeling
SHARP, Alec
Primera Edición, 2001
ARTECH HOUSE, INC.
Sitios web visitados
http://orbita.starmedia.com/~selajp/lecturas/online/medioambiente.htm
http://www.inf.udec.cl/revista/
http://www.dicofr.com/
http://interactif.lemonde.fr/
http://cariari.ucr.ac.cr/
http://www.acm.org/tsc/lifecycle.html
http://www.lithium.com.uy
221
http://tmitwww.tm.tue.nl/research/patterns
http://tmitwww.tm.tue.nl/research/patterns
http//www.verve.com
http://www.versata.com
http://www.sap.com/
http://www.cosa.de y http://www.cosa.nl
http://etna.int-evry.fr/COURS/UML/notation/notation10.html
http://www.lotus.com
http://www.ibm.com